2026-03-22
第 5 篇PostInitialization 为什么适合生成特性
把特性放到 PostInitialization 里生成，可以减少手写样板、降低接入成本，并让目标发现的入口更稳定。
分类
源生成器
这里汇总所有属于当前分类的博客文章。
2026-03-22
第 11 篇发布检查清单应该写进模板，而不是留在人的记忆里
模板真正进入首发阶段时，最容易遗漏的往往不是生成逻辑，而是包元数据、诊断前缀、示例配置和消费链路这些发布面。
2026-03-22
第 7 篇目标类型发现，为什么不能靠全文扫描
目标发现不是把所有类型扫一遍再碰运气，而是尽早缩小候选集，再把语义判断放进转换阶段。
2026-03-22
第 10 篇交付脚本应该是模板契约的一部分，而不是口头流程
模板如果要真正被团队复制和发布，改名、打包、恢复和消费验证这些动作就应该进入脚本层，而不是留在记忆和聊天记录里。
2026-03-22
第 9 篇sample 负责证明模板活着，tests 才负责证明它没撒谎
sample 和 tests 在源生成器模板里不是重复建设：前者证明链路活着，后者证明复杂边界没有被悄悄改坏。
2026-03-22
第 8 篇测试基座应该早于复杂功能扩展
对源生成器模板来说，先补测试基座再扩 AdditionalFiles、诊断和配置合并，通常比反过来便宜得多。
2026-03-22
第 8 篇从 Symbol 到模型：生成器为什么需要中间层
不要在拿到 Symbol 后直接拼字符串；先抽出目标类型模型、属性模型和声明模型，渲染层才会稳定。
2026-03-22
第 7 篇分层配置不该等到第二个仓库才设计
模板第一次落地时如果不先想清楚默认值、仓库级覆盖和文件级覆盖的边界，第二次接入时通常就会开始出现配置债。
2026-03-22
第 6 篇ProjectReference 跑通，不等于 PackageReference 可交付
本地 sample 的 ProjectReference 只能证明生成器在开发链路里活着，不能证明最终 nupkg、分析器收拢和外部消费者恢复链路都正确。
2026-03-22
第 4 篇第一版 GenerateToString 生成器，先把主链路跑通
第一版生成器不求复杂，只求把入口、发现、诊断和输出这条最小闭环跑通。
2026-03-22
第 5 篇从模板复制到新仓库时，最容易失败的是改名与包消费链路
模板真正落地时，最常见的失败点不是结构设计，而是改名不完整、包元数据遗漏，以及 PackageReference 消费链路没有被认真验证。
2026-03-22
第 4 篇enterprise 模板不是“文件最多”，而是“交付闭环最完整”
enterprise 模板真正贵的不是复杂度本身，而是它把声明诊断、配置契约、测试和 NuGet 消费链路一起闭环了。
2026-03-22
第 2 篇项目拆开以后，源生成器工程才开始稳定
生成器、示例程序和测试工程必须拆开；只有这样，引用关系、调试入口和回归验证才会清晰。
2026-03-22
第 3 篇standard 模板真正值钱的地方，是改动落点清晰
standard 模板不是 simple 的加厚版，而是大多数正式项目最该使用的默认骨架，因为每类改动都有明确落点。
2026-03-22
第 2 篇simple 模板适合验证，不适合长期还债
simple 模板最有价值的地方是快速确认 Roslyn 接线和生成闭环，而不是承载你后面所有工程复杂度。
2026-03-22
第 1 篇模板不是多余脚手架，而是长期成本控制器
真正有价值的模板，不是在第一天帮你少敲几行代码，而是在后面每次扩字段、补诊断、接配置和交付时持续压低成本。
2026-03-22
第 1 篇从零理解增量源生成器：为什么不是普通 Source Generator
先建立正确心智模型：增量源生成器不是在编译末尾一次性扫全项目，而是把发现、转换和输出拆成可复用的增量管线。
2026-03-22
第 9 篇显式文件发现，真正打破的是文件名约定的锁定
当生成器支持显式文件发现后，命名约定就不再是唯一入口，这一步才让第二案例真正适合接旧项目。
2026-03-22
第 8 篇共享资源键很脏时，前缀裁剪是在保护输出 API
前缀裁剪不是为了少打一段字符串，它真正解决的是共享资源键命名和最终生成 API 之间的边界污染。
2026-03-22
第 7 篇目录约定不是装饰，它直接改变输出命名空间身份
当目录约定进入第二案例后，目录层级不再只是文件组织方式，而会正式进入生成器的命名空间决议。
2026-03-22
第 6 篇一次生成能产出多少个类，分组键早就决定了
第二案例里，多输出组并存不是额外能力，而是分组键稳定之后自然出现的结果。
2026-03-22
第 5 篇一旦开始多文件并组，配置就不再是单文件问题
第二季真正把难度拉高的，不是又多读了几个 JSON，而是多个输入文件怎样稳定地并成同一个输出目标。
2026-03-22
第 4 篇多文件合并成一个输出类时，真正难的不是读文件
第二案例最难稳住的不是把 JSON 读进来，而是多个输入文件如何合法地并成同一个输出类型。
2026-03-22
第 3 篇全局默认值一旦进入生成器，契约边界就变了
项目级默认命名空间、类名和可见性不是便利配置而已，它们会直接改变生成器的输出契约和回退路径。
2026-03-22
第 2 篇文件级元数据不是 JSON 的一部分，它来自 MSBuild
很多人以为命名空间、类名和可见性都应该写在 JSON 里，但第二案例里，这些单文件覆盖项更适合来自 AdditionalFiles 元数据。
2026-03-22
第 1 篇为什么 AdditionalFiles 才是第二阶段真正的开始
当生成器开始读取 AdditionalFiles、MSBuild 元数据和项目默认值时，它就不再只是演示案例，而是开始接近真实工程输入。
2026-03-21
第 10 篇ToString 渲染层到底在解决什么问题
代码渲染不只是拼一段字符串，它要负责重新打开命名空间、嵌套类型和目标类型，并保证输出代码可编译。
2026-03-21
第 12 篇可空、泛型与嵌套类型，为什么总是高风险回归点
主路径一旦能跑，最容易被忽略的就是可空、泛型和嵌套类型；而这些恰恰最容易让生成器在真实项目里失效。
2026-03-21
第 13 篇诊断不是附属品，而是生成器契约的一部分
好的生成器不会在非法输入上默默失败，而是会明确告诉调用方为什么不能生成。
2026-03-21
第 14 篇编译级测试，为什么比字符串对比更重要
生成器测试不能只做文本断言，更关键的是验证生成结果是否能编译、诊断是否准确、边界是否被稳稳拦住。
2026-03-21
第 15 篇调试增量源生成器时，先看哪里
排错不要一上来盯着字符串渲染，先按入口、发现、模型、诊断、输出文件这条顺序查。
2026-03-21
第 16 篇做完第一个生成器之后，下一步该扩到哪里
第一个生成器跑通后，真正值得继续扩的方向不是再堆一个特性，而是扩输入边界、配置边界、模板边界和交付边界。
2026-03-20
第 3 篇项目结构与协作关系，要用生成器视角去看
看教程仓库时，不要只看文件树；更重要的是理解生成器项目、示例项目和测试项目之间怎样构成一条完整反馈回路。
2026-03-20
第 6 篇从入口方法看清主管线：生成器真正做了哪几步
入口方法不只是注册几个 API，它其实把整个生成器拆成了特性准备、目标发现、规格生成和源代码输出四个阶段。
2026-03-20
第 9 篇属性怎么选，输出面就怎么长
主案例只选择公开、可读、非索引器、非静态属性，这不是保守，而是在明确生成器的输出面。
2026-03-20
第 11 篇为什么 hint name 不是随便起一个文件名
hint name 决定生成文件的身份边界；对嵌套类型和多目标输入来说，它不是装饰，而是稳定输出的一部分。
2026-03-20
第 17 篇从主案例走向 AdditionalFiles，应该带着哪些能力过去
第二案例不是换一套玩法，而是把主线已经建立的发现、建模、契约和测试能力搬到更复杂的输入系统里。