企业官网建设流程全解析

ZLinq 这个名字对很多 C# 开发者来说已经不陌生。它瞄准的是一个高频痛点：LINQ 写起来确实爽，但每次查询背后那些委托分配、迭代器状态机、装箱拆箱和中间集合，在性能敏感场景里很容易变成隐患。零分配 LINQ 方案的思路就是尽量消除这些代价，让查询代码保持声明式风格，同时把 Hot Path 上的内存开销压到接近手写循环的水平。

这篇文章会从 LINQ 的性能成本出发，先解释为什么普通 LINQ 会慢，再介绍零分配方案的优化思路，然后给出一个可运行的最小示例，配合 BenchmarkDotNet 做基准验证，最后拆解实现原理，补齐常见坑、排查路径和生产环境使用建议。适合对 LINQ 有一定使用经验、想深入理解查询性能瓶颈、或者正在为高并发服务做 GC 优化的开发者阅读。学完以后，你可以判断自己的项目里哪些 LINQ 值得换掉，哪些保持原样反而更好。

1. 先理解普通 LINQ 查询到底慢在哪里

很多团队把 LINQ 当作业务代码的默认写法，理由很充分：可读性好、表达力强、和 SQL 思维接近。但一旦 QPS 上来，GC 压力和 CPU 耗时开始变得刺眼，问题就会集中暴露在几个固定的地方。

1.1 委托分配：每个 Where、Select 都在悄悄创建对象

LINQ 的Where、Select、OrderBy、Aggregate等方法接收的是委托。常规写法中，lambda 表达式如果捕获了外部变量，编译器会生成一个闭包对象；即使没有捕获外部变量，在某些调用方式下也可能产生额外的委托包装。

从代价上看，单个委托对象并不大，但放在每秒执行几十万次的查询链里，累积的分配量就相当可观。每个委托分配都会增加 GC 压力，GC 频率升高后，应用响应时间就会出现毛刺。

// 常见写法：lambda 捕获 count，编译器会生成闭包 var result = items.Where(x => x.Value > count) .Select(x => x.Name); // 语义相同的零捕获写法：可能被缓存为静态委托 var result = items.Where(static x => x.Value > 10) .Select(static x => x.Name);

这里的关键点是：staticlambda 自 C# 9 起允许使用，它不会创建闭包。但这只是第一层优化，普通 LINQ 本身还会继续产生后续开销。

1.2 迭代器状态机：yield 的便利背后是复杂的状态机类

几乎每个 LINQ 操作符都基于迭代器实现。编译器遇到yield return或yield break时，会生成一个实现了IEnumerable<T>和IEnumerator<T>的状态机类。

这个状态机内部要维护：

• 当前状态字段
• 当前元素字段
• 线程 ID 字段（用于区分首次枚举和后续枚举）
• 捕获的局部变量
• 被捕获的外部参数

这意味着，哪怕只是一个Where加一个Select，枚举过程也会创建两个或多个迭代器对象。在集合元素非常多、查询链路很长的场景下，这比委托分配的影响更直接。

// 自定义迭代器：表面上是简单的筛选，实际生成一个状态机类 public static IEnumerable<int> WhereGreaterThan(IEnumerable<int> source, int threshold) { foreach (var item in source) { if (item > threshold) { yield return item; } } }

表面看这段代码很自然，但每次调用都会创建状态机实例。枚举过程中MoveNext还要负责状态跳转、当前值赋值、异常恢复等逻辑，CPU 指令数并不低。

1.3 装箱：值类型在接口调用中被反复包装

C# 的泛型在 JIT 层面已经能做到值类型专用化，但一旦值类型被当作IEnumerable、IEnumerator、IComparer等非泛型接口使用，就会发生装箱。

这种问题最容易出现在：

• 对ArrayList这类非泛型集合做 LINQ
• 自定义值类型实现了泛型接口，但在某些重载中被推断成非泛型接口
• 比较器、选择器等委托返回object
• 使用了老的IEnumerable重载或foreach非泛型模式

装箱的代价不只是多一个对象，还包括分配、GC 回收以及后续拆箱时的类型检查。对高频小对象集合来说，装箱往往比委托分配更隐蔽。

1.4 中间集合和重复枚举：查询链越长，浪费越大

普通 LINQ 的执行模型是拉取式的。每个操作符都只做一件事，数据从一个操作符流到下一个操作符。这个设计本身很优雅，但遇到OrderBy、GroupBy、Distinct这类需要缓冲全部或部分元素的操作符时，内部会分配数组、哈希表或临时集合。

还有一种典型的浪费是重复枚举。同一个IEnumerable<T>被Count()一次、ToArray()一次、foreach一次，如果源不是ICollection<T>，每次枚举都会重新执行整个上游查询链。

// 重复枚举：nums 如果来自 Select 的惰性序列，每个聚合都会重新执行前面步骤 var nums = items.Select(ConvertToNumber); var totalCount = nums.Count(); var firstList = nums.Take(10).ToArray();

这些浪费叠加起来，最终表现就是：业务代码功能正常、可读性也好，但 GC 频率高、CPU 占用大、调用链越深越明显。

理解了这些来源，才能明白零分配 LINQ 方案不是玄学，而是针对这些固定分配点逐个做优化。

2. 零分配 LINQ 的核心思路：用 Enumerator 代替 Enumerable

ZLinq 这类方案的出发点很简单：默认 LINQ 把“可枚举的集合”作为抽象核心，而零分配 LINQ 把“可枚举的过程”作为抽象核心。

2.1 从 IEnumerable 到 Enumerator 的范式切换

普通 LINQ 的操作对象是IEnumerable<T>，它描述的是“这段数据可以被枚举”，但不保证枚举时是否产生新对象。

零分配方案的思路是直接操作Enumerator，也就是枚举器。枚举器是一个轻量结构体，它内部保存状态和当前值，MoveNext向前推进，Current返回当前元素。值类型枚举器可以被 JIT 内联和专用化，不需要接口调用，也就不用为每次枚举分配状态机对象。

用一句话概括：普通 LINQ 返回“一个可以继续查的数据源”，零分配 LINQ 返回“一个正在查询的数据流”。前者容易链式组装，后者更容易消除中间对象。

2.2 与 Span、ref struct 的设计哲学一脉相承

C# 7.2 引入ref struct后，C# 终于有了“只能存在于栈上”的类型。Span<T>、ReadOnlySpan<T>都是ref struct，它们不能装箱、不能进堆、生命周期受栈限制。

零分配 LINQ 的 Enumerator 设计正是沿用了这个思路：通过ref struct保证枚举器不会被无意中装箱或捕获到堆上，从而从语言层面强制避免一部分分配。

// 伪代码风格：说明 Enumerator 大致形状，实际实现要看具体库 public ref struct Enumerator<T> { private readonly Source<T> _source; private T _current; private int _state; public readonly T Current => _current; public bool MoveNext() { // 不分配任何对象，直接推进状态 } }

这解释了为什么零分配 LINQ 不是简单的 API 改名，而是要把查询操作从“对象图”改成“结构化状态机”。

2.3 ZLinq 这类方案的位置：不是替代 LINQ，而是补足极端场景

要清楚一点：零分配 LINQ 不会取代标准 LINQ。标准 LINQ 的优势是兼容性、生态、动态查询和简单场景下的可读性。零分配 LINQ 更偏向高性能路径。

适用场景包括：

• 游戏服务端、实时通信服务、网关等每请求处理大量小集合的模块
• 长时间运行的批处理任务，GC 停顿直接影响系统吞吐
• Unity 或客户端项目中需要控制 GC Alloc 的 Update 循环
• 数值计算、日志聚合、指标统计等高频循环
• 对已有集合做链式过滤、映射、聚合，但不要求每次重新生成集合

不适用或不需要替换的场景包括：

• 业务代码里一次查询只执行几次，且集合很小
• 需要使用查询表达式语法连接大量操作符
• 需要把查询对象保存、到处传递、延迟到别处执行
• 需要和 Entity Framework 等查询提供器一起工作

这里建议做个简单判断：如果当前代码的瓶颈不是 GC 或循环内部耗时，引入零分配方案并不会带来可感知收益，反而可能降低代码通用性。

3. 环境准备与最小可运行案例

下面用一个控制台项目展示 ZLinq 风格的基本用法。考虑到不同时期库的 API 可能变化，这里先给出通用的项目准备思路，再提供能说明核心概念的示例代码。

3.1 创建控制台项目和目录结构

建议使用 .NET 8 或更高版本，因为ref struct泛型支持、静态抽象接口等特性在较新版本里更完整。

dotnet new console -n ZLinqDemo cd ZLinqDemo dotnet add package ZLinq dotnet build

如果包名或版本无法匹配，可以用 Visual Studio 的 NuGet 包管理器搜索 ZLinq，选择稳定版本。实际项目中不要盲目引用最新版本，先确认目标框架兼容性。

项目结构保持简单：

ZLinqDemo/ ├── Program.cs ├── ZLinqDemo.csproj └── Models/ └── Order.cs

3.2 准备一组测试数据模型

为了体现实际业务场景，用订单数据做例子。订单包含客户名、金额、城市和下单时间。

namespace ZLinqDemo.Models; public sealed class Order { public int Id { get; init; } public string Customer { get; init; } = ""; public decimal Amount { get; init; } public string City { get; init; } = ""; public DateTime CreatedAt { get; init; } }

生成测试数据时，可以模拟一批真实度较高的订单，比如 10 万条，分布在不同城市和金额区间。

static List<Order> GenerateOrders(int count) { var cities = new[] { "上海", "北京", "深圳", "杭州", "成都" }; var random = new Random(42); var list = new List<Order>(count); for (var i = 0; i < count; i++) { list.Add(new Order { Id = i, Customer = $"Customer{i % 1000}", Amount = random.Next(100, 10000), City = cities[i % cities.Length], CreatedAt = DateTime.Now.AddDays(-random.Next(1, 30)) }); } return list; }

3.3 用 ZLinq 风格写一段查询并输出结果

为了演示，假设要统计“杭州地区金额大于 5000 的订单总金额”。先写一个普通 LINQ 版本：

var result = orders .Where(o => o.City == "杭州" && o.Amount > 5000) .Select(o => o.Amount) .Sum();

再写一个 ZLinq 风格版本。不同版本的 API 命名可能略有差异，但如果库遵循 Enumerator 模式，通常会有AsEnumerable()或AsSpan()这类入口，然后提供类似 LINQ 的链式方法：

using ZLinq; var result = orders .AsValueEnumerable() .Where(o => o.City == "杭州" && o.Amount > 5000) .Select(o => o.Amount) .Sum();

运行后可以确认两个结果一致。这个最小示例的意义在于：先把 API 形态和使用方式跑通，再进入基准测试，避免一开始就陷入复杂的性能分析。

注意：示例代码中的 API 名称以实际安装版本为准。开源库的命名空间和方法名可能在不同版本间调整，落地前先检查包文档或 IntelliSense 提示。

4. 用 BenchmarkDotNet 验证性能差异

没有基准测试就没有说服力。建议用 BenchmarkDotNet 来对比普通 LINQ、手动循环和 ZLinq 这三种实现。

4.1 安装 BenchmarkDotNet

dotnet add package BenchmarkDotNet

建议把基准项目设置为 Release 模式运行，并且不要在调试器下执行，否则结果会失真。

4.2 编写三类基准方法

using BenchmarkDotNet.Attributes; using BenchmarkDotNet.Running; using ZLinq; using ZLinqDemo.Models; public class LinqBenchmark { private List<Order> _orders = null!; [Params(100_000)] public int Count { get; set; } [GlobalSetup] public void Setup() { _orders = GenerateOrders(Count); } [Benchmark(Baseline = true)] public decimal StandardLinq() { return _orders .Where(o => o.City == "杭州" && o.Amount > 5000) .Select(o => o.Amount) .Sum(); } [Benchmark] public decimal ManualLoop() { decimal sum = 0; foreach (var order in _orders) { if (order.City == "杭州" && order.Amount > 5000) { sum += order.Amount; } } return sum; } [Benchmark] public decimal ZLinqQuery() { return _orders .AsValueEnumerable() .Where(o => o.City == "杭州" && o.Amount > 5000) .Select(o => o.Amount) .Sum(); } }

[Params(100_000)]表示每种方法都跑在 10 万条数据上，[Benchmark(Baseline = true)]会把普通 LINQ 作为基准。

4.3 运行基准并读懂输出

dotnet run -c Release

输出中重点看三列：

• Mean：平均执行时间
• Allocated：单次操作分配的内存量（重点关注）
• Ratio：相对基准的耗时比例

在典型情况下，可以看到普通 LINQ 的 Allocated 明显高于 ZLinq，手动循环的 Allocated 接近零，但 ZLinq 在耗时上可能比手动循环更接近。具体数值取决于 .NET 版本、JIT 优化、集合类型和查询复杂度，不能一概而论。

需要提醒的是：BenchmarkDotNet 的结果是相对参考，不是绝对性能承诺。升级 .NET 版本后，普通 LINQ 本身也在持续优化，某些场景下的差距可能缩小。

4.4 为什么建议同时保留手写循环基准

零分配 LINQ 的定位是“尽量接近手写循环”，而不是“一定超过手写循环”。在基准里同时保留手动循环，是为了确认两件事：

一是 API 是否真的没有引入额外分配； 二是性能差距是否在可接受范围内。

如果某个查询链在 ZLinq 下依然产生明显分配，就要回头检查：是否用了需要缓冲的操作符（OrderBy、GroupBy），是否捕获了变量导致闭包，是否源集合本身不支持零分配枚举。

5. 深入原理：零分配 LINQ 是怎么做到的

这一部分解释为什么零分配 LINQ 能减少分配。不是所有库都采用完全相同的实现，但核心思路可以拆成几个层次。

5.1 结构体枚举器：让 MoveNext 直接内联

普通 LINQ 的迭代器是类，调用MoveNext()是接口调用或虚方法调用，JIT 不一定能内联。零分配方案把枚举器定义为ref struct，它没有虚方法表，JIT 可以很容易把它内联到调用点。

// 示意代码：非真实库实现 public ref struct WhereEnumerator<T> { private readonly ReadOnlySpan<T> _source; private readonly Func<T, bool> _predicate; private int _index; public bool MoveNext() { while (_index < _source.Length) { var item = _source[_index]; _index++; if (_predicate(item)) { Current = item; return true; } } return false; } }

MoveNext内联后，整个查询链的每个步骤都可能在 CPU 指令流水线里连续执行，省掉了大量间接分支调用。

5.2 静态委托与 Lambda 缓存：避免闭包分配

在零分配 LINQ 的实现中，Where、Select等操作符接收的谓词和选择器会尽可能使用编译器缓存。如果 lambda 没有捕获外部变量，它可以被缓存在静态字段上，一直复用同一个委托实例。

使用时也需要配合：

// 好的用法：不捕获外部变量，避免闭包 .AsValueEnumerable() .Where(static o => o.Amount > 5000) // 一般用法：捕获 threshold，会产生闭包 .AsValueEnumerable() .Where(o => o.Amount > threshold)

如果确实需要传外部参数，可以改用专门的重载，把参数和谓词一起传入，让谓词变成结构体的一部分，而不是闭包对象。

5.3 切片和原生集合支持：减少中间对象

源集合如果是数组、List<T>、Span<T>，零分配 LINQ 通常可以直接拿到连续内存或专用枚举器，不需要包一层IEnumerable<T>。

int[] numbers = { 1, 2, 3, 4, 5 }; // 数组可以直接产生专用枚举器 var query = numbers .AsValueEnumerable() .Where(static x => x % 2 == 0) .Select(static x => x * 10);

对于List<T>，还可以通过CollectionsMarshal.AsSpan()拿到内部数组的 Span，进一步减少边界检查。

var span = System.Runtime.InteropServices.CollectionsMarshal.AsSpan(list); var query = span.AsValueEnumerable();

5.4 有状态操作符的代价评估

Where、Select、Take、Skip这类流式操作符可以做到零分配。但OrderBy、GroupBy、Distinct、Reverse这些操作符天然需要保存中间结果。零分配方案通常会把中间结果放在ArrayPool或复用缓冲区中。

这意味着：

• 对于纯流式查询，零分配优势明显。
• 对于带排序、分组、去重的查询，分配量会回升，但可能比普通 LINQ 更可控，因为使用了池化缓冲区。
• 使用完枚举器后，如果库提供了Dispose或返回缓冲区的方法，应当正确调用，否则池中的数组无法归还。

5.5 编译期泛型专用化：每种元素类型都有专门代码

普通 LINQ 的泛型虽然有 JIT 专用化，但操作符组合后还是运行时构建调用链。零分配方案更强调编译期类型组合：Where<WhereEnumerator<int>, Func<int, bool>>和Where<WhereEnumerator<string>, Func<string, bool>>在编译期就是不同的类型，JIT 可以分别优化，互不干扰。

这是一个很大的优势。复杂查询链在普通 LINQ 里可能涉及很多运行时接口调用，在零分配方案里则变成一组嵌套结构体的直接调用。

6. 常见问题与排查路径

实际使用零分配 LINQ 时，会遇到一些和普通 LINQ 不同的问题。下面按现象、原因、检查方式、解决方案来整理。

6.1 查询结果和普通 LINQ 不一致

现象：同样的逻辑，用 ZLinq 写出来的结果和普通 LINQ 不一样。

可能原因：

• 操作符语义差异。例如Select和SelectMany的使用方式没有对齐。
• 谓词里包含副作用。普通 LINQ 和零分配方案的执行顺序或执行次数不同。
• 比较器不一致。默认比较器在不同实现里可能有差异。
• API 版本变化，命名类似但行为不同。

检查方式：先把两个查询的输入缩小到几十条数据，打印每一步的中间结果。用相同的随机种子和相同数据集对比。

解决方案：以普通 LINQ 的结果为参照，逐段排查。生产项目中可以在关键路径两侧分别记录结果摘要，做一个短期的灰度校验。

注意：不要在谓词或选择器里修改外部状态。LINQ 的惰性求值意味着你的副作用可能被执行多次或零次，零分配 LINQ 对执行顺序的优化会放大这个问题。

6.2 出现 CS8340 或 ref struct 相关编译错误

现象：提示“instance of ref struct cannot be used”或类似错误。

可能原因：使用ref struct枚举器作为返回值后，编译器发现它被放进了接口、异步方法或 lambda 中。

检查方式：查看报错所在的代码行，看是否把枚举器赋值给了var后在 lambda 中使用，或者把包含枚举器的方法标记为async。

解决方案：

• 枚举器只应在方法内部短生命周期使用。
• 不要把它存到字段、数组或容器中。
• 不要在async方法中使用。
• 如果必须返回，可以返回结构体包装类型，但要避免逃逸到堆。

6.3 分配量没有下降，甚至比普通 LINQ 还高

现象：基准测试显示 Allocated 没有显著降低。

可能原因：

• 查询链中包含OrderBy、GroupBy等需要缓冲的操作符。
• lambda 捕获了外部变量，闭包依然分配。
• 源集合不是数组、List<T>或Span<T>，而是普通的IEnumerable<T>。
• 没有启用 Release 模式运行，或 JIT 没有进行优化。
• 库版本较老，对某种集合类型的支持不完整。

检查方式：

• 用 BenchmarkDotNet 单独测每个操作符。
• 查看闭包分配：把 lambda 改成static后比较 Allocated。
• 检查集合静态类型，确认确实是数组或List<T>而不是接口。

解决方案：

• 把大查询拆成两个阶段：先做流式过滤，再做缓冲操作。
• 上游如果需要传入参数，尽量使用参数化结构体重载。
• 对于IEnumerable<T>源，先ToArray()或ToList()，再进入零分配查询。

6.4 调试时看不到中间值，无法跟踪查询链

现象：普通 LINQ 中可以用 foreach 遍历中间结果，但零分配枚举器不方便直接查看。

可能原因：ref struct不能作为IEnumerable使用，所以调试器的“结果查看”支持有限。

检查方式：在关键步骤之间显式调用一个调试方法，或者临时把.ToArray()加在某个步骤后用 Debugger 查看。

解决方案：临时把链式调用拆开，分步保存中间结果并ToArray()。确认逻辑正确后，再合并回链式写法，并删除临时ToArray()。

// 调试时可以先这样拆开 var filtered = orders.Where(o => o.City == "杭州").ToArray(); var selected = filtered.Select(o => o.Amount).ToArray();

6.5 排查优先级

遇到性能或编译问题时，按这个顺序排查：

1. 先确认是否在 Release 模式下测试。
2. 确认源集合的具体类型，避免接口装箱。
3. 替换staticlambda，排除闭包。
4. 逐个操作符检查是否产生缓冲。
5. 确认枚举器生命周期没有逃逸到堆。
6. 查看基准测试的 Allocated 列，确认优化是否生效。
7. 最后再对比 CPU 耗时，避免只关注单一方面。

7. 生产环境使用建议与最佳实践

零分配 LINQ 能不能引入生产环境，取决于项目对 GC 的敏感度、团队的熟悉程度以及 API 的稳定性。

7.1 从收益最大、风险最小的代码开始替换

推荐选取满足以下条件的代码：

• 每天被调用数十万次以上
• 查询逻辑简单，以Where、Select、Sum、Any等流式操作符为主
• 源集合是数组或List<T>
• 不依赖查询表达式语法
• 有现成的单元测试或基准测试可以对比

不建议一上来就改造整个项目。先把两三个高频方法改掉，通过预发环境的 GC 指标和响应时间验证收益，再逐步扩展。

7.2 保持查询逻辑可读，避免过度优化

零分配 LINQ 的好处是保留链式调用，但复杂度仍然可能上升。如果一个查询链超过 5 个操作符，可读性会明显下降，此时建议拆成命名方法或分步查询。

private static decimal SumHangzhouHighValue(ReadOnlySpan<Order> orders) { return orders .AsValueEnumerable() .Where(static o => o.City == "杭州") .Where(static o => o.Amount > 5000) .Select(static o => o.Amount) .Sum(); }

保留语义清晰的命名，比一味追求链式函数式风格更重要。

7.3 对第三方库 API 做好版本锁定和回归测试

开源库的 API 变动可能比想象中频繁。在 csproj 中锁定大版本，并在 CI 中加入基准对比任务，发现分配量或吞吐明显退化时及时更新依赖。

<PackageReference Include="ZLinq" Version="1.*" />

这里Version="1.*"只锁定主版本。如果团队对稳定性要求更高，可以固定到精确版本，并单独维护依赖升级分支。

7.4 区分流式操作和缓冲操作

写代码前先做一个快速分类：

流式操作符：Select、Where、Take、Skip、Any、All、Contains缓冲操作符：OrderBy、GroupBy、Distinct、Reverse、ToArray、ToList

一个实用的设计是：查询链先用流式操作把数据缩小，再做缓冲操作。例如先Where过滤，再OrderBy排序，避免对全量数据集排序。

7.5 与 ArrayPool 配合时的内存归还

如果库使用ArrayPool管理中间缓冲区，需要确保枚举器使用完毕后正确释放。部分实现可能通过Dispose方法归还数组，如果你提前 break 退出循环，也要让 dispose 被调用。

// 使用 using 确保 Dispose 被调用 using var enumerator = source.AsValueEnumerable().GetEnumerator(); while (enumerator.MoveNext()) { var item = enumerator.Current; if (item == stopToken) { break; } }

另外，ref struct枚举器放进using时，调用位置不要跨越多个同步块，避免隐藏的对象逃逸。

7.6 基准测试要长期保留

性能优化最怕回退。建议在仓库中保留一个 benchmarks 项目，每次依赖升级或 .NET 版本升级时跑一遍，观察 Mean 和 Allocated 的变化。这类回归通常比功能测试更能暴露外部库升级带来的问题。

dotnet run -c Release --project benchmarks/ZLinq.Benchmarks

如果团队有 CI 资源，可以把基准测试脚本化，输出对比结果到构建日志，人工在合并前确认。

8. 总结与下一步扩展方向

零分配 LINQ 的核心价值不是让所有 LINQ 都变快，而是让高频查询路径上的分配可控。通过结构体枚举器、静态委托、Span 支持和泛型专用化，它把普通 LINQ 的分配成本降下来，同时保留声明式查询的可读性。

如果你的项目 GC 压力明显、调用链中有大量简单集合查询，建议按这篇文章的顺序做一次验证：先建基准项目，对比普通 LINQ、手动循环和 ZLinq，确认收益后再替换关键路径。不要把零分配 LINQ 视为普通 LINQ 的替代品，而是把它当作工具箱里一个新工具：在正确场景、正确约束下使用，收益才真正可观。

下一步可以沿着这些方向继续深入：

• 阅读 ZLinq 源码，理解它如何用结构体嵌套实现操作符组合
• 学习ref struct泛型、静态抽象接口、INumber<T>等在 .NET 8 中的新语法
• 尝试把List<T>通过CollectionsMarshal.AsSpan()接入更多零分配路径
• 研究Channel、Pipe等流式场景下如何与枚举器模式结合
• 在项目里建设一套基准测试流水线，把分配量作为性能回归的检查项

对于刚接触这个主题的开发者，最值得做的一件事，不是把线上代码立即换掉，而是先写一个 BenchmarkDotNet 小项目，亲手确认“零分配”到底是怎么回事。只有自己在数据上看到差异，后续选型才有依据。