使用==与Ordinal进行字符串比较的差异、性能区别及潜在问题

先给核心结论：不少开发者对C#字符串==的行为存在常见误解：.NET中string类型重载的==运算符，本身执行的就是和StringComparison.Ordinal完全一致的逐16位Unicode码元序号相等判断，二者在纯全串相等判断场景下的核心逻辑几乎一致，但在适用边界、性能场景、空值处理上存在明确差异，==的语法糖特性也带来了几个极难排查的隐蔽陷阱。

一、核心差异对比 #

比较逻辑层面 #

• 全串相等判断的核心逻辑一致：当比较双方的编译期类型均为string时，==会调用string静态Equals方法，先做引用相等快速短路判断，再做长度校验，最后逐位比较16位Unicode码元，完全不涉及文化相关的字符映射、组合字符处理，和显式传入StringComparison.Ordinal的相等判断逻辑100%匹配。
• 适用边界完全不同：==作为运算符，仅能支持全串的相等/不等判断；而Ordinal是一套通用的字符串比较规则，可以覆盖StartsWith、EndsWith、Contains、IndexOf、Compare、排序等所有字符串操作场景——这些场景的无参重载默认使用当前线程文化的比较规则，和Ordinal逻辑完全不同。
• 绑定时机不同：==是编译期静态绑定的运算符重载，比较逻辑在编译时就已经确定；Ordinal是运行时通过方法参数传入的比较规则，可以根据业务场景动态切换（比如业务需要时随时切换为OrdinalIgnoreCase），灵活性更高。
• 空值行为差异：==是静态运算符，任意一侧为null都不会抛出空引用异常；而实例方法调用的strA.Equals(strB, StringComparison.Ordinal)如果strA为null会直接抛出空引用异常，必须使用静态方法string.Equals(strA, strB, StringComparison.Ordinal)才能获得和==一致的空值安全表现。

性能表现层面 #

• 全串相等判断场景下性能几乎无差：二者最终都会走.NET运行时内部优化的逐码元比较逻辑，引用短路、长度校验的优化完全一致，基准测试差异在纳秒级，绝大多数业务场景可以忽略。唯一的微小开销来自实例方法Equals传入StringComparison.Ordinal时的枚举参数校验分支，这个开销可以忽略不计。
• 非相等判断场景下性能差距极大：如果在做前缀、包含、索引查找等操作时不显式指定StringComparison.Ordinal，运行时会默认加载当前文化的比较表、执行文化相关的字符归一化处理，性能比Ordinal比较慢3~10倍，这也是微软官方推荐所有文化无关场景显式指定Ordinal的核心原因——不是==比Ordinal慢，而是其他无参字符串方法默认不用Ordinal，性能差很多。
• JIT优化空间差异：显式指定Ordinal的字符串操作，JIT可以在编译时跳过文化设置读取的逻辑，做更激进的内联和循环优化，在高频字符串处理场景（比如路由匹配、字典键查找）下，长期运行的稳定性能表现会优于依赖默认规则的写法。

二、==写法的隐蔽陷阱 #

• 编译期类型不匹配导致走引用比较：这是出现频率最高的坑。只要比较双方的编译期类型不是string（比如是object、IComparable、泛型类型参数），==就不会调用string的重载逻辑，而是退化为object的引用相等判断。

  object s1 = "test";
  object s2 = new string("test".ToCharArray());
  Console.WriteLine(s1 == s2); // 输出False，两个字符串内容完全一致也不相等
  
  bool IsEqual<T>(T a, T b) where T : class
  {
      return a == b;
  }
  Console.WriteLine(IsEqual("test", new string("test".ToCharArray()))); // 输出False，泛型场景下也会触发
  

  注意如果两个字符串都是编译期字面量，会被CLR自动加入字符串拘留池指向同一个实例，这时候哪怕用object类型比较也会返回true，导致开发者本地测试时误以为逻辑正确，只有动态生成字符串（比如从接口读取、拼接、拆分子串）的时候才会触发bug，隐蔽性极强。
• 和其他字符串方法默认规则不一致导致逻辑bug：很多开发者知道==是不依赖文化的逐字符比较，却忘了StartsWith、Contains、IndexOf、CompareTo这些常用方法的无参重载默认用的是当前线程文化的比较规则，会出现逻辑矛盾：比如在德语文化下，"straße" == "strasse"返回false，但"straße".StartsWith("strass")会返回true，这类bug在本地开发（默认中文/英文文化）时完全复现不了，部署到对应文化区域的系统上就会出现异常。
• 码元比较的认知偏差：很多开发者以为==判断的是“视觉上相等的文本”，实际上它只判断16位Unicode码元的序列是否完全一致。比如带重音的é，既可以用单个码点U+00E9表示，也可以用基础字符e（U+0065）+ 组合重音符号（U+0301）两个码点表示，二者视觉上完全无法区分，但==会判定为不相等，这类涉及特殊字符、emoji、多语言文本的判断非常容易出问题。
• 空值逻辑的误用：很多开发者会把==的空值安全逻辑类推到带Ordinal参数的实例Equals方法上，写出strA.Equals(strB, StringComparison.Ordinal)的代码，当strA为null时直接抛出空引用异常，排查起来非常麻烦。

内容的提问来源于stack exchange，提问作者Programmerzzz