配置与运行时数据分离

原始讨论中最耐用的结论是：静态配置不要和运行时状态混在同一个数据类里。分开之后，策划表更新、存档迁移、联网同步和测试都会更清楚。

数据类型	示例	典型特征
静态配置	武器基础伤害、技能冷却、关卡表	由内容生产流程生成，运行时通常只读
持久状态	玩家等级、任务进度、背包	需要保存、迁移或同步
瞬时状态	当前血量、冷却计时、目标缓存	只在当前对局或场景生命周期中存在

一个可维护的边界

CSV / JSON / 表格
       ↓ 校验与代码生成
只读配置仓库（按 ID 查询）
       ↓ 创建或刷新
运行时实体 / 存档数据

• 导入阶段校验 ID 唯一性、引用完整性和数值范围，尽量不要等到运行时才发现坏数据。
• 业务代码通过统一接口按 ID 读取配置，避免到处直接解析文件。
• 运行时对象可以持有配置 ID 或只读引用，但不要把会变化的血量、数量等写回配置对象。
• 项目小时，全量加载通常最简单；配置量很大或启动时间敏感时，再按表、分包或按需缓存。
• 按需缓存并非无条件更快：要同时考虑首次读取延迟、内存占用、卸载策略和并发访问。

选择加载策略

条件	更合适的方案
配置少、启动快、内存宽裕	全量加载，保持实现简单
配置很多，但每个场景只用一部分	按表或按内容包加载
单项很大且访问稀疏	按 ID 懒加载并缓存
高频访问、性能敏感	启动或切场景时预热热点数据

原记录还展示了“从 CSV/JSON/XML 生成专用读取代码”和统一配置管理器的做法。这种代码生成并非必须，但在强类型项目里能把拼写错误和字段类型问题提前到构建阶段。

来源：群聊原始讨论与截图。