分层配置不该等到第二个仓库才设计

很多团队第一次复制源生成器模板时，会先想着把业务能力跑起来。

这当然没错。

但如果模板后面要进入第二个仓库、第三个仓库，你很快就会遇到一个比“能不能生成”更现实的问题：

配置到底分几层。

为什么这件事不能往后拖

第一次落地时，大家通常只有一个仓库、一个 sample，于是很容易觉得：

先把默认值写死，后面再说。

这一步最危险的地方在于，配置层次一旦没有先设计，后面补起来时就会变成：

• 一部分放在 JSON
• 一部分放在 Directory.Build.props
• 一部分直接硬编码在渲染器里

等第二个项目接入时，你已经很难解释清楚优先级到底是什么。

更稳的拆法应该是什么

模板阶段就应该把三层边界想清楚：

• 全局默认值，负责整仓库兜底
• 仓库级或项目级覆盖，负责当前项目定制
• 文件级或目标级覆盖，负责局部特殊情况

只要这三层先站住，后面接再多仓库，变化也只是在具体值上，而不是在契约结构上。

为什么 enterprise 模板必须提前处理它

enterprise 真正要解决的，从来不只是“更多功能”。

它处理的是“更多仓库、更多团队、更多约束”。

一旦进入这种场景，配置分层如果还靠口头约定，后果通常是：

• 维护者理解不一致
• 新接入项目靠猜优先级
• 回归问题出现时，很难快速定位是哪一层覆盖了哪一层

这正是模板应该提前收口的东西。

分层配置的真实收益

它最直接的收益不是“看起来更高级”，而是：

• 新项目接入时，知道先改哪一层
• 默认行为和局部例外不会混在一起
• 测试可以按层设计，而不是把所有情况揉成一个大样例

这会直接降低模板后续 rollout 的沟通成本。

一句话结论

分层配置真正应该设计的时机，不是第二个仓库出问题之后，而是第一套模板准备复制出去之前。