ContainsKey是判断键存在的最直接高效方式，时间复杂度O(1)，复用FindEntry且无异常、无临时对象；TryGetValue适用于“查+用”连贯场景，一次哈希完成存在性检查与值获取。
ContainsKey 是最直接、最高效的方式，它不抛异常、不分配临时对象、时间复杂度稳定为 O(1) 平均情况。别用 Keys.Any() 做键存在性判断——那是 LINQ 的暴力遍历，本质是 O(n)，纯属浪费。
为什么 ContainsKey 是首选
它直接复用字典内部的哈希查找逻辑，跳过值提取、枚举器构造、委托调用等开销。底层调用的是 FindEntry，只比实际取值（this[key]）少一次值拷贝。
- 不依赖
using System.Linq，无额外引用负担 - 返回
bool，语义清晰，和 if 判断天然契合 - 对 null 键有明确定义：引用类型键为
null时，若字典允许 null 键（如未指定EqualityComparer<tkey>.Default</tkey>且 TKey 为引用类型），则正常参与哈希比较；否则可能抛ArgumentNullException - 值类型键不可能为 null，无需空检查
TryGetValue 适合“查+用”连贯场景
当你不仅想知道键是否存在，紧接着还要用它的值，TryGetValue 就比 ContainsKey + this[key] 更优：一次哈希查找完成两件事，避免重复定位。
- 避免二次哈希计算：用
ContainsKey再取值，等于查了两次桶位置 - 线程安全更可控：在并发读多写少场景下，
TryGetValue是原子读操作，而ContainsKey+this[key]之间可能被其他线程修改 - 注意 out 参数必须声明变量接收，不能传字面量或表达式：
dict.TryGetValue("x", out string v)合法，dict.TryGetValue("x", out "dummy")编译失败
千万别用 Keys.Any() 判断 key 存在
这是最常见的误用。它表面像“查询”，实则是把整个 Keys 集合转成枚举器，再逐个调用 string.Compare 或 Equals ——完全绕开了哈希表的设计初衷。
- 性能灾难：字典有 10 万项时，最坏要比较 10 万次；
ContainsKey仍是常数级 - 隐式依赖 LINQ：需引入
System.Linq，在 Unity IL2CPP 或 AOT 编译环境下可能触发不必要的代码膨胀 - 语义误导：
Keys.Any(x => x == key)看起来简洁，但编译后生成闭包类和迭代器状态机，GC 压力明显高于纯方法调用 - 字符串比较还容易踩坑：没加
StringComparison.Ordinal时，默认文化敏感比较，可能在不同系统行为不一致
索引器访问（dict[key]）不是判断手段
直接通过下标访问并捕获 KeyNotFoundException 来判断，属于反模式。异常机制本就为“异常”设计，而非流程控制。
- 抛异常开销大：栈展开、异常对象构造、处理路径跳转，比一次
ContainsKey调用慢 100 倍以上 - 掩盖真正异常：如果字典本身被并发修改（如另一线程正在
Add），也可能抛InvalidOperationException，和 key 不存在混在一起难排查 - IDE 和静态分析工具（如 Roslyn 分析器）通常会警告这种用法，比如 CA2201
真正要注意的其实是键的相等性契约：如果你自定义了 IEqualityComparer<tkey></tkey>，那么 ContainsKey 和 TryGetValue 的行为完全取决于它的 GetHashCode 和 Equals 实现——这里出错，所有判断都会静默失效。
