在ConcurrentDictionary中使用ReadOnlySpan<char>替代string作为键能否提升性能？

嘿，这个问题问得挺务实的！咱们来好好唠唠这件事~

其实ConcurrentDictionary的源码里确实提到了TAlternateKey这个ref结构的设计方向，它的核心目的就是为了优化键的处理性能，而ReadOnlySpan<char>刚好是这类场景里的一个典型候选。

从性能角度来看，string作为引用类型，在哈希计算、相等性比较时，虽然CLR有不少底层优化，但免不了涉及堆内存的交互；而ReadOnlySpan<char>是值类型的内存跨度，能直接操作内存中的字符数据——如果你的键是从某个已有内存块（比如栈上的字符数组、解析中的临时片段）截取而来，用它代替string就可以跳过额外的字符串分配步骤，这在高频读写的场景下，能显著减少内存开销，同时提升哈希和比较的速度。

不过也得注意它的局限性：ReadOnlySpan<char>是ref结构，不能被存储在堆上的对象中，所以要在ConcurrentDictionary里用它当键，得依托源码里TAlternateKey这类专门适配ref类型的设计逻辑，不然直接用会有很多限制。另外，你还得确保ReadOnlySpan<char>的哈希算法和相等性逻辑符合你的业务需求，如果需要和原有的string键兼容，还要保证哈希值的一致性，不然会出现键匹配异常的问题。

总结下来：如果你的场景是大量处理临时字符片段作为键，且能通过ReadOnlySpan<char>避免不必要的字符串分配，那结合ConcurrentDictionary的TAlternateKey设计思路，确实能拿到不错的性能提升；但如果是普通的静态字符串键场景，性能提升可能不明显，反而会增加实现复杂度。

备注：内容来源于stack exchange，提问作者Wojciech