一次生成能产出多少个类，分组键早就决定了

很多人第一次看到第二案例里同时出现：

• BuildStrings
• AdminStrings
• Areas.Admin.AuditStrings

会把它理解成“生成器支持多个输出类了”。

这个描述不算错，但还不够准确。

更准确的说法应该是：

同一次生成能产出多少个类，取决于分组键怎样定义。

为什么“多个输出类”不是一个单独功能点

如果生成器的分组规则本身是稳定的，那么多个输出组并存只是自然结果。

因为只要最终目标不同，文件就应该进入不同组。

在第二案例里，最终分组看的不是输入文件名本身，而是：

• namespace
• className

只要这两个值不同，就应该拆成不同输出组。

为什么分组键这么重要

因为它决定的是“输出类型的身份”。

一份配置文件到底和谁合并，不该靠感觉，不该靠书写顺序，更不该靠哪个文件先被读到。

它应该只由稳定的目标身份决定。

所以第二案例真正要建立的心智模型不是：

“这个文件会不会多生成一个类”

而是：

“这个文件最终被解释成了哪个输出目标”

sample 为什么能同时产出三组

这其实就是分组键在工作。

同样是配置文件：

• 有的最终落到 Tutorial.SettingsGenerator.Sample.Generated + BuildStrings
• 有的最终落到 Tutorial.SettingsGenerator.Sample.Generated + AdminStrings
• 有的最终落到 Tutorial.SettingsGenerator.Sample.Generated.Areas.Admin + AuditStrings

所以最后自然就不是一个类，而是三组不同输出。

这不是渲染层“多输出”的技巧，而是更早阶段的分组决议结果。

为什么真实项目特别需要这件事

因为真实项目很少只有一类配置输出。

更常见的是：

• 一组基础文案
• 一组后台或管理区文案
• 一组实验开关或共享配置

如果生成器只能围绕“一个统一输出类”打转，它最多只是一个演示案例。

只有当分组键足够稳定，生成器才真正具备项目级扩展空间。

分组键不稳会带来什么

最直接的问题就是输出数量飘忽不定：

• 这次明明应该并到一起，却被拆开了
• 那次明明应该拆开，却被揉到一起

一旦发生这种情况，后面看到的所有症状都很难判断来源：

• 是默认值改了
• 是元数据覆盖了
• 还是目录约定把命名空间推到了另一个组

所以第二案例必须先把分组键站稳，否则多输出组根本不是“能力”，只是“副作用”。

一句话结论

第二季里，多输出组并存不是额外特性，而是“输出目标身份已经被稳定定义”后的自然结果。