搞C++图像处理的老哥，几乎都躲不过直线检测这道坎。不管是做文档扫描、车道线识别、工业尺寸测量还是机器人导航，“画面里有没有直线、直线在哪儿、角度是多少”都是最基础的需求。最近不少朋友私信问我OpenCV里直线检测到底怎么用，我干脆把实际项目里反复验证过的一套东西整理出来——从原理到选型，从参数调到性能优化，一次性说透。
我用的环境是OpenCV 4.x + C++11，编译器用的GCC和MSVC都跑过，下面的代码和结论在这些环境下实测都能正常复现。需要说明的是，OpenCV 3.x版本里API基本一致，个别参数名有差异，到时候查一下对应版本的头文件就行。
1. 直线检测的核心问题：从Hough变换的数学原理说起
1.1 为什么直线检测本质上是"投票问题"
直线检测的主流方案几乎都是基于Hough变换（霍夫变换）。它的核心思想，是把图像空间里的直线，映射到参数空间里的点，然后用投票的方式找出“最有资格”的那条直线。
图像空间里一条直线可以用斜截式y = kx + b表示，但这有个问题：当直线垂直于x轴时，斜率k会趋近于无穷大，没法直接处理。所以OpenCV用的是极坐标形式：
x * cos(theta) + y * sin(theta) = rho其中rho是直线到原点的垂直距离，theta是直线法线与x轴的夹角。图像空间中的一个点(x, y)，对应参数空间(rho, theta)里的一条正弦曲线；图像空间中的一条直线，则对应参数空间中的一个交点。于是问题就变成了：把一堆点映射成曲线，找曲线密集交叠的那个峰值。
我最早接触Hough变换时，觉得这个映射太抽象了。后来用了一个生活化的类比才彻底搞懂：想象一屋子人，每个人手里拿着一张透明胶片，上面画着一条正弦曲线。所有人把胶片叠在一起，对着光看，哪里的黑色最重，就说明很多人支持这里的“直线参数组合”。那个最黑的位置，就是我们要找的直线。
1.2 OpenCV里Hough变换的两种实现路径
OpenCV提供了两套接口，很多人分不清：
HoughLines：标准Hough变换。它返回的是直线的极坐标参数(rho, theta)，也就是说每条直线只有“法向距离”和“法向角度”两个属性，没有端点，也没有长度范围。它适合需要无限长直线的场景，比如找消失点、测量地面标线方向等。HoughLinesP：概率Hough变换。它在标准Hough变换的基础上做了改进——从图像中随机选取部分边缘点进行投票，投票结束后再通过线段合并、长度过滤等后处理，返回的是线段端点坐标(x1, y1, x2, y2)。它适合提取有限长度的线段，比如文档边缘、零件轮廓、车道标线。
我的经验是，大多数应用场景用HoughLinesP就够了，因为它直接给端点，后续无论是测量长度、计算交角还是拟合中线，都省去了一大堆几何推导。HoughLines返回的无限长直线，在实际项目里很少直接用，通常是为了配合几何模型做进一步推导。
2. 环境准备与第一个可运行的C++示例
2.1 OpenCV依赖配置的细节
在开始写代码之前，先把环境说清楚。我用的是OpenCV 4.8.0，Windows下通过vcpkg安装，Linux下通过apt或源码编译都行。这里有几个容易踩的坑：
- vcpkg安装时，要确认安装的是带
contrib模块的完整版本还是基础版本。直线检测属于imgproc模块，基础版就够用，不一定非要装contrib。 - Windows下使用MSVC编译，要注意运行时库设置。如果你用的OpenCV是MD编译的，你项目里也得用MD（Release模式默认就是），否则会把一堆
libpng、libjpeg的运行时错误炸出来。 - Linux下如果遇到
undefined reference to cv::HoughLinesP，十有八九是链接库顺序写错了。在g++命令行里，OpenCV的库要放在源文件后面，例如g++ main.cpp -o line_detect -lopencv_core -lopencv_imgproc -lopencv_highgui。
链接顺序这道坑我见过太多次，很多人把库文件写在源文件前面，链接器在扫描库符号时就找不到依赖，直接报错。这个顺序问题在gcc和clang里都很严格，MSVC则相对宽松一些，但也建议保持一致的习惯。
2.2 最小可运行的直线检测Demo
先给出一段可以直接编译运行的代码，上面用注释标注了每个步骤的位置，方便对着分析：
#include <opencv2/opencv.hpp> #include <iostream> int main(int argc, char** argv) { if (argc < 2) { std::cerr << "Usage: " << argv[0] << " <image_path>" << std::endl; return -1; } cv::Mat src = cv::imread(argv[1], cv::IMREAD_COLOR); if (src.empty()) { std::cerr << "Failed to load image" << std::endl; return -1; } cv::Mat gray, edges; cv::cvtColor(src, gray, cv::COLOR_BGR2GRAY); cv::GaussianBlur(gray, gray, cv::Size(5, 5), 1.2, 1.2); cv::Canny(gray, edges, 50, 150); std::vector<cv::Vec4i> lines; cv::HoughLinesP(edges, lines, 1.0, CV_PI / 180, 80, 30, 10); cv::Mat result = src.clone(); for (const auto& ln : lines) { cv::line(result, cv::Point(ln[0], ln[1]), cv::Point(ln[2], ln[3]), cv::Scalar(0, 0, 255), 2, cv::LINE_AA); } cv::imwrite("result.png", result); std::cout << "Detected " << lines.size() << " line segments" << std::endl; return 0; }这段代码逻辑很直白：读图、转灰度、高斯模糊、Canny边缘检测、HoughLinesP直线段提取、画线输出。我建议初学者先别急着调参，把这五步跑通，把所有中间结果显示在屏幕上，确认每一步都能看到预期效果，再往下走。很多复杂问题，最后都能追溯到预处理环节出了偏差。
3. 参数详解与调优：从阈值到minLineLength的实战手感
3.1 rho、theta和vote：三个参数是如何联动的
HoughLinesP的完整签名是：
void cv::HoughLinesP( InputArray image, // 输入图像，要求是8位单通道，通常是Canny输出 OutputArray lines, // 输出的线段数组 double rho, // 距离分辨率，单位像素 double theta, // 角度分辨率，单位弧度 int threshold, // 投票数阈值，低于该票数的直线被丢弃 double minLineLength, // 线段最短长度，低于该值的线段被丢弃 double maxLineGap // 同一直线上两点之间的最大间隔，超过该间隔则断开 );第一个容易产生困惑的是rho。它表示累加器在距离轴上的分辨率。设置rho = 1，意味着距离参数每1个像素做一个投票桶；设置rho = 2，则是每2个像素做一个桶。分辨率越低（数值越大），计算量越小，但检测精度也越低。我的习惯是默认1.0，处理大分辨率图像（比如3000×4000）时才允许放到2.0，否则某些短线段可能被“抹”进相邻桶里，导致角度偏移。
theta是角度分辨率，单位是弧度。CV_PI / 180表示每1度一个投票桶，CV_PI / 360表示每0.5度一个桶。对角度要求高的场景——比如斜切工件需要精确测量旋转角——我会把精度提高到0.5度，但随之而来的是累加器体积翻倍、投票时间变长。反过来，如果只是粗筛方向，CV_PI / 180足够。
threshold是最关键的参数。它代表能成为一条“直线”的最低票数。票数本质上是线段上边缘点的数量。threshold设得越低，检测出的线段越多、越碎；设得越高，漏检越严重。这个参数的敏感度极高，我甚至养成了一个习惯：任何图像的第一遍测试，先把它设成50，观察结果，再用二分法微调。
3.2 minLineLength和maxLineGap的把关作用
minLineLength用来过滤太短的线段。比如一个小螺丝钉的轮廓，边缘点可能也就二十来个像素，如果你把minLineLength设成100，它就直接被剔除了。反过来，在车道线检测里，如果路面上的虚线每段长约40像素，而你设了60，那虚线就全没了。所以这个参数必须根据你要检测目标的物理尺寸，换算成像素长度后再设定。
maxLineGap表示同一条直线上相邻线段之间的最大允许间隔。直白说，就是允许“接缝处”断掉多远还能拼成一条线。这个参数在检测被遮挡物切割的直线时特别有用——比如工件表面有一条很长的刻痕，中间被灰尘覆盖了一段，边缘不连续，如果maxLineGap太小，就会断成好几条短线段；设成20~30像素，就可以跨过灰尘区，把它们合并成一条完整直线。
有一点要特别提醒：maxLineGap设得太大会导致误连。比如两条平行线距离很近，中间有少量噪点，就可能被拼接成一条斜线。所以这类“宽容度”参数永远需要平衡，不能盲目调大。
3.3 一组可复用的调参经验值
我在不同光照、不同材质、不同分辨率图像上折腾了很久，总结出一组起点参数。注意这只是起点，不是标准答案：
| 场景类型 | threshold | minLineLength | maxLineGap |
|---|---|---|---|
| 文档扫描（300dpi A4） | 60~100 | 50 | 10 |
| 工业零件边线（500×500左右） | 80~120 | 30 | 10~15 |
| 车道线（1080p视频帧） | 30~50 | 40 | 20 |
| 图纸/图表直线提取 | 50 | 30 | 5 |
调参的逻辑顺序也很重要，我每次都是按“threshold -> minLineLength -> maxLineGap”的顺序来，因为threshold对结果的影响是全局性的，先把它稳定下来，再去处理线段长度和断接细节。如果一开始就纠结maxLineGap，你会发现怎么调都找不到满意的组合，因为噪音早就因为threshold太低而混进来了。
4. 边缘检测预处理：为什么它决定直线检测的成败
4.1 Canny之前的降噪策略
很多人拿到图像直接怼Canny，结果发现直线检测结果飘忽不定——今天检测出10条线，明天同样的图检测出17条，而且很多线还是断断续续的。原因几乎都出在边缘噪声上。
Canny本身已经内置了高斯滤波，但它的内部滤波器尺寸是固定的，控制力有限。如果输入图像本身有细粒度的纹理噪点（比如金属表面的拉丝、纸面的纤维），这些噪点在Canny里会被当成边缘响应出来，最终干扰Hough投票。
所以标准的做法是在Canny之前自己先做一次显式降噪。根据图像噪声类型分成几种策略：
- 高斯噪声为主（传感器噪声、压缩伪影）：使用
GaussianBlur，核大小根据噪声尺度决定，一般5×5或7×7。核越大，细节丢失越多，但有得必有失。 - 椒盐噪声（脉冲噪声）：使用
medianBlur，对脉冲噪声的抑制效果最好，核大小一般3×3或5×5。 - 光照不均（偏暗区域细节被吞）：先做直方图均衡化
equalizeHist，再考虑常规滤波。
我实际项目里最常见的是第一种+第三种的组合：白天室外拍摄的车道线图像，阳光直射导致局部过曝，远处又有阴影。我的预处理Pipeline是：
cv::Mat preprocessed; cv::cvtColor(src, preprocessed, cv::COLOR_BGR2GRAY); cv::GaussianBlur(preprocessed, preprocessed, cv::Size(5, 5), 1.5); cv::equalizeHist(preprocessed, preprocessed);有人担心equalizeHist会放大噪声，确实会。所以我的习惯是：高斯模糊放在直方图均衡化之前，让模糊先把噪声压掉一部分，再拉对比度，这样两侧兼顾。如果你用的是彩色图，equalizeHist跑在灰度图上就够，没必要对每个通道都做，否则颜色变化会带来意外的边缘。
4.2 Canny阈值选择与自适应方案
Canny的两个阈值low_threshold和high_threshold，是预处理阶段最关键的两个数字。OpenCV经典建议是高低阈值比取2:1或3:1。低于低阈值的点必被丢弃，高于高阈值的点必被保留，介于两者之间且与强边缘连通的点会被保留。
很多人搞不清楚“滞后阈值”的实际效果，我用一句话解释：图像里真正的轮廓边缘往往强弱连着——一边亮一边暗，强的一侧被高阈值捕获，弱的一侧单独看不够强，但因为它跟强边缘相连，就一起被保留下来了。
固定阈值的问题是：不同图像的对比度差异太大。白天阳光下的车道线对比度极高，晚上灯影下的车道线对比度极低，一套阈值不可能通吃。所以我更推荐自适应方案：
// 用图像梯度幅值的分位数动态设定阈值 cv::Mat dx, dy; cv::Sobel(preprocessed, dx, CV_16S, 1, 0); cv::Sobel(preprocessed, dy, CV_16S, 0, 1); cv::Mat magnitude; cv::magnitude(dx, dy, magnitude); magnitude.convertTo(magnitude, CV_8U); double minVal, maxVal; cv::minMaxLoc(magnitude, &minVal, &maxVal); double high_thresh = minVal + 0.7 * (maxVal - minVal); double low_thresh = high_thresh * 0.5; cv::Canny(preprocessed, edges, low_thresh, high_thresh);这里思想很简单：用Sobel算出的梯度幅值，统计全图最小最大值，然后取最高值的70%作为高阈值，低阈值为高阈值的一半。这套逻辑不需要太多人工干涉，基本能适配大部分场景。当然，如果你检测的图是固定环境、固定光照（比如产线上固定的工位相机），那直接用固定阈值更稳，自适应反而会因为背景杂物而意外波动。
4.3 ROI裁剪往往比算法优化更见效
如果检测区域只在图像的一部分——比如车道线只出现在画面下半部分，文档扫描线只集中在中心区域——最好先做ROI裁剪，再做边缘检测。很多人忽视这个常规操作，总觉得“算法要鲁棒”，实际上ROI裁剪不仅能减少背景杂波的干扰，还能大幅降低计算量，因为参与投票的边缘点数量少了一半以上。
ROI的写法很简单：
cv::Mat roi = preprocessed(cv::Rect(x, y, w, h));裁剪之后，Hough变换得到的线段坐标全部是ROI内的局部坐标。如果后续要在原图上画线，需要记得偏移回全图坐标：
line_point_global_x = line_point_local_x + x_offset; line_point_global_y = line_point_local_y + y_offset;这个偏移漏补是最常见的问题，没有之一。我见过不止一个项目，ROI内的直线检测效果极佳，结果一映射到原图，所有线条都倾斜了一圈，排了半天没找到问题，最后发现是忘了加偏移。
5. LSD算法对比：当我们谈论"另一种直线检测"时在谈什么
5.1 LSD（线段检测器）的算法思路
HoughLinesP之外，OpenCV里还有一条不太被注意的路线：LSD，全称是Line Segment Detector，实现在imgproc模块的LineSegmentDetector类中。它跟Hough变换是完全不同的思路——LSD不是先提取边缘、再投票，而是直接在图像上做梯度方向的一致性分组。
大致过程是：把图像划分成小的像素级区域，计算每个像素的梯度方向，然后把方向一致的相邻像素合并成线段支持区，最后用矩形逼近这些支持区，得到線段端点。换句话说，Hough是在“先找边界再投票”，LSD是在“直接顺着梯度方向拼线段”。
5.2 我测试过的两者差异
我拿了一套既有文档图像又有工业零件图像的数据，做了两边的对比测试。结果差异非常明显：
| 维度 | HoughLinesP | LSD |
|---|---|---|
| 检测完整度 | 长直线更完整 | 短线段更容易捕获 |
| 抗噪能力 | 依赖Canny质量 | 对噪声相对不敏感 |
| 参数数量 | 7个，调节空间大 | 几乎没有参数 |
| 运行速度 | 较快 | 相比Hough略慢，但可接受 |
| OpenCV版本支持 | 所有版本 | 4.x里需要确认实现 |
单独说说LSD的速度。LSD在某些文档图像上检测出的线段数量是HoughLinesP的3~5倍，因为它把每个曲线小段都拆出来了，计算开销也明显更高。如果你的场景是嵌入式设备，或者帧率要求高于30fps，LSD就不是首选。
LSD最大的优点是省心。它没有threshold、minLineLength这些需要反复调试的参数，拿过来就能跑。缺点是线段碎片特别多——同一个直线边缘会被切成一节一节的，这对后续拟合是负担。我通常只在HoughLinesP结果不稳定、又不想花时间调参的时候，把LSD作为“快速基线”来参考，看“理论上图里到底有多少条线”，辅助校准Hough参数。
5.3 两种方案怎么选：我的选型逻辑
如果需求是“测量工件边缘的角度”“找文档四条边”，也就是长直线主导的场景，选HoughLinesP，调参后效果远优于LSD。 如果需求是“提取地图里的街道线”“无参数约束的快速检测”，也就是短线段密布、背景杂波较多的场景，LSD可能更省力，但要接受它的碎片化结果。
还有人在讨论里问过LSD和Hough能不能叠用。我试过，效果并不好——因为两者提取的几何对象重叠度不高，融合结果往往出现重复线，处理不了反而增加复杂度。一般情况下，选一个方案坚持调下去，比两边混着用要高效。
6. 性能优化：当直线检测拖慢了整个流程
6.1 时间都花在哪儿了
很多人抱怨HoughLinesP慢，尤其视频流场景。其实把耗时拆开看，Canny和HoughLinesP的比例大致是1:2到1:3，而且大多数时间都花在投票循环和后处理排序上。有两个方向优化收益最大：
第一个方向是缩小图像。在检测直线之前，把输入图等比缩放到一个合理尺寸。比如原图1920×1080，缩放到960×540，Hough投票的计算量成倍下降，检测结果也不会差太多，因为直线的几何信息主要依赖方向一致性，缩放并不会改变方向。唯一要注意的是，minLineLength和maxLineGap的值也要随之等比缩放，否则语义就不对了。
第二个方向是提前退出。如果你知道最多只需要找几条线（比如找文档的四个边缘，只需要4条），那就在循环里对lines的size判定，一旦达到目标数量就跳出后处理。但HoughLinesP本身没有提前终止选项，它会把整张图全部算完再返回，所以这个优化其实写不写代码差别不大，真正的优化还是得靠降分辨率。
6.2 多线程与图像分块的一个忠告
直线检测天然依赖全局信息——一根横跨画面左右的直线，它的边缘点分散在很远的位置，需要在一个累加器里统一投票。如果你把图像随便切成四块并行检测，边界处的线段会被拦腰截断，即使你拼回来，也会有大量线段头尾残缺。我试过在拼接处做重叠裁边（每块之间重叠50像素），再按坐标合并，效果有一定改善，但代码复杂度上升得很快，处理又慢，性价比太低。
我的建议是：只有当你清楚直线不会跨块出现（比如检测对象本身就固定限制在某个小区域内）时，才做分块并行。否则就老老实实整图处理。OpenCV本身在内部已经对部分环节做了并行化，你用setNumThreads控制一下线程数，通常比手动造轮子更稳。
6.3 视频流的复用策略
如果做视频帧连续检测，别对每一帧都从头跑一遍完整流程。场景没大变时，上一帧检测出的线段位置可以作为当前帧的预测先验——先在最邻近区域做一遍小范围精确搜索，能省掉大量全局计算。这在车道线追踪、传送带上工件位置跟踪里特别有用。
最简单的一个实现：在上一帧线段端点周围画一个小ROI，下一帧只在这个ROI里做边缘检测和HoughLinesP。因为视频帧间物体位移通常不大，这个小搜索区域能覆盖90%以上的变化。我见过一些项目就是用这个思路，把每帧处理时间从15ms压到了6ms以下，效果很明显。
7. 项目实战复盘：一个测量平台的直线检测过程
7.1 项目需求与初版方案
去年我参与过一个模拟项目X，需求是测量某种透明工件上两条平行刻线的间距，精度要求0.1mm。透明工件在普通光照下几乎看不到刻线，所以一开始直接检测直线根本不行。我临时用背光源把刻线打亮成黑色线条，再进行检测。
初版方案是：灰度图 -> GaussianBlur -> Canny -> HoughLinesP -> 拟合。这版的问题，用脚趾头想都知道——“阈值波动”：同一工件换一个光照位置，检测到的线间距就波动十几个像素，完全没法满足0.1mm的精度。
7.2 排查弯路与最终方案
排查过程花了挺久。我先把Canny输出打印成图像，肉眼确认边缘是否连续。发现边缘本身是连续的，问题出在Hough参数上——threshold设置偏低时，会把一些很短的杂边当成直线；设置偏高时，真正的刻线又被截断。这导致线段的端点在反复横跳，间距自然不稳定。
最后方案是：预处理改成直方图均衡化增强刻线与背景的对比度，ROI裁剪到刻线所在区域，剔除其他杂波；Hough的minLineLength设成一条刻线物理长度对应的像素值，threshold按上面说过的自适应方法设定。改完后，同一工件反复装卡测量，间距标准差从1.2像素降到了0.3像素。再经过相机标定换算到毫米，精度稳定在0.08mm，勉强达标。
7.3 这次实测给直线检测带来的启示
复盘下来，核心教训有两条：
- 直线检测的精度上限，是由边缘质量决定的，不是由Hough参数决定的。你说阈值调到120、150，线还是飘，大概率是边缘本身虚化或者断裂了，先去解决预处理。
- 参数稳定比单纯“效果好看”重要得多。在工业测量场景里，我更看重“同一种工件不同次测量结果的一致性”，而不是“某张图标出来的线像不像直线”。
这也是为什么我在前面反复强调预处理和ROI裁剪——它们对性能稳定性的贡献，远远超过调一个threshold的收益。
8. 再往深处走一步：线段合并与角度分组的后续处理
HoughLinesP直接返回的结果是线段碎片，尤其是面对有阴影、有遮挡或曲率较大的边缘时，一条物理直线可能被拆成多条线段。所以工程上“检测出线段”只算完成了一半，真正的后半场是线段合并与几何细化。
8.1 基于角度与距离的聚类合并
我常用的合并策略分两步：
第一步，按角度分组。遍历所有线段，计算每条线段的方向角（atan2(y2-y1, x2-x1)），把方向角度差在允许误差（比如5度）之内、且空间距离在允许范围之内的线段分到同一组。
第二步，组内合并。同组线段按长度排序，长的当骨架，短的如果投影到骨架上的位置与骨架有重叠，就按权重合并成一条新线段。新线段的端点为所有参与线段端点的凸包或极值。
这步写起来就是几组点在直线上的投影计算，不算难。关键在于角度容差和距离容差的设置，还是那个原则：不要为了合并强行把相差很远的线段拉到一起。
8.2 从“多条线段”到“一条主直线”：最小二乘拟合
如果你需要的不是多个线段，而是“画面里那条最主要的直线”——比如工件的c角、螺纹的母线——就需要最小二乘拟合。
OpenCV里有一个fitLine函数，支持2D和3D点集的直线拟合，返回直线的方向向量和直线上的某一点。用法非常直接：
std::vector<cv::Point2f> points; for (const auto& ln : lines) { points.emplace_back(ln[0], ln[1]); points.emplace_back(ln[2], ln[3]); } cv::Vec4f line; cv::fitLine(points, line, cv::DIST_L2, 0, 0.01, 0.01); // line[0], line[1] 是方向向量；line[2], line[3] 是直线上一点fitLine的第二个参数是距离类型，默认用DIST_L2就是最小二乘；如果你觉得一些离群点干扰太大，可以换成DIST_HUBER或DIST_FAIR，它们在拟合时对远距离点的权重会降低，抗噪效果好不少。
还有一个实用细节：如果所有边缘点都落在一条直线上，直线方向向量长度会被归一化到1。如果要算直线角度，直接atan2(line[1], line[0])，再换算成角度制就行。
8.3 用形态学操作清理边缘断裂
有时候边缘断裂严重，线段碎片密集成一堆，合并代码写得再漂亮也无从下手。这时可以在Canny输出上做形态学处理，把缝隙“弥合”起来。
常用的操作是膨胀+闭运算：先膨胀一次，把断开的边缘点连起来，再做一次闭运算（膨胀+腐蚀），消除小孔洞和碎片之间的间隙。
cv::Mat kernel = cv::getStructuringElement(cv::MORPH_RECT, cv::Size(3, 3)); cv::morphologyEx(edges, edges, cv::MORPH_CLOSE, kernel);形态学处理会改变边缘的细节，宽度也会变大。如果后续需要精确测量宽度，这一步要慎用；如果只是为了连线段的断头，那它非常有效。
9. 写在最后的工程经验
把C++和OpenCV的直线检测真正用明白，花的功夫大概七成在图像预处理和参数调试上，代码本身是最简单的部分。我自己摸索的过程走了不少弯路，有几条经验值得分享给后来者：
第一，永远先把边缘图可视化出来再动手调Hough参数。你看不到Canny输出什么样，就不知道断线是预处理造成的还是threshold造成的，折腾半天等于盲调。
第二，建立自己的实验图像集。单一图像调参没意义，至少收集10-20张覆盖不同光照、不同角度的样本，每改一个参数，全部跑一遍，观察结果分布。能帮你规避“这张图行，换个场景就废”的陷阱。
第三，性能优化的优先级应当是：ROI裁剪 -> 降分辨率 -> 换算法 -> 多线程。前三步每步都可能带来成倍的性能提升，但代码改动量极小。多线程排最后不是因为不好，而是因为牵扯到数据竞争和合并逻辑，调试成本最高。
直线检测看着简单，真正决定一个项目成败的往往是那些不起眼的预处理细节和参数选择。希望这篇文章能帮你少踩一些我踩过的坑，把时间花在更有价值的地方。
