在C#开发中，字符串处理是最基础也最频繁的操作之一。当我们需要修改一段文本里的某些内容时，第一反应可能是用循环遍历字符，或者调用字符串自带的替换函数。实际上，.NET为我们准备了两条清晰路径：一条是简单的字符或子串替换，另一条是基于模式的正则表达式替换。两者在语法、性能和适用场景上都有明显区别，选错了方式不仅代码冗长，还可能拖累整个服务的吞吐能力。
使用string.Replace完成基础字符替换
string.Replace是System.String结构体上最直接的方法，它有两个常用重载：一个接收字符参数，另一个接收字符串参数。当我们明确知道要被替换的目标是什么，且不涉及任何模式规则时，这个方法既直观又安全。由于string在C#里是不可变类型，Replace并不会修改原对象，而是返回一个全新的字符串，原字符串依旧驻留在内存中。
下面的示例展示了如何把一段文本里的所有小写字母a替换成大写字母A，以及把子串"bad"替换成"good"。可以看到代码没有任何复杂结构，适合在配置初始化或简单数据清洗中使用。但要注意，如果原文很大且替换次数极多，频繁生成新字符串会带来一定的内存分配压力。
using System;
class Demo
{
static void Main()
{
string text = "a cat sat on a bad mat";
string r1 = text.Replace('a', 'A');
string r2 = text.Replace("bad", "good");
Console.WriteLine(r1);
Console.WriteLine(r2);
}
}
从性能角度看，string.Replace内部使用高效的内存复制，在确定性替换场景下比启动正则引擎要轻量得多。不过它有一个明显短板：无法忽略大小写做替换，也无法只替换单词边界上的内容。如果你希望把"cat"替换成"dog"但保留"category"里的"cat"，单纯用Replace就会误伤，这时就必须借助正则表达式。
利用Regex实现模式化替换
System.Text.RegularExpressions.Regex类提供了基于正则语言的替换能力。静态方法Regex.Replace允许我们传入输入字符串、模式串和替换串，运行时会先编译模式再扫描文本。对于需要按规则匹配的场景，比如提取所有数字替换为星号、或者把日期格式从斜杠改成横线，正则是最简洁的表达方式。
在代码编写中，正则里的特殊字符必须正确转义。例如点号在正则里代表任意字符，要匹配真实的点就得写\.。下面的例子演示了如何把文本里连续的数字替换成"#"，以及如何使用命名分组重组电话号码格式。可以看到，正则用很少的代码覆盖了复杂的逻辑，这是string.Replace做不到的。
using System;
using System.Text.RegularExpressions;
class RegexDemo
{
static void Main()
{
string input = "订单号12345和67890已发货";
string masked = Regex.Replace(input, @"\d+", "#");
Console.WriteLine(masked);
string phone = "13800138000";
string formatted = Regex.Replace(phone, @"(\d{3})(\d{4})(\d{4})", "$1-$2-$3");
Console.WriteLine(formatted);
}
}
除了静态调用，还可以先创建Regex实例并传入RegexOptions.IgnoreCase等参数，在循环替换时避免重复编译模式。对于超长文本或高并发接口，建议用带超时的构造方式防止恶意输入引发回溯爆炸。正则虽强，但写得太复杂会让后续维护者难以读懂，因此团队内部应当约定模式复杂度上限。
两种替换方式的选择与性能对比
在真实项目里，我们常常要在可读性和执行效率之间做权衡。如果需求只是把换行符统一成环境换行、或者把某个固定错别字改正，string.Replace足够且更快。一旦替换条件带有"前面必须是字母""只替换第三次出现"等上下文依赖，正则几乎是唯一选择。我们可以用一张简表来归纳差异。
| 维度 | string.Replace | Regex.Replace |
|---|---|---|
| 适用场景 | 固定字符或子串 | 模式匹配、格式重组 |
| 忽略大小写 | 不支持 | 通过RegexOptions支持 |
| 单次开销 | 低 | 中到高，视模式而定 |
| 代码可读性 | 极高 | 模式复杂时偏低 |
性能测试中，对一万次固定子串替换，string.Replace通常比等效正则快数倍，因为正则引擎要构建状态机。但当我们真的需要"把C:\Windows\System32路径里的反斜杠替换成斜杠并保留盘符"这类带结构的要求时，用Regex只需一行，而手写循环要处理边界与转义，反而更容易出错。这里的C:\Windows\System32就是典型的Windows路径，反斜杠必须原样保留在代码字符串里。
综合来看，建议把替换逻辑封装成独立方法，在方法内部根据入参特征决定走哪条路。这样既让上层业务代码干净，也方便后续用BenchmarkDotNet做量化对比。当正则成为瓶颈时，再考虑用Span<char>手动解析，但那已属于极端优化范畴，日常开发仍以清晰为主。