PostInitialization 为什么适合生成特性

当前主案例没有要求用户手写 [GenerateToString] 特性，而是直接在 RegisterPostInitializationOutput 里生成一份特性源码。

入口代码大致像这样：

context.RegisterPostInitializationOutput(static context =>
{
    context.AddSource("GenerateToStringAttribute.g.cs", "...");
});

为什么不手写特性

手写特性当然也能跑，但会带来两个额外负担：

• 消费方必须先引用一份特性定义
• 生成器入口和标记定义会分散在不同位置

把特性作为生成器的启动产物，最大的好处是接入成本会收缩。用户只需要引用生成器包，就能直接开始标记目标类型。

这一层为什么要尽量简单

PostInitialization 最适合做静态、稳定、没有业务分支的内容。

当前项目里它只负责一件事：把标记入口准备好。它不参与复杂判断，也不承担业务语义。这样做的好处是：

• 失败点更少
• 排错边界更清楚
• 不会把入口阶段和业务规则阶段混成一团

特性生成的真正价值

它不是为了省那几十行代码，而是为了让整个教程的入口更统一：用户看见特性，生成器就有目标；生成器有目标，后面的发现、建模和渲染才开始有意义。