直接用img.data而非at()是因为at()每次调用都执行边界检查和类型转换，开销大；而img.data返回裸指针，访问快、可控性强，适合百万级像素遍历，但需手动保证不越界、正确计算偏移（如考虑step而非仅cols*channels），并适配图像类型与通道数。
为什么直接用 img.data 而不是 at()？
因为 at() 每次调用都做边界检查和类型安全转换，开销大；而图像处理常需遍历百万级像素，img.data 返回裸指针，访问快、可控性强。但代价是：你得自己保证不越界——比如灰度图单通道时，img.data[i * width + j] 合法，彩色图（3通道）就得写成 img.data[i * img.step + j * 3]，否则会读错字节。
ptr<uchar>(i)</uchar> 和 data 有什么区别？
ptr<uchar>(i)</uchar> 返回第 i 行首地址，自动考虑了 OpenCV 的行填充（step），适合逐行扫描；data 是整个图像内存块起始地址，不带步长信息，必须手动计算偏移。常见错误是把灰度图当彩色图算：用 data[i * width + j] 处理 BGR 图，结果只改了 B 分量，G/R 不动——实际该用 data[i * img.step + j * 3] 或循环处理三个通道。
如何安全地做像素运算（比如反色）？
直接写 255 - c 看似简单，但若图像类型不是 CV_8UC1（如 CV_16UC1），就会溢出或截断。正确做法：
- 先确认类型：
img.type() == CV_8UC1或img.depth() == CV_8U - 用
saturate_cast<uchar>(255 - c)</uchar>替代裸减法，避免负值或超限 - 对多通道图，别只改一个分量；BGR 图要分别处理
[0]、[1]、[2]
指针操作时最容易被忽略的坑
OpenCV 的 Mat 默认按行优先存储，但每行末尾可能有填充字节（padding），所以 img.cols * elemSize() ≠ img.step。用 img.step 替代 width * channels 才能跨行安全跳转。例如：下一行首地址是 current_row + img.step，不是 current_row + width * 3（彩色图）。这个差值在宽不是 4 的倍数时尤其明显，会导致后续行数据错位——看起来像“条纹干扰”，调试时很难定位。
立即学习“C++免费学习笔记（深入）”；
