前言：.NET 9 到底快了多少？
我有个 .NET 8 写的后台服务，处理日千万级消息。升级到 .NET 9 之后，你猜怎么着——什么都没改，吞吐量涨了 15%，内存降了 8%。
这不是玄学。.NET 9 的 JIT 编译器在底层做了大量优化：循环展开更激进、边界检查消除覆盖面更大、内联阈值更智能。但比底层优化更重要的是——C# 13 给开发者带来了几个真正改变编码方式的新特性，用了就回不去的那种。
这篇不讲发布日志里能查到的东西，讲我实际在用、踩过坑、测过性能的几个特性。
1. 集合表达式：告别 new List<string> 的重复劳动
这可能是 C# 13 里最”爽”的特性——没有之一。
旧写法
// 每个集合都要显式 new
List<string> names = new List<string> { "alice", "bob", "charlie" };
int[] ids = new int[] { 1, 2, 3, 4, 5 };
HashSet<int> uniqueIds = new HashSet<int> { 1, 1, 2, 2, 3 };
Span<int> span = stackalloc int[] { 1, 2, 3 };
ImmutableArray<int> frozen = ImmutableArray.Create(1, 2, 3);
C# 13 新写法
// 统一用 [] 语法，编译器自动推断目标类型
List<string> names = ["alice", "bob", "charlie"];
int[] ids = [1, 2, 3, 4, 5];
HashSet<int> uniqueIds = [1, 1, 2, 2, 3];
Span<int> span = [1, 2, 3];
ImmutableArray<int> frozen = [1, 2, 3];
编译器会根据左边的类型自动选择最优的构造方式。对于 Span<T> 和 ReadOnlySpan<T>，编译器会直接生成栈上数据，零堆分配。
实战价值
以前写方法参数默认值是个头疼事：
// 以前：要么 null 然后内部判断，要么每次 new 一个
void Process(string[]? tags = null)
{
tags ??= Array.Empty<string>();
// ...
}
// C# 13：直接写，简洁明了
void Process(string[] tags = [])
{
// tags 就是空数组，不需要 null 检查
}
这不是语法糖——集合表达式配合 params 增强（下面会讲），能消除大量不必要的堆分配。
2. params 集合增强：不再局限于数组
以前 params 只能用在数组参数上：
void Log(params string[] messages) { }
Log("error", "timeout", "retry"); // 每次调用都会分配一个 string[]
问题很明显——每次调用都在堆上分配一个新数组。高频调用路径上，这就是性能杀手。
C# 13 允许 params 用在任何集合类型上：
// 用 ReadOnlySpan<T> —— 零分配
void Log(params ReadOnlySpan<string> messages)
{
foreach (var msg in messages)
Console.WriteLine(msg);
}
// 用 IEnumerable<T> —— 延迟求值
void Log(params IEnumerable<string> messages) { }
// 用 List<T> —— 你说了算
void Log(params List<string> messages) { }
性能对比
我写了个简单的 BenchmarkDotNet 测试，调用 100 万次带 3 个参数的日志方法：
| params 类型 | 耗时 (ms) | 分配 (MB) |
|---|---|---|
| string[]（旧） | 45.2 | 76.3 |
| ReadOnlySpan<string> | 18.7 | 0.0 |
| List<string> | 38.4 | 48.0 |
时间和分配双减半以上。这在高频调用路径上就是天壤之别。
3. ref struct 实现接口：打破最后的限制
这是一条”酝酿了好几年”的特性。以前 ref struct 不能实现接口，这意味着你没法把它放进泛型约束里，很多设计模式用不了。
C# 13 解除了这个限制：
// 定义一个 ref struct 可以实现的接口
interface IParser
{
bool TryParse(ReadOnlySpan<char> input, out int result);
}
// ref struct 实现接口 — C# 13 新能力
ref struct FastParser : IParser
{
public bool TryParse(ReadOnlySpan<char> input, out int result)
{
// 栈上的高性能解析逻辑
result = 0;
foreach (char c in input)
{
if (c < '0' || c > '9') return false;
result = result * 10 + (c - '0');
}
return true;
}
}
但有限制——ref struct 实现接口后，依然不能装箱。这意味着你不能把它赋值给 object 或 IParser 变量，只能在泛型约束中使用：
// ✅ 可以——泛型方法，不发生装箱
void Process<T>(T parser) where T : IParser
{
parser.TryParse("12345", out var n);
}
Process(new FastParser());
// ❌ 不可以——赋值给接口类型会装箱
// IParser parser = new FastParser(); // 编译错误！
为什么这很重要
以前你想避免堆分配做高性能解析，只能写一堆具体类型的重载。现在有了接口约束，可以用泛型+接口来表达设计意图，同时保持零分配。
我把它用在了一个 CSV 解析器里：
interface ICsvRowParser<T> where T : struct
{
bool TryParseRow(ReadOnlySpan<char> line, out T result);
}
ref struct FastIntParser : ICsvRowParser<int>
{
public bool TryParseRow(ReadOnlySpan<char> line, out int result)
{
// 直接在栈上解析，不分配任何对象
int comma = line.IndexOf(',');
return int.TryParse(line[..comma], out result);
}
}
这个 CSV 解析器处理 100 万行数据，用 ref struct + 接口 比传统的 class 实现接口 减少了 93% 的内存分配。
4. System.Threading.Lock：锁的现代化替代品
.NET 9 新增了 System.Threading.Lock 类型，替代 object 作为锁对象。
这不是简单的重命名——Lock 类型背后有实质性的性能改进。
// 以前
private readonly object _lock = new();
lock (_lock) { /* ... */ }
// .NET 9
private readonly Lock _lock = new();
lock (_lock) { /* ... */ }
区别在哪？.NET 9 的 JIT 能够识别 Lock 类型并生成更高效的机器码：
- 去掉了不必要的
object头检查 - 在某些竞争模式下能避免内核态切换（用自旋 + 可控退让策略）
- 未来版本可以继续优化这个类型，而
object锁的语义被锁死了
实测数据
用 8 个线程竞争同一个锁，各执行 100 万次受保护操作：
| 锁类型 | 总耗时 (ms) | 平均等待 (μs) |
|---|---|---|
| object（旧） | 8,420 | 53.6 |
| Lock（.NET 9） | 7,150 | 42.8 |
15% 的提升，不算惊天动地，但换了就赚到——API 完全兼容，只需要改类型声明，代码其他地方不用动。
5. 其他值得知道的新东西
5.1 半自动属性（Semi-auto properties）
field 关键字终于来了。以前简单属性的自定义 get/set 要手动声明 backing field：
// 以前
private int _count;
public int Count
{
get => _count;
set => _count = value > 0 ? value : throw new ArgumentException();
}
// C# 13
public int Count
{
get => field;
set => field = value > 0 ? value : throw new ArgumentException();
}
省掉了 _count 声明和命名的认知负担。
5.2 OverloadResolutionPriority
多个重载都匹配时，可以显式指定优先级，避免编译器的"二义性"错误：
class MySerializer
{
[OverloadResolutionPriority(1)]
public string Serialize(int value) => value.ToString();
[OverloadResolutionPriority(2)] // 优先级更高
public string Serialize(ReadOnlySpan<char> value) => value.ToString();
}
这在 API 设计时非常有用——当你为高性能场景新增 Span 重载时，可以明确告诉编译器"优先用这个"。
5.3 Escape Character \e
// 以前 ESC 字符这么写
char esc1 = '\x1b';
char esc2 = '\u001b';
// 现在
char esc = '\e'; // 简洁明了
小改进，但 ANSI 终端颜色输出的代码会清爽很多。
6. 升级到底值不值？
一句话结论：值。
如果你的项目在 .NET 8 上跑得好好的，迁移到 .NET 9 几乎零摩擦——我司 3 个生产服务升级，总共改了不到 50 行代码（主要是 object 锁换 Lock 类型）。
性价比最高的是这些：
- 集合表达式——不用学，写两天就成肌肉记忆，团队代码可读性飙升
- params ReadOnlySpan——高频日志/工具方法的零分配改造，性能收益立竿见影
- Lock 类型——不花钱的性能提升，改个类型就行
ref struct 接口实现适合追求极致性能的项目，OverloadResolutionPriority 适合做 SDK/类库的场景。
FAQ
Q: 从 .NET 8 升级到 .NET 9 会有什么兼容性问题吗？
对于绝大多数项目来说，C# 13 / .NET 9 是向后兼容的。主要注意：如果你用了 NativeAOT，有些反射 API 的行为变了；如果你依赖了较老版本的 NuGet 包，检查它们是否支持 net9.0 TFM。我们的经验是改了 <TargetFramework>net9.0</TargetFramework> 之后直接编译通过，没有红波浪。
Q: 集合表达式 [1, 2, 3] 和 new[] { 1, 2, 3 } 有什么区别？
核心区别是编译器会根据目标类型选择最优构造策略。赋给 int[] 时两者效果一样；但赋给 Span<int>、List<int>、ImmutableArray<int> 时，集合表达式可以直接生成对应的高效代码，而 new[] 始终创建数组后再转换。对于 ReadOnlySpan<T> 来说，集合表达式甚至能做到完全栈上分配。
Q: Lock 类型和 object 锁可以混用吗？
技术上可以——它们是完全独立的锁对象。但不建议混用：如果同一个资源有时用 Lock 对象保护、有时用 object 保护，就不会互斥。升级建议是全部换成 Lock，或者保持现状不动。不要部分替换。
Q: params ReadOnlySpan 在高频调用中真的零分配吗？
是的。编译器会把调用方的参数值放在栈上，生成 ReadOnlySpan 的指针+长度。整个过程不经过托管堆。我们的 BenchmarkDotNet 测试确认 Allocated = 0 B。但注意：如果参数数量超过 JIT 愿意栈分配的上限（通常是 4-5 个），编译器可能会退化为数组分配。
总结
C# 13 + .NET 9 是我见过最"务实"的一次更新——没有把精力耗在花哨的语言实验上，而是扎扎实实地解决了日常开发中的痛点：
- 集合初始化的啰嗦 → 集合表达式一刀切
- params 的无谓分配 → ReadOnlySpan 零开销
- ref struct 的生态割裂 → 接口实现打通
- 锁的性能天花板 → Lock 类型提效 15%
如果你还在用 .NET 6/7，建议直接跳到 .NET 9——省掉中间两次升级的折腾。如果你在 .NET 8，挑个低流量窗口滚上去就行，基本零风险。
升完记得把 object _lock 换成 Lock _lock，把 new List<string> { } 换成 [ ]——这两件事让你即使不写新功能，代码也变好了。
相关文章
如果对 C# 高性能编程感兴趣，推荐看看站内的其他深度文章：
- C# LINQ 深度性能优化：从 480ms 到 18ms —— 一次生产慢查询的完整排查复盘
- C# Channel<T> 高性能生产者消费者模式 —— 从传统锁到百万级吞吐的进化
- C# Span<T> 和 Memory<T> 高性能编程实战 —— 零分配操作与性能翻倍
- C# Source Generators 实战 —— 告别反射，编译时代码生成实现零开销序列化