一旦开始多文件并组，配置就不再是单文件问题

很多人第一次看第二案例，会把注意力集中在：

• 生成器开始读 AdditionalFiles
• 可以从 JSON 提取配置
• 还能拿到 MSBuild 元数据

这些当然重要，但还不是第二季真正把难度拉高的地方。

真正的分水岭是：

多个输入文件开始指向同一个输出类。

为什么这和“多读几个文件”不是一回事

如果只是多读几个文件，问题大多还是单文件局部问题：

• 这份 JSON 能不能解析
• 这个元数据有没有读到
• 这个默认值有没有生效

但一旦开始并组，问题类型立刻变了：

• 哪些文件本来就应该落到同一组
• 哪些文件其实不该被并在一起
• 同组里出现冲突时应该怎么失败

这已经不是“文件读没读到”的问题，而是“输出契约怎么定义”的问题。

为什么第二案例必须把“创建”和“合并”拆开

在工程上更稳的做法，是把两件事彻底分层：

• Create
  • 解释单个输入文件
• Merge
  • 决定多个输入文件怎样形成最终输出

只有这样，排错时你才能稳定判断：

• 单文件内容错了，先看创建阶段
• 输出类数量、条目来源或冲突行为不对，再看合并阶段

如果这两层混在一起，第二季后面所有错误都会看起来像“随机不稳定”。

为什么同组冲突不能靠“默认优先级”糊过去

当多个文件都想并进同一个输出类时，最危险的做法是静默覆盖。

例如：

• 同名条目重复定义
• 可见性不一致
• 一个名字既想当值，又想当父节点

如果生成器在这些情况下继续“猜一个最合理的结果”，调用方只会看到某次构建多了点东西、少了点东西，却不知道变化是从哪里来的。

所以第二案例真正重要的不是“能合并”，而是：

能不能在不合法时稳定失败。

为什么这一步更像架构而不是技巧

因为它直接决定最终输出类型的身份边界。

一旦并组规则不稳，后面就会出现这些问题：

• 本来应该拆开的配置被揉进一个类
• 本来应该合并的配置被拆成多个类
• 某个项目配置一改，生成类数量立刻变化

这类问题在真实项目里往往比“文件解析失败”更难排，因为消费方看到的只是生成结果变了，而不是明显的解析错误。

sample 其实已经在证明这件事

第二案例里真正的重点，不是 shared.release.json 被读进来了，而是它进入后：

• 怎样和 tutorial.base.strings.json
• 以及 tutorial.features.strings.json

一起稳定并进 BuildStrings。

如果这里的并组契约不稳，这个案例根本没法说明“多文件配置输入”是可维护的。

一句话结论

第二季真正把生成器推进到工程阶段的，不是多了文件输入，而是生成器开始为“多个输入怎样组成一个合法输出”负责。