作为一个常年跟激光SLAM算法打交道的人，我深知LIO-SAM这套代码的含金量。它是Tixiao Shan在LEGO-LOAM基础上迭代出来的作品，核心思路是把激光雷达、IMU和GPS（可选）通过因子图做紧耦合，在实时性和精度之间取得了很好的平衡，而且代码量不大，非常适合拿来学习多传感器融合的工程实现。不过很多人在Ubuntu 20.04 + ROS Noetic环境下编译LIO-SAM时，会踩到不少坑，尤其是GTSAM版本、PCL/OpenCV版本冲突这类问题，网上资料虽然多，但真正能一次性跑通的教程却不多。这篇文章我就把LIO-SAM在Noetic下从零编译到跑通demo数据集的完整过程梳理一遍，把我踩过的坑和验证过的方案都写清楚，给需要的人省点时间。
先说结论：LIO-SAM在Ubuntu 20.04 + Noetic下是完全可以编译通过的，核心难点不在代码本身，而在依赖库版本的选择上。只要把GTSAM、PCL、OpenCV这几个关键依赖的版本和编译顺序处理好，整个编译过程其实很顺。
1. 编译前的全局思路与方案选型
1.1 为什么推荐用Ubuntu 20.04 + Noetic来跑LIO-SAM
虽然LIO-SAM的作者最初是在Ubuntu 18.04 + Melodic环境下开发测试的，但如今Ubuntu 20.04 + Noetic已经成为ROS生态的主流组合，特别是Noetic是最后一个完全基于Python 2官方支持的ROS版本？说反了，恰恰Noetic是第一个默认使用Python 3的ROS发行版，这意味着大量新工具链和新算法库都在这个版本上做了适配，生态更健康，后续做扩展开发也方便。
但问题也随之而来：Noetic自带的PCL 1.10、OpenCV 4.2以及Eigen 3.3.7等库，和LIO-SAM在18.04环境下依赖的旧版本库有细微差异。这会导致编译过程中出现各种类型不匹配、函数签名改变、头文件路径缺失等报错。所以编译前搞清楚各依赖库的版本对应关系，比盲目改代码重要得多。
我整理了一张常见的环境组合对比表，可以直观看到差异：
| 依赖项 | Ubuntu 18.04 + Melodic 默认 | Ubuntu 20.04 + Noetic 默认 | 说明 |
|---|---|---|---|
| PCL | 1.8.1 | 1.10.0 | 头文件路径有变化，部分API弃用 |
| OpenCV | 3.2.0 | 4.2.0 | 部分旧API需要兼容处理 |
| Eigen | 3.3.4 | 3.3.7 | 差异不大，基本兼容 |
| gtsam | 需要自行编译 | 需要自行编译 | LIO-SAM核心后端优化库 |
| ROS底层 | Melodic | Noetic | 消息接口基本一致 |
实际编译时，PCL和OpenCV的API变化是主要的坑点，后面我会专门讲。
1.2 编译策略的确定：先攻依赖，再战源码
LIO-SAM编译失败的案例里，绝大多数不是因为LIO-SAM源码本身有问题，而是GTSAM没有编译好，或者GTSAM与PCL的冲突没有处理好。GTSAM是Georgia Tech开发的因子图优化库，LIO-SAM用它来实现位姿图优化，是后端的关键依赖。因此，整个编译路线应当按照"系统依赖 → ROS基础包 → 算法依赖库 → LIO-SAM功能包"的顺序分层推进。
这个顺序是有讲究的：先确保系统的包管理器装好基础库，再用源码方式编译GTSAM，最后才编译LIO-SAM本体。如果反过来，先编译LIO-SAM再处理GTSAM，你会陷入"报错→改代码→又报错→重新编译"的循环里，非常浪费时间。
2. 依赖环境搭建与核心库编译实操
2.1 系统与ROS基础环境的准备
首先，你需要一台装了Ubuntu 20.04的机器。如果是双系统或者虚拟机，需要注意分配足够的磁盘和内存，我建议至少分配4核CPU和8GB内存，否则编译C++工程时会比较吃力，特别是在编译GTSAM这种模板库时，内存不够很容易被系统OOM杀死。
然后是ROS Noetic的安装，这里我默认你已经完成了ROS Noetic的安装和rosdep的初始化。如果没有安装，请参考ROS官方Wiki的安装步骤，先安装Desktop-Full版本，因为Desktop-Full自带RVIZ、TF树可视化工具和常用消息包，后面跑demo数据包时都会用到。需要注意的一点是：Noetic推荐使用Python 3环境，如果之前切换过Python版本，要注意保证ROS工具链能正常运行，可以用roscore快速验证一下。
rosdep初始化记得要做好，因为后续编译过程中，catkin会通过rosdep检查功能包的依赖是否齐全。如果rosdep没有update成功，编译时会出现"Unable to resolve dependencies"的提示。
2.2 核心依赖库的安装与版本匹配
在开始编译LIO-SAM前，要把这些系统依赖库装齐：
sudo apt-get install -y \ ros-noetic-pcl-ros \ ros-noetic-velodyne-msgs \ ros-noetic-rviz \ ros-noetic-tf2-geometry-msgs \ ros-noetic-cv-bridge \ libeigen3-dev \ libopencv-dev \ libpcl-dev \ libyaml-cpp-dev \ libgflags-dev \ libgoogle-glog-dev \ libtbb-dev这里重点说说PCL和OpenCV。Noetic自带的libpcl-dev版本是1.10。LIO-SAM源码里，imageProjection.cpp和featureExtraction.cpp等文件大量使用了PCL的点云类型和滤波功能，这些在1.10版本下基本都能编译通过，但有一个需要注意的地方：pcl_conversions的头文件路径和消息转换接口在ROS版本间有调整，必须保证编译时能找到pcl_conversions/header.h，否则会出现找不到头文件的错误。
OpenCV则需要注意cv_bridge的版本匹配问题。Noetic自带的cv_bridge默认针对OpenCV 4.x编译，LIO-SAM中visual_feature.cpp（如果启用视觉特征）可能会使用OpenCV的特征提取接口，这些接口在OpenCV 4.2中统一到了opencv2/features2d.hpp中，不再推荐使用旧的opencv2/xfeatures2d/nonfree.hpp。所以只安装libopencv-dev即可，不需要额外安装OpenCV 3的兼容包。
安装完基础依赖后，用下面命令验证关键版本的匹配情况：
pcl-config --version pkg-config --modversion opencv4 pkg-config --modversion eigen3正常输出的版本号应该分别是1.10.0、4.2.0和3.3.7。
2.3 GTSAM源码编译：整个流程中最关键的环节
GTSAM的编译是LIO-SAM编译成功与否的分水岭。LIO-SAM官方推荐的GTSAM版本是4.0.2。这个版本经过了LIO-SAM作者的验证，稳定性最好。网上有人说4.0.3也能用，确实能编译通过，但有个坑是4.0.3在部分Ubuntu 20.04版本的Boost库下会出现模板实例化的问题，虽然概率不高，但一旦遇到，排查起来非常痛苦。我的建议是：不要冒这个险，直接从GitHub拉取4.0.2的tag。
具体编译步骤如下：
cd ~ git clone --branch 4.0.2 https://github.com/borglab/gtsam.git cd gtsam mkdir build && cd build cmake -DGTSAM_BUILD_WITH_MARCH_NATIVE=OFF -DGTSAM_USE_SYSTEM_EIGEN=ON -DGTSAM_BUILD_TESTS=OFF -DGTSAM_BUILD_UNSTABLE=ON .. make -j$(nproc) sudo make install这里有几个关键参数我要特别说明：
GTSAM_BUILD_WITH_MARCH_NATIVE=OFF：这个参数非常关键。如果设置为ON，GTSAM在编译时会根据当前CPU的指令集做针对性优化，这意味着编译生成的二进制文件只能在你当前这台机器上运行。如果你后续要把编译好的代码拷贝到其他机器，或者与其他库混用，就会出现非法指令（illegal instruction）的错误。在编译LIO-SAM所依赖的算法库时，我统一建议关掉这个选项，提升可移植性。GTSAM_USE_SYSTEM_EIGEN=ON：让GTSAM使用系统已安装的Eigen，而不是自己捆绑的Eigen版本。这一步能有效避免“Eigen对齐冲突”这类经典的编译错误。Eigen是一个模板库，它内部使用了大量固定大小的向量化内存对齐，如果同一个程序里使用了不同版本的Eigen头文件，会直接导致各种奇怪的段错误或编译报错。统一使用系统Eigen是消除这类问题的根本手段。GTSAM_BUILD_UNSTABLE=ON：LIO-SAM的IMU预积分因子部分实际上依赖了GTSAM的Unstable模块，所以这个选项必须打开，否则编译LIO-SAM时会出现找不到ImuFactor相关头文件的错误。
编译GTSAM的时间取决于CPU性能，一般10分钟到半小时不等。编译完成后执行sudo make install，GTSAM的库文件会被安装到/usr/local/lib，头文件到/usr/local/include/gtsam，这些路径后续编译LIO-SAM时需要cmake能找到。
安装完成后，建议验证一下GTSAM的版本信息：
ls /usr/local/include/gtsam/base/Vector.h能列出这个文件就说明GTSAM的基本头文件已经就位。
2.4 一个需要提前确认的依赖：Ceres Solver
LIO-SAM本身不强制依赖Ceres，但很多基于LIO-SAM改造的项目（比如LIO-SAM-Map优化、激光-视觉联合标定流程）会用到Ceres做BA优化。如果你只是跑LIO-SAM原生代码，Ceres可以不装。但如果你是做SLAM方向的研究，后续大概率会用到，我建议顺手把Ceres也装好，避免之后用到时再回头补环境。
Ceres的源码编译在Ubuntu 20.04下比较顺畅：
sudo apt-get install -y libceres-dev也可以选择源码编译最新版本，但系统源里的Ceres版本对LIO-SAM相关项目来说完全够用，源码编译反而可能因为依赖冲突浪费时间。实测下来，Ubuntu 20.04自带的Ceres 1.14版本在后续标定项目中表现稳定。
3. LIO-SAM源码编译与demo数据包运行实录
3.1 工作空间的创建与源码拉取
依赖库就位后，就可以创建ROS catkin工作空间了。我习惯把所有算法的代码统一放在~/catkin_ws/src下，这样方便维护，也方便和后续其他功能包交叉引用。
mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src git clone https://github.com/TixiaoShan/LIO-SAM.git cd ~/catkin_ws catkin_make这里的catkin_make会报错吗？第一次直接运行catkin_make一般会失败，因为工作空间里只有LIO-SAM一个功能包，而且它会去查找GTSAM等依赖。报错信息通常会在CMake阶段就中止，提示找不到GTSAM。这是因为GTSAM安装到/usr/local后，LIO-SAM的CMakeLists.txt中find_package(GTSAM COMPONENTS ...)需要能搜索到/usr/local/lib/cmake/GTSAM路径。
如果遇到找不到GTSAM的情况，可以手动设置环境变量：
export GTSAM_ROOT=/usr/local或者干脆在~/.bashrc中加上：
export GTSAM_ROOT=/usr/local export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH然后source一下使得环境变量生效。
3.2 编译过程与关键参数调整
重新打开一个终端，进入工作空间执行以下命令：
cd ~/catkin_ws catkin_make -j4-j4是并行编译的线程数，我这里故意保守一点用4线程，因为LIO-SAM的源码里包含了几个比较大的模板类，比如mapOptimization.cpp、imageProjection.cpp，这些文件单文件编译内存开销比较大，如果机器内存不足，并行线程数开太高容易被系统杀掉。如果是16GB内存以上的机器，用-j8也问题不大。
整个编译过程通常会遇到一个警告，就是using namespace Eigen;和某些第三方库的命名空间冲突，但一般只是warning不会报错，可以忽略。
编译成功的标志是在~/catkin_ws/devel/lib/lio_sam/目录下生成四个可执行文件：
lio_sam_imageProjectionlio_sam_featureExtractionlio_sam_mapOptimizationlio_sam_imuPreintegration
看到这四个节点文件就说明编译已经通过了，接下来可以进行demo数据测试。
3.3 demo数据集的运行与launch文件修改
跑demo数据前，需要先下载官方提供的rosbag数据集。LIO-SAM官方在GitHub的README里提供了一组Google Drive链接，内容覆盖了各种场景，我们选其中最常见的walking dataset为例来演示。
下载好rosbag后，需要修改LIO-SAM的launch文件中的参数配置。打开终端，编辑~/catkin_ws/src/LIO-SAM/config/params.yaml：
gedit ~/catkin_ws/src/LIO-SAM/config/params.yaml重点修改以下内容：
useImuLoopClosure: true这里可以保持默认，它控制是否启用IMU+雷达的里程计回环检测。savePCD: false如果要保存地图点云，改为true并设置savePCDDirectory为你的目标路径。注意，这个路径必须是已存在的绝对路径，否则程序运行时会直接崩溃，不会给出任何友好提示。
然后是launch文件中的参数调整，打开~/catkin_ws/src/LIO-SAM/launch/run.launch，检查以下两项：
- 点云话题名称：数据集中的点云话题一般是
/points_raw，和launch文件里默认的/velodyne_points不同。需要把<param name="pointCloudTopic" value="/points_raw" />改对。 - IMU话题名称：数据集中的IMU话题一般是
/imu_raw，同样要检查是否匹配。
改完之后，启动三个终端：
终端1启动roscore：
roscore终端2启动LIO-SAM：
cd ~/catkin_ws source devel/setup.bash roslaunch lio_sam run.launch终端3播放数据集：
rosbag play your_downloaded_dataset.bag播放之后，RVIZ窗口会实时显示点云地图的构建过程。这里有个小技巧：如果RVIZ里看不到地图，先检查点云话题时间戳是否和系统时间同步。如果是下载的公开数据集，时间戳是历史时间，需要加上--clock参数，让ROS使用bag中记录的时间：
rosbag play --clock your_downloaded_dataset.bag同时，在run.launch中确认use_sim_time设置为true。这样TF树和各传感器的时间戳才能对齐。
3.4 运行效果评估与地图输出
运行结束后，LIO-SAM会在控制台输出位姿轨迹信息和回环检测结果。如果一切正常，你会看到回环检测报出多条“loop found”信息，地图构建也非常平滑。此时，如果设置了savePCD: true，运行结束后在设定的目录下会生成map.pcd文件，可以手动保存地图。
我个人实操时，用walking数据集在普通笔记本上（i7-9750H + 16GB内存 + GTX1660Ti）能保持30Hz左右的实时建图，CPU占用率在80%左右，说明LIO-SAM的轻量化特性确实名不虚传。
4. 编译与运行中的高发报错与排查方案
4.1 GTSAM相关的编译报错
编译LIO-SAM时最常见的报错是：
/usr/local/include/gtsam/...: error: 'gtsam::PinholeCamera' has not been declared这类错误，九成原因是GTSAM版本不对，或者GTSAM没有被正确找到。尤其是如果你系统里碰巧装了多个GTSAM版本，比如通过apt装过ros-noetic-gtsam，然后你又手动编译安装了4.0.2，两者就会冲突。
排查方法：先查看/opt/ros/noetic/lib下是否有gtsam相关库文件。如果执行dpkg -l | grep gtsam能查到系统自带gtsam，建议先卸载它：
sudo apt-get remove ros-noetic-gtsam然后再重新手动编译安装4.0.2版本。这个坑我踩过，当时编译LIO-SAM时一直提示某些头部函数声明找不到，后来源头是apt版GTSAM版本过旧，和LIO-SAM期望的API版本不一致。
4.2 PCL版本相关的编译报错
在Ubuntu 20.04 + Noetic环境下，PCL 1.10相比PCL 1.8有一些接口弃用和改名。LIO-SAM源码中，容易触发问题的是以下两个位置：
imageProjection.cpp中使用了pcl::PointCloud<PointType>::Ptr和pcl::transformPointCloud。这些在PCL 1.10下完全没有问题，但如果出现“找不到PCLPointCloud2转换函数”这类错误，说明pcl_ros的消息类型没有正确链接。解决方法是检查是否安装了ros-noetic-pcl-ros，并在CMakeLists.txt中确认find_package(PCL REQUIRED)被正确声明。mapOptimization.cpp中调用了pcl::voxel_grid滤波和pcl::StatisticalOutlierRemoval滤波，1.10版本中这些类的头文件路径变为pcl/filters/voxel_grid.h和pcl/filters/statistical_outlier_removal.h，一般不会冲突。
另外，GTSAM和PCL同时使用时，可能会出现Eigen::aligned_allocator相关的报错。这本质上是Eigen内存对齐引起的编译冲突，解决方案已经在前面说过了：保证GTSAM使用系统Eigen（GTSAM_USE_SYSTEM_EIGEN=ON），同时不要往任何加了EIGEN_MAKE_ALIGNED_OPERATOR_NEW的类里塞STL容器元素，这属于Eigen的老话题了。
4.3 OpenCV版本相关的运行时异常
LIO-SAM默认不依赖视觉特征，但如果你的项目中额外启用了visualFeature相关模块，可能会遇到OpenCV 4.2下的API差异。最典型的问题是cv::solvePnP函数在多解时的行为变化，以及在OpenCV 4下findEssentialMat默认使用RANSAC时抛出的异常。
如果遇到这类运行时崩溃，首先确认是否安装了libopencv-dev和ros-noetic-cv-bridge，其次检查cv_bridge和OpenCV版本是否一致。Noetic默认的cv_bridge针对OpenCV 4编译，如果你另外用源码编译了OpenCV 3，那必然会产生链接冲突。这种情况下的解决方法只有一个：保持系统标准版本，不要动OpenCV。
4.4 编译卡死或内存不足现象
LIO-SAM的mapOptimization.cpp在编译时是出了名的吃内存。如果你使用的是虚拟机，或者物理内存只有8GB，那么catkin_make -j$(nproc)经常会导致编译进程被系统杀死，表现为终端显示Killed字样。
处理办法有两个方向：
- 降低并行编译线程数，例如用
catkin_make -j2，让每个编译任务拥有更多内存。 - 临时增加swap空间，在
/etc/fstab中配置一个swap文件，或者直接用fallocate和mkswap创建一块临时swap来缓解物理内存不足。
我个人实际测试，8GB内存的机器用-j2编译LIO-SAM是完全能通过的，只是时间会稍长一些，大概多等10分钟而已。不要盲目追求编译速度，稳定通过才是第一目标。
4.5 运行时不建图或地图闪退问题排查
运行LIO-SAM时，最让人头疼的问题就是RVIZ中看不到点云，或者地图稍微转两下就崩溃。这类问题通常不是编译造成的，而是数据时间同步和TF坐标系设置的问题。
用rqt_tf_tree命令检查TF树是否完整。LIO-SAM的正常TF树结构应当是：
map -> odom odom -> base_link base_link -> sensor_link (通常是 velodyne 或 camera_init)如果map到odom的TF一直没有发布，说明回环检测或者后端优化节点没有正常工作，检查mapOptimization节点的输出日志。如果odom到base_link抖动剧烈，则说明IMU数据处理有误，检查imuTopic话题中的数据频率是否正常，LIO-SAM要求IMU频率不低于100Hz，如果只有50Hz，需要调整参数或使用IMU内插数据。
另外，数据集的点云话题如果是/points_raw，但你的launch文件里用的是/velodyne_points，那么RVIZ中当然不会有任何点云，因为节点根本就没有订阅到数据。用rostopic list查看当前话题列表，用rostopic hz /points_raw查看话题发布频率，这都是排查数据链路问题的基本功。
4.6 常见问题排查速查表
我把上边提到的坑整理成一个速查表，方便以后排障时直接查阅：
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| CMake找不到GTSAM | GTSAM未安装或未加入环境变量 | 检查/usr/local/lib/cmake/GTSAM是否存在；添加GTSAM_ROOT=/usr/local环境变量 |
| 编译时报Eigen对齐错误 | GTSAM使用了自带Eigen而非系统Eigen | 重编GTSAM，加上-DGTSAM_USE_SYSTEM_EIGEN=ON |
undefined reference togtsam::... | GTSAM版本不对或与系统自带版本冲突 | 卸载apt版GTSAM，源码安装4.0.2 |
运行时找不到/points_raw话题 | 点云话题名称不匹配 | 修改launch文件中的pointCloudTopic参数 |
| RVIZ无地图且无TF | 时间戳不同步 | 播放bag时加--clock参数，launch中设置use_sim_time: true |
| 编译时内存不足被Killed | 并行线程数过多或物理内存不足 | 降低-j线程数或增加swap空间 |
| 运行时崩溃：Segmentation fault | 保存pcd的路径不存在 | 确保savePCDDirectory路径存在且可写 |
| 运行时报Invalid argument | IMU话题频率过低 | 检查IMU话题数据频率，重新录包或增加IMU数据率 |
5. 编译成功后的功能扩展与二次开发方向
5.1 从LIO-SAM到LIO-SAM-Map与语义SLAM
一旦LIO-SAM在Noetic下成功编译和运行，你就拥有了一个非常稳定的多传感器融合SLAM底座。最常见的扩展方向是LIO-SAM-Map这种引入大量历史帧进行大规模建图的变种。它和LIO-SAM的主要差异在后端优化策略：后者保留更大的局部地图进行扫描匹配，对内存和算力的需求更高，但建图精度也会提升。实现方式通常是修改mapOptimization.cpp中的关键帧插入策略，并增加一个SC-PGO（Scan Context全局回环检测）模块。SC-PGO和LIO-SAM的结合是当前比较热门的增强方向，它能显著改善大场景下的累计漂移问题。
如果你对语义SLAM感兴趣，LIO-SAM的轻量化结构非常适合嫁接语义分割网络。思路也简单：在LIO-SAM提取特征之后，加入一个语义分割线程，为每个点云帧增加语义标签，让里程计和回环检测只使用地面点和背景点等静态物体，而把车辆、行人等动态物体剔除。这个方向在Noetic下实现起来很方便，因为Noetic对Python 3的支持很好，很多语义分割模型都可以直接部署。
5.2 适配自有传感器：从demo到真实设备
跑通demo数据集之后，下一步大概率是要把LIO-SAM迁移到自己的传感器平台上。这一步的关键在于把传感器数据转换成ROS消息格式，并且保证时间戳同步。
LIO-SAM的输入是：
- 一个3D激光雷达话题，消息格式为
PointCloud2 - 一个6轴或9轴IMU话题，消息格式为
sensor_msgs/Imu
如果使用的激光雷达是Livox系列，需要额外注意点云数据的预处理。Livox官方提供了livox_ros_driver2，发布的消息是自定义的livox_ros_driver2/CustomMsg，LIO-SAM原版是不认这种数据格式的，需要先使用livox_point_cloud_converter把它转成标准的PointCloud2格式，再通过pointcloud_to_laserscan或直接转发到/points_raw话题。如果直接让LIO-SAM订阅CustomMsg，编译能过，但运行时不会有点云数据。
IMU的安装位置校准也容易被忽视。LIO-SAM假设IMU和激光雷达之间的外参已经标定好，如果外参不准，即使编译运行成功，建出的地图也会有明显的漂移和分层现象。建议先使用lidar-IMU联合标定工具（如LiLi-OM、lidar_imu_calib）做好外参标定，再把外参参数填入params.yaml。
5.3 性能调优实践：编译优化参数
如果你对实时性有更高要求，还可以在编译阶段做一些优化。LIO-SAM源码的CMakeLists.txt中默认使用的是-O2优化级别，你也可以尝试改为-O3，在某些CPU上能带来5%-10%的帧率提升。修改方式是在CMakeLists.txt中找到add_definitions或者set(CMAKE_CXX_FLAGS_RELEASE ...)的行，加上-O3 -march=native。但要注意，-march=native和GTSAM编译时的可移植性设定是冲突的，如果是自己本机使用，可以加上；如果后续要换机器运行，就别加。
另一个调优方向是修改params.yaml中关键帧之间的距离阈值和角度阈值，让系统插入更少的关键帧，减轻后端优化的压力。对于室外大场景，将keyFrameMeter从1.0调整到1.5或2.0，能明显降低CPU占用，而精度损失通常在一个可接受范围内。这个参数的调整没有绝对标准，需要根据传感器精度和应用场景实测折中。
6. 写在最后：一个过来人的经验小结
LIO-SAM的编译折腾下来，我的最大感受是：这套代码的质量整体是过硬的，它之所以让很多人卡住，问题几乎都集中在依赖库管理上。Ubuntu 20.04 + Noetic的组合只要把GTSAM的编译参数选对，把PCL和OpenCV的版本匹配处理好，整个编译过程比想象中顺利。
最后分享一个我自己的习惯：编译任何SLAM算法之前，先把系统的所有依赖库版本记录下来，用pkg-config --modversion逐个验证一遍，这比编译报错后再回头排查要高效得多。另外养成使用catkin build而不是catkin_make的习惯，catkin build在增量编译时更人性化，能精确告诉你每个功能包的编译状态和依赖顺序，排查问题的时候直观很多。
如果你的编译过程遇到了我在文章里没提到的问题，优先去GitHub的Issue区搜索，很多坑早就有前人留下了解答。祝大家都能顺利跑通LIO-SAM，在自己平台上建出漂亮的第一张地图。
