标准NMS必须每次从剩余框中动态选取当前最高分框再抑制，而非预排序后单向遍历，否则会漏掉被中间高分框遮蔽但定位更准的低分框。
为什么直接用 std::sort 排序后遍历会漏掉多层重叠框？
很多初学者写 NMS 时先按置信度降序排，再逐个取框、剔除与其 IoU > 阈值的后续框——这看似合理，但实际会漏掉被中间高分框“遮蔽”的低分但更准的框。根本原因是：排序后剔除只向前看（即只删后面的），而真实场景中，一个低分框可能和前面多个高分框都重叠，但它本身可能覆盖更准的边界，只是分数略低。标准 NMS 要求每次选当前最高分剩余框，再删所有与其 IoU 超限的其他框，而不是一次性排完就线性扫一遍。
实操建议：
- 用
std::vector<:tuple int float>></:tuple>存（score, idx, x1, y1, x2, y2），避免排序时丢失原始索引 - 每次循环前用
std::max_element找剩余元素里 score 最大的，而非预排序后固定顺序遍历 - IoU 计算必须用浮点运算，
int坐标相减易因截断导致交集为 0（尤其小目标）
cv::dnn::NMSBoxes 的 score_threshold 和 nms_threshold 到底谁先起作用？
OpenCV 的 cv::dnn::NMSBoxes 是最常被调用的封装接口，但参数执行顺序容易误解：score_threshold 是硬过滤，在 NMS 前就丢弃所有 score nms_threshold 才是真正的 IoU 阈值，用于抑制阶段。两者不是“或”关系，而是“先筛再压”。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 设了
score_threshold=0.5却发现输出框数远少于预期 → 实际输入框里大量 score 在 0.4~0.49 区间，被提前滤掉了 - 调大
nms_threshold到 0.7 还是抑制过猛 → 检查是否score_threshold太高，导致只剩几个高分框，它们之间 IoU 天然就高 - 传入的
boxes是std::vector<:rect></:rect>，但坐标是归一化值（0~1）→ 必须先乘以原图宽高转成像素坐标，否则 IoU 计算失真
手写 NMS 时，IoU 计算里 std::max(0.f, ...) 为什么不能省？
IoU 公式里的交集面积是 std::max(0.f, x_right - x_left) * std::max(0.f, y_bottom - y_top)。省掉 std::max(0.f, ...) 看似省事，但一旦两个框不重叠（比如一个在左上、一个在右下），x_right - x_left 就是负数，乘出来是负面积，最终 IoU 可能算出负值甚至 NaN（尤其开启浮点异常时），后续比较直接崩。
使用场景提醒：
- 目标检测输出的 box 坐标可能是
(x_center, y_center, w, h)格式 → 必须先转成(x1, y1, x2, y2)，且注意x1 = x_center - w/2，别漏除 2 - 如果模型输出带 padding 偏移（如 YOLOv5 在 resize 后做了 letterbox），IoU 计算前必须先把 box 映射回原始图像坐标系，否则 IoU 值不可比
- 性能敏感场景（如嵌入式端），可把
std::max(0.f, ...)换成分支预测友好的三元运算符(a > b ? a - b : 0.f)，部分编译器优化更好
C++17 下用 std::span 管理 box 数组会不会提升 NMS 性能？
不会。NMS 的瓶颈从来不在数组访问开销，而在双重循环的 O(N²) 时间复杂度和频繁的浮点计算。用 std::span 替代 std::vector 或裸指针，只改变接口契约，不减少任何实际计算量。反而可能因额外的 size 检查（debug 模式下）或失去 vector 的 cache 局部性（若 span 指向非连续内存）拖慢速度。
真正值得做的优化：
- 把 box 数据组织成 SoA（Structure of Arrays）：四个独立的
std::vector<float></float>分别存 x1/y1/x2/y2，利于 SIMD 向量化（如用__m128一次算 4 个交集） - 在 IoU 内层循环加 early-exit：若当前交集宽度已 ≤ 0，直接跳过高度计算
- 对大尺寸输出（如 1000+ 框），先用网格法（grid-based filtering）粗筛：把图像划成 8×8 网格，每格只保留 top-3 分数框，再进 NMS
实际项目里，90% 的 NMS 性能问题出在没做 score 预过滤或 IoU 计算写错，而不是容器选型。
