Fix item splitter stack limits 修复物品分配器掉落物堆叠上限

[WhereisFff]

• 按物品实际堆叠上限拆分每个目标位置的掉落物。
• 保留均分份额、余数、零动量和默认拾取延迟。
• fixed [Bug] 物品分配器被铁砧砸吐出超出堆叠上限的物品实体 #5135

[Gugle2308]

代码审查摘要 — PR #5136

操作: opened（已确认现状：state=open、merged=false、mergeable=true；无重复评论风险）
范围: 1 个文件（1 Java）/ +15 −13 / diff 39 行
目标分支: dev/1.21/1.6（1.21.1 / NeoForge）
完整性核对: 已额外从 base 分支 dev/1.21/1.6 拉取 ItemSplitterBlockEntity.java 与 PR head 逐行 diff，结果与 patch 完全一致 → 该 PR 仅改 dropAt 一个方法，无隐藏改动、无 ghost 文件、无 EOF 缺失。

变更概要

private void dropAt(BlockPos target, ItemStack stack) {
    if (this.level == null) return;
    Vec3 center = target.getCenter();
    while (!stack.isEmpty()) {
        ItemEntity itemEntity = new ItemEntity(
            this.level, center.x, center.y, center.z,
            stack.split(stack.getMaxStackSize()),   // ← 按实际上限切分
            0, 0, 0);
        itemEntity.setDefaultPickUpDelay();
        this.level.addFreshEntity(itemEntity);
    }
}

📋 声称验证表

声称	状态	证据
按物品实际堆叠上限拆分掉落物	✅	stack.split(stack.getMaxStackSize())（L289），循环至 stack 耗尽
保留均分份额	✅	splitToSpace() 的 share = getTotalCount() / shares 与调用点未改动
保留余数（除不尽留在自身）	✅	extractTotal / break 逻辑未改动
保留零动量	✅	仍显式传 0,0,0（8 参数构造器，非 5 参数带随机动量版本）
保留默认拾取延迟	✅	setDefaultPickUpDelay() 移入循环体内，每个实体都调用
fixed #5135	✅	issue #5135「物品分配器被铁砧砸吐出超出堆叠上限的物品实体」（1.21.1 / snapshot-2385，open），根因与修法吻合

🔴 关键问题

无。

⚠️ 警告

• ItemSplitterBlockEntity.dropAt()（L279） — 契约变更未写入文档：修改前 dropAt 不修改入参，修改后会把传入的 stack 清空（split() 逐次 shrink）。当前唯一调用方 splitToSpace() 传入的是 extractTotal() 返回的临时副本（result = extracted.copy()，非库存槽位引用），因此没有实际 bug；但 Javadoc「在指定位置以零动量抛出一份物品」建议补一句「调用后会清空 stack」，否则后续新增调用方复用同一 stack 会被静默吞掉物品（这类"隐式消耗入参"很容易在重构时踩坑）。

💡 建议

• 建议提为局部变量并做下界保护：final int max = Math.max(1, stack.getMaxStackSize()); —— 既避免每次迭代重复读数据组件，也消除 max <= 0 时的理论死循环（split(0) 返回空 stack 且 shrink(0) 无效，while (!stack.isEmpty()) 永不退出）。正常路径不可达（max_stack_size 组件 codec 约束 1..99），属防御性改动，不阻塞。
• 「切分行为」保留在抛出处而非限制 extractTotal 的 share 是正确取舍：同一个 share 仍需支持下发给容器的多槽大堆（走 ItemHandlerHelper.insertItem 时由各槽自行 clamp），不应在源头截断。

🟢 看起来不错

• ItemStack.split(amount) 内部按 Math.min(amount, getCount()) 截断 → 循环不会丢物品、不会超发；不可堆叠物（上限 1）也自然退化为 1 个/实体，比原实现（10 把剑塞进 1 个实体）正确。
• 出货路径未受牵连：splitToContainers() 的超限 portion 由 ItemStackHandler / 容器 insertItem 按槽上限收纳；insertBack() 的兜底走原版 Containers.dropItemStack，其自带 10~30 的分堆，本身安全。
• 实体总数有界：内部 16 槽 × 上限 ⇒ 单次 dropAt 最多 16 个实体，总量守恒，无性能/刷实体风险。
• 改动最小、无无关文件、无生成资源污染。

ℹ️ 下游行为备注（非阻塞，供维护者确认预期）

同一次 dropAt 打出的多个实体坐标、初速完全相同（完全重叠），原版 Containers.dropItemStack 是会随机散布的。后果是：同一格上的 16 个实体，漏斗每 8gt 只能吸走一个，自动化抽取节奏比"1 个超限实体"慢（但这就是正确行为的必然代价，且与玩家手动丢弃的原版表现一致）。若维护者希望散布，可加微小随机偏移/初速 —— 但那会与 PR 声明的"零动量"设计意图冲突，当前实现按 PR 描述是正确的。

🧪 测试建议

被测目标	推荐测试场景	优先级
ItemSplitterBlockEntity.dropAt()	16 槽装满 1024 个可堆叠物 + 铁砧落下（share > 上限）：期望每目标格生成 ceil(share/64) 个 64 堆叠实体，实体计数之和 == 原数量	🔴
同上	不可堆叠物（16 把不同/相同剑）：期望 16 个 1 堆叠实体，无合并成超限实体	🟡
同上	share 非上限整数倍 + 除不尽余数：余数仍留在分配器内部	🟡
实体交互	多实体完全重叠时：玩家拾取、漏斗抽取均正常，地面上不残留 count > 上限 的实体	🟢

结论: APPROVE — 修复点选得准（切分放在抛出处而非截断 share），split() 的截断语义保证不丢不超，PR 描述的四项保留全部成立，最小改动且与 issue #5135 完全对应。仅建议补 dropAt 的"消耗入参"文档 + 一行防御性 max 下界。

PR 标题 Fix item splitter stack limits 修复物品分配器掉落物堆叠上限 已准确（英文+中文），无需修改（本机 gh token 已失效，未做标题编辑）。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'anvilcraft-anvil-impact-review' (1 replacement). · Patched references/shell-only-diff-navigation.md in skill 'github-webhook-pr-review' (1 replacement). · Patched references/pr-class-routing.md in skill 'github-webhook-pr-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]

代码审查摘要 — PR #5136

标题： Fix item splitter stack limits 修复物品分配器掉落物堆叠上限（标题准确，无需修改）
操作： ready_for_review
范围： 1 个文件 · Java 1 个 · +15 / −13 行（ItemSplitterBlockEntity.java）

diff 完整性已校验：patch-diff 与本地 git diff rvbase1216(94dd46d3)..rvhead5136(2060eff7) 除 hunk 上下文函数名外逐字节一致，无截断、无 ghost 文件、无跨界改动。

---

🔍 变更核实

- ItemStack stack 原样塞进 ItemEntity            // 单实体，count 可 > maxStackSize
+ while (!stack.isEmpty()) {
+     stack.split(stack.getMaxStackSize()), 0, 0, 0   // 按实际上限切分，逐个生成
+ }

追踪了唯一调用链 tick() → splitToSpace(shares) → extractTotal(share) → dropAt(target, portion)：

检查点	结论
是否会真的产出超上限堆叠	✅ 会。extractTotal() 跨 16 槽 grow() 累加，share = getTotalCount()/shares，shares=1 时可达 1024；与 issue #5135「均分后超过该物品堆叠上限」完全对应
dropAt 是否只此一处调用	✅ 仅 splitToSpace（第 150 行），修复覆盖面完整
split() 参数被消耗是否影响调用方	✅ 安全。portion 是 extractTotal 内 extracted.copy() 产生的新实例（ItemStackHandler.extractItem 返回的引用已被 .copy() 隔离），且调用方每次循环都重新赋值、用后即弃，不会二次读取
循环可终止性	✅ getMaxStackSize() 对非空堆叠恒 ≥ 1，每轮至少消耗 1，不会死循环
数量守恒	✅ split 不丢失物品；moved=true 的判定仍基于 portion.isEmpty()，语义未变
声称保留的行为	✅ 0,0,0 零动量保留；setDefaultPickUpDelay() 保留；@param shares 均分/余数留在自身的语义未触碰

另一个正向点： 同位置零动量的多个实体在后续 tick 会走 ItemEntity 的邻居合并，而合并上限即 getMaxStackSize()，因此修复后的状态是自稳定的——不会出现「合并回去又超上限」的回退。

---

💡 建议（非阻塞）

• dropAt 的 javadoc 未反映新的副作用：@param stack 待抛出的物品 现在实际是「会被 split() 消耗的堆叠」。同类方法 OverflowChuteBlockEntity 用的是 stack.copy()（调用方语义为不消耗），本方法改为消耗式，建议补一句 （会消耗传入的堆叠），或改为在方法内先 stack.copy() 再切分，避免未来调用方踩坑。
• 与原生 Containers.dropItemStack 的差异：原版（本文件 insertBack 的回退路径第 270 行也在用）按 random.nextInt(21)+10 切分并附带微小随机偏移，使实体略有散开；此处按 getMaxStackSize() 切分、位置与动量完全相同，多个实体会重叠成一堆再合并。这符合 PR「保留零动量」的意图，若希望视觉上不重叠，可加 ±0.1 级的随机位置偏移而不动动量。

---

🟢 结论

APPROVE — 最小改动、行为等价、无副作用外溢。修复精准命中 #5135（snapshot-2385，铁砧砸分器均分后单实体超堆叠上限），无阻塞问题；上面两条仅为文档/风格层面的可选改进。

🧪 测试建议

被测目标	推荐场景	优先级
dropAt()	16 槽塞满 64 个物品、shares=1 → 断言产出 16 个 count=64 的 ItemEntity（而非 1 个 1024）	🔴
dropAt()	上限为 1 的工具类物品（share=8）→ 断言生成 8 个 count=1 实体	🟡
dropAt() / splitToSpace()	share 恰好等于上限（64）→ 断言只生成 1 个实体，未产生退化行为	🟢

备注：gh auth status 显示当前 token 已失效（Gugle2308），故未执行 gh pr edit；本 PR 标题本身已符合 <英文标题> <中文标题> 格式，无需修改。

---

由 Hermes Agent 审查

[Gugle2308]

💾 Self-improvement review: Patched SKILL.md in skill 'anvilcraft-anvil-impact-review' (1 replacement). · Patched references/item-drop-stack-limit-split-review.md in skill 'anvilcraft-anvil-impact-review' (1 replacement).

[Gugle2308]

PR #5136 状态为 closed，按 webhook 审查约束第 1 条（closed/labeled → 停止），不再进行审查，也不会发布任何评论。

未执行任何 diff 下载或评论操作。如需对已关闭/已合并的 PR 做事后审查，请显式告知，我再单独处理。