C 語言賦予開發者強大的能力 —— 既能用來研發航天器，也能讓你的筆記本電腦在午飯前就徹底癱瘓。這份清單不是空洞的說教，而是一份實用指南，專門指出新手開發者反復踩坑的那些問題。這些漏洞輕則讓人頭疼不已，重則有時會按需觸發故障，有時卻又幾乎無法復現。

這類問題在團隊處于開發沖刺階段時，危害尤為嚴重。不過值得慶幸的是，其中很多錯誤都十分典型，我們能夠將它們一一列舉、剖析，并幫助你養成良好的編碼習慣，讓代碼以最佳的方式趨于 “平淡”：在不同編譯器、不同優化級別和不同平臺下，都能表現出可預測性。

這些技巧適用于所有開發者，同時本文還給出了遵循 MISRA C/C++ 等標準的相關建議。

1.  字符串 “差一錯誤”：忘記字符串結束符（NUL）

C 語言新手在為文本分配內存時，總想著 “剛剛好”—— 結果卻多寫了一個字節的數據（見圖 1）。你根據字符串有 n 個字符，就將緩沖區大小設為 n，然后問題來了：你忘了字符串結束符也需要占用一個字節的空間。這個缺失的字節正是許多隱性緩沖區溢出問題的根源，甚至可能導致日志輸出演變成內存損壞故障。這類問題具有確定性和可復現性，而且危害極大。

圖 1 字符串 “差一錯誤” 示例：忘記字符串結束符（NUL）

專業修復方案：為 C 語言字符串分配內存時，務必預留長度+1的空間；優先使用snprintf函數（而非sprintf），并檢查其返回值；讀取字符串時，使用strnlen函數限制讀取長度。若存在疑問，可先用memset函數初始化緩沖區，并在寫入數據后，斷言緩沖區的最后一個字節為 0。經驗法則：如果統計了字符個數，就要加 1；如果沒統計，那你就得問問自己為什么了。

2.  有符號 / 無符號類型混用：讓 - 1 變成 40 億

你將一個int類型變量（比如某個函數返回的錯誤碼 - 1）與size_t類型變量（數組長度）進行比較，此時編譯器會將int類型提升為無符號類型 —— 沒錯！這正是 C 語言標準規定的行為。這么一來，原本的 - 1 就搖身一變成了 4294967295，你所做的邊界檢查形同虛設，直接為程序崩潰敞開了大門（見圖 2）。

圖 2 有符號 / 無符號類型混用示例：讓 - 1 引發 40 億量級的問題

這類問題同樣具有確定性和可復現性，而且隱蔽性極強。修復方案：全程使用size_t類型表示尺寸和索引；僅在 API 接口處使用顯式的窄化類型轉換；通過獨立的渠道（比如專門的返回碼）傳遞錯誤信息，而非用負數作為無效的長度值；開啟編譯器的-Wsign-compare警告選項。若確實需要混用類型，務必先進行標準化處理 —— 在轉換為size_t類型前，驗證數值是否大于等于 0，并通過斷言來確認你的假設。另外，千萬要重視編譯器給出的警告信息，這些警告其實就是潛伏的漏洞，隨時可能 “反噬” 你！

3.  誤以為strncpy函數 “絕對安全”，最終導致未終止字符串被投入使用

strncpy函數看似是編程路上的 “救生衣”，但你遲早會發現：當源字符串過長時，它并不會保證目標字符串以結束符結尾（見圖 3）。你以為得到了一個 “安全” 的緩沖區，結果里面的數據打印出來全是亂碼，解析器無法識別，strcmp函數也無法正常工作。更糟的是，當源字符串較短時，strncpy會用 0 填充緩沖區剩余空間，造成算力浪費。

圖 3 誤用strncpy函數示例：誤以為其 “安全”，最終導致未終止字符串問題

正確做法：如果需要在截斷字符串的同時保證其以結束符結尾，請使用snprintf函數（并檢查返回值）。若必須使用strncpy，則要在調用后立即手動添加結束符：buf[n-1] = '