写这篇东西是因为前两天帮一个同事排查一个非常诡异的 Bug某个内部订单匹配系统在运行过程中明明往Dictionary里放进去的数据过一会儿再去读居然报KeyNotFoundException。更离谱的是用调试器去看键值对明明还在字典里ContainsKey却返回False。那个键的类型是一个自定义的Structure里面装了几个字符串和时间字段。当时我就意识到又是一个 VB.NET 里Dictionary键的经典大坑Structure值类型和Class引用类型作为键时行为是完全不同的。很多人从 C# 或从数组、列表转过来用字典都会栽在这里。这篇文章把这个问题从头到尾讲透包括底层原因、复现过程、定位方法和根治方案希望能帮你少走几个小时的弯路。这篇文章适合谁看只要你在 VB.NET 里用过Dictionary或者准备用复合字段做一个键类型都建议花几分钟看完。尤其是那些习惯把结构体当轻量级类来用的人这一课的学费最好是今天交而不是等到上线后出事故再交。1. 一次让我排查到深夜的幽灵键问题1.1 现场描述字典明明有数据却返回不存在先说那个现场。某系统里维护了一批待处理的订单逻辑大概是这样的程序启动时加载一批订单以客户编码 商品编码 订单日期的组合作为键存入Dictionary。后续某个后台线程会按同样的组合去查字典取出对应的订单进行流转。诡异的地方在于第一次加载后查询一切正常但只要程序跑一段时间某些单子就会凭空消失。重新启动程序后又好了再过一阵又犯。日志里清清楚楚能看到字典Count没有变化说明键值对并没有被移除但ContainsKey就是返回False。这种故障是最让人头疼的——它不是每次都稳定复现而是带着明显的随机性和时间相关性。一开始同事怀疑是线程安全问题因为涉及多线程读写同一个字典。后来加了锁问题依然存在。又怀疑是字符串拼接时格式不统一数据不一致导致查不到。排查了很久都没头绪直到我介入帮忙梳理。1.2 排除过程从线程安全误判到数据判空误判切入之后我先按惯例排除几个常见嫌疑。第一个是线程安全。.NET的Dictionary在并发读和并发写同时发生时是有可能出现内部状态损坏的。但同事给所有Add和TryGetValue都加了SyncLock之后问题没有消失。这说明并不是并发写坏字典的问题锁住了也照样丢键方向不对排查方向要转。第二个是键值本身不一致。比如存进去的时候键的字段值是2024-01-01 10:30:00查询的时候因为解析格式化问题变成了2024-01-01 10:30那肯定查不到。但检查日志发现存和查用的都是同一个格式化函数而且字符串内容肉眼一致。数据看起来没问题。第三个是大小写问题。VB.NET 的字符串比较默认不区分大小写但字典默认的字符串比较器是区分大小写的。这个曾经也坑过人。不过检查后发现数据本身没有大小写变化。排除到最后我注意到一个细节这个键类型是Structure并且它的字段不是只读的。在系统运行过程中有一段代码会取回这个键对象然后直接修改其中的一个字段比如把订单状态字段写进去。就是因为这一下修改整个游戏变了。1.3 真相浮出水面结构体字段被修改后哈希值变了我先写了一个只有几十行的小 Demo 来验证猜想。用一个自定义Structure作为键插入字典后修改结构体的一个字段再尝试用修改后的键去查字典。结果毫不意外ContainsKey返回False。但真正让我确认问题根子的是另一个细节即便是用修改前完全一致的内容重新构造一个键去查也可能查不到。你可能觉得奇怪内容一样为什么还查不到别急这个我在第 2 节解释字典的底层逻辑时你会彻底明白。简单说结构体作为键时Dictionary会调用它的GetHashCode得到哈希值再用哈希值定位内部桶的位置。结构体默认的GetHashCode会基于它所有字段的值来计算。你把某个字段改了哈希值就变了。而字典内部在插入时是根据旧哈希值把键值对放进某个桶里的。改动字段之后你用新哈希值去定位桶自然走到了一个完全不同的位置上当然找不到原来的键值对。数据明明在字典里但它的物理位置是拿旧哈希码算出来的你手里拿着新哈希码能走到同一个桶才怪。2. 字典查找只有两板斧哈希码定位Equals 确认2.1 底层运行逻辑从图书馆找书的例子说起要理解这个坑需要先把字典查找的两板斧原理搞清楚。第一板斧是哈希码定位第二板斧是 Equals 确认。这两步缺一不可。我习惯用一个图书馆找书的例子来解释。假设图书馆有 1000 个书架每个书架贴了一个编号。你来还一本书管理员不会从第一个书架开始逐本翻而是先看书的编号把它映射到一个书架号这就是哈希直接走到那个书架然后再在书架上比对书籍信息确认是不是你要找的那一本这就是 Equals。Dictionary的道理完全一样。每个键调用GetHashCode得到一个整数值Dictionary内部用这个值去模一个内部的数组长度得到一个桶索引bucket index键值对就挂在以这个索引为首的链表上。查找时先通过GetHashCode得到桶索引然后只在那个桶的链表上用Equals逐一比对键看是不是完全匹配。所以GetHashCode决定去哪里找Equals决定找到了没有。哈希码只要一变查找就会去错地方后面的Equals根本连出场机会都没有。2.2 为什么哈希码变了会直接导致 KeyNotFound现在回到那个场景。插入字典时结构体的哈希码是A字典把键值对放到桶A % 容量的位置。后来字段被改了你再拿这个对象去查GetHashCode计算出的是B字典走到桶B % 容量去找那个桶里自然没有你要的键值对。这就是为什么即便你用修改前内容一致重新构造的新键去查也可能查不到的深层原因——等一下这句话其实要分开看。如果新键的内容与插入时的原始键完全一致那哈希码也会一致是查得到的。但如果你的内容一致只是肉眼一致比如格式化差异、字符串大小写差异、浮点数精度差异映射到哈希码就可能不同了。我在 1.2 节里说的内容一样也可能查不到严格来说是指肉眼看起来一样实际二进制层面并不一样。这个差异值得你记住字典的相等性判断是严格按字节逻辑来的不看你打印出来的样子。还有一种情况结构体默认的GetHashCode在 .NET Framework 和 .NET Core/.NET 5 中有不同的实现策略。在某些版本中结构体的默认哈希码不是严格基于字段值计算的而是基于对象的某些运行时元数据混合出来的这会导致同一个结构体在同一个进程里前后两次调用GetHashCode可能返回不同的值。这在某些老版本 .NET Framework 上是被真实踩过的坑。如果恰好撞上这种实现结构体用默认GetHashCode当字典键就彻底不可靠了。这也是为什么自定义结构体作键必须手动重写GetHashCode的铁律原因之一。2.3 Equals 和 GetHashCode 的家规必须同时重写Equals和GetHashCode之间有一条强制性的契约违反它就会出各种怪问题如果两个对象Equals为True那么它们的GetHashCode必须完全一致。反过来GetHashCode一致的Equals可以不一致哈希碰撞是允许的只影响性能不影响正确性。一个对象的GetHashCode不要求在整个生命周期内保持不变但如果它被放进依赖哈希值的集合字典、哈希集里那么集合存活期内哈希值就不该变。很多人只重写Equals不重写GetHashCode或者反过来都会破坏这条契约。特别是当你用Class作键、却又想让它按业务值相等时这个规则尤其容易踩雷。我用一个表格把这两种类型作为键时的默认行为差异列出来键类型默认 GetHashCode 依据默认 Equals 依据字段修改后哈希值变化典型风险Structure值类型字段值部分老版本不可靠ValueType.Equals逐字段比较会变字段参与哈希修改字段导致 KeyNotFoundClass引用类型对象引用唯一性引用相等同一对象才 Equal不变引用地址不变不同实例内容相同但查不到Class重写 Equals 且重写 GetHashCode业务字段计算业务值比较会变看实现修改参与哈希的字段导致 KeyNotFound这张表值得收藏。你只要记住一句话只要是哈希值参与定位的集合哈希值计算所依赖的对象成员就绝对不要被修改。3. Structure 与 Class 的本质差异值语义与引用语义的连锁反应3.1 默认行为Structure 逐字段比较Class 比引用地址要说清楚这个坑的底层必须理解值语义和引用语义的区别。Structure值类型在赋值、传参时是整体拷贝的。你写Dim a As New MyStruct()然后Dim b a这时a和b是两份完全相同但彼此独立的数据。ValueType.Equals的默认实现会逐字段比较也就是看两个结构体的字段内容是否完全一样一样就认为是相等的。这就是值语义。Class引用类型则完全不同。Dim a As New MyClass()Dim b a这时a和b指向的是同一个堆对象只拷贝了引用地址。默认的Equals和人一样现实只有当你指向同一个对象时才认为是相等的。这就是引用语义。这两种语义对字典键的影响是决定性的。用结构体作键字典认同的是内容一致性用类作键字典认同的是对象同一性。3.2 可变结构体的危害哈希值随字段漂移数值语义本身不是问题问题出在我们的结构体是可变的。VB.NET 允许你声明结构体后直接修改字段比如dictKey.Status 2。但结构体一旦是可变的而它又被用作字典键那么修改操作就会改变GetHashCode的返回值。哈希值一变字典的桶索引就失效了键值对变成越狱状态——它还在字典里但从任何桶索引都找不到它了。这就像你把一本书放到了按书号排的书架上后来又把书号改了却没有把书挪到新的位置。下次任何人按新书号来找书都只会走到一个空荡荡的位置。书还在图书馆里但已经丢失了。最气人的是这种问题不会立刻爆发。通常是在运行了一段时间、某些键恰好被修改过之后才出现而且一旦出现便如同石沉大海日志完全看不出任何异常。它比数组越界、空引用这类暴力报错隐蔽得多。3.3 装箱与性能不重写哈希码的结构体字典为什么慢除了正确性还有性能问题。结构体如果不重写GetHashCode交给默认实现处理在 .NET Framework 上往往会经历装箱值类型被转换成引用类型以便调用基类方法。装箱会在堆上分配对象产生 GC 压力。在一个高吞吐场景下如果用结构体做键且频繁查找性能开销是肉眼可见的。更严重的是老版本 .NET Framework 的ValueType.GetHashCode内部可能使用了反射来枚举字段性能极差。实测数据我不具体展开了但同样的字典操作重写哈希和默认实现在批量场景下可能有数倍差距。这就不只是正确性的问题属于能跑但很惨的范畴。所以结论非常明确所有用来自定义字典键的结构体都必须重写GetHashCode和Equals并且最好实现IEquatable(Of T)接口来避免装箱。这不是锦上添花的优化而是必要手段。4. 全面复盘我用什么方法一步步定位和验证问题4.1 最小复现 Demo 的构造过程空口无凭还是得靠实验验证。我复盘一下当初的完整定位过程你可以跟着操作复现。第一步构造最小复现 Demo。我定义了一个与线上结构相同的最小结构体注意要看懂它的可变性要害Public Structure OrderKey Public CustomerCode As String Public ProductCode As String Public OrderDate As DateTime Public Status As Integer 这个字段后来会在程序里被修改 Public Sub New(customerCode As String, productCode As String, orderDate As DateTime) Me.CustomerCode customerCode Me.ProductCode productCode Me.OrderDate orderDate Me.Status 0 End Sub End Structure然后构造一个字典插入一个键值对接着修改键的字段再查询Dim dict As New Dictionary(Of OrderKey, String)() Dim originalKey As New OrderKey(C1001, P8001, #1/1/2024#) dict.Add(originalKey, 订单详情) 运行时某处代码修改了键的字段 originalKey.Status 2 Dim lookupKey As New OrderKey(C1001, P8001, #1/1/2024#) Console.WriteLine(dict.ContainsKey(lookupKey)) False猜到了这段代码输出False。到这里已经能证明修改结构体字段后即使重建相同业务内容的键也查不到了因为哈希码已经因 Status 变动而变化。4.2 三个关键实验原地修改、重建键、观察哈希码为了进一步验证哈希码变了导致索引错位这个判断我做了三个实验。实验一原地修改后查询。就是上面的代码ContainsKey返回False。这证明了修改字段后用同一个引用对象结构体按值传给ContainsKey本质是拷贝查不到。实验二修改前后分别打印哈希码。Dim keyWithStatus0 As New OrderKey(C1001, P8001, #1/1/2024#) Console.WriteLine(keyWithStatus0.GetHashCode()) 例如 123456 keyWithStatus0.Status 2 Console.WriteLine(keyWithStatus0.GetHashCode()) 例如 789456变了两个哈希码完全不同直接验证了哈希漂移的猜想。实验三直接用类替代结构体观察行为差异。我把Structure改成Class字段不变插入字典后修改同一实例的字段再查询。结果仍然是False如果类重写了基于字段的哈希逻辑。但如果类不重写任何方法只靠默认引用哈希那么同一个实例修改字段后哈希码不会变查询不会出问题——这是我用来说明引用类型天然更抗这种意外修改的例子但代价是要求传进来的必须是同一个实例业务语义上往往反而更严格。4.3 从现象到结论不同 Step 的对照结果把三个实验合起来看结论链路非常清晰结构体默认可变且默认哈希基于字段值。字段被修改 → 哈希码改变。哈希码改变 → 字典定位桶索引出错。桶索引出错 → 键值对无法再被路由到。最终表现 →ContainsKey/TryGetValue返回False尽管键值对仍在字典中。为了防止我脑袋一热下错结论还补做了两个对照实验。对照一插入后不修改结构体任何字段再按相同内容重建键查询一切正常返回True。对照二把结构体所有字段改为ReadOnly强制不可变插入后尝试修改会编译报错从而杜绝了哈希漂移的可能。这两个对照实验从反方向印证了核心结论问题根源不是结构体本身而是结构体的可变性被意外修改。只要字段不可变结构体做键时完全可靠。5. 这些写法最容易被坑四种典型错误用法5.1 用可变结构体当复合键这是最典型的错误。大家喜欢把客户编码 品名 日期这种多个字段拼成一个结构体当复合键又顺手在结构体里声明了可变字段方便后续更新状态。这等于亲手埋了一颗雷因为结构体的可变字段在程序运行期一旦被赋值哈希码就变了。我的建议是如果结构体只用来做键那就把所有字段都变成ReadOnly并在构造函数里一次性赋值。如果确实有些字段需要更新那你根本不应该把这个结构体当键应该把状态字段拆到键外部的值对象里。5.2 结构体里放了可变引用字段这一种的隐蔽程度更高。看一个变体Public Structure OrderKey Public ReadOnly CustomerCode As String Public ReadOnly OrderDate As DateTime Public Tags As List(Of String) 危险引用字段本身会变 End Structure即使CustomerCode和OrderDate是只读的Tags是一个List(Of String)它的内容随时可以被修改。如果结构体默认哈希实现把Tags的哈希也算进来在部分版本中ValueType.GetHashCode会反映引用字段的内容哈希那么修改Tags的某个元素同样会改变整个结构体的哈希码。这种写着只读、实际可变的字段是最阴险的坑。解决思路是键结构体里的字段要么是不可变的值类型要么是不可变的引用类型如String、ReadOnlyCollection(Of T)。千万别放List、Dictionary、数组这些可变对象。5.3 重写了 Equals 却没重写 GetHashCode这个错误在Class作键时更常见。比如定义了一个订单类想让它按单号相等于是重写了Equals但忘记重写GetHashCode。结果是什么GetHashCode依然返回引用地址哈希两个代表同一张订单的不同实例Equals为True哈希码却不同。字典查找时先计算哈希码两者哈希不同就分到不同桶里结果是字典里明明存在逻辑相同的键你却查不到。这违反了 2.3 节说的契约同样是致命的。反过来也有一种错误重写了GetHashCode却忘了重写Equals。这会怎样两个不同实例哈希相同桶定位到了同一个链表但Equals还是比引用地址于是查不到。或者两个相等实例哈希码相同Equals返回False照样查不到。所以要么都不重写要用业务相等就必须两个一起重写没有中间状态可谈。5.4 用浮点数或 DateTime 做复杂键这个属于选择数据类型的坑。Double、Single这类浮点数的相等性判断在计算机里是出了名的不可靠两个数学上相等的数经过不同路径计算后存储的二进制可能不同。如果把它们当成键的一部分你会时不时遇到看起来一样字典认为不一样的诡异场景。DateTime也有微妙的坑。它在 VB 里是以Ticks为底层精度存储的两个DateTime如果在代码格式化为字符串时只显示到秒但底层的Ticks不同哈希码也不同肉眼相等但字典不相等。我的建议是键尽量用String、Integer、Long、Guid这类稳定精确的类型。如果必须用数值先统一归一化比如先取整到一定小数位或者转成Decimal再放进键里。用DateTime时统一先做规范化比如dateTime.Date只取日期部分别把时间分秒时刻带进去。6. 根治方案安全自定义键的设计范式6.1 规则一键结构体必须不可变这是最大的一条规则。键结构体的所有公共字段必须是ReadOnly并且只在构造函数里赋值。一旦你想给某个字段赋值编译器就会阻止你。这就从根上杜绝了哈希漂移。Public Structure OrderKey Public ReadOnly CustomerCode As String Public ReadOnly ProductCode As String Public ReadOnly OrderDate As DateTime Public Sub New(customerCode As String, productCode As String, orderDate As DateTime) Me.CustomerCode customerCode Me.ProductCode productCode Me.OrderDate orderDate End Sub End Structure如果你需要状态字段把它放在字典的Value部分不要放在Key结构体里。这是职责分离也是安全设计。6.2 规则二重写 Equals、GetHashCode 并实现 IEquatable(Of T)除了不可变还要手动重写关键方法。IEquatable(Of T)接口的意义是让结构体在比较时走强类型路径避免装箱提升性能。Public Structure OrderKey Implements IEquatable(Of OrderKey) Public ReadOnly CustomerCode As String Public ReadOnly ProductCode As String Public ReadOnly OrderDate As DateTime Public Sub New(customerCode As String, productCode As String, orderDate As DateTime) Me.CustomerCode customerCode Me.ProductCode productCode Me.OrderDate orderDate End Sub Public Overrides Function Equals(obj As Object) As Boolean If TypeOf obj IsNot OrderKey Then Return False Return Equals(DirectCast(obj, OrderKey)) End Function Public Overloads Function Equals(other As OrderKey) As Boolean Implements IEquatable(Of OrderKey).Equals Return Me.CustomerCode other.CustomerCode AndAlso Me.ProductCode other.ProductCode AndAlso Me.OrderDate other.OrderDate End Function Public Overrides Function GetHashCode() As Integer Dim hash As Integer 17 hash hash * 31 If(Me.CustomerCode Is Nothing, 0, Me.CustomerCode.GetHashCode()) hash hash * 31 If(Me.ProductCode Is Nothing, 0, Me.ProductCode.GetHashCode()) hash hash * 31 Me.OrderDate.GetHashCode() Return hash End Function End Structure这里使用了常见的17 乘 31组合哈希算法。17是初始种子值31是乘法因子质数能降低哈希碰撞概率。每次乘 31 再加上一个字段的哈希码确保不同的字段顺序能产生不同的组合哈希同时保持同字段值 → 同哈希码的确定性。注意组合哈希算法中选择大质数是为了让最终哈希码的位分布更均匀减少碰撞。实际项目的键如果字段不多也可以用位移加异或的组合方式。但无论哪种必须保证字段顺序不同时结果不同比如(a,b)和(b,a)不应该得到相同哈希。6.3 规则三哈希码要稳定且均匀稳定是说同一个键对象内容相同在程序生命周期内每次调用GetHashCode返回的值必须一致。上面实现中只依赖几个字段的哈希码字段不可变哈希自然稳定。均匀是说不同键的哈希码尽量散开不要大量撞到一个桶里。如果哈希码分布很差字典的查找效率会从 O(1) 退化到 O(n)表现就是程序变慢、CPU 飙升。对于复合键只要字段本身分布合理String的哈希码通常相当均匀组合算法的分布也足够好。如果你自定义结构体里用了一些非常规律的数据比如Integer都是连续值再加上质数乘法基本不会有问题。6.4 规则四容器级防御——用只读包装器或明确契约即便你把键结构体做成了不可变代码里某个程序员可能会聪明地用反射去改ReadOnly字段或者把结构体转成可变版本的另一个结构体再塞进去。这种情况极少见但为了防御有几个实践可以养成习惯第一永远不把正在使用的键对象暴露给外部修改。从Dictionary里取键时尽量别直接拿来操作。如果TryGetValue拿到了 Value 对象改 Value 里的字段没问题如果拿到了 Key就把它当只读数据看别去碰它。第二在团队协作里约定键类型不承担任何业务行为。结构体里除了构造函数、Equals、GetHashCode、ToString之外不写任何会修改自身状态的方法。这也是Functional Core思路在键设计上的体现。第三如果真的担心外部修改可以在键结构体的字段中加入一个版本号概念每次状态变更就重建一个新键对象而不是修改旧键。虽然这样会带来一些额外的分配但在正确性面前完全值得。7. 项目里的实际处理从踩坑到建立规范7.1 修复动作清单当时处理那个内部订单匹配系统我总共做了四件事第一把键结构体的字段全部改成ReadOnly。这需要把原本会修改键的代码改成新建键对象的方式代码上有一定的改动量但逻辑完全清晰了。第二给键结构体重写Equals、GetHashCode并实现IEquatable(Of OrderKey)。这一步不仅修复了潜在的哈希漂移还顺手解决了一个性能隐患原本默认GetHashCode在某些场景下会装箱现在完全避免了。第三把原本放在键里的状态字段挪到了字典的Value对象里。键只管定位值才管业务状态。这一下子从根上消除了因为要改状态所以不得不改键的诱因。第四针对全项目排查了一遍其他地方凡是结构体作键的全部按上述规则复查凡是类作键且重写了Equals的检查GetHashCode是否是配套的。7.2 上线验证与效果修复上线后又跑了一周跟踪观察KeyNotFoundException没有再出现过。更明显的是程序加载数据阶段的高峰吞吐有了一些提升这应该归功于去掉了装箱和反射式的默认哈希计算。虽然这个提升在整体耗时里被其他 IO 操作稀释了但性能方向是对头的也不存在正确性风险了。这个案例后来成了我们组内讨论时的经典素材也被当作一段参考放进新项目脚手架里的注释中。对于任何使用复合键的场景要求直接采用当时那个不可变结构体的模板。7.3 关于用 String 做键是不是最省事的一点补充排查完这个之后有人问我为什么不直接用客户编码 商品编码 订单日期拼成一个字符串当键非要折腾结构体其实这也是一种可行的简易方案。字符串天然是引用类型作为键时哈希和相等性由 .NET 管理不可变不容易踩坑。但它的缺陷也很明显拼接字符串有额外的分配开销且如果拼出来的格式不够规范字段边界模糊可能产生意外碰撞。比如AB C和A BC拼出来都是ABC两个不同的逻辑键会撞成同一个字典键这是更加隐蔽的业务错误。结构体键从类型层面保留了字段边界不会发生这种歧义。所以两种方案各有取舍。如果你追求最快最稳可以用结构体但遵循上面的四条规则如果你不想记忆那么多规则用规范化的String键加上不可见分隔符甚至限定长度也一样能安全运行。最忌讳的是在一个系统里混用几种方案那才会造成混乱。8. 多留一手的检查方法与调试技巧8.1 给键类型加 ToString 便于日志观测排查这类问题最怕的是看不见。给自定义键结构体重写ToString把各个字段用管道符号|拼起来输出日志就能一目了然地看到存进去的键和查询用的键到底哪里不一样。Public Overrides Function ToString() As String Return ${CustomerCode}|{ProductCode}|{OrderDate:yyyy-MM-dd HH:mm:ss} End Function排错时直接在日志里打两边的ToString一眼就能看出差异。这个习惯成本极低但价值极大。代码里的隐式信息不打印出来全靠猜永远是低效的。8.2 用哈希码对比工具做快速定位如果你怀疑是哈希漂移问题可以在出问题前打印键的哈希码问题复现时再打印一次对比差异。如果两边一致说明哈希码没问题那就要查Equals如果两边不一致说明哈希码漂移了重点排查哪个字段被改过。基于这个思路我把前面的定位过程整理成一张检查表供你参考症状检查方向工具/手段ContainsKey 返回 False日志中键貌似一致哈希码是否漂移打印插入时与查询时的 GetHashCode同一实例插入后立刻查不到哈希字段被并发修改检查字段修改点断点观察两个逻辑相同的不同实例一个查到另一个查不到Equals 与 GetHashCode 是否同时重写用调试器对比两者输出性能突然劣化字典操作明显变慢哈希分布差/装箱严重统计每个桶的数量或用分析工具看 GC浮点数键偶发查询失败类型不稳定改为 Decimal/取整后用 String 键这张表你可以直接复制到项目文档中作为团队内部排查字典键问题的手册。8.3 单元测试里的三点断言在写单元测试时任何自定义键类型至少要有三个测试用例第一条相等断言。构造两个内容相同的键断言Assert.AreEqual(key1, key2)成立且key1.GetHashCode() key2.GetHashCode()。第二条集合行为断言。把key1放入字典再用key2去查断言能查到。这相当于端到端验证字典的完整查找链路。第三条不可变断言。把键结构体所有字段设为ReadOnly后这个测试从编译层面就已保证了不需要额外运行时断言。如果字段没办法设成只读那就必须写一个修改字段后再查询会抛异常或返回预期值的用例去验证你明知会出问题从而避免有人乱改。这三条测试用例会把你从晚上熬夜排查的境地中拯救出来。一旦它们存在且通过字典键相关的幽灵问题基本就能被拦截在发布之前。这个项目处理完以后我自己有个感触凡是变量被隐式修改引发的问题都比变量显式写错更难查。结构体作键的坑之所以阴魂不散是因为它的修改总是发生在不经意之间——你甚至不会觉得自己在修改键只是顺手给某个状态字段赋了个值。而字典查找的这种先定位再确认的两段式逻辑又把修改后的哈希漂移变成了一个彻底见不到影子的隐患。所以在后来的几乎每个项目里我养成了一个条件反射每当我准备把一个自定义类型塞进Dictionary当键都会先停下来问三个问题——这个类型是可变的吗哈希码稳定吗相等性和哈希契约一致吗回答完这三个问题再动手写代码之后再也没在键这件事上吃过亏。最后再留个小建议如果你接手了别人的旧代码看到自定义类或结构体被用作字典键先别急着改业务逻辑花十分钟检查一下那个类型的Equals、GetHashCode和字段可变性。这十分钟的检查往往能帮你避免一次深更半夜的线上事故。