属性级版本控制需手动设计数据结构与拷贝逻辑，无法依赖框架内置深拷贝机制；必须为每个属性附加版本元数据、定义快照接口、重写克隆方法，并维护属性路径到变更记录的映射，或采用变更集替代方案。
属性级版本控制本身不是标准术语，也没有现成的“属性级版本控制”机制直接支持在深拷贝过程中自动记录每一层原始节点的变更历史。它需要你主动设计数据结构与拷贝逻辑，把版本追踪能力嵌入到对象模型和克隆流程中，而不是依赖框架内置功能。
理解核心限制
像 Freezable.CloneCurrentValueCore 这类方法虽能做深层复制，但只复制当前值——动画、绑定表达式、未设置属性等均不参与版本快照；它不保存“谁改了哪一属性”“何时改的”“改前值是什么”，更不会为嵌套对象的每个字段单独打点留痕。
真正的属性级变更历史，必须由你显式定义：
- 每个可变属性需附带版本元数据（如时间戳、操作者、变更集ID）
- 对象层级结构需支持递归遍历并逐层触发快照采集
- 深拷贝动作本身要被包装为“版本生成事件”，而非无状态复制
实现路径：手动注入版本上下文
以一个可版本化的业务对象为例（如 DocumentSection），你可以这样组织：
- 为每个关键属性添加
VersionedValue<t></t>包装器，内部存Value、VersionId、Timestamp、SourceChangeSet - 定义
IVersioned接口，含TakeSnapshot()和GetChangeHistory()方法 - 重写
CloneCurrentValueCore或自定义DeepCloneWithVersioning()，在每层递归时调用子对象的TakeSnapshot()并关联父版本号 - 用字典或链表维护
PropertyPath → List<versionrecord></versionrecord>映射，路径如"Content.Paragraphs[0].Text"
替代方案：用变更集代替属性快照
比起为每个属性存完整历史，更轻量的做法是记录“变更集（Changeset）”：
- 每次修改前，生成唯一
ChangesetId，记录操作类型（Set、Add、Remove）、目标属性路径、旧值、新值、时间、用户 - 深拷贝时，不是复制属性值，而是复制整个变更集链，并允许按指定
ChangesetId回滚到任意状态 - 利用 Git 或 TFVC 的语义——它们不记录“某字段第3次改成了什么”，而是记录“第17次提交改了哪些文件的哪些行”
工具辅助建议
若不想从零实现：
- Git 可用于文件级或序列化后 JSON/XML 的属性变更追踪（配合 pre-commit hook 提取 diff）
- EF Core 审计日志（如 Audit.NET）支持实体属性级变更捕获，适合数据库映射场景
- JSON Patch（RFC 6902） 格式天然适配属性路径 + 操作 + 值，可用于序列化版本差异
