摘要

状态估计（SE）保存的一份单英雄剖析显示：274 次公开属性投影中，施法配置构造函数被调用 241,120 次，累计 3.437764 秒（剖析器开销下的诊断值，不是正常延迟）。SE 请 Simulator 一方评估能否复用。本评估结论：在一次属性查询内部、每次访问都先跑完现有校验之后，按校验后的资源组合复用不可变配置是兼容的；不需要新接口、新字段、新规则版本或缓存服务。评估本身不改任何可执行行为，实现见实验 0329。

要回答的问题

缓存的键应是什么？生命周期多长？会不会让无效输入“蹭”到有效记录？会不会改变输出或错误顺序？

分析

  • 当前路径：一次公开查询创建一个所有者上下文，先准备一次法术书和装备，再对每个成长结果和候选计算前后潜力；每次潜力计算都重新构造施法配置。
  • 可共享性：导出的配置是冻结的，只含不可变元组和整数开局回合；共享对象只改变 Python 对象身份，而现有合同从未承诺对象唯一。
  • 键：校验后的槽位倍率元组。资源组合只有 8 种：一次普通 (1.0,)、两次普通 (1.0, 1.0)、普通加一次超载 (1.0, m)、两次普通加一次超载 (1.0, 1.0, m)，其中 m 取 1.5、1.75 或 2.0。在固定上下文中，学派绕过、开局回合和默认说明不变，所以最多 8 条记录。
  • 顺序：每次访问依次跑英雄校验（类型、所有者、完整法术书、整数咒力）、资源校验，再查找；未命中时才调用原构造器。绝不在校验前用原始值查找，因为 True == 1 会让无效值命中有效记录。
  • 生命周期：缓存只属于这次查询，正常返回或失败都随上下文释放，不进入全局、引擎、SE 或工作进程状态。

交付前必须通过的兼容检查

方向 要求
8 种资源配置 与原构造完全类型化相等，并用不同的有效咒力/法力/施法计数重复
缓存已热时的无效英雄/资源 仍按原优先级拒绝
上下文与构造器隔离 不同学派/开局门禁不共享；畸形输入仍被拒
整份公开投影 每个候选、结果、分数、属性、法力、法术、费用、说明都相等
现有消费者 SE 响应整体不变，旧的空配置默认不被替换

局限

  • 操作计数能证明“校验后构造更少”，但不能证明稳定提速；任何延迟比较须另立资源与时钟协议。
  • 本评估不授权“整份潜力值记忆化”：那需要覆盖全部六个英雄属性（含幸运/士气）以及所有上下文相关输出的完整类型化键，而剖析没有保存参数值，命中率未知。
  • 只读审计与独立审阅都不运行任何产品导入、查询、模型或原生操作。

结论与下一步

复用在上述边界内兼容。实现及完整等价证据见实验 0329；本评估没有声称任何提速或整帧 p95 改善。