cv::Mat 默认赋值触发深拷贝因引用计数为1且目标已有独立内存时执行memcpy；避免方法包括显式clone、指针直访、复用dst并固定resize参数。
为什么 cv::Mat 的默认构造/赋值会触发深拷贝？
OpenCV 的 cv::Mat 在赋值（如 a = b）或函数返回时，若未显式控制引用计数，会检查 u（指向数据的 MatAllocator）和引用计数。一旦引用计数为 1 且目标 Mat 已有独立内存，就可能触发 memcpy —— 这在每帧都调用的检测 pipeline 中直接放大延迟。
常见错误现象：detect_and_crop(cv::Mat frame) 内部对 frame 做 ROI 或 resize 后传给推理引擎，结果发现 CPU 占用高、帧率卡顿，perf record 显示大量 memcpy 耗时。
- 避免隐式拷贝：始终用
.clone()显式深拷贝，或用.rowRange().colRange()+.data指针直接访问原始内存 - 确认是否共享：打印
mat.data == other_mat.data和mat.u == other_mat.u，二者同时为 true 才是真正共享 - resize 等操作默认不共享：即使
cv::resize(src, dst, ...)中dst已分配，OpenCV 仍会重新 malloc 并 memcpy；应提前复用dst并用cv::resize(src, dst, ..., 0, 0, cv::INTER_NEAREST)配合固定尺寸避免重分配
如何用裸指针绕过 cv::Mat 的引用计数开销？
当检测模型输入要求固定格式（如 NHWC uint8_t*），且你已确保生命周期可控（例如所有处理都在单线程 detector 对象内完成），可跳过 cv::Mat 封装，直接传递原始指针。
使用场景：YoloV5/Triton 推理前的预处理（BGR→RGB→normalize→NHWC→float32），中间不依赖 OpenCV 函数，只用 memcpy 和 SIMD。
立即学习“C++免费学习笔记（深入）”；
- 从摄像头/解码器拿到帧指针后，立即用
cv::Mat(HEIGHT, WIDTH, CV_8UC3, raw_ptr, step)构造“零拷贝视图”，注意step必须匹配实际行字节数（含 padding） - 后续所有 ROI、通道变换用指针算术：例如 BGR→RGB 可用
std::swap(ptr[i], ptr[i+2])原地交换，而非cv::cvtColor - 禁止在该
cv::Mat上调用.copyTo()、.convertScaleAbs()等会触发深拷贝的函数；如有需要，先.data = nullptr解绑再操作
std::shared_ptr<uint8_t></uint8_t> 能否安全管理检测帧内存？
可以，但必须配合自定义 deleter，并且不能和 cv::Mat 混用其内部引用计数逻辑——否则会出现 double-free 或提前释放。
典型错误：用 std::shared_ptr<uint8_t>(new uint8_t[size])</uint8_t> 创建缓冲区，再用它构造 cv::Mat；此时 cv::Mat 不知道该指针归属 shared_ptr，析构时可能释放两次。
- 正确做法：用
std::shared_ptr<uint8_t></uint8_t>+ 自定义 deleter（如 lambda 调用aligned_free），再通过cv::Mat(height, width, type, ptr.get(), step)构造非托管 Mat - 关键约束：该
cv::Mat生命周期必须短于 shared_ptr；禁止调用mat.setTo(...)或任何会尝试 realloc 的操作 - 性能影响：shared_ptr 的原子计数在高频帧下有轻微开销（约 1–2 ns/次），但远低于 memcpy（通常 >1000 ns）；若极致追求，改用
std::unique_ptr+ move 语义更合适
推理引擎输入层如何对接裸指针而不触发额外拷贝？
主流引擎（ONNX Runtime、TensorRT、Triton）的输入 API 均接受 void*，只要内存布局、dtype、尺寸完全匹配模型要求，就可零拷贝传入。
容易踩的坑：TensorRT 的 IExecutionContext::enqueueV2() 要求输入内存页对齐（如 256 字节），而 new uint8_t[] 不保证；ONNX Runtime 的 Ort::MemoryInfo::CreateCpu(..., OrtArenaAllocator) 默认走 arena 分配，与外部指针冲突。
- TensorRT：用
posix_memalign(&ptr, 256, size)分配，传入context->setBindingData(0, ptr)；确认 binding 0 是 input 且context->allInputDimensionsSpecified()为 true - ONNX Runtime：创建
Ort::MemoryInfo::CreateCpu(OrtAllocatorType::OrtArenaAllocator, OrtMemType::OrtMemTypeDefault)时，若要传外部指针，必须用OrtAllocatorType::OrtInvalidAllocator并手动管理 lifetime - 验证方式：在推理前打日志输出
input_tensor.GetTensorMutableData<uint8_t>() == your_ptr</uint8_t>，确保地址一致
真正的难点不在指针本身，而在生命周期边界的精确控制——哪一帧由谁分配、谁释放、谁持有引用，漏掉任意一个环节都会导致 crash 或静默内存污染。调试时优先用 AddressSanitizer + UBSan，比靠经验猜更可靠。
