深度克隆是实现热重载数据安全隔离的必要手段，因其能递归复制嵌套对象及集合字段（如effectlist数组），彻底切断新旧配置间引用共享，避免运行时状态污染；浅克隆仅复制顶层引用，导致修改新配置时意外影响正在运行的逻辑。
深度克隆本身不直接实现热重载，但它能为热重载提供安全、隔离的数据基础——关键在于用克隆切断新旧配置间的引用共享，避免运行时状态污染。
为什么必须用深度克隆而非浅克隆
游戏配置表（如装备表、技能表）通常不是扁平的 key-value 结构，而是嵌套对象或含集合字段（例如：Equip 包含 Quality 枚举、Pic 路径、甚至关联的 EffectList 数组）。浅克隆只复制顶层字段，若 EffectList 是引用类型，新旧配置仍指向同一内存地址。一旦热重载后代码修改了新配置里的 effect，原始正在运行的战斗逻辑可能意外读到被改写的数据，引发崩溃或行为错乱。
热重载流程中深度克隆的介入时机
真正起作用的不是“克隆动作”本身，而是它在配置切换环节的位置：
- 监听配置文件变更（如 Excel 或 CSV 被保存）
- 解析新数据，生成全新 Domain 实体（如 Equip 列表）
- 对这批新实体执行深度克隆，确保每个对象及其所有嵌套引用（列表、字典、子对象）都是全新内存实例
- 原子性替换旧缓存：用 Interlocked.Exchange 或 ReaderWriterLockSlim 替换整个 Dictionary
引用 - 旧缓存对象随后被 GC 回收，无残留引用
实际开发中需绕开的坑
深度克隆不是调个 JSON.parse(JSON.stringify(obj)) 就完事。游戏配置常含以下不可序列化内容：
- 循环引用：比如 Skill 持有 Buff，而 Buff 又反向引用触发它的 Skill —— 必须用带引用追踪的克隆库（如 C# 的 MemberwiseClone 配合自定义 ICloneable，或 Rust 的 serde + preserve）
- 非托管资源：配置类里若误存了 Texture2D 或 AudioClip 引用（应只存路径），克隆会复制指针导致双释放 —— 设计上要严格分层，Domain 类只含纯数据，资源加载由独立系统按需绑定
- 静态/单例依赖：若配置类构造时读取了 GameConfig.Instance.Language，克隆过程会触发新语言读取，破坏当前 UI 状态 —— 克隆逻辑必须限定在纯数据层，禁止副作用
参考成熟框架的做法
BepInEx 的 Configuration 模块支持热重载，其底层正是基于 TOML 解析后构建新配置实例，并通过反射+递归遍历完成字段级深拷贝；UE4SS 的 HotReloadSystem 在启用时（EnableHotReloadSystem=1），也会在重新加载脚本前丢弃旧配置对象图，强制重建干净实例。它们共同验证了一点：热重载的稳定性，不取决于“是否重载”，而取决于“新旧数据是否彻底解耦”。深度克隆，就是实现解耦最可控的手段。
