移动语义与流水线：点云/图像缓冲如何少拷一次

1. 每帧 10MB 的拷贝从哪来

点云 decode → filter → publish，profiling 显示 CPU 一半耗在 memcpy，接口却全是 const Cloud&。某 stage 把引用存进成员等于每帧深拷贝；队列 pop 后仍读旧 frame 是 use-after-move；return 前 std::move(local) 阻止 NRVO。根因不是算法慢，是所有权没画清。移动语义不是编译器「优化 hint」，是把「谁拥有 buffer」写进类型系统的语言特性。pipeline 设计应先画 ownership 箭头，再写函数签名；事后全局搜 std::move 往往补不齐接口漏洞。底盘上常见误判是「加线程就能快」——线程多了拷贝次数没变，只是把 memcpy 摊到更多核上，内存总线先饱和。验收时若 copy ctor 仍在 hot path，先查签名与成员存储，再谈算法优化。团队 review 可要求新 stage 附 ownership 简图：从 driver 到 publish 标注 move、copy、shared 三种边，比事后 profiler 猜更省时间。

2. 链式 by-value 与 NRVO

独立 stage 优先 by-value 接、by-value 返，让编译器在整条调用链上做一次 move/copy 决策。return std::move(local) 可能阻止 named RVO——只在确定不能 elision 时用。中间 stage 需保留历史帧做 debug 或双路输出时，显式 split 出 copy 或 shared_ptr<const Cloud>，别在 hot path 默认共享。PCL 大点云可用 std::swap 交换内部指针，语义比连续 move assign 更清楚。若 stage 必须保留上一帧做差分，在文档写清「此处 intentional copy」，避免后人当成 bug 删掉 copy 却破坏算法。

Cloud pipeline(Cloud cloud) {
  cloud = voxelDownsample(std::move(cloud));
  cloud = transform(std::move(cloud));
  return cloud;  // 让 NRVO 生效，别 return std::move(cloud)
}

3. 参数形态：sink、view、转发

sink(Cloud&&) 消费临时；const Cloud& 只读不拿所有权。std::move(const Cloud&) 仍是 copy——要转移所有权必须 Cloud&& 或 by-value sink。ROS 2 loaned message 是另一层零拷贝契约：能 loan 就别先 copy 进自定义 Cloud 再 move，否则「用了移动语义」仍每帧 memcpy 整包数据。包装层用完美转发保持 factory 返回值类别，避免多一次 copy；sensor adapter 模板里漏 forward 一处，profiler 就会在 unexpected 栈帧里看到 copy ctor。三种形态混用时，call site 一眼应能判断：这行是只读、消费还是可能 copy。

4. vector 拼接与 noexcept

多帧合并先 reserve，再用 move iterator 插入，避免 reallocate 触发全量 copy。std::vector 扩容时若 move ctor 非 noexcept，标准库会退回复制——给 SensorFrame 声明 noexcept move。driver 产出 unique_ptr<Msg>，worker move 进 pool，publish 前 shared_ptr<const> 冻结只读快照。单路径 pipeline 滥用 shared_ptr 会让「谁最后释放」不可见，refcount 泄漏 debug 时曲线也难读。benchmark 时对比 vector::push_back 在 noexcept 前后 reallocate 次数，往往比换 faster memcpy 更能说明问题。

5. 与 shared_ptr 的取舍

单路径用 move 更轻；共享点应屈指可数且文档化。viz 只读预览可在 publish 边界 shared_ptr<const> 冻结一帧，pipeline 内部仍 move。每个 shared_ptr 都要有理由——多订阅者、异步 viz，不是「省事默认」。loan message 与自定义 Cloud 并存时，文档写清哪一段 borrow、哪一段 own，避免中间层「先 copy 再 move」的假优化。若 viz 与算法都要同一帧，在 publish 边界 fork 一次 copy 或 shared 冻结，别在 filter 链中间默认 shared。

6. 失败症状

仍每帧 copy：const Cloud& 却存成员，或 push_back(frame) 漏 move。move 后读原 vector：下游空数据。move ctor 未 noexcept：vector reallocate 静默 copy 大 buffer。return 前 move local：NRVO 失效。这些症状在录包回放与线上应能复现同一 copy 栈——若只有线上有，查 loan 边界是否多 copy 了一次。GCC -Rpass=move 或 Clang -Rpass=return 可快速定位 hot path 里意外的 copy ctor 实例化。

7. 案例：const 引用存成员

filter 签名 void apply(const Cloud& in)，内部 working_ = in 每帧深拷贝百万点。改成 by-value 或 Cloud&& 后，同 bag CPU 降一截——改一行签名加一行 move，比换 faster memcpy 诚实。这类 bug 在 review 里常被「接口一直这样」掩盖，直到真机带宽打满才暴露；ownership 图画出来一眼就能看见「这里多了一条拥有边」。同 bag 改前后各跑一遍，copy ctor 调用次数应从每帧 N 次降到接近零。

8. 验收

GCC -Rpass=move 或 Clang -Rpass=return：hot path 无意外 copy ctor。debug -fno-elide-copy 确认 move 链。同 bag benchmark：copy vs move pipeline 带宽与 CPU 可区分。review：push_back/emplace 对局部 frame 是否 move。日志带 frame_id 与 stage 名，copy 热点指到具体函数，而不是只说「感知 CPU 高」。新 stage PR 附 ownership 简图，与代码签名对照无矛盾。

9. 与录包回放对齐

离线回放 deserialize 输出应 by-value 交给 filter，别经 const& 缓存层。线上、回放各跑同一 bag，copy ctor 计数应同量级——否则优化只活在实验室。移动语义把「少拷一次」变成类型问题；看得懂 ownership 箭头，才看得懂每一行该不要 copy。录包复盘时若 copy 栈只出现在回放路径，说明 deserialize 与 live driver 的接口类别不一致，应统一为 by-value 或 loaned 边界后再比 benchmark。