能否用ReadOnlyMemory<char>全面替代string？

你的基础认知是准确的：从string获取ReadOnlyMemory<char>几乎没有性能开销，但反过来从ReadOnlyMemory<char>转换为string通常需要内存分配与复制，成本很高。好在CLR的不少方法已经新增了ReadOnlySpan<char>重载，而ReadOnlySpan<char>可以从ReadOnlyMemory<char>低成本获取，所以多数场景下不用全量替换string就能拿到性能收益——只要记住在调用支持Span的重载时，把string.Substring()换成string.AsSpan().Slice()就行。

下面针对你的三个问题逐一解答：

1. 中等规模方案中全量替换string为ReadOnlyMemory的实践 #

确实有开发者在中等规模的高性能场景（比如高吞吐文本解析、数据处理服务）尝试过这类全量替换，但这种实践并不普遍。原因是多数业务场景下string的性能开销完全可接受，全量替换带来的性能收益抵不上改造所需的时间和维护成本。

2. 全量转换可能遇到的问题 #

• API兼容性障碍：大量第三方库、框架仍只接受string类型参数，比如ORM实体属性、日志库的消息参数等。这种情况下你不得不做ReadOnlyMemory<char>到string的转换，反而引入额外的内存开销。
• 哈希与相等性判断的陷阱：ReadOnlyMemory<char>的默认哈希码基于其指向的内存块和范围计算，如果你用同一个string的不同切片作为ReadOnlyMemory<char>，默认相等性判断会认为它们不相等，但业务场景中你往往需要按文本内容判断相等。如果自定义哈希和相等性逻辑，会增加代码复杂度；就算用聚合哈希码的readonly struct，也要注意哈希码的缓存有效性——如果ReadOnlyMemory<char>指向的是可变内存（比如char[]），内存内容被修改会直接破坏字典的一致性，只有指向不可变的string时才安全。
• 调试与排查难度上升：调试时查看ReadOnlyMemory<char>的内容比直接看string麻烦得多，需要额外展开查看细节，增加了问题排查的成本。
• 团队学习成本增加：团队成员需要重新理解ReadOnlyMemory<char>的生命周期、内存指向逻辑，新手很容易踩内存引用失效的坑（比如指向已经被回收的内存块）。

3. 无需额外分配内存使用子字符串作为字典键的替代方案 #

有两种实用的方案可以避免Substring()的内存分配：

• 自定义字典键结构体：实现一个readonly struct，内部持有ReadOnlyMemory<char>，同时预计算并缓存哈希码，自定义基于文本内容的相等性判断逻辑。这样既可以避免内存分配，又能正常作为字典键。注意如果ReadOnlyMemory<char>指向的是可变内存（比如char[]），要确保在字典的生命周期内内存内容不会被修改；如果指向的是string则无需担心，因为string是不可变的。
• 使用StringSegment（.NET 5及以上）：这是.NET官方专门为字符串切片设计的类型，本质是对string切片的封装，默认的哈希和相等性判断都是基于文本内容的，而且完全不需要额外内存分配。你可以直接用StringSegment作为字典的键，这样用字符串切片查找时就不用调用Substring()了。

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