string.split 默认保留空字符串，需用 stringsplitoptions.removeemptyentries 过滤；分隔符优先选 char[] 提升性能；split 不自动 trim，需手动处理；高频调用应改用 span.split 避免分配开销。
Split 会把空字符串当成有效元素？
默认情况下，String.Split 遇到连续分隔符（比如 "a,,b"）或开头结尾的分隔符（比如 ",a,b,"），会保留空项。这不是 bug，是设计行为。
- 用
StringSplitOptions.RemoveEmptyEntries参数过滤掉空字符串："a,,b".Split(',', StringSplitOptions.RemoveEmptyEntries)→["a", "b"] - 不加这个参数，结果是
["a", "", "b"]，容易在后续遍历时触发NullReferenceException或逻辑错乱 - 特别注意读取 CSV 行、日志行、配置文件时，原始数据常带多余空格或空段，漏掉这个参数会导致数组长度不可预期
用单字符分隔符还是字符串数组？
传 char 比传 string[] 快且内存友好，但语义不同：前者是“任一分隔符字符”，后者是“任一分隔符字符串”。
- 想按逗号或分号切？用
new char[] {',', ';'}—— 简单、高效、支持 Unicode 字符 - 想按固定字符串如
"::"或"\r\n"切？必须用string[]重载，且要加StringSplitOptions参数，否则编译不过："a::b".Split(new string[]{"::"}, StringSplitOptions.None) - 误把
"\n"当成char写成'\n'没问题，但写成"\n"却传给char[]重载会报错
Split 后的数组要不要 Trim？
Split 不处理空白，哪怕你用 " , " 分隔，结果里每个元素前后仍可能带空格。
- 常见场景：解析用户输入、HTTP 头、INI 文件值 —— 直接用
result[i]可能匹配失败 - 别在循环里反复调
.Trim()，先用 LINQ：str.Split(',').Select(s => s.Trim()).ToArray()，但要注意引用类型开销 - 如果只是校验或比较，建议延迟 Trim：用
string.Equals(a.Trim(), b.Trim(), StringComparison.OrdinalIgnoreCase)，避免无谓分配
大文本反复 Split 性能差怎么办？
每次调 Split 都新建数组，对长字符串或高频调用（如解析日志流）有 GC 压力。
- 优先考虑
Span<char>.Split</char>（.NET Core 2.1+）：text.AsSpan().Split(',')返回ReadOnlySpan<char></char>，零分配 - 若需兼容旧框架，改用
ReadOnlyMemory<char></char>+MemoryExtensions.Split - 绝对不要在 for 循环里对同一长字符串反复
Split—— 提前拆好存起来，或者改用IndexOf+Substring手动切
空字符串处理、分隔符类型选择、Trim 时机、分配开销——这四点没对齐，Split 就容易从便利工具变成隐藏雷区
