写C代码的语言检人迟早都会碰到段错误。程序跑着跑着突然崩了，语言检终端只丢下一句“Segmentation fault (core dumped)”，语言检什么行号、语言检什么变量，语言检统统没有。语言检这时候能救命的语言检，就是语言检检查手段。

最原始的语言检办法是加printf。别笑，语言检这招到今天依然管用。语言检在可疑位置前后各打一条日志，语言检看程序到底走到哪一步才断气。语言检我见过一个同事排查内存越界，语言检硬是语言检在一个循环里插了二十多条printf，最后定位到是数组下标多减了1。笨，但有效。printf的问题在于它会改变程序时序，多线程环境里可能把bug藏起来，也可能凭空造出新bug。

编译器其实一直在帮你检查，只是很多人把警告当噪音。gcc加上-Wall -Wextra，能揪出一堆类型不匹配、未使用变量、隐式声明的问题。我习惯再加-Werror，把警告直接升级成错误，逼自己当场改掉。有个细节：-Wall并不包含所有警告，比如-Wshadow要单独开，它能发现内层变量遮蔽外层变量的情况，这种bug查起来特别费眼。

真正难缠的是内存问题。栈上的数组越界，编译器管不了；堆上的use-after-free，运行时才发作。这时候得请出AddressSanitizer。编译时加-fsanitize=address -g，程序跑起来会变慢，但一旦踩到非法内存，它立刻打印出完整的调用栈，连哪一行申请、哪一行释放、哪一行又去访问都标得清清楚楚。我第一次用它抓到double free时，看着那份报告愣了半天——原来自己写的释放逻辑在异常分支里被走了两遍。

Valgrind是另一条路。它不需要重新编译，直接跑二进制就行，缺点是慢得离谱，有时候慢五十倍。适合在单元测试阶段用，不适合压测。它的memcheck工具能发现未初始化内存读取，这个AddressSanitizer默认不查，得开-fsanitize=memory，而且那个模式要求所有代码都重新编译，混用第三方库会很麻烦。

静态分析工具属于另一层防线。cppcheck扫一遍代码，能找出不少逻辑漏洞，比如if (a = b)这种手滑。它不需要编译，直接读源码，适合塞进CI流程里当门禁。但别指望它万能，指针别名一复杂，它就开始瞎猜，误报率不低。

说个真实教训。之前写一个解析二进制协议的模块，本地测试全过，上了测试环境就随机崩溃。用gdb挂上去，发现崩在memcpy，但源地址和目标地址看着都合法。折腾半天才想起来，结构体里有柔性数组，分配时少算了几个字节，写越界了。AddressSanitizer一跑，直接指到那行malloc——大小算错了。这种问题靠肉眼review根本看不出来，因为代码逻辑“看起来”完全正确。

检查C程序，没有银弹。printf打底，编译器警告全开，AddressSanitizer和Valgrind按场景切换，静态分析当补充。工具越多，漏网的bug越少。但归根结底，写代码时对内存和边界多留个心眼，比事后拿一堆工具去追要省力得多。

(责任编辑：时尚)