ProjectReference 跑通，不等于 PackageReference 可交付

这是源生成器模板最容易被误判的一步。

很多人看到 sample 已经通过 ProjectReference 正常生成代码，就自然会得出一个结论：

这套模板可以交付了。

实际上，这个结论通常还早了一步。

ProjectReference 证明的到底是什么

ProjectReference 能证明的是：

• 生成器项目本身能编译
• sample 项目能在本地开发链路里引用它
• 最小配置和生成结果是活的

这一步非常重要，但它证明的只是“开发期联调成立”。

PackageReference 额外暴露哪些问题

一旦进入 PackageReference，验证对象就变了。

你需要确认的不再只是代码会不会生成，还包括：

• nupkg 里有没有把 analyzer 和 generator 正确收进去
• 包版本、包名和依赖有没有配对
• NuGet.Config 指向的源能不能正常恢复
• 外部消费者在没有项目源代码上下文时，是否还能拿到相同结果

这些都不是 ProjectReference 能替你证明的。

为什么很多问题只会在最后一步才暴露

因为 ProjectReference 共享的是本地项目图。

而 PackageReference 共享的是打包后的交付物。

这两个阶段看到的世界并不一样。

前者更适合开发联调，后者才是真正面对消费者的现实形态。

所以你会看到一种很典型的情况：

• sample 能跑
• 测试也通过
• 但 pack 之后，consumer restore 失败或者生成器没有生效

这不是异常，而是说明你终于开始验证真正的交付边界了。

更稳的验证顺序

如果要判断一个模板是否真的具备交付能力，更稳的顺序应该是：

1. dotnet test
2. dotnet run sample
3. dotnet pack
4. dotnet restore package consumer
5. dotnet run package consumer

少任何一步，你都只是在验证局部成立。

一句话结论

ProjectReference 只能证明模板在本地开发链路里活着；只有把 pack -> restore -> run consumer 整条链路走通，才谈得上真正可交付。