GC.TryStartNoGCRegion 为什么不能随便用
它不是“开启无 GC 模式”的开关，而是向运行时申请一段内存预算，在此期间若分配超出预算，会直接抛出
OutOfMemoryException，而不是触发 GC。低延迟场景下误用反而导致崩溃，比 GC 延迟更致命。 必须配合
GC.EndNoGCRegion()成对调用，否则后续所有 GC 都可能被阻塞或失败 申请的字节数是「托管堆净增」上限，不包括已存在对象、大对象堆（LOH）分配、非托管内存 如果运行时无法预留足够连续内存（例如堆已碎片化），
TryStartNoGCRegion直接返回
false，不抛异常也不生效 在 .NET 6+ 中，若启用了
Server GC且线程未绑定到特定 GC 节点，行为可能不稳定
适合什么低延迟代码段
仅适用于可精确预估内存用量、执行时间极短（毫秒级）、且绝对不允许 GC 干扰的确定性逻辑，比如高频行情解码、实时音频 buffer 处理、确定性物理步进计算。
典型模式：先用GC.GetTotalMemory(true)+ 预估峰值分配量，再尝试锁定 不能包含任何可能触发 JIT 编译、反射、字符串插值（
$"..."）、LINQ 构建新集合的操作 禁止调用任何可能隐式分配的 API，例如
Exception.ToString()、
DateTime.Now（某些实现会分配字符串）、
Guid.NewGuid()推荐只在
unsafe上下文或纯数值计算中使用，避免引用类型分配
实际调用时的关键参数和陷阱
GC.TryStartNoGCRegion(long totalSize, bool disallowFullBlockingGC = false)的两个参数都影响成败。
totalSize必须 ≥ 当前
GC.GetTotalMemory(false)与预期新增分配之和，建议多留 10% 余量
disallowFullBlockingGC = true表示连 full blocking GC 都禁止——这会让
OutOfMemoryException更早到来，但能杜绝 STW；设为
false则仍可能被后台 GC 干扰 调用前需确保 GC 处于“干净”状态：
GC.Collect(2, GCCollectionMode.Forced, blocking: true)+
GC.WaitForPendingFinalizers()，否则已有待回收对象会占用预算 在 ASP.NET Core 等托管环境中，HTTP 上下文、日志器、依赖注入容器等随时可能触发分配，
TryStartNoGCRegion几乎不可用
一个安全的最小可行示例
以下代码演示如何在可控子过程中启用并验证 NoGC 区域，含 fallback 逻辑：
bool noGcStarted = GC.TryStartNoGCRegion(
totalSize: 1024 * 1024, // 1MB 预算
disallowFullBlockingGC: true);
<p>if (!noGcStarted)
{
// 回退到常规路径，记录警告
Log.Warn("Failed to enter NoGC region, falling back");
ProcessWithGC();
}
else
{
try
{
ProcessWithoutGC(); // 纯栈操作 / 预分配数组复用 / unsafe 指针运算
}
finally
{
GC.EndNoGCRegion(); // 必须执行，即使异常也要保证
}
}真正难的不是写这几行，而是证明
ProcessWithoutGC()在所有路径下都不分配——这需要 IL 反编译或使用
dotnet-trace验证分配行为。没做这步验证就上线，等于把延迟毛刺换成随机崩溃。
