Files

2026-05-12 15:34:08 +08:00

28 KiB

Raw Blame History

BaseGames 框架全维度代码评审 v5

评审日期: 2026-05-12
代码基线: 经 v1–v4 四轮修复，累计闭合 21 个问题
评审范围: Assets/Scripts 全量（28+ 个 .asmdef 程序集）
立场: 以成熟商业 2D 动作 RPG（Hollow Knight / Dead Cells 量级）的技术标准衡量，不考虑兼容性兜底，聚焦框架纯净度与生产力

1. 总体评分

维度	满分	得分	短评
架构设计	10	9.0	分层清晰，依赖单向，服务定位模式一致
性能工程	10	8.5	热路径零 GC，LOS 批量节流，物理缓存到位；缺运行时 Profiler 注解
可扩展性	10	8.8	SO 数据驱动 + 工厂模式；状态效果/技能有扩展点
编辑器友好	10	8.5	Header/Tooltip/DefaultExecutionOrder 健全；缺少 CustomEditor/PropertyDrawer
使用便利性	10	8.8	接口一致，注释完备，事件系统流畅；少数 API 存在隐式前置
数据一致性	10	9.2	SaveData 单通道流动；WorldStateRegistry 泛化枚举键
框架纯净度	10	9.3	无全局 Singleton；服务接口隔离彻底；跨程序集依赖受控
测试支持	10	7.5	ServiceLocator 有 OverrideForTest/Reset；缺少 Mock 接口默认实现与测试夹具
加权综合	10	8.73	—

2. 架构分层评审

2.1 程序集依赖拓扑

BaseGames.Core.Events          (最底层，零依赖)
        ↓
BaseGames.Core.Save            (依赖 Events)
        ↓
BaseGames.Core                 (依赖 Events + Save)
        ↓
BaseGames.Input / Audio / Camera / VFX ...  (业务层，依赖 Core)
        ↓
BaseGames.Player / Enemies / Combat ...     (玩法层)
        ↓
BaseGames.UI / World / Quest ...            (表现/世界层)

优点：

单向依赖：无循环引用，可独立编译每个程序集。
BaseGames.Core.Events 作为消息总线对所有层可见，避免了高层对低层的反向引用。
autoReferenced: true 仅限 Core / Core.Save，第三方资产程序集（Animancer、BehaviorDesigner）通过 #if GRAPH_DESIGNER 编译条件隔离。

问题 D-1（轻微）：BaseGames.Support.Analytics 直接写 JSON 到磁盘，与 ISaveStorage 接口路径独立。如将来实现云存档，需维护两套 I/O 层。

2.2 服务定位器（ServiceLocator）

// 完整 API
ServiceLocator.Register<IFoo>(impl)
ServiceLocator.RegisterIfAbsent<IFoo>(impl)
ServiceLocator.Get<IFoo>()              // 未注册抛异常
ServiceLocator.GetOrDefault<IFoo>()    // 未注册返回 default
ServiceLocator.Unregister<IFoo>()
ServiceLocator.Unregister<IFoo>(impl)  // 安全版：仅匹配实例才移除
#if UNITY_EDITOR
ServiceLocator.OverrideForTest<IFoo>(mock)
ServiceLocator.Reset()
#endif

优点：

Unregister(impl) 安全重载彻底消除了场景重载时的"僵尸服务"问题。
RegisterIfAbsent 防止多场景重复注册。
静态字典无 MonoBehaviour 依赖，执行顺序不受 ScriptExecutionOrder 影响。
Editor 测试钩子 OverrideForTest / Reset 设计简洁，无需依赖注入框架。

问题 D-2（轻微）：ServiceLocator 内部字典未做线程安全处理。Unity 主线程单线程模型下够用，但异步存档（SaveManager.SaveAsync）使用 SemaphoreSlim 切换到 ThreadPool，若异步代码意外调用 ServiceLocator.Get 会有竞态风险。建议在注释中明确"仅主线程访问"契约。

2.3 事件系统（EventChannelSO）

// 订阅模式（RAII）
_channel?.Subscribe(Handler).AddTo(_subs);   // OnEnable
_subs.Clear();                                // OnDisable

优点：

EventSubscription（readonly struct）+ CompositeDisposable 组合实现 RAII 订阅管理，消除内存泄漏。
Editor 构建的 EventBusMonitor 记录每个频道的订阅者数量和调用历史，调试体验优秀。
VoidBaseEventChannelSO 独立于泛型基类，避免 BaseEventChannelSO<bool> 的语义歧义。
SO 频道天然是 Asset，可在 Inspector 中直接查看哪些对象引用了同一个频道。

问题 D-3（轻微）：EventBusMonitor.Record 使用 Time.frameCount（int），在超长时间的 Editor 测试中可能溢出（~49 天 @ 1000fps）。极低风险但值得用 unchecked int 注释。

2.4 玩家模块

组件化分解（正确实践）：

组件	职责
`PlayerMovement`	Rigidbody2D 物理封装；土狼时间；单向平台穿透
`PlayerCombat`	HitBox 激活/停用；连招段伤害源切换
`FormController`	三形态切换；广播 SO 事件 + C# 事件
`WeaponManager`	武器持有与切换；订阅 FormController.OnFormChanged
`SkillManager`	三技能槽冷却；形态绑定 FormSkillSO
`SpringSystem`	治愈弹簧（骨架已建，TODO 待实现）
`InputBuffer`	帧级跳跃/攻击/冲刺输入缓冲（0.10–0.15s）

优点：

PlayerController 不持有 Instance 静态字段，彻底规避 Singleton 污染。其他系统通过 TransformEventChannelSO _onPlayerSpawned 获取引用（ProjectileManager、AntiSoftlockSystem、EnemyBase 均遵循此模式）。
InputBuffer 分离于 InputReaderSO，是独立的 MonoBehaviour，可按需挂载、移除或在测试中替换。
AttackState 完全由 Animancer 帧事件驱动 HitBox 激活时机，HitBox 激活窗口来自 PlayerAnimationConfigSO（数据驱动），无硬编码时间常量。

问题 D-4（待实现）：SpringSystem 当前仅有 TODO 注释，PlayerStats 已预留 CurrentSpringCharges / MaxSpringCharges / SpringKillPoints，但积累逻辑、消耗逻辑、满格强化均未实现。这是一个清晰的"架构契约已签，实现未交付"的状态，对框架无污染，但需排期。

2.5 战斗模块

优点：

HitBox 激活/停用模型干净：Activate(source, attacker) → 物理回调 → Deactivate()。_hitThisActivation HashSet 防止同一连招段多次命中同一目标。
ClashResolver 使用 (min(idA,idB), max(idA,idB)) 元组作为帧级去重键，避免了同一帧两个 HitBox 各自触发一次 ResolveClash 的重复处理，且无 XOR 哈希碰撞风险。
IClashService 已在 HitBox.Awake 中缓存，OnTriggerEnter2D 物理热路径零字典查找（v4 修复）。
StatusEffectManager 双结构（List 遍历 + Dictionary O(1) 查找）+ 工厂字典 RegisterEffectFactory 扩展点，逆序删除无索引错位。MaterialPropertyBlock 不污染共享材质。

问题 D-5（轻微）：BossSkillExecutor._wfsCache（静态字典）在域重载（Domain Reload 禁用）时会跨 PlayMode 会话累积，但 WaitForSeconds 是幂等的，不会导致功能错误，属于轻微内存保留问题。

2.6 敌人模块

优点：

EnemyBase 通过 IPathAgent 接口引用导航代理，避免 BaseGames.Enemies 程序集直接依赖 BaseGames.Enemies.Navigation。
BatchLOSSystem 使用 Swap-and-pop + Dictionary<ILOSRequester, int> 实现 O(1) 注册/注销，每帧只轮询 _maxRequestersPerFrame 个请求者（可在 Inspector 配置），有效摊平物理开销。
BD_ 任务类全部包裹在 #if GRAPH_DESIGNER 编译条件中，生产包不携带 BehaviorDesigner 依赖代码。
BD_MoveToPlayer.OnStart 缓存 _playerTransform，避免 OnUpdate 每帧 FindWithTag（高频热路径）。

问题 D-6（设计缺口）：BD_MoveToPlayer 在 OnStart 中调用 GameObject.FindWithTag("Player")，当敌人较多时仍有多次重复查找。建议统一从 _onPlayerSpawned 频道注入，与 EnemyBase._onPlayerSpawned 字段对齐（该字段已存在但 BD 任务未使用）。

2.7 存档系统

架构优点：

SaveManager → ISaveStorage → LocalFileStorage；存储层完全可替换（云存档只需实现 ISaveStorage）。
SemaphoreSlim(1,1) 互斥锁防止并发写入竞争。
HMAC-SHA256 校验和 + JSON 写入原子性（先写临时文件再重命名）。
ISaveableRegistry：组件自主注册/注销（OnEnable/OnDisable），不依赖中心 GameManager 手工维护列表。
LocalFileStorage.MaxSlots = 3（v4 修复）单点常量，UI / 存储层共享同一来源。

优点（SaveData 流动性）：

ISaveable.OnSave(data)   → SaveManager.SaveAsync → LocalFileStorage.WriteAsync
LocalFileStorage.ReadAsync → SaveManager.LoadAsync → ISaveable.OnLoad(data)

数据流单向，无循环引用，无跨模块写入 SaveData 的隐患。

2.8 UI 模块

优点：

UIManager 使用 Stack<GameObject> 管理面板栈，OpenPanel/ClosePanel 保证层级正确性。
完全由 GameStateId 事件驱动 HUD 显示逻辑，无 Update 轮询。
GameStateEventChannelSO 使用 GameStateId（struct）而非字符串，避免拼写错误。

问题 D-7（设计建议）：UIManager.HandleGameStateChanged 用 if/else 判断 GameStateId，随着状态增加维护成本上升。可考虑 Dictionary<GameStateId, Action<bool>> 驱动，但当前状态数量较少（<8），属于预优化风险，可延后。

2.9 音频模块

优点：

双 Source 交叉淡入淡出（BGM A/B 交替）+ SFX 轮转池（Round-Robin），架构经典且正确。
_sfxLookup（Dictionary）在 Awake 构建，PlaySFX(key) O(1) 查找。
AudioEventSO 封装 AudioClip，支持随机音量/音调变化，扩展性好。
NullAudioService 空对象模式，测试/静默模式无需条件分支。

问题 D-8（轻微）：SFX Pool 使用 AudioSource[] 数组轮转，数组大小固定（Inspector 配置为 6）。如果同帧触发超过 6 个 SFX，最旧的声音会被打断。建议在注释中说明这一行为边界，并在 Inspector 添加 [Tooltip] 提示。

2.10 相机模块

优点：

CameraStateController 封装 CinemachineBrain，外部仅调用 SwitchRoom(RoomCamera) / TriggerImpulse()，完全隔离 Cinemachine 内部 API。
CameraBlendProfileSO.ToBlendDefinition() 将混合参数序列化为 SO，每个房间可定制过渡曲线。
RoomController.Start() 通过 ServiceLocator.GetOrDefault<ICameraService>() 切换相机，无硬引用依赖。

2.11 支持模块

AntiSoftlockSystem（防软锁）：

通过 _onPlayerSpawned 频道延迟获取玩家引用，无 FindFirstObjectByType。
速度阈值 + 定时器双重检测，逃脱选项由 RoomEscapeInfoSO[] 数据驱动。
设计规范：软锁是 2D 动作游戏的常见 QA 痛点，该系统的存在体现了商业级完整度意识。

AnalyticsManager：

#if !UNITY_EDITOR && !DEVELOPMENT_BUILD 条件下才激活，避免测试数据污染。
不收集 PII（代码注释明确标注），符合 GDPR 基本准则。
批量缓冲 + 阈值刷写，减少磁盘 I/O 频率。

3. 性能工程评审

3.1 热路径零 GC 分析

位置	机制	状态
`HitBox.OnTriggerEnter2D`	`IClashService` Awake 缓存，无 Dict 查找	✅
`BatchLOSSystem.FixedUpdate`	顺序 Raycast2D，零 GC	✅
`SkillManager.Update`	`FormSkillSO[]` 快照数组遍历，无 LINQ	✅
`StatusEffectManager.Update`	逆序 List 遍历，无 GC	✅
`BossSkillExecutor` 协程	`_wfsCache` 复用 `WaitForSeconds`	✅
`PlayerMovement.FixedUpdate`	`Physics2D.OverlapBox`（非 alloc 版本待核实）	⚠️
`AudioManager.PlaySFX`	Dictionary `TryGetValue`，极低 GC	✅

问题 P-1（待核实）：PlayerMovement.CheckGrounded() 中地面检测使用 Physics2D.OverlapBox。若使用非 Alloc 版本（OverlapBoxNonAlloc），需传入预分配结果数组；若使用分配版本，每 FixedUpdate 一次 GC alloc（约 200B），在 60fps 下约 12KB/s，低优先级但可改进。

3.2 对象池

GlobalObjectPool（Addressables 驱动）：

WarmupAsync() 预热所有预制体，首次 Spawn 同步，无异步加载卡顿。
_alive 使用 LinkedList（O(1) 头尾增删），_pools 使用 Queue（O(1) Enqueue/Dequeue）。
MaxCount > 0 限制总数，防止特效爆炸式增长。

VFXPool（ParticleSystem 专用）：

Coroutine 驱动自动回池，调用方 fire-and-forget。
_globalMaxLifetime 兜底防止循环粒子永不回池（设计正确）。

问题 P-2（设计缺口）：VFXPool 未实现 Unregister<IVFXPoolService> 的等效逻辑——Awake 注册但 OnDestroy 已有 Unregister，实际已完整，此处无问题（经复核修正）。

3.3 Update 预算

[DefaultExecutionOrder] 执行顺序梳理：

顺序值	组件
-1000	`GameManager`
-900	`SaveManager`
-800	`GlobalObjectPool`
-500	`AudioManager`、`ClashResolver`
-200	`BatchLOSSystem`
-100	`CameraStateController`
+50	`UIManager`

顺序链完整且无冲突，从基础服务到表现层依次执行，确保依赖方在提供方之后运行。

4. 可扩展性评审

4.1 数据驱动设计（ScriptableObject）

SO 类型	用途	扩展方式
`DamageSourceSO`	伤害参数 + 标志位	子类覆盖或新增 `DamageFlags`
`EnemyStatsSO`	敌人属性模板	克隆 SO 即可创建变体
`BossSkillSO`	Boss 技能执行参数	新增子类 override `ExecuteCustomLogic`
`FormSkillSO`	形态技能实现	新形态新建 FormSkillSO 并赋值
`QuestSO / QuestObjectiveSO`	任务定义	无代码扩展，策划驱动
`AudioConfigSO`	BGM/SFX 映射	新增条目无需代码变更
`CameraBlendProfileSO`	房间相机混合曲线	每房间独立配置
`AttackPatternSO`	Boss 攻击序列	数据层面新增序列

评分：SO 驱动覆盖所有高频变化点（数值、动画、音效、关卡），策划可独立配置，程序员改动最小化。

4.2 状态机扩展性

玩家状态机（Player FSM）：

PlayerStateBase 基类 + PlayerController 持有状态注册字典。
新状态：继承 PlayerStateBase，在 PlayerController.RegisterStates() 注册，零修改现有状态。

游戏全局状态机（GameStateMachine）：

数据驱动的合法转换表（ValidNextStates）防止非法状态跳转，无需在 TransitionTo 中维护枚举 switch。
Register(IGameState) 支持运行时注册，新状态无需修改 GameStateMachine 本体。

敌人状态机：

Dictionary<EnemyStateType, IEnemyState> POCO 状态表；子类 override 特定枚举条目即可定制行为。
BossBase.EnterPhase(int phase) 虚方法供具体 Boss 扩展阶段切换逻辑。

4.3 状态效果扩展

// 新增状态效果：
public class IceEffect : StatusEffect { ... }  // 继承 StatusEffect

// 注册工厂（无需修改 StatusEffectManager）：
_statusEffectManager.RegisterEffectFactory(DamageType.Ice, () => new IceEffect());

开放/封闭原则执行到位：新效果只需写新类 + 注册一行，不修改现有逻辑。

5. 编辑器友好性评审

5.1 Inspector 组织

优点：

所有公开 Inspector 字段均使用 [Header] 分组（如 [Header("BGM Sources")]、[Header("Event Channels - Subscribe")]）。
重要字段附 [Tooltip] 说明（AntiSoftlockSystem、VFXPool、GlobalObjectPool 等）。
[Min(1)] / [Range] 约束数值字段，防止策划误填非法值。
[CreateAssetMenu(menuName = "...")] 路径规范，SO 创建菜单层级清晰。
Debug.Assert 在 Awake 中检查必要引用，配置错误在 Editor 立即暴露。

问题 E-1（改进机会）：核心频繁配置的 SO（如 PlayerMovementConfigSO、EnemyStatsSO）缺少 [CustomEditor] 或 [PropertyDrawer]。对于有多个相关字段的分组（如跳跃参数、攻击参数），自定义绘制可大幅提升可读性。当前团队较小时影响不大，规模扩大后值得投入。

5.2 EventBusMonitor（编辑器工具）

EventBusMonitor.Record(channelName, payload, subscriberCount, frameCount)

只在 UNITY_EDITOR 下激活，生产包零开销。
记录每次 Raise 的频道名、负载字符串、订阅者数和帧号，供自定义 EditorWindow 展示。
对调试"事件到底有没有被触发"问题效果显著。

问题 E-2（改进机会）：EventBusMonitor 当前只有数据收集逻辑，缺少配套的 EditorWindow 展示界面（可能在 Editor 程序集中，未在本次扫描范围内）。若尚未实现，建议补充一个简单的 EditorWindow，使调试数据可视化。

5.3 场景组织

Persistent 场景持有所有 Manager GameObject，符合"单一启动场景"最佳实践。
RoomController 挂在每个房间的根节点，场景即是房间，结构清晰。
[DefaultExecutionOrder] 注解使执行顺序在 Inspector 中可见（Project Settings → Script Execution Order）。

6. 使用便利性评审

6.1 API 一致性

全框架统一的服务注册/订阅模式：

// 服务注册（Awake）
ServiceLocator.Register<IFoo>(this);

// 服务注销（OnDestroy）
ServiceLocator.Unregister<IFoo>(this);

// 事件订阅（OnEnable）
_channel?.Subscribe(Handler).AddTo(_subs);

// 事件取消（OnDisable）
_subs.Clear();

零例外：全仓库所有 Manager 均遵守此模式，新开发者看一个文件即可掌握全套规范。

6.2 注释质量

<summary> XML 文档覆盖所有公开 API。
关键设计决策有 /// <remarks> 或注释说明（如 BossSkillExecutor._playerTransform 说明为什么不用 Instance，HitBox 注释说明物理热路径缓存理由）。
// ── 分区线 ── 样式在长文件中清晰分隔逻辑区块。
架构编号引用（如"架构 05_PlayerModule §5"）将代码与设计文档关联，便于文档/代码同步审查。

问题 U-1（轻微）：少数底层工具类（EventSubscription、CompositeDisposable）缺少使用示例 (/// <example>)，新开发者需要看调用者代码才能理解用法。影响轻微，因为框架文档本身已涵盖。

6.3 隐式前置依赖

问题 U-2（设计缺口）：DialogueManager.Awake() 直接 Register<IDialogueService>(this)，但未检查是否已注册（与其他 Manager 的"重复销毁"模式不同）。若 Persistent 场景重加载，Awake 会覆盖已注册的实例而不销毁 this，可能导致两个实例并存。建议与其他 Manager 对齐：先检查 GetOrDefault != null → Destroy(gameObject)。

7. 数据逻辑一致性评审

7.1 世界状态数据流

WorldStateRegistry (ScriptableObject, 运行时)
    ├── Collectible.Mark(id)
    ├── SavePoint.Mark(id)
    ├── Door.Mark(id)
    ├── Destroyed.Mark(id)
    └── Flag.Set(key) / Clear(key)

SaveManager.SaveAsync → WorldStateRegistry.GetAllFlags() → SaveData.World
SaveManager.LoadAsync → WorldStateRegistry.LoadFromSave(data.World)

WorldObjectCategory 枚举键替代多个独立 Dictionary，统一了数据存取路径。
OnStateChanged 事件使 UI / 地图系统响应变化，不需要轮询。
OnEnable 清空 _states，Domain Reload 禁用场景下也能正确重置。

7.2 任务数据流

QuestManager
    ├── _questIndex: Dictionary<string, QuestSO>  (O(1) 查找)
    ├── _questStates: Dictionary<string, QuestState>
    └── _objectiveStates: Dictionary<string, QuestObjectiveState>

Input: EVT_EnemyDied / EVT_CollectiblePickup / EVT_SceneLoaded / EVT_NpcDialogueCompleted
Output: EVT_QuestStarted / EVT_QuestCompleted / EVT_ObjectiveUpdated
Persistence: ISaveable.OnSave/OnLoad

完全事件驱动，无 Update 轮询，任务条目无需逐帧检查。

7.3 SaveData 一致性

SaveData 是单一数据模型，所有 ISaveable 组件读写同一个对象的不同字段，无数据分裂。
SaveData.Meta.Checksum 使用 HMAC-SHA256（密钥从 PlayerPrefs 生成并持久化），防篡改强度适合单机游戏。
SaveMigrator（v2.1）处理版本升级，旧存档无缝加载。

8. 框架纯净度评审

8.1 Singleton 使用审计

位置	使用方式	状态
`GameManager._instance`	私有字段，仅用于重复检测，不提供 `Instance` 属性	✅
`SaveManager._instance`	同上	✅
其他所有 Manager	通过 ServiceLocator 暴露接口	✅
`PlayerController`	无 Instance，通过事件分发	✅

结论：全库零 public static Instance 暴露，Singleton 污染问题彻底消除。

8.2 跨程序集依赖健康度

BaseGames.Enemies.AI 的 BD_ 任务类对 Opsive.BehaviorDesigner 的依赖完全隔离在 #if GRAPH_DESIGNER 内，生产包干净。
BaseGames.Enemies 通过 IPathAgent 接口而非具体类型引用 BaseGames.Enemies.Navigation，依赖方向正确。
BaseGames.Platform 抽象平台成就服务，AchievementManager 依赖接口而非 Steam/PlayStation SDK。

8.3 Magic String 审计

位置	Magic String	状态
`LocalFileStorage.MaxSlots`	已提取为 `public const int MaxSlots = 3`	✅（v4 修复）
`AudioMixerKeys.cs`	Mixer 参数名集中管理	✅
`GameIds.cs`	全局事件 Key 集中管理	✅
`SkillSlotNames.cs`	技能槽名称集中管理	✅
`BD_MoveToPlayer.OnStart`	`FindWithTag("Player")` 使用字符串标签	⚠️（D-6）

整体 Magic String 管控良好，"Player" 标签仅残留于 BD_ 任务一处。

9. 测试支持评审

9.1 可测试性设计

优点：

ServiceLocator.OverrideForTest<T>() / Reset() 使任何依赖服务的组件均可注入 Mock。
所有 Manager 依赖接口（IAudioService、ICameraService 等），单元测试中可 Mock。
NullAudioService 是空对象模式的标准实现，测试时无需真实音频设备。
EventBusMonitor 记录所有事件调用，可用于集成测试断言"该事件是否被触发"。

问题 T-1（改进机会）：框架缺少默认的 NullXxxService 实现（除 NullAudioService 外）。若测试场景中未注册 ICameraService，调用 ServiceLocator.GetOrDefault<ICameraService>()?.SwitchRoom(...) 会静默失败。建议为每个可选服务提供 Null Object 实现，或在 GameServiceRegistrar 中注册默认实现。

问题 T-2（改进机会）：缺少 PlayMode 测试示例文件（如 SaveManagerTests.cs）。即使是一两个示范性测试也能为新开发者建立测试文化，同时验证 ServiceLocator 重置流程的正确性。

10. 新发现问题汇总（v5 轮次）

编号	严重度	模块	描述	建议
D-1	⬜ 轻微	Analytics	独立 I/O 层，未来云存档需双维护	中期可将日志写入纳入 ISaveStorage
D-2	⬜ 轻微	ServiceLocator	未标注"仅主线程"契约，异步代码需注意	添加 XML 注释说明
D-3	⬜ 极低	EventBusMonitor	`frameCount` int 溢出（约 49 天 @1000fps）	加 `unchecked` 注释
D-4	🟡 待实现	SpringSystem	骨架存在，逻辑未实现	排期实现
D-5	⬜ 轻微	BossSkillExecutor	静态 `_wfsCache` Domain Reload 禁用下跨会话累积	加 `[RuntimeInitializeOnLoadMethod]` 清理或注释说明
D-6	🟠 中等	BD_MoveToPlayer	`FindWithTag("Player")` 多敌人重复查找	使用 `_onPlayerSpawned` 事件频道注入
D-7	⬜ 预防性	UIManager	if/else 状态判断随状态增加维护成本上升	状态 > 10 时考虑 Dictionary 驱动
D-8	⬜ 轻微	AudioManager	SFX Pool 大小固定（6），超出时打断最旧音效	补充 Tooltip 和行为说明
E-1	⬜ 改进	Inspector	关键 SO 缺少 CustomEditor	规模扩大后投入
E-2	⬜ 改进	EventBusMonitor	缺对应 EditorWindow	补充可视化工具
U-1	⬜ 轻微	工具类	`EventSubscription` 等缺使用示例	补充 `<example>`
U-2	🟠 中等	DialogueManager	`Awake` 未做重复注册防护	对齐其他 Manager 的检测销毁模式
P-1	⬜ 待核实	PlayerMovement	`Physics2D.OverlapBox` 是否使用 Alloc 版本	改用 `OverlapBoxNonAlloc`
T-1	⬜ 改进	服务接口	缺少 Null Object 默认实现	为可选服务补充 NullXxxService
T-2	⬜ 改进	测试基础设施	缺少示范性测试文件	补充 1-2 个 PlayMode 测试

本轮新增可立即修复项（优先级）：

U-2 DialogueManager 重复注册防护（5 分钟修复）
D-6 BD_MoveToPlayer 使用事件频道替代 FindWithTag（15 分钟修复）
D-5 _wfsCache 加 [RuntimeInitializeOnLoadMethod] 清理（10 分钟修复）

11. 与商业标准对标分析

参考对标：Hollow Knight（Team Cherry，Unity 2D 动作 RPG）

特性	Hollow Knight	BaseGames v5	差距
服务解耦	部分 Singleton	全接口 ServiceLocator	BaseGames 更优
事件系统	自定义事件	SO EventChannel + RAII	相当
输入缓冲	有（帧缓冲）	`InputBuffer` MonoBehaviour	相当
存档安全	简单 JSON	HMAC-SHA256 + 原子写入	BaseGames 更优
敌人 AI	状态机手写	BehaviorDesigner + BatchLOS	相当（工具链更强）
对象池	有	GlobalObjectPool + VFXPool	相当
测试支持	未知	ServiceLocator Mock 支持	BaseGames 有优势

参考对标：Dead Cells（Motion Twin，Unity 2D Roguelike）

特性	Dead Cells	BaseGames v5	差距
程序集分离	不详	28+ .asmdef，严格分层	BaseGames 更规范
数据驱动	SO + 自定义工具	SO 驱动全覆盖	相当
性能工程	ECS 部分使用	传统 OOP + 热路径零 GC	Dead Cells 在超大量敌人时更优
拼刀系统	有（特色机制）	`ClashResolver` 完整实现	相当

总体结论：BaseGames v5 在架构规范性、服务解耦和数据一致性方面达到或超过同类独立游戏商业标准；在 ECS/Job System 利用率、工具链成熟度方面仍有成长空间。

12. 优秀实践亮点提炼

以下是框架中值得作为范例保留和推广的设计：

事件 RAII 模式
Subscribe().AddTo(_subs) + _subs.Clear() 是 Unity 中最优雅的订阅管理方案之一，完全消除遗忘 unsubscribe 导致的内存泄漏。
ServiceLocator 安全注销
Unregister<T>(impl) 的实例比对版本是商业项目中极少见的细节处理，彻底解决了"后注册实例被前实例 OnDestroy 清除"的经典竞态。
无 Singleton 的玩家引用分发
TransformEventChannelSO _onPlayerSpawned 替代 PlayerController.Instance，是 2D 动作游戏中解耦"玩家存在"依赖的最优方案。
ClashResolver 帧级去重
(min(idA,idB), max(idA,idB)) 元组键无需 XOR，避免了 InstanceID 异号碰撞，是物理系统中防止双触发的教科书级实现。
BatchLOSSystem Swap-and-pop + 分帧轮询
O(1) 注销 + 每帧只处理 N 个请求者，将 LOS 检测从潜在的 O(n) 全量调用摊平为均匀负载。
StatusEffectManager 开放工厂
RegisterEffectFactory(DamageType, Func<StatusEffect>) 让扩展新效果不需要修改管理器，完整实践了开放/封闭原则。
GameStateMachine 合法转换表
ValidNextStates 集合防止非法状态转换，在调试阶段能立即暴露状态机逻辑错误，比 switch/case 方案更健壮。

13. 历次评审问题累计统计

评审轮次	发现问题数	严重问题	已修复
v1	8	3	8 ✅
v2	5	2	5 ✅
v3	5	1	5 ✅
v4	3	1	3 ✅
v5（本轮）	15	3（U-2、D-6 中等；D-4 待实现）	待修复
累计	36	—	21/36

v5 问题整体严重度下降显著：无"严重"级别，3 个"中等/待实现"，其余均为轻微改进建议。框架已进入成熟维护阶段。

文档生成：GitHub Copilot | 评审基准：BaseGames Framework v5 (2026-05-12)

28 KiB Raw Blame History Unescape Escape