从一段崩溃的图像灰度转换说起
上周写个图像灰度化程序，跑起来直接段错误。图片数据指针明明分配了内存，结果在循环里访问就崩。这种问题在图像处理项目里太常见了——数据量大、内存操作频繁，一个小越界就能让整个程序瘫痪。折腾了俩小时，靠几个简单的调试手段才定位到问题出在宽高传反了。
用 printf 定位执行路径
别小看最原始的方法。在关键函数入口打个标记：
#include <stdio.h>
void convert_to_grayscale(unsigned char* rgb, unsigned char* gray, int width, int height) {
printf("[DEBUG] 进入灰度转换，尺寸: %d x %d\n", width, height);
// ...处理逻辑
}输出一下参数值，立刻能看出是不是传参出了问题。比如我把 width 和 height 搞混，打印出来一眼就发现宽是3，高是800，明显不对劲。
检查内存边界像查菜谱一样 routine
图像数据常以一维数组存储二维像素，计算索引时容易越界。比如遍历像素：
for (int y = 0; y < height; y++) {
for (int x = 0; x < width; x++) {
int idx = y * width + x;
if (idx >= width * height) {
printf("越界警告: x=%d, y=%d, idx=%d\n", x, y, idx);
}
gray[idx] = /* ... */;
}
}这种检查写多了就成了习惯，就像切菜前先洗刀。尤其处理BMP或RAW这类手动管理内存的格式时，多一行判断能省去后续大把时间。
善用编译器警告，别视而不见
gcc 加上 -Wall -Wextra 后经常报一堆“未使用变量”或“隐式声明”，很多人直接忽略。但有一次它提示我 memcpy 参数少写了长度，刚好是在图像通道复制时漏了 size*3，差点酿成大错。现在我的 Makefile 里都带着 -Werror，只要报警就过不了。
gdb 不一定非得断点连着用
有时候程序崩溃了，直接上 gdb 执行一遍，它会停在出错那行。比如看到提示 “Cannot access memory at address…” 马上就知道是空指针解引用。配合 backtrace 看调用栈，能快速回溯到是哪个读取函数没正确初始化缓冲区。
有个小技巧，在代码里主动加个 __builtin_trap() 或 asm("int $3"); 可以让程序运行到这里自动中断进调试器，比反复设断点方便。
构造小尺寸测试图加快反馈
别一上来就拿 4K 图片测试。做个 5x5 的 BMP 文件，手动写点固定值进去，输出也容易核对。发现问题改完后再放大验证。这个习惯让我在实现卷积滤波时少跑了几十遍大图。
把调试信息写进日志文件
图像处理程序常要批处理一堆文件，这时候把 debug 信息重定向到日志更高效：
printf("处理 %s: 分配内存 %d bytes\n", filename, size);
// 重定向到文件：./process > debug.log 2&&1处理完翻日志，哪一步卡住一目了然，不用盯着终端等输出。
调试不是玄学，就是一点点抠细节。每个图像处理程序员的功力，往往体现在他怎么对付那些“理论上应该没问题”的代码上。