c# 中 string 是不可变引用类型，所有修改操作均返回新对象；replace 等方法不改变原字符串，必须显式赋值；高频拼接应优先用 stringbuilder，避免 o(n²) 性能陷阱。
直接说结论：C# 中的 string 不是“可修改的容器”，而是不可变的引用类型——所有看似“修改”的操作（比如 Replace、Trim、Substring）都返回新对象，原字符串不变。这点不理解，后续所有性能问题、引用误判、内存泄漏都会跟着来。
为什么 string.Replace 不改变原变量？
因为 string 在 .NET 中被设计为不可变（immutable）。调用 Replace 只是创建并返回一个新字符串，原字符串对象仍留在内存里（等待 GC）。
- 常见错误现象：
str.Replace("a", "b");执行后str内容没变——漏了赋值 - 正确写法必须显式接收：
str = str.Replace("a", "b"); - 如果反复链式调用（如
str.Replace(...).Trim().ToLower()），会生成多个中间字符串对象，小量操作无感，高频或大文本时 GC 压力明显 - 注意：它区分大小写，且只做全字匹配；要忽略大小写，得用
StringComparison.OrdinalIgnoreCase重载版本
拼接多个字符串，该用 +、$ 还是 StringBuilder？
取决于场景：编译期已知的字面量拼接用 + 最安全；运行时动态拼接且次数不确定，优先选 StringBuilder。
-
+和+=在单条语句中（如var s = a + b + c;）会被编译器优化为一次string.Concat，没问题 - 但循环中写
result += item;是典型反模式——每次都会新建字符串，时间复杂度 O(n²) - 字符串插值
$"Hello {name}"底层调用string.Format或string.Concat，适合少量变量嵌入；含大量条件分支或重复拼接时不推荐 -
StringBuilder真正优势在「多次 Append」场景，尤其配合Capacity预设（避免内部数组反复扩容）
Trim、Substring、ToCharArray 的隐性开销在哪？
它们都分配新对象，但容易被忽略的是：这些方法不处理 Unicode 组合字符或代理对（surrogate pairs），仅按 char（UTF-16 code unit）索引。
-
Trim()返回新字符串，空字符串调用也返回新实例（不是引用string.Empty） -
Substring(0, n)若n超出长度，抛ArgumentOutOfRangeException；建议先检查Length或用AsSpan().Slice(0, n).ToString()（.NET 5+ 更安全） -
ToCharArray()总是复制全部内容，哪怕你只读前 3 个字符；若只需遍历，直接用foreach (char c in str)更省内存 - 涉及中文、emoji（如 ?）、带音标文字时，
str[2]可能切在代理对中间，导致乱码；真要按“字符”而非“码元”操作，得用StringInfo或ReadOnlySpan<char>.EnumerateRunes()</char>
最常被跳过的点：别把 string 当成可复用缓冲区去反复“清空重填”。一旦逻辑里出现“先初始化为空字符串，再逐步拼接”，基本就该换 StringBuilder 了——哪怕只是拼 5 次，长期维护成本也远高于初期多写两行。
