https://yun7211.github.io/c-language/debug-quality/Recent content in 调试与质量 on Yun 的个人博客Hugo -- gohugo.iozh-cnMon, 18 May 2026 11:40:00 +0800https://yun7211.github.io/c-language/debug-quality/code-review-checklist/Mon, 18 May 2026 11:40:00 +0800https://yun7211.github.io/c-language/debug-quality/code-review-checklist/<h2 id="审查目标">审查目标 </h2><p>C 代码审查不是挑风格问题，而是提前发现运行时成本最高的问题：内存错误、资源泄漏、接口歧义、错误路径遗漏和不可测试的全局状态。</p> <h2 id="接口语义">接口语义 </h2><p>先看函数接口是否清楚：</p> <ul> <li>参数能否为 <code>NULL</code></li> <li>返回值如何表达错误</li> <li>调用方是否负责释放资源</li> <li>输出参数失败时是否有效</li> <li>函数是否修改传入缓冲区</li> </ul> <p>接口语义不清楚时，后续实现再漂亮也容易出问题。</p> <h2 id="内存和边界">内存和边界 </h2><p>重点检查长度、容量和生命周期：</p> <ul> <li>字符串空间是否包含 <code>\0</code></li> <li><code>memcpy</code>、<code>snprintf</code>、数组下标是否有边界</li> <li>释放路径是否覆盖所有失败分支</li> <li>指针释放后是否还会被访问</li> </ul> <h2 id="错误路径">错误路径 </h2><p>C 项目里很多 bug 只在异常路径出现。审查时要刻意走失败分支：申请失败、文件打开失败、设备不存在、协议字段不合法、部分初始化后返回错误。</p> <h2 id="小结">小结 </h2><p>好的代码审查清单能把经验固化下来。每次发现新问题，都应该把它变成下一次能提前检查的条目。</p>https://yun7211.github.io/c-language/debug-quality/debugging-memory-bugs/Mon, 18 May 2026 10:50:00 +0800https://yun7211.github.io/c-language/debug-quality/debugging-memory-bugs/<h2 id="常见现象">常见现象 </h2><p>C 内存问题经常表现得很绕：崩溃点不一定是出错点，今天能复现的问题明天可能消失，打开日志后问题也可能变化。</p> <p>常见类型包括：</p> <ul> <li>数组或缓冲区越界</li> <li>使用已经释放的指针</li> <li>重复释放</li> <li>未初始化读取</li> <li>资源泄漏</li> </ul> <h2 id="先缩小范围">先缩小范围 </h2><p>不要一开始就盯着崩溃现场。先确认最近改动、输入数据规模、线程数量、编译优化级别和是否只在特定平台出现。</p> <p>如果问题能稳定复现，优先构造最小复现用例。</p> <h2 id="检查边界">检查边界 </h2><p>内存越界通常和长度计算有关。重点检查：</p> <ul> <li>缓冲区大小是否包含结尾 <code>\0</code></li> <li><code>memcpy</code> 长度是否来自可信来源</li> <li>循环边界是否使用 <code>&lt;</code> 而不是误用 <code>&lt;=</code></li> <li>结构体长度和协议字段是否一致</li> </ul> <h2 id="检查生命周期">检查生命周期 </h2><p>悬空指针来自对象生命周期结束后继续访问。释放后可以把指针置为 <code>NULL</code>，但这只能减少部分误用，不能替代清晰的所有权设计。</p> <h2 id="小结">小结 </h2><p>排查内存问题要有耐心，也要有方法。先稳定复现，再缩小范围，最后回到边界、生命周期和错误路径。</p>