Fix storage port server-side scanning crash 修复服务端扫描仓储端口时崩溃

[WhereisFff]

fix(storage-port): 修复服务端扫描仓储端口时崩溃 (#5137)

• 仅在客户端拾取仓储端口时读取 Ctrl 按键并复制缓存、标记或流体数据，避免服务端扫描加载客户端类。
• fixed [Bug] 玩家在服务器中手持神秘时代（重置）的魔导透镜时对准储存端口即被无限踢出 #5137

[Gugle2308]

已完成核对（PR 状态：opened，未合并；diff 24 行，2 文件 +2/-0；已通过 mclo.gs 原始日志与 1.21.1 mappings 交叉取证）。

---

代码审查摘要 — PR #5140

操作: opened（开放中，未合并）
范围: 2 个文件（均为 Java 逻辑代码，无生成资源）/ +2 −0

变更本质

在 StoragePortBlock#getCloneItemStack（base 第 81 行）与 StorageFluidPortBlock#getCloneItemStack（base 第 68 行）的 Ctrl 判断链最前面插入 && realLevel.isClientSide，使 Screen.hasControlDown() 在服务端被短路，永不触发客户端类加载。

崩溃链路复核（issue #5137 / mclo.gs/8zamqcq，实测日志）

Thaumcraft(tc4port) ThaumometerObservationSystem.onPlayerTick:33
  → ScanManager.findTarget:85
  → nf IBlockStateExtension.getCloneItemStack:242      ← 第三方扫描模组走 NeoForge 扩展方法
  → anvilcraft StoragePortBlock.getCloneItemStack:81   ← 崩溃点
  → RuntimeDistCleaner: Attempted to load class
     net/minecraft/client/gui/screens/Screen for invalid dist DEDICATED_SERVER
  ← Player.tick:332 / ServerPlayer.doTick:556（服务端 tick 中抛异常 → 踢人 → 重连即复现）

触发者不是原版中键拾取（客户端路径），而是第三方模组在服务端 PlayerTick 里遍历扫描方块状态。PR 精确命中了该调用链。

🟢 修复评估（正确且完整）

维度	结论	证据
短路顺序	✅	isClientSide 位于 Screen.hasControlDown() 之前，服务端分支永不解析 Screen
项目一致性	✅	已有同款先例：StorageBlockEntity.applyPickStorageId() 用 if (!level.isClientSide() || !Screen.hasControlDown()) return;。本 PR 是该约定的补漏，未引入新写法
覆盖完整性	✅	全仓核对所有 override getCloneItemStack 的文件，只有这两个文件 import net.minecraft.client.*；CrateBlock/LargeCrateBlock/ShulkerContainerBlock/HyperdimensionStorageStationBlock 走已守卫的 applyPickStorageId，PipeBlock 无客户端类引用，AbstractStoragePortBlock 及其第三子类 StoragePortConsolidatorBlock 也干净 —— 仓储端口系列的服务端扫描路径已无同类残留
功能回归	✅ 无	核对 mappings：1.21.1 没有 ServerboundPickItemFromBlockPacket（拾取栈由客户端计算），创造模式经 ServerboundSetCreativeModeSlotPacket 携带组件同步 ⇒ 客户端算出的带数据栈仍能到达服务端，「Ctrl 拾取带缓存/标记/流体」在联机中照常生效
附带收益	✅	新条件把 isClientSide 放在 realLevel.getBlockEntity(pos) 之前，服务端不再于第三方每 tick 扫描热路径中访问方块实体（Level#getBlockEntity 可能触发同步区块访问），顺带缓解 issue 中提到的「mspt 暴涨」

⚠️ 建议（非阻塞）

1. 注释缺 dist 约束：两处注释只写了「保留…数据」，没说明为什么必须限定客户端。建议补一句「仅客户端；服务端禁止加载 Screen，见 [Bug] 玩家在服务器中手持神秘时代（重置）的魔导透镜时对准储存端口即被无限踢出 #5137」，防止后续重构把守卫当冗余删掉——本次 bug 正是这类误删的后果。
2. 模式已重复 3 处 → 建议抽共用判定，如 StorageBlockEntity.isPickDataRequested(LevelReader)（内部 level.isClientSide() && Screen.hasControlDown()），两个端口 + applyPickStorageId 复用，从结构上杜绝再写出裸 Screen.hasControlDown()。
3. 同类风险长期防护：建议为「非 client/ 包不得直接引用 net.minecraft.client.*」加一条轻量 CI/grep 门禁，或在 AGENTS.md 固化 dist 守卫约定。顺带核查过的近邻（SpacetimeSupercomputerBlock 用 @OnlyIn(CLIENT)、PlacementIntervalsBlockItem / HeliostatsBlockEntity / MobAmberBlock / ResentfulAmberBlock 均在客户端判据之后才引用客户端类）目前均安全，无需本 PR 处理。

🧪 测试建议

被测目标	场景	优先级
两个 getCloneItemStack	专用服务端放置带缓存/标记/流体的仓储端口，用扫描类模组（Thaumometer 类）每 tick 扫该方块 → 不得抛 RuntimeDistCleaner、不得踢人、不得 mspt 飙升	🔴
同上	客户端创造模式 Ctrl+中键拾取 → 仍附带缓存/标记/流体数据	🔴
同上	客户端普通中键拾取（无 Ctrl）→ 不带数据（行为与修复前一致）	🟡

📋 声称验证表

PR 声称	状态	证据
仅在客户端拾取时读取 Ctrl 并复制数据	✅	两处新增 isClientSide 短路，服务端直接跳过整块分支
避免服务端扫描时加载客户端类	✅	与崩溃栈 RuntimeDistCleaner / IBlockStateExtension.getCloneItemStack 完全对应
fixed #5137	✅	issue 指定崩溃点 StoragePortBlock.java:81，正是本次修改的条件所在行

结论：APPROVE — 修复正确、最小、覆盖完整，可合并；仅建议补注释与抽公共判定。

标题核对：「Fix storage port server-side scanning crash 修复服务端扫描仓储端口时崩溃」已是「英文 + 中文」规范格式且描述准确，无需修改（另外 gh auth status 显示 token 已失效，即使需要也无法自动改标题，本次未执行 gh pr edit）。

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'client-server-side-separation-review' (1 replacement).

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Gugle2308]

❌ Non-retryable error (HTTP 400): HTTP 400: You have insufficient credits to make this request. Please purchase more credits to continue using the service.

[Gugle2308]

HTTP 400: You have insufficient credits to make this request. Please purchase more credits to continue using the service.

[Gugle2308]

代码审查摘要 — PR #5140

操作: ready_for_review（PR 状态：Open；关联 issue #5137 仍为 Open）
范围: 2 个文件（2 Java，+2 行 / -0 行，24 行 diff）；无新增/删除文件，无 ghost 文件，无 EOF 缺失

文件	变更
block/StoragePortBlock.java	getCloneItemStack 条件链新增 && realLevel.isClientSide（head:80）
block/StorageFluidPortBlock.java	同上（head:67）

✅ 崩溃机理核对（与 issue #5137 描述一致）

• 触发点确认为 StoragePortBlock#getCloneItemStack 中无 dist 判断地调用 net.minecraft.client.gui.screens.Screen.hasControlDown()（base:81）。
• 服务端 RuntimeDistCleaner 在专用服务端拒绝加载 Screen → 抛 RuntimeException，因发生在 player tick 内被包装成 ReportedException: Ticking player → 玩家被踢出（issue 中的「无限踢出」）。
• 调用方为第三方 mod（ThaumCraft 4R 移植版符文扫描仪）在玩家 tick 内对瞄準方块调用 getCloneItemStack；单人不复现是因为 dist=CLIENT。这是一个「公共代码引用客户端类」的通用缺陷，不是该第三方 mod 的 bug，修复方向正确。

✅ 修复正确性与覆盖度验证

1. 短路顺序正确：守卫置于 getBlockEntity(pos) 与 Screen.hasControlDown() 之前，服务端在 isClientSide==false 处直接短路，Screen 的符号引用永不解析 → 无 NoClassDefFoundError/RuntimeDistCleaner 异常。✅
2. 客户端行为零变化：客户端 Level 与集成服务端的客户端侧 isClientSide==true，Ctrl 中键复制缓存/标记/流体路径完全保留；单人世界不受影响。✅
3. 同类位点已穷尽：对 base 分支全仓扫描全部 16 个 getCloneItemStack 覆写文件，只有这两个文件 import net.minecraft.client.*（git grep -ln "^import net.minecraft.client" rvbase1216 -- <getCloneItemStack 覆写文件>）。其余仓储类方块（ShulkerContainerBlock、HyperdimensionStorageStationBlock）经 StorageBlockEntity.applyPickStorageId 走，而该方法本身已有 dist 守卫（if (!level.isClientSide() || !Screen.hasControlDown()) return;）。→ 拾取路径上已无遗留同类风险。✅
4. 与项目既有惯例一致：同一文件的 getTicker 已用字段式 level.isClientSide，新增写法风格统一、可编译（Level.isClientSide 字段在本分支存在）。✅
5. 流体端口一并修复合理：issue 只报了 StoragePortBlock，但 StorageFluidPortBlock:68 是完全相同的模式，属于正确的预防性同修，不是范围蔓延。✅

🟢 与 dev/26.1/1.6 的交叉验证（重要正向证据）

26.1 线（dev/26.1/1.6）中同两个方块已经用更好的方案解决了同一问题：改用原版 getCloneItemStack(..., boolean includeData, ...) 参数（block/logistics/storage/StoragePortBlock.java:67-82、StorageFluidPortBlock.java:54-71），完全不引用客户端类，服务端同样安全。1.21.6 的 NeoForge 签名是 getCloneItemStack(BlockState, HitResult, LevelReader, BlockPos, Player)，没有 includeData（全分支 git grep includeData 无命中），因此本分支用 isClientSide 守卫是当前 API 下的合理等价手段。该 PR 的效果与 26.1 线对齐。✅

💡 建议（非阻塞）

• 给守卫加一句 dist 注释：现有注释只解释「拾取时保留数据」，未说明 isClientSide 是为了避免服务端加载客户端类。后续维护者若调整条件顺序（把 Screen.hasControlDown() 前移）会立刻复现 [Bug] 玩家在服务器中手持神秘时代（重置）的魔导透镜时对准储存端口即被无限踢出 #5137，建议补一行注释固化该约束。
• 两处方块重复同一守卫：可考虑像 StorageBlockEntity.applyPickStorageId 那样抽一个 AbstractStoragePortBlock 的静态 helper（内部做 dist 判断 + saveToDrop），减少第二处遗漏的可能。可选，不阻塞。
• 行为差异备忘：服务端第三方调用方现在拿到的是无数据的裸物品（此前是抛异常）。26.1 线在服务端调用方传 includeData=true 时仍会附带数据，两分支对非原版调用方语义略有差异——属于设计取舍，记录即可。

🧪 测试建议

被测目标	场景	优先级
StoragePortBlock#getCloneItemStack	专用服务端上模拟第三方 mod 在 player tick 内直接调用 → 应返回 new ItemStack(this) 且无异常（#5137 回归验证）	🔴
StorageFluidPortBlock#getCloneItemStack	同上	🔴
两方块 Ctrl 中键拾取	专用服务端 + 单人世界分别验证缓存/标记/流体仍写入物品与 tooltip 显示正常	🟡
集成服务端（单人）	确认 isClientSide 守卫不会误伤客户端拾取路径	🟡

📋 声称验证表

PR 声称	状态	证据
仅在客户端拾取时读取 Ctrl 键并复制缓存/标记/流体	✅	head 源码 isClientSide 短路 + 客户端行为不变
避免服务端扫描加载客户端类	✅	守卫先于 Screen.hasControlDown()，客户端类符号服务端不解析
fixed #5137	✅	issue #5137 仍 Open，崩溃行 base:81 已被守卫覆盖，合并后应自动关闭

结论: APPROVE（comment 级） — 变更极小、机理核对无误、同类位点已穷尽、与 26.1 线方案对齐，未发现需要修复的问题，可合并。

标题：现有标题 Fix storage port server-side scanning crash 修复服务端扫描仓储端口时崩溃 准确且已中英双语，无需修改。本次 gh auth status 显示 /opt/data/home/.config/gh/hosts.yml 中 token 已失效，故未执行 gh pr edit（未做任何凭据导出操作）。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched references/public-api-invoked-from-server-by-third-party-mods.md in skill 'client-server-side-separation-review' (1 replacement). · Patched references/common-side-client-class-linkage.md in skill 'client-server-side-separation-review' (1 replacement). · Patched SKILL.md in skill 'client-server-side-separation-review' (1 replacement).

[Gugle2308]

PR #5140 的 webhook 操作类型为 closed，按审查流程约束第 1 条（closed/labeled → 停止），本次不进行审查、不发布任何评论。

如需要该修复的审查意见，请在 PR 重新打开（reopened / ready_for_review）后再次触发。