摘要

这是一项内部性能优化。实验 0018 找到一个很慢的节点：14 支部队在场、后续菜单有 314 个施法选项，一次成对比较要约 2 秒。剖析发现，Simulator 每次刷新部队的攻防等动态属性时，即使数值没变，也会生成一个“值相等的新对象”；而后面已有的缓存是按对象身份识别的，于是无法命中，只好重新遍历大量状态去证明“没变”。修改后，只要刷新结果完全不变，就保留原对象。这个节点快了约 11.5%，结果完全一致；但完整深度搜索开局几乎没变快。

要回答的问题

能否在不改搜索深度、评分、规则和保存格式的前提下，减少这类无效的对象更换？

方法

修改 Simulator 战斗引擎的动态属性刷新：照常完成全部派生值计算、状态校验、免疫检查、生命投影和反击容量调整，最后检查结果。只有部队完全值相等、生命结构仍是原对象、反击次数类型未变、参数已是规范类型时，才保留原对象。

一个陷阱：Python 的“值相等”不等于“规范表示相同”。整数和浮点、列表和元组不能混用；-0.0 == 0.0 但保存的表示不同。初版漏了负零，新增测试复现后修正。

剖析显示，不可变结构检查的递归调用从 1,291,162 次降到 637,981 次；动态刷新 334 次、状态应用 4,707 次、规则校验 293 次保持不变，收益来自后续复用，不是跳过了规则步骤。

设置

沿用实验 0018 冻结的 27 个英雄状态（四场保存的 Simulator 测试局），先用原函数和原型包装器对照，结果相等后才改生产代码。

结果

检查 原版 最终版
14 堆比较，三次中位数 1.9304 秒 1.7078 秒
27 次 quick 合计 12.5315 秒 11.1912 秒
候选开局完整 deep 66.4522 秒 65.8969 秒

三次比较是同一节点的重复测量，不是三场独立对局。完整 deep 两版都选择对红方魅魔施放镜像，7,472 个节点、8,752 次缓存命中、全部候选评分完全一致。四份旧完整存档共 452 个事件和终态重新回放一致；622 项相关测试通过。

失败与负结果

完整 deep 只快不到 1%，不能认定实质提速。27 次 quick 合计里有 9 个节点单次略慢，不能当逐节点稳定提速。

局限

收益只在这个特定法术节点上测量，不能外推到其它构筑；没有重测网页端到端延迟。

结论与下一步

优化保留。一分钟级的完整 deep 开局仍需拆解剩余成本，并关注 4 秒内能完成的有效比较数量（见实验 0021、0007）。