指定初始容量和选对stringcomparer能让dictionary查找快15%~30%；默认构造从容量0开始，首次add即扩容至3并按质数序列增长，每次扩容需重哈希全部元素，且字符串键若未显式指定stringcomparer.ordinalignorecase会导致额外tolower开销。
直接说结论：指定初始容量和选对 StringComparer 能让 Dictionary<string t></string> 查找快 15%~30%，尤其在批量初始化或高频查找场景下，效果肉眼可见。这不是“锦上添花”，而是避免掉进默认行为埋的坑。
为什么 new Dictionary() 默认很慢？
默认构造函数从容量 0 开始，第一次 Add 就扩容到 3，之后按质数序列增长（3 → 7 → 15 → 17 → 31 → 37…）。每次扩容都要重哈希全部已有元素——10 万条数据可能触发 15+ 次重建，光是内存拷贝和哈希重算就吃掉大量 CPU。
更隐蔽的问题是：字符串键默认用 StringComparer.Ordinal，但如果你实际比较逻辑是不区分大小写（比如查 HTTP header 名），却没显式指定 StringComparer.OrdinalIgnoreCase，就会导致每次 ContainsKey 或 TryGetValue 都多一次字符串 Normalize 或 ToLower 调用，拖慢单次查找 20% 以上。
- 预估数量后直接传入容量值即可，.NET 内部会自动向上取整到最近质数（如传 1000 → 实际用 1009）
- 别手动算质数，也别传 1024 这种 2 的幂——
Dictionary不用 2 的幂做桶数组，那是老式哈希表的套路 - 如果键来自用户输入或外部 API，且业务上允许忽略大小写，必须在构造时传
StringComparer.OrdinalIgnoreCase，而不是靠key.ToLower()临时转换
StringComparer 选错的典型表现
现象：TryGetValue("content-type", out var v) 返回 false，但你知道字典里明明有 "Content-Type"；或者性能分析器显示 string.ToLower() 占了 12% 的 CPU 时间。
原因：默认 StringComparer.Ordinal 是严格二进制比较，"Content-Type" 和 "content-type" 哈希值不同、Equals 也返回 false；而你又没在构造时声明比较方式，导致每次查找都得手动转小写再查——等于做了两次哈希 + 一次字符串分配。
-
StringComparer.Ordinal：最快，纯字节比，适合内部 ID、配置项等确定格式的字符串 -
StringComparer.OrdinalIgnoreCase：推荐用于 HTTP header、JSON field name、数据库列名等场景，性能损失极小（.NET 6+ 已深度优化） - 绝对不要用
StringComparer.CurrentCulture做键比较——文化相关逻辑会引发哈希不一致，同一字符串在不同线程/区域设置下可能算出不同哈希值
怎么验证你的 Dictionary 真的变快了？
别只看“代码写得漂亮”，要盯住两个硬指标：
- 构造后立刻检查
dictionary.Capacity是否接近你预设值（比如预设 1000，实际是 1009），不是 3 或 7 —— 否则扩容已发生过 - 用
dictionary.Count / (double)dictionary.Capacity算负载率，长期高于 0.7 就说明要么容量设小了，要么键哈希分布太差（比如全用 GUID 字符串作键） - 在调试模式下打断点，观察
dictionary.buckets数组里各桶的链长，平均超过 2 就值得怀疑键设计
最常被忽略的一点：StringComparer 必须在构造时指定，后续无法修改；而容量虽可通过 dictionary.Capacity = 2000 手动调大，但不会自动缩容，且 set 容量会强制触发一次重哈希——所以宁可一开始设略大，也不要中途反复调整。
