你是否曾经为了重复的代码模板而感到厌烦？是否想过让编译器帮你自动生成代码？今天我要分享一个C#开发中的"黑科技"——源生成器（Source Generator）。这项技术可以在编译时自动生成代码，不仅能提升开发效率，还能减少运行时反射的性能开销。本文将通过一个完整的实战案例，带你掌握这项强大的技术。
🔍 问题分析：为什么需要源生成器？
在日常C#开发中，我们经常遇到这些痛点：
重复代码问题：比如属性通知、序列化代码、API接口包装等，大量模板化代码需要手写。
运行时反射开销：传统的代码生成依赖反射，会带来性能损耗。
编译时安全性：动态生成的代码缺乏编译时检查，容易出现运行时错误。
代码维护困难：手写的模板代码增加了维护成本。
源生成器完美解决了这些问题，它在编译时分析你的代码，然后自动生成需要的代码片段，既保证了性能，又提供了编译时安全性。
💡 解决方案：Source Generator核心机制
源生成器基于Roslyn编译器平台，工作流程如下：
- 编译时触发：在编译过程中，生成器被调用
- 语法分析：分析现有代码的语法树
- 代码生成：根据分析结果生成新的代码文件
- 注入编译：将生成的代码加入到编译过程中
还在为重复的代码模板而烦恼？还在手动维护数百个属性访问器？作为.NET开发者，我们经常遇到这样的痛点：大量重复且机械的代码编写工作不仅效率低下，还容易出错。今天要分享的C# Source Generators技术，将彻底改变你的开发方式——让编译器在编译时自动生成代码，告别重复劳动，拥抱高效开发！
本文将从实际问题出发，深入剖析Source Generators的核心逻辑与实现方式，并提供完整的实战代码示例，助你快速掌握这项"让代码自己写代码"的强大技术。
🔍 问题分析：开发痛点深度剖析
传统开发的三大痛点
痛点一：模板代码泛滥
C#// 传统方式：每个实体类都需要手写这些重复代码
public class User
{
private string _name;
public string Name
{
get => _name;
set
{
if (_name != value)
{
_name = value;
OnPropertyChanged(nameof(Name));
}
}
}
// 还有几十个属性要这样写...
}
痛点二：维护成本高昂
当业务模型变化时，相关的序列化、映射、验证代码都需要同步修改，容易遗漏且出错率高。
痛点三：运行时反射性能损耗
传统的动态代码生成依赖反射，在高并发场景下会成为性能瓶颈。
👺解决方案：Source Generators 的思路与架构
- 核心思想：在编译时（Roslyn 编译流程中）读取源代码语法树与语义模型，根据约定或标注生成新的 C# 源文件，最终参与编译。
- 优点：
- 零运行时开销：生成代码在编译时就已经生成并编入程序集。
- 强类型、可调试：生成的是普通 C# 文件，可以在 IDE 中查看和调试。
- 可扩展与可组合：可通过属性标注（Attribute）或约定（Convention）来控制生成行为。
- 关键组件：
- Generator 类：实现
ISourceGenerator或新版IIncrementalGenerator。 - 语法/语义分析：使用
SyntaxReceiver或增量管线收集目标节点。 - 模板/代码构建：使用字符串拼接、
StringBuilder，或更强的 Code DOM 模板（如 Scriban）生成代码。 - 测试与发行：单元测试生成结果、打包为 NuGet 提供给团队复用。
- Generator 类：实现
💡 Source Generators：编译时代码生成的完美解决方案
🌟 核心优势
- 编译时生成：零运行时开销，性能最优
- 强类型支持：生成的代码享受完整的IntelliSense和编译时检查
- 无侵入性：不影响现有代码结构
- 高度可定制：基于Roslyn语法树，灵活性极强
你是否遇到过这样的困扰：明明写好了Source Generator，编译时却不按预期执行？或者多个Generator之间相互干扰，输出结果混乱？这些问题的根源往往在于对Source Generator底层执行机制的理解不足。
本文将带你深入C# Source Generator的内核，从编译器视角揭秘代码生成的完整流程。通过实战案例和关键节点分析，让你彻底掌握Generator的执行顺序和最佳实践，轻松避开常见陷阱。
🎯 问题分析：为什么要深入了解执行顺序？
常见痛点
在实际开发中，开发者经常遇到这些问题：
- 生成时机混乱：不知道Generator何时执行，导致依赖关系处理不当
- 多Generator冲突：多个Generator同时工作时出现意外结果
- 性能问题：Generator执行效率低下，拖慢编译速度
- 调试困难：无法准确定位Generator执行过程中的问题
这些问题的核心在于缺乏对Source Generator执行机制的深度理解。
💡 解决方案：揭秘编译器执行流程
🚀 Roslyn编译器中的Generator执行阶段
C# Source Generator并非独立运行，而是深度集成在Roslyn编译器的管道中：
text源码解析 → 语法分析 → 语义分析 → Generator执行 → 代码合并 → IL生成
内存泄露是指在程序运行过程中，已分配的内存由于某些原因未能释放，导致随着程序的运行时间越长，占用的内存越多，最终可能导致程序运行缓慢甚至崩溃。在 C# .NET 环境中，尽管有垃圾回收（GC）机制帮助管理内存，但仍有一些情况会导致内存泄露。本文将通过示例探讨几种常见的内存泄露情况及其应用场景，并提供测试方法。
事件订阅未取消
应用场景
在 .NET 中，事件是实现对象间通信的一种机制。如果订阅者对象订阅了发布者对象的事件，但在不再需要时未取消订阅，那么发布者将持续持有订阅者的引用，导致订阅者对象无法被垃圾回收。
示例
C#// 定义一个事件发布者类
public class EventPublisher
{
// 声明一个事件，使用 EventHandler<TEventArgs> 委托，这里的事件数据类型为 EventArgs
public event EventHandler<EventArgs> MyEvent;
// 触发事件的方法
public void RaiseEvent()
{
// ?.Invoke 安全地触发事件。如果 MyEvent 不为 null，则调用所有订阅者的方法
MyEvent?.Invoke(this, EventArgs.Empty);
}
}
// 定义一个事件订阅者类
public class EventSubscriber
{
// 在构造函数中订阅事件
public EventSubscriber(EventPublisher publisher)
{
// 订阅 publisher 发布的 MyEvent 事件
publisher.MyEvent += Publisher_MyEvent;
}
// 事件处理方法，当事件被触发时执行
private void Publisher_MyEvent(object sender, EventArgs e)
{
// 输出消息表示事件已接收
Console.WriteLine("Event received.");
}
}
// 测试代码
var publisher = new EventPublisher();
var subscriber = new EventSubscriber(publisher);
publisher.RaiseEvent();
// 此时应取消订阅，否则 subscriber 无法被 GC 回收
// publisher.MyEvent -= subscriber.Publisher_MyEvent;
在 .NET 应用程序中，提高执行效率和响应速度是开发者追求的目标之一。随着多核处理器的普及，利用并行编程来充分利用多核处理器的能力成为了提高应用程序性能的有效手段。System.Threading.Tasks.Parallel 类提供了一种简单而强大的并行编程模型，使得开发者能够更加方便地实现并行操作。
本文将介绍 Parallel 类的基本用法，并通过几个实例展示如何在 .NET 应用中使用 Parallel 来提升性能。
应用场景
Parallel 类适用于以下几种场景：
- 数据并行处理：当需要对数据集合中的每个元素执行相同的操作时，可以使用数据并行来加速处理过程。
- 并行任务执行：当有多个相互独立的任务需要执行时，可以并行地执行这些任务以减少总体执行时间。
示例 1：并行循环
假设我们需要对一个整数数组的每个元素执行计算密集型操作。
串行实现
C#int[] numbers = Enumerable.Range(1, 1000000).ToArray();
// 串行处理
var watch = Stopwatch.StartNew();
foreach (var num in numbers)
{
// 执行某些计算密集型操作
Compute(num);
}
watch.Stop();
Console.WriteLine($"串行执行时间: {watch.ElapsedMilliseconds} ms");
