cv::HoughLines返回极坐标参数(ρ,θ)，不提供端点；cv::HoughLinesP直接输出线段端点(x₁,y₁,x₂,y₂)，适用于需斜率或几何定位的场景，且更鲁棒、免去反推端点步骤。
cv::HoughLines 和 cv::HoughLinesP 的核心区别在哪？
直接用 cv::HoughLines 得到的是极坐标表示的直线（ρ, θ），它不返回端点，只给参数；而 cv::HoughLinesP 返回的是像素坐标下的线段端点（x1,y1,x2,y2），更适合后续计算斜率。如果你只需要斜率、且图像中直线有明显起止位置（比如车道线、文档边缘），优先选 cv::HoughLinesP——它省去反推端点的步骤，也更鲁棒。
常见错误是：用 cv::HoughLines 后硬算两个交点再求斜率，结果因 ρ/θ 精度问题导致斜率跳变甚至 inf 或 nan。
-
cv::HoughLinesP输出是std::vector<:vec4i></:vec4i>，每个元素为[x1, y1, x2, y2] - θ 范围是 0~π，但斜率 k = tan(θ) 在 θ≈π/2 时爆炸，所以实际要区分垂直线
- 预处理很关键：必须先做 Canny 边缘检测，否则 Hough 变换基本失效
怎么从 Vec4i 线段安全算出斜率？
不能无脑写 (y2-y1)/(x2-x1)——除零、浮点精度、坐标顺序颠倒都会出错。正确做法是先判断是否接近垂直，再统一用 atan2 计算角度，最后转斜率。
for (const auto& line : lines) {
int x1 = line[0], y1 = line[1], x2 = line[2], y2 = line[3];
double dx = x2 - x1;
double dy = y2 - y1;
// 避免除零：用 atan2 直接得弧度角
double angle = atan2(dy, dx); // 注意是 dy, dx，不是 dx, dy
double slope = (abs(angle - M_PI_2) < 0.1 || abs(angle + M_PI_2) < 0.1)
? std::numeric_limits<double>::infinity()
: tan(angle);
}
-
atan2(dy, dx)自动处理象限和 dx=0 情况，比单独算tan(θ)安全得多 - 用
M_PI_2（即 π/2）加阈值判断垂直，比直接比较dx == 0更鲁棒（像素级误差难免） - 斜率正负号由方向决定：从 (x1,y1) 到 (x2,y2) 的向量决定，若需统一朝向（如都按左→右），可先排序 x 坐标
为什么检测结果忽多忽少？关键调参项有哪些？
Hough 线检测对三个参数极度敏感：threshold（投票阈值）、minLineLength、maxLineGap。它们不是“越大越好”或“越小越好”，而是相互制约。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
threshold：太小 → 噪声线暴增；太大 → 真线被过滤。建议从 50 开始试，配合可视化调试 -
minLineLength：小于该长度的线段直接丢弃。若目标线较短（如棋盘格短线），必须调低（如 10~20） -
maxLineGap：允许同一直线上的断点最大间隔。Canny 边缘断裂时靠它合并，设太大则不同线被误连 - 输入图像分辨率影响大：缩放后未重调参，
minLineLength数值意义就变了
OpenCV 默认坐标系下斜率和人眼直觉相反？
OpenCV 图像坐标原点在左上角，y 轴向下增长，所以一条从左上到右下的线（人眼觉得“斜率为正”），其 dy > 0、dx > 0，atan2(dy, dx) 算出来确实是正角，斜率也正——这点和数学笛卡尔坐标系一致。真正容易混淆的是：显示时图像被翻转了 y 轴，但计算过程没翻转，所以只要全程用 OpenCV 坐标，斜率符号就是可信的。
唯一陷阱是：如果你用 matplotlib 显示原图（默认 y 向上），再叠加 OpenCV 算出的斜率标注，视觉和数值会矛盾。解决方法只有统一坐标系——要么用 cv::imshow 查看，要么对 matplotlib 显示做 plt.gca().invert_yaxis()。
复杂点在于：真实场景中直线常带透视畸变，单条线段的斜率只是局部近似；若需全局几何校正，得拟合多条平行线再解单应性，那已经超出 Hough 单线检测范畴了。
