结论：string.Split()可用但需注意空项和分隔符陷阱；StringBuilder适用于多次拼接且长度增长明显场景，单次或短字符串反而更慢。
直接说结论：用 string.Split() 分割字符串没问题，但频繁拼接时别用 + 或 string.Concat()，该上 StringBuilder；不过它不是万能加速器——单次拼接、短字符串、少量操作反而更慢。
什么时候该用 string.Split()？注意分隔符陷阱
string.Split() 看似简单，但默认行为容易踩坑。比如 "a,,b".Split(',') 默认会返回三个元素：["a", "", "b"]，空字符串不会被自动过滤。
- 要跳过空项，必须显式传参：
"a,,b".Split(new char[] {','}, StringSplitOptions.RemoveEmptyEntries) - 多个分隔符（如逗号+空格）建议用字符数组：
str.Split(new char[] {' ', '\t', ','}, StringSplitOptions.TrimEntries)（.NET 6+ 支持TrimEntries） - 正则分割？别硬套
Split()，改用Regex.Split()，否则写错转义或忽略贪婪匹配会漏数据 - 性能敏感场景（如日志行解析），避免每次调用都新建 char 数组，可缓存
static readonly char[] Separators = {',', ';'}
StringBuilder 真的比 + 快？看这三点再决定
快的前提是：多次追加、字符串长度增长明显、且你控制得了容量。否则 StringBuilder 的对象创建和内部数组扩容反而拖后腿。
- 初始化时尽量预估长度：
new StringBuilder(1024)比无参构造少一次内存分配 - 追加内容前检查是否为空或 null，
sb.Append(obj?.ToString() ?? "")比直接sb.Append(obj)安全（避免NullReferenceException） - 拼完记得调用
ToString()才能得到最终字符串；反复调用ToString()不会缓存结果，别在循环里写sb.ToString().Length - .NET 6+ 中，如果只是拼接几个固定字符串，
string.Create()可能更快，但适用面窄，新手先别碰
常见误用：把 StringBuilder 当“万能字符串容器”
有人习惯性把所有字符串操作都塞进 StringBuilder：查子串、替换、截取、甚至反复 ToString() 后再 Split()。这完全背离设计初衷。
-
StringBuilder没有IndexOf()、Contains()、Replace()的高效实现（它的Replace()是线性扫描+重建） - 需要搜索或校验内容时，先
ToString()再用原生string方法——只要不频繁创建，开销可控 - 想删掉末尾几个字符？别用
sb.Remove(sb.Length - n, n)然后又追加，不如记录位置、最后一次性sb.Length = targetLength - 多线程共用同一个
StringBuilder实例？它不是线程安全的，要么加锁，要么每个线程一个实例
真正关键的不是“用不用 StringBuilder”，而是识别出哪段逻辑在反复触发字符串内存分配——那才是性能瓶颈的信号源。其他时候，写清楚、别出错，比强行优化更重要。
