从 Symbol 到模型：生成器为什么需要中间层

很多第一版生成器都会犯一个错误：拿到 INamedTypeSymbol 以后，直接在同一个方法里一边判断、一边取值、一边拼代码。

这样短期能跑，长期一定难维护。

当前项目在 GenerationSpecFactory 里先把输入整理成几层模型：

• TypeDeclarationModel
• PropertyModel
• TargetTypeModel
• GenerationSpec

为什么不能边扫边拼字符串

因为生成器里真正复杂的地方，不是“怎么写 StringBuilder”，而是“到底有哪些信息是稳定输出必须依赖的”。

例如当前项目会显式抽出：

• 命名空间
• 外层嵌套类型
• 当前目标类型的声明形式
• 公开可读属性集合
• 诊断集合

这些信息如果不先整理成模型，后面的渲染层就会不断回头读 Roslyn 对象，最终导致职责混乱。

中间层最大的好处

它把“理解语义”和“输出代码”分开了。

这样你改渲染时，不会碰发现逻辑；你补诊断时，也不需要同时重写输出逻辑。结构一旦拆开，边界就清楚了。

一个实用判断标准

如果你的渲染函数还在频繁访问 ITypeSymbol、INamedTypeSymbol、IPropertySymbol，那通常说明中间层还不够干净。渲染层越接近纯文本输出，回归风险就越低。