合理初始化容量、优化键类型哈希设计可显著提升Dictionary性能。预设容量避免频繁扩容，如预计1000条时用new Dictionary(1024)可提速10%~20%；字符串作键应避免过长或随机GUID，推荐使用不可变字段且重写GetHashCode与Equals的自定义键，禁用浮点数作键以防精度问题；负载率超0.7时需扩容或换SortedDictionary等替代方案，确保哈希分布均匀以维持O(1)查找效率。
Dictionary
合理预设容量，避免反复扩容
Dictionary 默认初始容量是 0，第一次 Add 就扩容到 3，之后按 2 倍增长（3→7→15→31…），每次扩容都要重新哈希全部已有元素，开销不小。如果你知道大概要存多少项，直接指定容量能跳过多次重建哈希表的过程。
- 估算数量后向上取整到下一个质数（.NET 内部扩容用的是质数容量表，比如 3、7、15 不是质数但内部会选 17）——其实你不用手动算，直接传入预估总数即可，框架会自动匹配最接近的合适质数容量
- 例如：预计存 1000 条，写 new Dictionary
(1024) 比默认构造快 10%~20%，尤其在批量初始化场景下效果明显 - 如果数据量动态变化大且无法预估，可考虑用 Dictionary.Capacity 属性在适当时机手动调整，但别频繁 set
确保键类型的 GetHashCode 稳定高效
哈希冲突多，往往不是 Dictionary 的问题，而是 TKey 的 GetHashCode() 实现太弱或不稳定。比如字符串过长、自定义类没重写、或哈希值分布严重倾斜。
- 字符串作为键时，避免用超长随机 GUID 字符串（如 Guid.NewGuid().ToString()），它生成的哈希值虽唯一但分布未必均匀；用 Guid.ToByteArray() 再哈希反而更稳（不过通常没必要，.NET 的 string.GetHashCode 已经够好）
- 自定义类作键，必须同时重写 GetHashCode() 和 Equals()，且 GetHashCode 返回值应仅依赖不可变字段；推荐用元组或 record 自动生成（(a, b).GetHashCode()）
- 避免用浮点数（float/double）作键——精度误差会导致 Equals 返回 false，但 GetHashCode 可能偶然相同，引发查找失败或逻辑错乱
识别并缓解哈希冲突的实际影响
冲突本身不可完全避免，但高冲突率（比如平均链长 > 3）会退化成接近 O(n) 查找。可通过 Dictionary.Count / Dictionary.Capacity 粗略判断负载率，再结合 Object.ReferenceEquals 或调试器观察桶内链表长度。
- 负载率超过 0.7 就该考虑扩容或优化键 —— .NET 默认阈值是 0.72，达到即触发扩容
- 用 System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode(obj) 做兜底哈希（适用于无良好 GetHashCode 的引用类型），但它不保证相等对象哈希一致，仅适合临时排错
- 真遇到高频冲突且无法换键，可改用 SortedDictionary（O(log n) 稳定，无哈希依赖），或用 ConcurrentDictionary 的分段锁机制缓解争用（非性能提升，是并发安全下的折中）
基本上就这些。Dictionary 的快，建立在哈希靠谱、空间够用、键不捣乱的基础上。不复杂但容易忽略。
