C产品如何满足特定用户需求？

本文共计918个文字，预计阅读时间需要4分钟。

`Span.Slice()` 不是安全的底层操作，越界使用会导致直接崩溃，而非抛出异常——你必须自己校验索引，不能依赖运行时检查。

Span.Slice(start, length) 的参数陷阱

很多人把 Slice(3, 5) 理解成取索引 [3..5)，实际是“从索引 3 开始，取 5 个元素”，即覆盖 [3..8)。一旦 start + length > span.Length，Release 模式下直接触发 System.IndexOutOfRangeException，且该异常在 AOT 或 unsafe 上下文中可能表现为访问违规，无法被常规 try/catch 捕获。

• 永远先做长度校验：if (start >= 0 && length >= 0 && start + length
• 来自外部输入（如 HTTP header 解析位置、日志字段偏移）的 start 和 length 必须显式截断，例如：var safeLen = Math.Min(length, span.Length - start)
• C# 8+ 的范围语法 span[start..end] 语义更清晰，但底层仍是调用 Slice()，同样不自动校验
• 调试阶段可用 Debug.Assert(start + length 辅助定位越界点

字符串切片必须用 AsSpan()，不能用 fixed 或 stackalloc

string 是托管堆上的不可变对象，想获得其字符视图，唯一安全方式是调 str.AsSpan()。任何试图绕过它的做法都会破坏零拷贝前提，甚至引发悬垂指针。

• 用 fixed (char* p = str) 后转 Span<char></char>：若 GC 在 span 生命周期内移动字符串，p 就变成野指针，结果是随机乱码或崩溃
• 用 stackalloc char[256] 拷贝内容再建 span：多一次堆分配 + 字符复制，完全失去 Span 的意义
• 把 AsSpan() 结果存为类字段或 async 方法局部变量：编译直接报错 CS8347，因为 Span<t></t> 不能逃逸栈帧
• 正确姿势：只在单个同步方法内流转，用完即弃；需跨方法传递时，改用 ReadOnlyMemory<char></char>

ReadOnlySpan 切片后仍绑定原字符串生命周期

ReadOnlySpan<char></char> 本身不持有数据，它只是对原始字符串内存的一层轻量包装。只要原字符串没被 GC 回收，span 就有效；但一旦原字符串释放或变更（比如被 intern 或重用），span 就失效。

• 不要在函数中调 line.ToString() 再切片——这行代码立刻触发堆分配，前面所有优化归零
• 优先使用原生方法处理：line.IndexOf(':')、line.Trim()、int.TryParse(line, out int val)
• 若需长期持有某段内容（如缓存、日志输出、序列化），必须显式转 string，但只在真正需要时做一次
• 传参时函数签名必须声明为 ReadOnlySpan<char></char>，否则一进方法就隐式调 .ToString()，白费功夫

最易被忽略的点：Slice 本身不分配、不复制，但任何一次 .ToString()、任何一次跨方法返回、任何一次未校验的索引计算，都会让整个零拷贝链条断裂。性能收益不在“用了 Span”，而在“全程没掉出 Span 生态”。