ToLower() 因依赖当前区域性在土耳其语等场景将 I 转为 ı，非 bug；语言无关场景应使用 ToLowerInvariant()，它基于 Unicode 标准映射但不处理全角字符、组合符或兼容等价。
为什么 ToLower() 有时不按预期转小写
因为 ToLower() 默认依赖当前线程的区域性（CultureInfo.CurrentCulture），遇到土耳其语、阿塞拜疆语等语言时，I → i 的映射会被替换成带点的 ı，导致 "I".ToLower() 变成 "ı" 而非 "i"。这不是 bug，是 Unicode 大小写规则的正常体现。
- 若业务逻辑与语言无关（如数据库 key、HTTP header、JSON 字段名），必须用
ToLowerInvariant() -
ToLower()在不同服务器上可能行为不一致——比如 Linux 容器里CultureInfo缺失或为en-US，而 Windows 测试机是tr-TR - 性能上，
ToLowerInvariant()略快，因跳过区域性查找和缓存逻辑
ToLowerInvariant() 是不是永远安全
它比 ToLower() 更可预测，但仍有边界情况：它只处理 Unicode 标准定义的大小写映射，对自定义符号、组合字符（如带重音的字母加修饰符）、或某些罕见的兼容等价字符（如全角 ASCII 字符）不保证“完全等价”。
- 全角英文字母（如
ＡＢＣ）调用ToLowerInvariant()后仍是全角，不会变成半角abc - 含组合字符的字符串（如
"a\u0301"，即 a + 重音符）可能在大小写转换后打乱组合顺序，影响渲染或比较 - 若需严格 ASCII 小写（比如协议字段），建议先用
Encoding.ASCII.GetString(Encoding.ASCII.GetBytes(s))做清洗，再转小写（仅适用于纯 ASCII 场景）
性能敏感场景下怎么选
高频字符串处理（如日志解析、路由匹配）中，ToLower() 和 ToLowerInvariant() 都会分配新字符串，且内部遍历每个 char 查表。没有零分配方案，但可减少不必要的调用。
- 避免链式调用：
s.Trim().ToLowerInvariant().StartsWith("api")→ 改为s.AsSpan().Trim().ToLowerInvariant().StartsWith("api", StringComparison.OrdinalIgnoreCase)（.NET 6+） - 用
StringComparison.OrdinalIgnoreCase替代先转小写再比较，省掉一次字符串分配 - 若反复对同一字符串做小写比较，可缓存结果（但注意内存泄漏风险——用
WeakReference或ConcurrentDictionary+Lazy控制生命周期）
底层原理其实就两步
.NET 的 ToLowerInvariant() 底层调用的是 ICU（Windows 上是 NLS，但 .NET Core 3.0+ 统一用 ICU）的 u_strToLower，核心逻辑只有两个动作：
- 查 Unicode Character Database（UCD）里的
Simple_Lowercase_Mapping表，逐字符替换 - 对某些特殊字符（如德语
ß），按上下文展开为多字符（ss），此时返回新字符串而非原长度
所以它不“理解”语义，也不做词干提取或规范化——想把 "İSTANBUL" 正确转成 "istanbul"？得显式指定 new CultureInfo("tr-TR").ToLower()，而不是指望 Invariant。
