string.Replace适用于字面量全局替换，安全高效；Regex.Replace仅用于模式匹配场景，需注意元字符转义与预编译；C#无ReplaceAll方法，Replace默认即全量替换。
Replace 和 ReplaceRange 别混用：普通替换不用正则
字符串替换不一定要上正则——string.replace 足够快、安全、可读。它只做字面量匹配，不解析模式，也没捕获组、贪婪控制这些干扰项。适合“把所有 old 换成 new”这种明确场景。
常见错误是误以为 string.Replace 支持通配符或转义，比如写 "a.b".Replace(".", "_") 想替换成 "a_b"，结果确实能成，但纯属巧合；一旦遇到 "a\.b" 就失效，因为 Replace 根本不认反斜杠语义。
-
Replace区分大小写，要忽略大小写得先转小写再换，或改用Regex.Replace - 它返回新字符串，原字符串不可变——别漏接返回值
- 性能比正则快 3–5 倍（小字符串下），无编译开销，无 JIT 正则引擎启动延迟
Regex.Replace 什么时候必须上？
只有当你要匹配“一类模式”而非“某个固定串”时，才该切到 Regex.Replace。比如删掉所有连续空白、提取邮箱前缀、把 id=123 中的数字提出来再加工……这些 string.Replace 做不了。
典型踩坑是拿正则去干简单活：写 Regex.Replace(s, "abc", "xyz")。这不仅慢，还可能因未转义元字符出错——比如 "a.c" 会被当成 “a + 任意字符 + c”，不是字面意思。
- 模式字符串里所有正则元字符（
.、*、+、?、[、^、$等）必须手动Regex.Escape - 频繁调用建议预编译：用
new Regex(pattern, RegexOptions.Compiled)缓存实例，避免每次重复解析 - .NET 6+ 支持源生成器
RegexGenerator，编译期生成高效代码，但需标记[GeneratedRegex]属性
ReplaceAll 是啥？别被名字骗了
C# 没有 string.ReplaceAll 这个方法。有人在 Stack Overflow 或旧博客里看到这个词，其实是 Java 或 JavaScript 的写法，或者误把 Regex.Replace 当成了“全量替换接口”。C# 里 string.Replace 本来就是全局替换，不存在“只换第一个”的默认行为。
另一个混淆点是 LINQ 的 Replace 扩展——某些第三方库加了类似命名的扩展方法，但标准 BCL 里没有。查文档时盯紧命名空间：System.Text.RegularExpressions.Regex 和 System.String 才是正主。
- 用 IDE 查
Replace弹出的重载列表，只有两个参数（旧串/新串）或三个（加StringComparison）的是原生方法 - 带
RegexOptions参数的一定是正则入口，不是“增强版 Replace” - 别在循环里反复 new Regex，尤其没加
Compiled，GC 压力会明显上升
特殊字符和编码陷阱：\r\n、\0、代理对
替换失败常不是逻辑问题，而是输入本身藏了隐形字符。比如从文件读入的字符串含 \r\n，你却按 \n 去换；或者 JSON 字符串里有 Unicode 代理对（如 ?），用 Substring 截断再替换会破坏 UTF-16 序列。
还有更隐蔽的：Windows 记事本保存的 ANSI 编码文件，在 C# 里用 File.ReadAllText 默认按 UTF-8 解，导致乱码后替换完全失焦。
- 调试时先打日志：用
BitConverter.ToString(Encoding.UTF8.GetBytes(s))看真实字节 - 处理换行统一用
Environment.NewLine替代硬写"\n"或"\r\n" - 涉及 emoji 或中文古籍文本，确认源数据编码，并显式传给
Encoding参数（如File.ReadAllText(path, Encoding.UTF8)）
正则不是银弹，字符串也不是黑箱——真正卡住你的，往往在边界字符、编码假设和方法归属感上。
