Any 和 All 是布尔逻辑运算符：Any 遇一真即真，All 全真才真；空集合时 Any 返回 false、All 返回 true（空真），易致逻辑错误，需显式检查非空；Any() 性能优于 Count > 0，Any(x=>...) 避免多余迭代器；EF Core 中复杂嵌套可能触发客户端求值。
Any 和 All 不是“有没有”和“全不全”的模糊判断，而是明确的布尔逻辑运算符——前者只要找到一个匹配就返回 true，后者必须每个元素都满足条件才返回 true；空集合对 Any 返回 false，对 All 却返回 true，这点最容易翻车。
空集合时 All 返回 true 是反直觉的坑
很多人写 list.All(x => x > 0) 检查“所有数是否为正”，结果空列表也通过了，导致后续逻辑出错。这不是 bug，是谓词逻辑中的“空真”（vacuous truth）——没有反例即视为成立。
- 如果业务上“至少一个元素且全部满足”才是本意，得显式加长度判断：
list.Any() && list.All(x => x > 0) - 数据库查询（如 Entity Framework）里
All会被翻译成NOT EXISTS(... AND NOT ...)，空表同样返回true，行为一致 - 别用
All替代“非空校验”，它不保证集合非空
Any 带条件 vs 无参重载性能差异很小，但语义不同
两种写法：list.Any() 只检查是否非空；list.Any(x => x.Status == "Active") 才做筛选。前者是 O(1)（IEnumerable 除外），后者最坏 O(n)。
-
Any()对List直接读Count，比Count > 0更安全（避免Count属性被重写成耗时计算） - 对
IEnumerable（比如 LINQ 查询未执行的结果），Any()内部只取第一个元素就停，而Count() == 0会遍历全部 - 别写
list.Where(x => x.Id == id).Any()，直接用list.Any(x => x.Id == id)，少建中间迭代器
在 EF Core 中用 Any/All 要小心子查询嵌套
EF Core 6+ 支持大部分 Any/All 场景，但复杂嵌套可能触发客户端求值（Client Evaluation）或生成低效 SQL。
-
context.Orders.Any(o => o.Items.All(i => i.Price > 10))通常能正确翻译成NOT EXISTS嵌套，但若Items是导航集合且未正确配置关系，可能报InvalidOperationException - 避免在
All条件里引用外部变量并参与比较（如list.All(x => x.Value > threshold)），某些旧版本 EF 会降级到客户端执行 - 用
AsNoTracking()配合Any可提升只查存在性的场景性能
真正难的不是语法，是每次写 All 都得心里默念一遍：“空集合算满足吗？”——多数时候不算，但代码不会提醒你。
