内插字符串默认性能开销在于未指定处理器时编译器生成string.format或stringbuilder调用，导致高频拼接中大量短生命周期字符串分配和gc压力。
内插字符串默认性能开销在哪
从 C# 6 开始，$"Hello {name}" 表面简洁，但编译器默认会生成 string.Format 或临时 StringBuilder 调用——尤其在循环中高频拼接时，会触发大量短生命周期字符串分配和 GC 压力。
关键点：**不是所有内插都慢，而是未指定处理器时，编译器无法做零分配优化。**
- 单次、低频拼接（如日志头）基本无感
- 高频路径（如网络包序列化、日志批量写入）必须干预
-
ToString()被隐式调用多次时（例如{obj.Property}），额外装箱或方法调用开销放大
使用 DefaultInterpolatedStringHandler 手动控制分配
C# 10+ 引入了可被编译器识别的“内插字符串处理器”机制，DefaultInterpolatedStringHandler 是官方提供的轻量级实现，支持栈分配（Span-based）、避免中间字符串创建。
前提是：你写的接收方法必须声明形参为 DefaultInterpolatedStringHandler，且标记 [InterpolatedStringHandler] 特性（通常由编译器自动生成，你只需按约定写方法）：
public static void Log(in DefaultInterpolatedStringHandler handler)
{
// handler.ToStringAndClear() 返回最终字符串，内部已做最优缓冲
Console.WriteLine(handler.ToStringAndClear());
}
<p>// 调用时仍用 $，但编译器会自动转成 handler 模式
Log($"User {id} logged in at {DateTime.Now:HH:mm}");- 必须用
in修饰参数，否则编译器不启用 handler 优化 - handler 实例本身是 ref struct，不能逃逸到堆，也不能存为字段
- 若内插项含复杂表达式（如
{ExpensiveMethod()}），仍会在 handler 构造前执行——优化的是拼接过程，不是求值时机
什么时候该用 Span<char></char> + TryFormat 替代内插
当目标是极致零分配（比如高性能日志、底层协议编码），且格式固定、长度可预估时，Span<char></char> 配合 TryFormat 比任何内插处理器都直接：
Span<char> buffer = stackalloc char[256];
bool success = $"User {id} @ {ts:HH:mm:ss}".TryFormat(buffer, out int charsWritten);
// ❌ 错误：TryFormat 不接受内插字符串字面量
// ✅ 正确：对每个部分单独 TryFormat
success = buffer.TryWrite("User ", id, " @ ", ts, ":", "ss");-
TryFormat族方法（如int.TryFormat、DateTime.TryFormat）才是真正的零分配主力 - 内插字符串字面量无法直接传给
TryFormat，必须拆解为逐段写入 - 需手动预估 buffer 大小；写入失败时返回
false，不能忽略
第三方处理器（如 FastFormatting）的取舍
社区有封装好的高性能处理器（如 FastFormatting.InterpolatedStringHandler），它们通常扩展了对集合、条件、自定义格式器的支持，但引入了额外依赖和学习成本。
- 如果你只需要基础数值/日期拼接，原生
DefaultInterpolatedStringHandler足够 - 若要支持
{list.Count,5}这类对齐语法，或{value:C2}货币格式，需确认处理器是否兼容IFormattable和 format string 解析 - 注意处理器是否线程安全——多数基于
Span<char></char>的实现仅限单线程栈使用
真正难的不是选哪个 API，而是判断哪条调用路径值得优化：先用 dotTrace 或 dotMemory 抓出字符串分配热点，再决定是加 handler、换 TryFormat，还是干脆用 Utf8Formatter 直出二进制。盲目替换内插语法，可能白忙一场。
