传感器融合模块用指针而非值语义，因数据流持续异步、多源且各传感器生命周期不一、体积大，拷贝开销高并破坏实时性；须用虚析构函数，优先 unique_ptr 管理所有权，跨线程共享用 shared_ptr；多线程更新读取融合结果宜用 atomic_store 交换 shared_ptr<const FusionResult>。
传感器融合模块为什么要用指针而不是值语义
因为传感器数据流是持续、异步、多源的，且各传感器对象（如 LidarDriver、ImuFusionNode、CameraTracker）生命周期不一致，体积大（含缓冲区、校准参数、状态机），直接拷贝会触发深拷贝或编译报错。值语义还会让 std::vector<sensorbase></sensorbase> 在扩容时反复调用析构/构造，破坏实时性。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有传感器基类必须有虚析构函数，否则
delete派生类指针会未定义行为 - 优先用
std::unique_ptr<SensorBase>管理所有权，避免裸指针；跨线程共享时改用std::shared_ptr，但注意引用计数原子操作开销 - 不要把传感器指针存进
std::vector<std::unique_ptr<SensorBase>>后再用.get()长期缓存原始指针——一旦 vector 重分配，原始指针就悬空
如何安全地在多线程中更新和读取融合结果
典型场景：IMU 线程以 1kHz 推送原始角速度/加速度，视觉线程每 30ms 输出位姿估计，融合节点需合并两者并输出 Eigen::Vector3d fused_position。裸指针 + std::mutex 容易漏锁或死锁，而 std::atomic<Eigen::Vector3d*> 不合法（Eigen::Vector3d 非 trivially copyable）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::shared_ptr<const FusionResult>替代原始指针传递只读结果，写线程 new 新对象，读线程原子交换指针：std::atomic_store(&latest_result_, std::make_shared<FusionResult>(new_data)) - 若需低延迟（boost::lockfree::spsc_queue），但必须确保
FusionResult是 trivially copyable 或手动 memcpy - 绝对不要在中断服务例程（ISR）里 new/delete 或调用
std::shared_ptr构造——RTLinux 或 ROS2 micro-ROS 下会直接触发 hard fault
为什么 sensor fusion 的工厂函数返回 std::unique_ptr 而不是 std::shared_ptr
工厂函数如 create_sensor(const std::string& type) 返回 std::unique_ptr<SensorBase>，是因为大多数传感器在系统中是单例、独占硬件资源（如 /dev/ttyUSB0）、且生命周期由主控节点严格控制。用 shared_ptr 会隐式延长对象生存期，导致设备句柄未释放、串口被占用无法重启。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 工厂内部用
new构造后立即包进unique_ptr，禁止返回裸指针再由调用方包装 - 若某传感器确实需多处观察（如调试 GUI 和控制闭环同时读取 IMU），由上层显式转成
shared_ptr：auto imu_ptr = std::move(factory.create_sensor("mpu6050")); auto gui_ref = std::shared_ptr<ImuDriver>(imu_ptr.release(), [](ImuDriver* p) { delete p; }); - ROS2 中通过
rclcpp::Node::create_subscription注册回调时，传入的std::bind捕获传感器指针，必须用std::ref或std::weak_ptr避免循环引用——否则节点 shutdown 后传感器对象仍驻留内存
std::unique_ptr 在实时循环中频繁创建销毁是否影响性能
不影响——只要不触发堆碎片。现代 Linux 内核（≥5.4）+ glibc 2.31 后，malloc 对小块内存（unique_ptr 析构时的 delete 几乎是 O(1) 常数时间。真正拖慢的是传感器驱动层的 read() 系统调用或 DMA 拷贝。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对高频传感器（如 10kHz 编码器），改用对象池（
boost::object_pool<EncoderSample>）预分配内存，避免每次 new 分配页表项 - 禁用
std::make_unique在硬实时循环中调用——它内部有异常检查分支，GCC 默认开启-fexceptions会插入额外指令；直接写std::unique_ptr<T>(new T{...})更可预测 - 用
valgrind --tool=massif抓住峰值内存，确认没有意外的临时std::vector<std::unique_ptr<...>>在循环内反复构造
最常被忽略的一点：传感器指针本身不“融合”，融合逻辑永远在独立的 FusionEngine 类里，它持有对各传感器的 weak_ptr 并定期调用 sensor->latest_reading()。裸指针或强引用会让融合模块无法感知传感器离线，进而输出陈旧甚至错误的状态估计。
