span.slice()越界会直接崩溃而非抛异常，slice(3,5)表示从索引3取5个元素即[3..8)，需手动校验start≥0、length≥0且start+length≤span.length。
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 生态”。
