怎么安全地取值？别再用 dict[key]
直接访问了
直接写
dict["user1"]看似简洁，但只要键不存在，立刻抛出
KeyNotFoundException——线上服务一崩就是这个原因。真实项目里，键来源常来自用户输入、配置文件或数据库字段，根本不能假设“一定存在”。 ✅ 推荐用
TryGetValue()：安全、高效、一行搞定 ❌ 避免
ContainsKey() + dict[key]两次查找：性能白丢一半 ⚠️
GetValueOrDefault()可用，但注意默认值是类型默认值（比如
int是 0，
string是
null），容易掩盖逻辑错误
Dictionary<string, string> userMap = new Dictionary<string, string> { ["user1"] = "Alice" };
if (userMap.TryGetValue("user2", out string name))
{
Console.WriteLine($"找到用户：{name}");
}
else
{
Console.WriteLine("用户不存在");
}
添加键值对时，Add()
、索引器、TryAdd()
到底该选谁？
三者行为完全不同，混用会导致逻辑混乱甚至数据丢失。
Add()：键已存在 → 立刻抛
ArgumentException；适合“严格不允许覆盖”的场景（如注册唯一ID） 索引器赋值（
dict[key] = value）：键存在则覆盖，不存在则新增；适合缓存更新、状态快照等
TryAdd()（.NET Core 2.0+ / .NET 5+）：键不存在才添加，存在则静默失败并返回
false；适合并发初始化或“只设一次”的配置项
var config = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
config.TryAdd("Timeout", "30"); // 成功
config.TryAdd("timeout", "60"); // 失败（忽略大小写，键已存在），返回 false
config["Timeout"] = "45"; // 强制覆盖为 45
为什么预设容量很重要？不是说字典能自动扩容吗？
能扩，但每次扩容都要重建整个哈希表：重新计算所有键的哈希值、重排
Entry[]数组、复制数据——这会卡主线程，实测在万级数据插入时，不预设容量比预设慢 3–5 倍。 默认初始容量是 0（实际内部桶数组长度为 3），第一次 Add 就触发扩容 扩容策略是质数序列（如 3→7→13→29…），频繁扩容还会导致内存碎片 如果你知道大概要存 2000 条记录，直接写
new Dictionary<int user>(2048)</int>
// ✅ 好习惯：按需预估，向上取最近的质数（或直接略大一点） var userCache = new Dictionary<int, User>(10_000); // ❌ 别这样：让字典自己反复 realloc var badCache = new Dictionary<int, User>(); // 后续 Add 1w 次，至少扩容 10+ 次
遍历和排序：字典天生无序，想按插入顺序或 Key 排序得绕个弯
Dictionary内部是哈希表，
foreach遍历顺序 ≠ 插入顺序，也 ≠ Key 大小顺序。这是高频误解点，尤其做导出、日志、调试时容易翻车。 要按插入顺序：改用
System.Collections.Generic.Dictionary不行，得换
System.Collections.ObjectModel.KeyedCollection<tkey tvalue></tkey>或自行维护
List<keyvaluepair ...>></keyvaluepair>要按键排序：用 LINQ 的
OrderBy()（返回
IOrderedEnumerable，非字典） 要按值排序：同理，但注意值可能重复，Key 会丢失
var scores = new Dictionary<string, int> { ["Bob"] = 85, ["Alice"] = 92, ["Charlie"] = 78 };
// 按 Key 字母序输出（注意：结果是新序列，不是字典）
var sorted = scores.OrderBy(kv => kv.Key);
foreach (var kv in sorted)
{
Console.WriteLine($"{kv.Key}: {kv.Value}");
}
// 输出：Alice: 92, Bob: 85, Charlie: 78
字典的“快”建立在哈希正确、无冲突、容量合理的基础上；一旦键的 GetHashCode()实现不稳定，或者大量键哈希碰撞，性能会断崖下跌——这点比语法细节更值得花时间验证。
