仓库: basil/vampire-like
本次变更概述
本次共 3 个 commit，涉及 13 个文件，新增 381 行，删除 40 行。核心工作是引入第三方计时器模块 TimerModule，并基于此重构了 Enemy 和 Weapon 的攻击冷却计时逻辑，将原先分散在多个 Entity 内部的帧累计计时统一交由该模块管理。
做了什么
1. 导入 TimerModule
新增 Assets/Plugins/TimerModule/ 目录（包含接入说明文档、asmref 引用、Editor 元数据等），并在 GameEntry.Custom.cs 中注册了 TimerComponent，同时在 Launcher.unity 中挂载了对应的 GameObject。这一步为后续的计时器统一调度奠定了基础。
2. Enemy 攻击冷却迁移
MeleeEnemy.cs 和 RemoteEnemy.cs 中移除了原来的 _currAttackTimer 字段和帧累加逻辑，改用 TimerHandle _attackTimerHandle 来管理冷却。同时修复了 TimerComponent.cs 中 Schedule 方法的参数错误——重复执行间隔原本传的是 0f，导致立即再次触发；修正为 delay 后，重复执行行为才符合预期。
3. Weapon 攻击冷却迁移
WeaponBase.cs 中移除了 _currAttackTimer，新增 bool _canAttack 标记，并添加了 ResetAttackCooldown 方法。子状态机（AttackState、CheckInRangeState 等）不再手动累加计时，而是通过 _canAttack 状态和 Timer 回调来控制攻击节奏，使得状态判断更加直观。
为什么这么做 / 遇到了什么问题 / 有什么权衡
决策考量
引入 TimerModule 的核心想法是：把游戏里大部分的计时器调度统一到一个模块里，方便统一管理和复用。虽然当前项目中很多计时需求其实比较简单（比如冷却倒计时），但为了将来能支持更复杂的计时策略（如变速、暂停、分组取消等），提前扩充可复用的组件库是值得的。我们也评估过 Unity 原生的 Coroutine、Invoke 以及 DOTween 等方案，但它们要么在批量取消、暂停恢复上不够灵活，要么依赖字符串或外部库，而 TimerModule 可以更自然地融入已有的 GameFramework 架构，并且提供了编辑器扩展，便于运行时调试。
发现并修复的 bug
在迁移 Enemy 冷却时，意外发现 TimerComponent.Schedule 的重复执行间隔参数传的是 0——这其实是一个设计上的疏忽。之前并没有实际使用过这个模块的重复执行功能，所以只有在真正接入业务逻辑时才暴露出来。这也提醒我们，即使测试覆盖再全面，也难免遗漏边角情况，只有结合真实场景跑通才能发现隐式问题。修复后，该模块的重复执行行为才回到正轨。
后续思考
后续计划把更多基于帧累加的计时逻辑（技能冷却、Buff 持续时间、敌人攻击间隔等）逐步迁移到 TimerModule。在性能开销上，和原来的 Update 累加相比差距不大，但调试体验会好很多——TimerComponent 的编辑器面板会列出所有注册中的计时任务及其进度，比在 Inspector 里翻找私有字段直观多了。当然，也需要关注 TimerHandle 在场景切换、对象销毁时的正确清理，避免产生幽灵定时器。
注：本文由模型
deepseek-v4-flash生成（草稿与终稿同模型）。