std::binary_search仅返回bool表示存在性，不提供位置信息；需获取位置应直接使用std::lower_bound或std::upper_bound，二者返回迭代器且复杂度同为o(log n)。
std::binary_search 返回 bool 而不是迭代器，是设计取舍，不是疏忽
它压根就不是为“找位置”写的——名字里带 search 是误导，实际语义是“确认存在性”。c++ 标准库把“查存在”和“查位置”拆成了两个独立算法，这是有意为之：避免用户误以为能靠一个函数同时满足两种需求，又不暴露实现细节或增加接口复杂度。
常见错误现象：std::binary_search 返回 true 后，有人直接用 std::lower_bound 再查一遍，以为在做“补全”，其实多了一次二分；更糟的是，有人手写循环去线性扫描找位置，完全浪费了已排序的前提。
-
std::binary_search只做一次比较决策：中间元素 ≥ 目标？然后缩区间，最终只回答“见过还是没见过” - 它不记录最后一次匹配的索引，也不保证中间状态可访问——编译器甚至可能优化掉部分比较步骤
- 如果你需要位置，
std::lower_bound或std::upper_bound才是正解，它们返回迭代器，且复杂度同样是O(log n)
想拿到位置？别绕弯，直接用 lower_bound
90% 场景下你要的“第一个等于目标的位置”，就是 std::lower_bound 的结果，前提是它指向的元素确实等于目标（得自己判一下）。它比 binary_search 多做的只是一次最终解引用比较，开销几乎可忽略。
使用场景：查找插入点、统计重复元素个数、实现 map/set 的底层逻辑——这些都需要位置，而不是布尔值。
立即学习“C++免费学习笔记（深入）”；
- 调用后必须检查：
it != container.end() && *it == value，否则*it可能越界或不等 -
std::lower_bound返回的是“首个不小于 value 的位置”，所以即使没找到相等元素，它也有定义（比如插入位置） - 如果容器是
std::vector且你只需要下标，用it - vec.begin()，别用std::distance——前者是常数时间，后者对随机访问迭代器虽也 O(1)，但可读性差
auto it = std::lower_bound(vec.begin(), vec.end(), x); if (it != vec.end() && *it == x) { size_t pos = it - vec.begin(); // 这才是你要的位置 }为什么标准不改？兼容性和抽象边界很关键
加一个返回迭代器的重载看似方便，但会破坏现有代码的重载解析，尤其当传入自定义比较器时。更深层的原因是：C++ 算法库坚持“一个函数一个职责”，binary_search 的契约就是“只问真假”，改它等于改契约。
性能影响几乎为零——lower_bound 和 binary_search 底层共享同一套二分逻辑，差异仅在最后一步是否解引用、是否提前退出。
- 所有标准库实现（libstdc++、libc++、MSVC STL）都复用相同的核心二分循环，
binary_search就是删掉了结果处理那几行 - 如果你封装一个“安全版 find_index”，内部仍得调
lower_bound，没法绕过这个事实 - 某些嵌入式或极端性能场景会手动展开二分，这时要不要存位置，完全由你控制——标准库不替你做这种权衡
容易被忽略的边界：迭代器失效和比较器一致性
最常踩的坑不是不会选函数，而是忘了 lower_bound 的行为依赖于整个范围的有序性，而这个“有序”是由你传入的比较器定义的。一旦比较器和排序时用的不一致，结果就不可预测，而且不会报错。
- 排序用了
std::greater<int>()</int>，查找时却用默认，<code>lower_bound会返回垃圾位置 - 容器在查找前被其他线程修改，或迭代器因
push_back失效，lower_bound行为未定义——它不校验有效性 -
std::binary_search同样受此影响，但它至少不会让你误以为得到了有效位置
事情说清了就结束：要位置，就老实用 lower_bound；信不过它，就自己写带断言的二分——但别指望 binary_search 补上这个缺口。