geometry-tower-defense-base 开发日志
本周在 L0 Domain 层完成了 5 笔提交，主要干了三件事：把仓库骨架搭起来、按依赖拓扑继续往纯 C# 领域层搬代码、以及把 DataTable 的二进制解析彻底收拢到领域层里。整体方向就是把“能脱离 Unity 的逻辑”一点一点从上层的阴影里拖出来。
干了什么
仓库初始化与分层共识
新增了 .gitignore、CLAUDE.md 和 TODO.md。CLAUDE.md 除了说清楚项目只能在 Unity Editor 里构建，还写下了 L0（纯 C# 领域层）/ L1（粘合层）等分层的初步约定。有了这份说明，后续成员就不会在“这行代码该放哪”上反复打架。第一波已经完成了 62 个文件（主要是枚举和事件定义），进度在 TODO.md 里用表格记下来了。
第二波：数学库替换与攻击/命中结构体
这一波迁移是按文件间的依赖拓扑决定的，不是谁对哪个模块更熟就先动哪个。前一波已经把枚举事件抽走了，接下来自然就轮到依赖这些定义的攻击相关数据结构。于是把 UnityEngine.Vector3 和 Mathf 全部切到了 System.Numerics，同时落地了 AttackPayload、HitContext 和 TagRuntimeUtility。目前还没有碰到浮点精度不一致或者缺少辅助方法这类问题，不过 System.Numerics 和 Unity 数学库在序列化、哈希上的行为差异迟早要正视，后续准备挑几处关键战斗计算补几个对比用例，防止它们变成哑雷。
第三波：Tag 系统的 IDataRow 实现与规则注册
继续顺依赖链往下推，把 Tag 相关的 IDataRow 实现（RarityTagBudgetRow、TagRow）以及生成规则注册表（RarityTagBudgetRule、TagGenerationRule、RarityTagBudgetRuleRegistry）都搬进了 L0。这样一来，L0 层已经可以独立描述“稀有度 Tag 的预算规则和生成规则”，不再需要 Unity 的环境来验证这坨逻辑。
二进制解析彻底下沉到 L0
之前 RarityTagBudgetRow 碰到二进制路径就直接抛异常，这不符合分层的预期。这次补上了 BinaryReaderExtension，把真正的解析逻辑写在了领域层内部，并让 RarityTagBudgetRow 消费它。
为什么不让 L1 胶水层把二进制流转成纯数据结构再交给 L0？胶水层的本职工作就是弥合纯 C# 与 Unity 之间的鸿沟，不应该往里塞业务反序列化的代码。把解析能力留在 L0，领域层才能在不依赖 Unity 的环境（比如服务端模拟或纯单元测试）里直接抱着一个 Stream 完成数据加载，这是领域内聚的考虑，也给以后切分运行时留了一扇门。
代价当然也有：L0 的 DataTable 实现现在对二进制格式变更高度敏感；而且数据文件必须从 Unity 资源管理流程中导出成 .bytes 才能在外部使用，生产工具链还差一截，这是后面必须填的坑。
文档与进度维护
顺便更新了 TODO.md，第三波完成 6 个文件后累计迁移 73 个，总目标约 180 个。CLAUDE.md 也写明了 L0 现在允许引用纯 C# 的 GameFramework.dll，没有 Unity 依赖，避免因为多了个外部 dll 就被当作“不纯净”而误判。
哪些地方埋了雷
-
GameFramework.dll 的边界
L0 为了复用 DataTable 基础能力引了GameFramework.dll，它确实是纯 C# 的。但后续需要盯紧它与 Unity 侧 GameFramework 版本的接口一致性，否则二进制格式一错位，解析就崩了。 -
剩余 ~100 个文件的迁移风险
分波策略是按依赖拓扑而不是按谁熟哪个模块来切，这样每波爆炸半径小，但剩下的文件里，最让人不放心的还是那些藏在深层、隐式依赖了GameObject或Transform的类。它们很可能处在依赖链的中下游，平时不起眼，一旦开始迁就会扯出一连串修改，这是后面推进时需要重点关注的地方。 -
二进制数据从哪来
领域层可以读了，但生成二进制的管线还没落实。现在只能靠 Unity 侧喂文件，如果想在服务端或者 CI 里独立跑起来，需要尽快把二进制导出自动化的缺口补上。
接下来
- 继续按拓扑推进剩余文件迁移，优先揪出那些隐式依赖 Unity API 的“地雷模块”。
- 给
System.Numerics切换补上精度对比测试，哪怕没发现明显问题也留个底。 - 着手搭建二进制数据导出工具，让 L0 能真正脱离 Unity 独立自测。
注：本文由模型
unknown生成（草稿与终稿同模型）。