std::equal_range 优先于手写循环，因其语义清晰、复用 lower/upper_bound 避免重复比较，且编译器深度优化；手写易出错，如 right = size 时边界处理不当。
std::equal_range 为什么比手写循环更值得优先用
标准库的 std::equal_range 不仅语义清晰，而且在绝大多数场景下比手写二分循环更快——它复用了 std::lower_bound 和 std::upper_bound 的底层实现，避免了重复比较；编译器对标准算法有深度优化（比如内联、分支预测提示），而手动写的 while 循环容易因边界条件出错或触发未优化路径。
常见错误现象：自己实现时把 left/right 初始值设错（比如 right = size 却用 判定），或在查找失败时没统一返回空范围，导致后续解引用 <code>first 或 second 崩溃。
- 必须确保容器已排序（升序），否则行为未定义；
std::equal_range不做校验，也不报错 - 支持自定义比较器，但必须满足严格弱序（strict weak ordering），否则结果不可靠
- 对
std::vector、std::array、原生数组等随机访问迭代器，时间复杂度稳定为O(log n)；对std::list等不支持随机访问的容器，退化为O(n)，不应使用
如何正确调用 std::equal_range 并安全解包结果
std::equal_range 返回的是 std::pair<iterator iterator></iterator>，其中 first 指向第一个不小于目标值的位置，second 指向第一个大于目标值的位置。两者相等说明没找到该值。
典型误用：直接用 auto [l, r] = std::equal_range(...) 在 C++17+ 中看似简洁，但如果容器为空或目标不存在，r 可能等于 end()，后续用 std::distance(l, r) 是安全的，但若误以为 r 总是有效迭代器并解引用就会 UB。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 检查是否存在：用
if (range.first != range.second)，而非if (!range.first)（迭代器没有布尔转换） - 获取数量：用
std::distance(range.first, range.second)，不要用range.second - range.first（对非随机访问迭代器不合法） - 遍历匹配元素：
for (auto it = range.first; it != range.second; ++it)，注意别写成it
std::vector<int> v = {1, 2, 2, 2, 3, 4, 4};
auto range = std::equal_range(v.begin(), v.end(), 2);
// range.first → points to first 2
// range.second → points to 3
自定义比较器下 equal_range 的陷阱
当用 std::equal_range 查找结构体或自定义类型时，传入的比较器必须和排序时完全一致。哪怕只差一个 const 或参数顺序，都可能导致找不到结果或越界。
常见错误现象：排序用 [](const auto& a, const auto& b) { return a.key ，但 <code>equal_range 里传了 [](auto a, auto b) { return a.key （少了 <code>const&），编译可能通过，但运行时行为异常（尤其涉及临时对象时）。
- 比较器类型必须完全相同：函数指针、lambda 类型、functor 类型三者互不兼容
- lambda 捕获变量后不能用于
equal_range（无法复制/默认构造），应改用函数对象或静态函数 - 若比较逻辑依赖外部状态（如 locale、精度阈值），务必确保该状态在查找期间不变
性能敏感场景下的替代方案：手写二分还是用 lower/upper 分开调用？
除非 profiler 明确指出 std::equal_range 是瓶颈（极少见），否则不要替换。但若真要优化：分开调用 std::lower_bound 和 std::upper_bound 并复用第一次的结果——标准库内部其实也这么做，但用户手动复用可省一次迭代器加法（例如在 vector 中，upper_bound 起点设为 lower_bound 返回位置而非 begin）。
不过这种优化收益微乎其微，且增加代码复杂度；真正影响性能的是数据局部性（cache line）、分支预测失败（比如重复查找稀疏值），而不是算法常数项。
- 不要为“少一次比较”去手写二分——现代 CPU 的分支预测和预取机制让标准库实现几乎总是最优
- 如果目标值高频重复出现，考虑用
std::map或哈希表存索引映射，而非反复二分 - 对小数组（
size ），线性扫描反而更快；<code>std::equal_range没有自动 fallback，需自行判断
最易被忽略的一点：std::equal_range 对浮点数查找极其危险——由于精度误差，排序时的 和查找时的 <code> 可能产生不一致结果。必须用整数键、或固定精度的定点表示，或改用带 epsilon 的自定义比较器并全程统一使用。
