很多人第一次选激光雷达，习惯性地先看线数，觉得线数越高越好，堆上去总没错。真正在项目里踩过坑的人都知道这是个陷阱：给一台在平整车间里跑固定路线的 AGV 装上32线固态雷达，成本翻了三倍，算力平台跟着升级，结果现场跑了一个月发现，真正用得上的还是那几十个扫描平面上的点。反过来，用单线雷达去做无人叉车的托盘识别，你会发现雷达"看不见"托盘——因为它只扫一个高度切面，托盘腿之间那块空隙对它来说就是不存在。多线与单线的选择，本质上不是性能高低的取舍，而是你的任务到底需要"一个切片"还是需要"一整片点云"的问题。这篇内容就把这两类固态激光雷达的差异、选型判据和实测里容易翻车的地方一次说清楚，适合正在做机器人、无人车、工业检测、安防监测这类项目的工程师和产品同学参考。
1. 单线固态雷达和多线固态雷达，数据形态到底差在哪
1.1 单线输出的是一条"闭合圆环"，不是图像
单线固态激光雷达的工作方式，是在一个固定俯仰角上，通过 MEMS 微振镜或者反射棱镜把激光束水平扫过一个扇面（常见 270° 或者 360°），每扫一个角度就测一次距离。最终你拿到的是极坐标形式的一串点：角度 + 距离 + 反射强度。把这些点画出来，就是地面或者说某个高度平面上的一条闭合曲线。
这条曲线的信息密度其实不低。它天然包含了两件对导航极其有用的事：第一，这个高度上有没有障碍物；第二，障碍物离我多远、在哪个方位。对一台沿固定轨道运行的设备来说，这就够了。它的数据量也小得可爱——一圈 720 到 2000 个点，10Hz 帧率，串口或者以太网就能轻松吞吐，主控用一颗中低端 MCU 甚至都能处理。
但它有个绕不开的短板：垂直方向的信息完全缺失。悬空的横梁、低于扫描平面的台阶、倾斜的坡面、挂在半空的线缆，只要不在那一个俯仰角上，它一律当你看不见。我见过最典型的翻车案例是一台在仓库里做巡检的设备，路径上有一个 15 厘米高的门槛，雷达装在离地 20 厘米的高度，扫描平面直接从门槛上方扫过去，设备一头撞上去。你没法怪雷达，它确实诚实地告诉了你"20 厘米高度这一圈是干净的"。
1.2 多线的"线数"是个被严重误读的参数
多线固态雷达，是把多个发射/接收通道在垂直方向上按一定角度排布，或者用二维 MEMS 振镜在垂直方向也做扫描，从而在垂直 FOV 内形成十几到上百条扫描线。16线、32线、64线这些数字，说的就是垂直方向上有多少个独立的扫描平面。
但线数本身不等于"看得清"。真正决定你能不能分辨目标的，是垂直角分辨率，也就是相邻两条线之间的夹角。它约等于垂直视场角除以（线数 − 1）。举个具体的：一台 32 线雷达，垂直 FOV 是 40°，那么垂直角分辨率大约是 40 ÷ 31 ≈ 1.29°。在 30 米外，相邻两条扫描线打在地面上的间距是 30 × tan(1.29°) ≈ 0.68 米。这意味着，一个 0.5 米高的物体站在 30 米外，很可能正好卡在两条扫描线中间，被完整地"穿过"。
所以你在选型时如果只盯着线数，很容易被带偏。同样是 32 线，垂直 FOV 40° 和垂直 FOV 15° 是两种完全不同用途的产品：前者强调大视场覆盖，适合近距离建图和盲区补盲，但角分辨率被摊薄；后者把 32 条线挤在 15° 里，角分辨率能到 0.48°，30 米外的线间距降到 0.25 米，远处小目标的检出率会好一大截，代价是近处头顶和脚下的盲区变大。这两个参数是互相拉扯的，没有免费午餐。
1.3 固态架构决定了两者在物理上怎么实现
叫"固态"是因为里面没有传统机械式雷达那种匀速旋转的电机和滑环。目前主流实现路径有三条，每条对单线/多线的适配度不一样。
第一条是MEMS 微振镜。用一颗毫米级的硅基振镜做一维或二维偏转，激光器固定不动。做单线时通常用一维振镜，只做水平扫描；做多线时用二维振镜，或者在垂直方向堆叠多个激光器配合一维扫描。这是目前量产最成熟、性价比最好的一类，缺点是振镜的机械谐振频率有限，长期可靠性对封装工艺要求高。
第二条是Flash 面阵式。没有扫描动作，一次脉冲把整个视场的激光全部发出去，接收端用 SPAD 阵列一次性成像。它的物理形态天然就是"面阵"的，输出的是低分辨率的三维点阵，所以严格来说 Flash 不属于单线范畴，但它的点云密度往往比同价位多线扫描式稀疏得多，通常只适合 10 到 30 米内的近距离避障。好处是完全没有运动部件，抗振动能力极强，体积可以做得非常小。
第三条是OPA 光学相控阵。通过调节多个发射单元的相位，让激光束在空间中偏转。理论上它是最理想的形态——无机械运动、扫描速度快、可以任意编程扫描图案。但工程上卡在旁瓣抑制、相位校准和量产良率上，市面上能买到的成熟产品很少，选型时如果供应商主推 OPA，务必把样机拿到你的真实环境里跑够时长再决定。
理解这三条路径的意义在于：当你看到两个产品都是"32 线"，一个是 MEMS 扫描、一个是 Flash 面阵，它们的点云分布规律、远端表现、抗环境光能力完全不同，不能拿同一个参数表直接对比。
2. 选型前必须先算清楚的三笔账
2.1 视场角与盲区：垂直 FOV 决定你能不能看到地面
垂直视场角这个参数，很多人扫一眼就过，但它直接决定了雷达装上去以后"脚下"和"头顶"能看多近。假设雷达水平安装、离地高度 h，垂直下半 FOV 是 θ，那么雷达在正下方能扫到地面的最近距离是 h ÷ tan(θ)。
拿一个具体的算：雷达装在 0.6 米高，垂直下视场 25°，那么最近能扫到地面的距离是 0.6 ÷ tan(25°) ≈ 1.29 米。也就是说，离车 1.3 米以内的地面区域，这台雷达是盲的。对一台高速行驶的设备来说，这 1.3 米可能就是刹车距离。解决办法无非三种：把雷达俯仰角往下压一点（牺牲远处）、降低安装高度（可能被泥水糊住）、或者加一个短距补盲雷达（Flash 或者超声波）。
多线雷达在这里的优势就体现出来了：它不是一条线，而是一个面。即便有盲区，盲区边缘也会有连续的扫描线落在地面上，你能看到地面轮廓慢慢展开，而不是突然出现。这个差异在颠簸路面上尤其明显——单线雷达遇到车体俯仰，扫描平面会上下漂移，一会儿扫地面一会儿扫空中，数据跳变很厉害；多线雷达有冗余，姿态变化时只是有一部分线扫到地面，整体仍然可用。
2.2 点频换算：你的数据链路到底吃不吃得消
点频这个指标，标称值往往是理论最大值。它的算法是：点频 = 线数 × 每线采样点数 × 帧率。一台 32 线雷达，每线每帧 1500 个点，帧率 10Hz，那么就是 32 × 1500 × 10 = 480k 点/秒。
这个数字直接决定你的数据带宽。每个点如果存 XYZ 坐标加反射强度，用 float32 是 16 字节，用 int16 压缩存储是 8 字节。480k 点 × 8 字节 = 3.84 MB/s，也就是约 30 Mbps 的持续带宽。看起来不高，但别忘了这是持续稳定的数据流，而且你还要同时跑相机、IMU、GPS。
更现实的约束是算力。单线雷达的点云，一个欧氏聚类加个阈值过滤，在 Cortex-A53 上都能实时跑完。32 线以上的点云，如果要做地面分割、聚类、目标跟踪，基本要上到一个像样的多核 ARM 或者配一个轻量 GPU。我见过团队在雷达上省了三千块，结果算力平台多花了两万，还拖长了半年开发周期。
这里有个容易被忽略的细节：有效点云率。标称 480k 点/秒，但里面有相当一部分点是打在雨滴、扬尘、光窗污渍上产生的噪点，还有一部分是超出有效测距范围被丢弃的空点。实际可用的点可能只有标称的 60% 到 80%。做带宽和算力预算时，用一个 1.3 倍的安全系数比较稳妥。
2.3 测距标称值的三个隐藏前提
几乎每个雷达规格书都会写"最远探测距离 XX 米"，但后面通常跟着一串小字。这几个前提条件如果不看清楚，选型必然翻车。
第一是目标反射率。行业里常见两种标定基准：90% 反射率（相当于白墙）和 10% 反射率（深灰、黑色物体）。同一个雷达，标称 150 米 @90% 反射率的，在 10% 反射率的物体上往往只有 50 到 60 米。如果你的应用场景里有大量深色物体——黑色托盘、深色衣物的人、沥青路面——一定要按 10% 反射率那一栏的数据来选。
第二是环境光强度。常见标称条件写的是 100klux，大致对应晴天正午的直射阳光。如果你的设备是室内用，这条可以放宽；但如果是室外，必须确认在强阳光下测距衰减了多少。有些雷达在室内表现很好，一推到室外，有效距离直接腰斩，因为接收端被环境光淹没了。
第三是探测概率。是 90% 还是 95% 的探测概率下测得的距离？在自动驾驶这类场景里，通常要求 95% 以上，意味着更保守的有效距离。
把这三条对齐之后，再去看那串数字，你会发现候选清单会缩短很多。
| 标称条件 | 常见数值 | 对实际选型的影响 |
|---|---|---|
| 目标反射率 | 90% / 10% | 深色目标场景按 10% 那一列选，差距可达 2 到 3 倍 |
| 环境光 | 100klux / 室内 | 室外项目必须确认强光下的有效距离衰减 |
| 探测概率 | 90% / 95% | 高可靠场景按 95% 取值，距离再打一次折扣 |
| 探测精度 | ±2cm / ±5cm | 影响标定与融合精度，也影响近距离避障阈值设置 |
3. 场景对号入座：单线能干的活和多线的刚需区
3.1 单线的舒适区：约束明确、只看一个平面的任务
有一类任务，它的物理约束非常明确，单线雷达几乎是最优解。
轨道交通和厂内轨道设备的防撞：设备沿着固定轨道走，需要判断前方轨道上有没有障碍物。扫描平面就设在轨道上方 10 到 20 厘米处，任何高度超过这个阈值的物体都会被检出。这类场景的障碍物几乎全是"实体挡路"，不存在悬空或者台阶问题，单线足够，而且可靠性极高，因为没有多余数据需要处理，误报率能做得很低。
周界入侵和区域监测：把单线雷达装在地面或者立柱上，设定一个扇形警戒区，任何进入区域的物体都会破坏这条扫描线。它的优势在于不受光线影响，夜间、逆光、雨雾（一定范围内）都能工作，比摄像头稳定得多。这类应用的典型配置是 270° 或者 360° 扫描，把有效区域裁成一个梯形，边界之外的读数直接忽略。
料位、堆体轮廓测量：这个稍微特殊一点。雷达固定在某个位置，只扫一个方向，靠物料表面的回波距离判断料位高度。或者装在一个旋转机构上做二维扫描，配合运动重建出堆体的三维轮廓。这时候用多线雷达反而是浪费，因为你要的精度是单点距离精度，而不是三维点云。
AGV 和 AMR 的沿边导航：这是单线雷达最经典的战场。用雷达扫出周围环境的 2D 轮廓，和预先建好的地图做匹配定位，同时用前方扇区做避障。整套算法（比如基于 2D 栅格地图的定位与导航）非常成熟，计算量小，是很多工业移动机器人的标配方案。
3.2 多线的刚需区：需要理解地形、高度和三维语义
一旦你的任务里出现了"高度"这个变量，单线基本就出局了。
无人叉车的托盘识别与插取：托盘有腿、有面、有孔，你需要知道腿在哪、插孔的高度是多少、托盘朝向是什么。这是典型的三维几何问题，只有多线雷达（或者加上视觉）能解。而且叉车的工作距离通常在 2 到 8 米，恰好是 16 到 32 线雷达的最佳工作区间，不需要太远的探测距离，但对点云密度要求高。
室外无人配送车和低速无人车：室外路况的复杂度在于地面不是平的。有路缘石、有斜坡、有井盖凹陷、有减速带。单线雷达扫到一个路缘石，只能告诉你前方有个障碍物，但分不清这是 5 厘米高的路缘（可以过）还是 25 厘米高的台阶（不能过）。多线雷达能通过点云的高度分布做地面分割，把"可通行地面"和"障碍物"分开，这是室外导航的基础能力。
测绘与地形建模：这类应用对点的绝对精度和一致性要求极高，通常会用 32 线甚至更高，配合高精度 GNSS 和 IMU 做轨迹解算，最后拼接出完整点云。这里的关键是雷达的时间同步和运动补偿能力，不是线数越高越有用——如果时间戳抖动大，线数再高拼出来的点云也是糊的。
机械臂抓取和三维重建：小视场、高点密度的多线雷达配合机械臂做无序抓取，这里对近距离的角分辨率要求很高，通常会用垂直 FOV 较小但线数密集的型号。
3.3 中间地带：4线和8线的定位
4线和 8线这类轻量多线产品，是最近两年增长很快的一个品类。它们的定位很微妙：比单线多了垂直方向的几十度覆盖，能感知坡度、能识别低矮障碍；比 16/32 线便宜不少，点云也稀疏得多，算力需求处在中间。
适合它们的场景大概有三类。一是室内服务机器人在复杂地面环境下的避障，比如有地毯、有门槛、有桌腿的办公场景，8 线足以看出桌腿和地面的差别。二是清洁和巡检设备的贴边作业，需要同时感知侧面墙体和地面边缘。三是低成本的室外园区车，如果车速很低（比如 3 到 5 km/h），8 线的点云密度配合合适的算法勉强够用，但要接受更高的漏检率。
关键判断标准是：你能不能接受"看得见但不精确"。轻量多线给你的信息是"这里大概有个东西，大概这么高"，而不是精确的几何形状。如果你的下游算法对几何精度要求高，还不如直接上 16 线。
4. 参数表之外的坑：实测里真正拖后腿的几件事
4.1 强光与反射率：标称 100 米，实测 30 米
这是最普遍的一类翻车。问题出在测试方法和实际场景的错位。实验室里测试用的是白色标定板，室内光线，正对目标，静止测量。实际场景里是深色物体、强阳光、倾斜角度、目标还在动。
我建议在样机验证阶段做一个"最坏情况测试"：在室外正午，找一块深灰色（接近 10% 反射率）的板子，放在你最关心的最远工作距离上，看雷达能不能稳定输出有效点。如果这时候能稳定检出，那这个距离就是你的安全距离。做这个测试的时候还要注意角度——激光打在倾斜的深色表面上，回波强度会再掉一个数量级，很多雷达在这种情况下会直接丢点。
还有一个容易被忽略的因素：雨雾和扬尘。空气中悬浮的颗粒会产生大量近距离的假回波，在点云里表现为围绕雷达的一圈"雾噪"。解决办法通常是做强度阈值过滤加距离窗口过滤，但如果噪点太密，会把真实目标也一起滤掉。选购时可以问供应商要一份雨雾环境下的实测数据，或者自己用加湿器在密闭空间里造个简单环境测一下。
4.2 多台同型号雷达互扰：这个坑几乎人人都会踩
当同一个场地里装了两台以上参数相同的雷达，尤其是扫描频率接近的时候，A 雷达的激光会打到 B 的接收端，B 就会读到一个虚假的近距离点。表现为点云里随机出现一圈或多圈跳动的噪点，位置不固定，像幽灵一样。
这个问题在单台测试时完全发现不了，往往要等到现场部署两台以上才暴露。典型的解决思路有这么几种：
- 物理错位：让两台雷达的安装高度或者俯仰角错开，减少接收端直接对视的概率，加装遮光罩把发射和接收视场卡窄。
- 相位/频率错开：部分产品支持配置不同的扫描相位或者轻微的工作频率偏移，错开之后互扰概率大幅降低。选型时值得专门问一句这个功能有没有。
- 时序分时：让多台雷达分时工作，但会牺牲帧率，一般只在雷达数量不多时可行。
- 算法过滤：利用互扰噪点通常表现为孤立、强度异常、帧间不相关的特点做滤除。但这属于事后补救，效果不如前三种。
我的经验是：在方案设计阶段就把雷达数量、安装位置、型号组合画出来，评估对视关系。如果两台雷达必须在同一高度对视安装，那就选不同型号或者支持相位错开的产品。
4.3 光窗污染和安装角度带来的隐形盲区
光窗上的污渍、水渍、泥点，会被雷达当成一个近距离障碍物。在 AGV 场景里，这会导致设备莫名其妙地急停，而且清理完以后又能跑，非常难排查。工程上要做两件事：一是在点云处理里加一个"近距离固定区域过滤"，把离雷达 5 到 10 厘米以内的回波直接丢弃；二是在结构设计上给光窗加一个向下的倾角或者加个简单的气帘，减少积灰积水。
安装角度同样有讲究。如果雷达向下倾斜安装去补脚下盲区，会带来一个副作用：近处地面的反射光更容易进入接收端，导致近处出现一片饱和噪点。这时候需要在软件里设置一个最小工作距离，把这段异常区域屏蔽掉。有些产品的近处盲区就是被这个物理效应限制的，不是算法能做掉的。
还有一个隐蔽问题：透明和反光物体的检出。玻璃、镜面、深色高光表面，激光打上去要么直接穿透，要么被反射到别的方向，回波极弱。这在实验室里很难复现，但在实际仓库和商场场景里到处都是。如果目标里有玻璃门、不锈钢货架，一定要现场实测，不能只看规格书。
4.4 时间同步与数据链路：多传感器融合的隐性成本
一旦你从单雷达升级到多雷达加 IMU 加相机，时间同步就变成一个必须解决的问题。雷达的时间戳如果和 IMU 对不齐，运动补偿就会出错：车在动的时候，雷达扫描一圈需要 100 毫秒，这 100 毫秒里车可能移动了几十厘米，如果不做补偿，扫出来的点云是扭曲的。
常见的同步方案是用 PPS 秒脉冲加 PTP 精确时间协议，把各传感器的时间戳统一到同一个时钟源。选型时要确认雷达是否支持硬件时间戳，以及是否支持外部触发输入。有些便宜的产品只给你一个软件打的时间戳，精度在毫秒级，做静态测绘勉强够用，做动态融合就不行了。
链路方面，以太网是主流，但要注意雷达的 UDP 包是"尽力而为"的，网络拥塞时会丢包。点云丢包在视觉上表现为某一帧局部点缺失，算法上可能触发误判。如果雷达支持 PTP 和流量控制，尽量用上；如果不支持，就把它和相机分开到不同的网口，别塞在一个交换机上互相抢带宽。
5. 落地选型清单：怎么把上面这些收敛成一个决定
5.1 按任务维度逐条打分
与其在参数表里来回比较，不如把自己的需求拆成几条硬性判据，逐条筛。
第一条，是否需要高度信息。这是分水岭。如果任务里没有任何涉及高度的判断，闭着眼睛选单线；只要有台阶、坡度、悬空物体、需要区分可通行地面和障碍物中的任何一条，直接进多线。
第二条，最小可接受的目标尺寸和最远工作距离。把这两个数字代进角分辨率公式，算出需要多少线。举个例子，目标最小 0.3 米，最远 20 米，允许相邻线间距小于 0.3 米，那么角分辨率至少要小于 atan(0.3/20) ≈ 0.86°。如果垂直 FOV 是 30°，那么线数至少要 30 ÷ 0.86 + 1 ≈ 36 线，向下取整到 32 线就有点勉强，考虑到有效点云率和检测概率，实际应该选 40 线以上或者缩短工作距离。
第三条，环境苛刻程度。室外强光、雨雾扬尘、振动冲击、高低温，每一项都会削掉一部分有效性能。环境越差，越要把标称距离打更大的折扣，也越要关注产品的防护等级和车规验证情况。
第四条，算力和带宽预算。这个不用算太细，粗估一下就行：单线按 0.1 MB/s，16 线按 1.5 MB/s，32 线按 3 MB/s，64 线按 6 MB/s 的量级去预留。如果主控平台已经定了，这条就是硬约束，反向决定你能选多少线。
| 判据 | 偏向单线 | 偏向多线 |
|---|---|---|
| 是否需要高度/地形信息 | 不需要，只判断有无障碍 | 需要地面分割、坡度或悬空检测 |
| 目标最小尺寸与距离 | 目标大、距离近，切片即可覆盖 | 目标小或距离远，需角分辨率支撑 |
| 使用环境 | 室内、光照可控、地面平整 | 室外、强光雨雾、路面颠簸 |
| 算力与带宽 | 主控资源有限，追求低功耗 | 有独立算力平台，可承受点云处理 |
| 成本敏感度 | 单机成本敏感，追求批量一致性 | 可接受较高的单台成本 |
5.2 轻量与重量的权衡：成本不只是采购价
做选型预算时，很多人只算了雷达的采购成本，忽略了后面跟着的一串。多线雷达带来的连锁成本至少有四项：算力平台升级、数据链路的带宽和线缆要求、结构件的散热和减震设计、以及开发和调试的人力。后两项最容易被低估。
散热这块值得单独说。多线雷达的功耗通常是单线的 2 到 4 倍，如果设备是密封结构，热量散不出去，会导致内部温度升高，影响振镜和激光器的长期稳定性。我见过一个项目因为雷达和计算单元装在一个密闭腔体里，夏天室外连续工作两小时后雷达开始间歇性丢帧，最后不得不重新设计风道。这类问题在设计早期改成本很低，到后期就是返工。
减震同理。MEMS 振镜虽然比机械旋转式抗振好很多，但依然有自己的谐振点。如果设备要跑在颠簸路面上，雷达的安装支架最好带减震垫，并且避开整机的共振频率段。做样机时用加速度计测一下安装点的振动频谱，和雷达供应商确认一下耐受范围，这十几分钟的活能省掉后面很多麻烦。
5.3 小批量样机验证怎么做才有效
参数表看完了，方案也定了，最后一步是把样机放到真实场景里跑。这一步做扎实，能挡掉九成的返工。
验证清单我一般按这个顺序做：先在室内静态测一遍基础功能，确认数据格式、坐标定义、时间戳都对得上；然后做最坏情况测试，也就是 4.1 节里说的深色目标加最远距离加最差角度；接着做多台互扰测试，把计划部署的所有雷达同时开起来，看在真实位置关系下有没有干扰噪点；再往后是长时间烤机，至少连续跑 48 小时，观察有没有丢帧、温漂、点云偏移；最后才装到设备上做实际场景跑测。
跑测阶段最值得记录的数据是误报率和漏报率，而不是"能不能跑通"。跑通是基本要求，误报和漏报才是决定这个方案能不能量产的关键。建议在跑测时同步录一段视频做真值参考，事后逐帧回看，把每一个误报和漏报的场景都截图存档，分析是雷达特性导致的还是算法没调好。这份记录在后续换型号或者调参数时，价值极大。
最后分享一个我个人踩过几次坑之后形成的习惯：永远准备一个降级方案。多线雷达的方案在设计时，就想好如果成本压不下来、或者某个场景始终调不好，能不能退回到"单线加视觉"或者"多台单线不同高度安装"的组合。很多时候，两台不同俯仰角的单线雷达，在特定场景下的性价比比一台 16 线更高，而且冗余度更好——坏一台还有一台能保证安全停车。选型这件事，最优解往往不是参数最高的那个，而是和你团队的开发能力、维护能力、成本结构最匹配的那个。
