std::all_of和std::any_of用于明确表达容器条件检查意图，但需警惕空容器逻辑、谓词异常传播、悬垂迭代器、误读存在性语义及lambda捕获导致的悬垂引用等问题。
直接说结论：用 std::all_of 和 std::any_of 做容器条件检查，不是图“一行代码”炫技，而是为了明确表达意图、避免手写循环出错；但真要写对，得盯紧谓词返回值逻辑、迭代器范围有效性，以及 lambda 捕获引发的隐式生命周期问题。
std::all_of 判定失败比成功更常见，别默认它“像 if 一样安全”
很多人写 std::all_of(v.begin(), v.end(), [](int x) { return x > 0; })，以为只要容器非空就稳妥——其实空容器会直接返回 true（逻辑上“所有元素都满足”在空集上恒真）。这在权限校验、配置检查等场景容易埋雷。
- 若业务要求“至少一个元素且全部满足”，必须显式加
v.empty()判断 - 谓词里抛异常？
std::all_of不做异常防护，一旦抛出就传播，别指望它吞掉错误 - 用
auto推导迭代器时，注意v是临时对象会导致begin()/end()返回悬垂迭代器——比如std::all_of(get_vec().begin(), get_vec().end(), ...)是未定义行为
std::any_of 的“存在性”语义常被误读为“存在且唯一”
std::any_of 只回答“有没有至少一个满足”，不关心有几个、位置在哪。有人拿它替代查找，结果后续逻辑隐含了“只该有一个”的假设，却没验证。
- 想确认“有且仅有一个”，不能只靠
std::any_of；得配合std::count_if或手写计数循环 - 谓词返回
true后算法立即返回，不会遍历完——这本是性能优势，但若谓词有副作用（比如日志打印、状态修改），副作用只发生在第一个匹配元素上，这点极易被忽略 - 和
std::find_if比：后者返回迭代器可继续操作，std::any_of只给布尔值；别为了省一行代码，丢掉后续处理能力
lambda 捕获导致的 dangling reference 是静默崩溃主因
最典型的坑：std::all_of(v.begin(), v.end(), [&config](int x) { return x ，其中 <code>config 是函数局部变量，而 v 生命周期更长（比如传给异步任务）——lambda 持有对已销毁对象的引用，运行时崩得毫无征兆。
立即学习“C++免费学习笔记（深入）”；
- 捕获值优先：改用
[config = config]或[config]（C++17 起支持结构化绑定捕获） - 若必须捕获引用，确保引用所指对象的生命周期严格长于算法调用及 lambda 存续期
- 编译器不会警告这种错误；启用
-fsanitize=address,undefined能在测试中暴露大部分情况
真正难的从来不是写出那一行 std::all_of，而是想清楚“空容器算不算通过”“谓词能不能抛异常”“这个 [&] 引用到底活到什么时候”。这些点不抠清，一行代码反而比三行 for 循环更容易出生产事故。
