：從零手寫Web接口，替代Spring Boot的輕量方案)
簡介這是一份面向C網(wǎng)絡(luò)編程學(xué)習(xí)者與Web開發(fā)歷史研究者的C CGI庫源碼資源作者windawn。庫內(nèi)封裝了CGI請求解析、字符串處理、MySQL數(shù)據(jù)庫訪問與Socket通信等模塊核心類包括CGI、MySQLConnection、StringUtil與Socket可用于構(gòu)建動態(tài)網(wǎng)頁、后臺管理系統(tǒng)等場景幫助開發(fā)者理解早期Web服務(wù)的底層實現(xiàn)路徑。資源包共49個文件以17個cpp源文件與17個h頭文件為主體另含4個makefile構(gòu)建腳本及若干備份與輔助文件壓縮包約43KB目錄按libutils、libtcp、libcgi等模塊劃分結(jié)構(gòu)清晰便于按需查閱。目前已有324人學(xué)習(xí)下載。通過閱讀源碼讀者可掌握查詢字符串解析、HTML拼接、數(shù)據(jù)庫連接管理、Socket收發(fā)響應(yīng)等具體實現(xiàn)思路并對照Makefile理解多模塊編譯組織方式適合希望深入C網(wǎng)絡(luò)編程或探究CGI技術(shù)演進的開發(fā)者參考。1. 一個C CGI庫從零手寫Web接口的另一種選擇如果你現(xiàn)在要寫一個Web接口第一反應(yīng)大概是上Spring Boot或者Flask。但有些場景偏偏不能這么干——比如嵌入式設(shè)備上跑一個配置頁面或者給一個已經(jīng)用C寫好的計算引擎套一層HTTP殼子。這時候引入一整套Web框架光是依賴就能把編譯時間拉長好幾倍。我最近拆的這個C CGI庫走的是完全不同的路子它不依賴任何Web框架直接實現(xiàn)CGI協(xié)議把HTTP請求解析成C里的環(huán)境變量和標準輸入你只需要寫一個main函數(shù)從環(huán)境變量里讀參數(shù)、往標準輸出里寫HTML一個接口就成了。整個庫的核心代碼量不大編譯出來就是一個可執(zhí)行文件扔進cgi-bin目錄就能跑。適合誰適合那些需要在C項目里快速暴露HTTP接口、又不想引入重型依賴的開發(fā)者尤其是嵌入式、邊緣計算、或者老系統(tǒng)改造的場景。2. 核心架構(gòu)拆解CGI協(xié)議怎么在C里落地2.1 請求解析從環(huán)境變量到C對象CGI協(xié)議的核心思路很樸素Web服務(wù)器比如Apache、Nginx收到HTTP請求后把請求方法、路徑、查詢字符串、請求頭這些信息塞進環(huán)境變量然后啟動一個CGI進程把請求體通過標準輸入傳進去。CGI進程處理完把響應(yīng)頭和響應(yīng)體寫到標準輸出服務(wù)器再轉(zhuǎn)發(fā)給客戶端。這個庫要做的第一件事就是把那些散落在environ里的環(huán)境變量收攏成一個結(jié)構(gòu)體。常見做法是定義一個Request類在構(gòu)造函數(shù)里遍歷environ把REQUEST_METHOD、QUERY_STRING、CONTENT_LENGTH、CONTENT_TYPE這些關(guān)鍵字段提取出來。// request.h class Request { public: std::string method; // GET / POST std::string queryString; // URL 里的 ? 后面那串 std::string contentType; // application/x-www-form-urlencoded 或 multipart/form-data std::string body; // POST 請求體 Request() { // 從環(huán)境變量里抓請求方法 const char* m getenv(REQUEST_METHOD); method m ? m : GET; // 查詢字符串GET 請求的參數(shù)都在這里 const char* qs getenv(QUERY_STRING); queryString qs ? qs : ; // 內(nèi)容類型POST 請求靠它判斷怎么解析 body const char* ct getenv(CONTENT_TYPE); contentType ct ? ct : ; // 讀取標準輸入拿到 POST 的請求體 const char* lenStr getenv(CONTENT_LENGTH); if (lenStr) { int len std::atoi(lenStr); if (len 0) { body.resize(len); std::cin.read(body[0], len); } } } };這段代碼里有兩個點值得注意。第一CONTENT_LENGTH必須判斷是否存在因為GET請求沒有請求體這個環(huán)境變量可能壓根不存在。第二std::cin.read讀取的是二進制數(shù)據(jù)不能用操作符否則遇到空格就斷了。參數(shù)說明method決定后續(xù)走GET還是POST分支queryString是原始字符串需要進一步解析成鍵值對body在POST場景下才有效。2.2 參數(shù)解析查詢字符串與表單數(shù)據(jù)拿到queryString和body之后下一步是解析成keyvalue的形式。GET請求的參數(shù)在queryString里格式是name張三age25POST請求如果是application/x-www-form-urlencoded格式一樣只是數(shù)據(jù)在body里。解析邏輯不復(fù)雜按分割再按分割注意URL解碼。URL解碼要處理%XX和號號在查詢字符串里代表空格。// 解析 keyvaluekey2value2 格式 std::mapstd::string, std::string parseParams(const std::string data) { std::mapstd::string, std::string params; std::stringstream ss(data); std::string pair; while (std::getline(ss, pair, )) { auto pos pair.find(); if (pos std::string::npos) continue; std::string key urlDecode(pair.substr(0, pos)); std::string value urlDecode(pair.substr(pos 1)); params[key] value; } return params; } // URL 解碼%XX 轉(zhuǎn)字符 轉(zhuǎn)空格 std::string urlDecode(const std::string str) { std::string result; for (size_t i 0; i str.size(); i) { if (str[i] ) { result ; } else if (str[i] % i 2 str.size()) { int hex; std::stringstream ss; ss std::hex str.substr(i 1, 2); ss hex; result static_castchar(hex); i 2; } else { result str[i]; } } return result; }這里有個容易翻車的地方%后面必須跟兩個十六進制字符如果請求里出現(xiàn)單獨的%substr會越界。我一般會在解碼前先檢查i 2 str.size()不滿足就原樣輸出。另外std::map會自動按key排序如果業(yè)務(wù)對參數(shù)順序有要求得換成std::vectorstd::pair...。2.3 響應(yīng)構(gòu)造從標準輸出到HTTP響應(yīng)CGI進程的輸出必須遵循固定格式先輸出Content-Type頭再輸出一個空行然后是響應(yīng)體。這個庫通常會封裝一個Response類提供setHeader、write、redirect這些方法最后在析構(gòu)或者顯式調(diào)用flush的時候統(tǒng)一輸出。// response.h class Response { public: void setHeader(const std::string key, const std::string value) { headers[key] value; } void write(const std::string content) { body content; } void redirect(const std::string url) { setHeader(Location, url); statusCode 302; } void flush() { // 狀態(tài)行CGI 里通常寫 Status: 200 OK if (statusCode ! 200) { std::cout Status: statusCode OK\r\n; } // 默認 Content-Type if (headers.find(Content-Type) headers.end()) { headers[Content-Type] text/html; charsetutf-8; } for (auto kv : headers) { std::cout kv.first : kv.second \r\n; } std::cout \r\n; // 空行分隔頭和體 std::cout body; } private: std::mapstd::string, std::string headers; std::string body; int statusCode 200; };注意\r\n不能寫成\n有些Web服務(wù)器對換行符敏感用\n可能導(dǎo)致響應(yīng)頭解析失敗。另外Status頭只在非200的時候需要顯式寫200是默認值。Content-Type如果不設(shè)置瀏覽器可能把HTML當純文本渲染中文還會亂碼所以默認給text/html; charsetutf-8比較穩(wěn)妥。3. 編譯與部署讓CGI程序在服務(wù)器上跑起來3.1 編譯參數(shù)與依賴管理這個庫本身沒有第三方依賴只需要C標準庫。編譯命令很直接g -stdc11 -O2 -o hello.cgi hello.cpp request.cpp response.cpp-stdc11是底線因為用到了std::map的初始化列表和auto。-O2優(yōu)化在嵌入式場景下建議加上CGI進程每次請求都要啟動一次啟動速度直接影響響應(yīng)時間。如果目標機器是ARM架構(gòu)交叉編譯的時候記得加-static避免動態(tài)庫缺失導(dǎo)致CGI進程啟動失敗。常見做法是把編譯產(chǎn)物直接放到Web服務(wù)器的cgi-bin目錄下。以Nginx為例需要配置fastcgi_pass或者用fcgiwrap來轉(zhuǎn)發(fā)CGI請求。Apache的話ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/這一行就夠了。3.2 一個完整的Hello World示例把前面的Request和Response串起來一個最小的CGI程序長這樣// hello.cpp #include request.h #include response.h int main() { Request req; Response res; // 解析 GET 參數(shù) auto params parseParams(req.queryString); res.write(htmlbody); res.write(h1Hello, CGI!/h1); if (params.count(name)) { res.write(p你好, params[name] /p); } else { res.write(p請傳入 name 參數(shù)/p); } res.write(/body/html); res.flush(); return 0; }編譯后放到cgi-bin目錄訪問http://your-server/cgi-bin/hello.cgi?name張三就能看到頁面輸出。這個例子雖然簡單但已經(jīng)覆蓋了CGI的核心鏈路環(huán)境變量讀取、參數(shù)解析、響應(yīng)輸出。3.3 調(diào)試技巧日志往哪寫CGI程序的標準輸出被Web服務(wù)器拿走了所以std::cout不能用來打日志。調(diào)試信息只能往標準錯誤寫或者寫文件。// 調(diào)試日志寫到 stderrWeb 服務(wù)器通常會記錄到 error_log std::cerr [DEBUG] method req.method query req.queryString std::endl;如果服務(wù)器配置了error_log這些信息會出現(xiàn)在日志里。另一個辦法是寫臨時文件但要注意權(quán)限問題——CGI進程通常以www-data或nobody用戶運行寫/tmp一般沒問題寫其他目錄可能被拒。4. 避坑與常見問題排查4.1 中文亂碼Content-Type 和 URL 編碼的雙重坑現(xiàn)象頁面上的中文顯示成亂碼或者參數(shù)里的中文變成%E5%BC%A0%E4%B8%89。原因兩個地方可能出問題。一是Content-Type沒指定charsetutf-8瀏覽器按默認編碼解析二是URL編碼沒解碼參數(shù)值還是原始百分號形式。解決響應(yīng)頭里強制寫Content-Type: text/html; charsetutf-8參數(shù)解析時走一遍urlDecode。如果用的是std::cout輸出中文確保源文件保存為UTF-8編譯時不需要額外加-finput-charset但有些老編譯器默認GBK那就得顯式指定。4.2 POST 請求體讀不全CONTENT_LENGTH 的陷阱現(xiàn)象POST請求提交的表單數(shù)據(jù)只讀到一半或者干脆是空的。原因CONTENT_LENGTH環(huán)境變量在某些服務(wù)器配置下可能不存在或者值不對。另外std::cin默認是文本模式遇到\r\n會轉(zhuǎn)換讀二進制數(shù)據(jù)要用std::cin.read。解決先判斷CONTENT_LENGTH是否存在不存在就按0處理。讀取的時候用read而不是getline。如果數(shù)據(jù)量特別大比如文件上傳要考慮分塊讀取避免一次性分配太大內(nèi)存。4.3 CGI 進程啟動失敗權(quán)限與路徑問題現(xiàn)象瀏覽器返回500錯誤服務(wù)器日志顯示Permission denied或No such file or directory。原因CGI文件沒有執(zhí)行權(quán)限或者路徑配置不對。Web服務(wù)器通常以低權(quán)限用戶運行如果CGI文件在用戶主目錄下可能沒有執(zhí)行權(quán)限。解決chmod x hello.cgi給執(zhí)行權(quán)限。路徑方面Apache的ScriptAlias和Nginx的fastcgi_param SCRIPT_FILENAME都要指向正確的絕對路徑。另外SELinux開啟的情況下CGI文件需要打上httpd_sys_script_exec_t標簽這個坑在CentOS上特別常見。4.4 并發(fā)性能CGI 的天然短板現(xiàn)象并發(fā)請求一多響應(yīng)時間直線上升CPU占用飆升。原因CGI是“一個請求一個進程”的模型每個請求都要fork一個新進程進程創(chuàng)建和銷毀的開銷在高并發(fā)下非常明顯。解決如果并發(fā)量確實大可以考慮FastCGI——它讓進程常駐避免反復(fù)fork。但這個庫本身是CGI實現(xiàn)要上FastCGI得換一套接口。另一個思路是在前面加一層Nginx緩存把不常變的頁面緩存住減少CGI進程啟動次數(shù)。我一般會在壓測階段用ab或wrk跑一下看看QPS能不能接受不能接受就得上FastCGI或者換方案。5. 二次開發(fā)從能跑到好用的改造思路這個庫的代碼量不大正好適合拿來練手或者按自己的需求改造。我一般會從三個方向下手。第一個方向是路由系統(tǒng)。原生的CGI程序靠文件名區(qū)分接口hello.cgi、user.cgi、login.cgi各是一個可執(zhí)行文件。接口一多編譯產(chǎn)物就散得到處都是。改造思路是只保留一個入口index.cgi在里面根據(jù)PATH_INFO或者QUERY_STRING里的action參數(shù)做路由分發(fā)。比如/cgi-bin/index.cgi?actionuser.list在main函數(shù)里解析action然后調(diào)用對應(yīng)的處理函數(shù)。這樣編譯產(chǎn)物只有一個部署和升級都方便。// 簡易路由分發(fā) std::string action params[action]; if (action user.list) { handleUserList(req, res); } else if (action user.detail) { handleUserDetail(req, res); } else { res.setHeader(Status, 404 Not Found); res.write(h1404/h1); }第二個方向是模板渲染。直接在C代碼里拼HTML字符串短頁面還行頁面一復(fù)雜就變成字符串地獄。常見做法是引入一個輕量級模板引擎比如inja或者自己寫一個簡單的占位符替換。模板文件放在templates/目錄下運行時讀取、替換變量、輸出。這樣前端和后端能稍微解耦一點改樣式不用重新編譯C。第三個方向是JSON接口支持?，F(xiàn)在很多場景不需要返回HTML而是返回JSON給前端框架用。改造起來很簡單把Content-Type設(shè)成application/json然后手寫一個極簡的JSON序列化函數(shù)把std::map轉(zhuǎn)成JSON字符串。注意轉(zhuǎn)義雙引號和反斜杠中文不需要轉(zhuǎn)義成\uXXXX直接輸出UTF-8就行。std::string toJson(const std::mapstd::string, std::string data) { std::string json {; bool first true; for (auto kv : data) { if (!first) json ,; json \ escapeJson(kv.first) \:\ escapeJson(kv.second) \; first false; } json }; return json; }驗證改造效果的方法也很直接寫一個test.cgi用curl發(fā)請求看返回的JSON能不能被jq解析。curl -s http://localhost/cgi-bin/index.cgi?actionuser.list | jq .如果能正常格式化輸出說明JSON結(jié)構(gòu)沒問題。從那以后我每次改完CGI程序都強制走一遍“curl測接口 → 瀏覽器看頁面 → 看error_log”這三步少一步都可能漏掉編碼或者權(quán)限的坑。希望幫到你。本文還有配套的精品資源點擊獲取 C++ CGI庫實戰(zhàn)：從零手寫Web接口，替代Spring Boot的輕量方案
簡介這是一份面向C網(wǎng)絡(luò)編程學(xué)習(xí)者與Web開發(fā)歷史研究者的C CGI庫源碼資源作者windawn。庫內(nèi)封裝了CGI請求解析、字符串處理、MySQL數(shù)據(jù)庫訪問與Socket通信等模塊核心類包括CGI、MySQLConnection、StringUtil與Socket可用于構(gòu)建動態(tài)網(wǎng)頁、后臺管理系統(tǒng)等場景幫助開發(fā)者理解早期Web服務(wù)的底層實現(xiàn)路徑。資源包共49個文件以17個cpp源文件與17個h頭文件為主體另含4個makefile構(gòu)建腳本及若干備份與輔助文件壓縮包約43KB目錄按libutils、libtcp、libcgi等模塊劃分結(jié)構(gòu)清晰便于按需查閱。目前已有324人學(xué)習(xí)下載。通過閱讀源碼讀者可掌握查詢字符串解析、HTML拼接、數(shù)據(jù)庫連接管理、Socket收發(fā)響應(yīng)等具體實現(xiàn)思路并對照Makefile理解多模塊編譯組織方式適合希望深入C網(wǎng)絡(luò)編程或探究CGI技術(shù)演進的開發(fā)者參考。1. 一個C CGI庫從零手寫Web接口的另一種選擇如果你現(xiàn)在要寫一個Web接口第一反應(yīng)大概是上Spring Boot或者Flask。但有些場景偏偏不能這么干——比如嵌入式設(shè)備上跑一個配置頁面或者給一個已經(jīng)用C寫好的計算引擎套一層HTTP殼子。這時候引入一整套Web框架光是依賴就能把編譯時間拉長好幾倍。我最近拆的這個C CGI庫走的是完全不同的路子它不依賴任何Web框架直接實現(xiàn)CGI協(xié)議把HTTP請求解析成C里的環(huán)境變量和標準輸入你只需要寫一個main函數(shù)從環(huán)境變量里讀參數(shù)、往標準輸出里寫HTML一個接口就成了。整個庫的核心代碼量不大編譯出來就是一個可執(zhí)行文件扔進cgi-bin目錄就能跑。適合誰適合那些需要在C項目里快速暴露HTTP接口、又不想引入重型依賴的開發(fā)者尤其是嵌入式、邊緣計算、或者老系統(tǒng)改造的場景。2. 核心架構(gòu)拆解CGI協(xié)議怎么在C里落地2.1 請求解析從環(huán)境變量到C對象CGI協(xié)議的核心思路很樸素Web服務(wù)器比如Apache、Nginx收到HTTP請求后把請求方法、路徑、查詢字符串、請求頭這些信息塞進環(huán)境變量然后啟動一個CGI進程把請求體通過標準輸入傳進去。CGI進程處理完把響應(yīng)頭和響應(yīng)體寫到標準輸出服務(wù)器再轉(zhuǎn)發(fā)給客戶端。這個庫要做的第一件事就是把那些散落在environ里的環(huán)境變量收攏成一個結(jié)構(gòu)體。常見做法是定義一個Request類在構(gòu)造函數(shù)里遍歷environ把REQUEST_METHOD、QUERY_STRING、CONTENT_LENGTH、CONTENT_TYPE這些關(guān)鍵字段提取出來。// request.h class Request { public: std::string method; // GET / POST std::string queryString; // URL 里的 ? 后面那串 std::string contentType; // application/x-www-form-urlencoded 或 multipart/form-data std::string body; // POST 請求體 Request() { // 從環(huán)境變量里抓請求方法 const char* m getenv(REQUEST_METHOD); method m ? m : GET; // 查詢字符串GET 請求的參數(shù)都在這里 const char* qs getenv(QUERY_STRING); queryString qs ? qs : ; // 內(nèi)容類型POST 請求靠它判斷怎么解析 body const char* ct getenv(CONTENT_TYPE); contentType ct ? ct : ; // 讀取標準輸入拿到 POST 的請求體 const char* lenStr getenv(CONTENT_LENGTH); if (lenStr) { int len std::atoi(lenStr); if (len 0) { body.resize(len); std::cin.read(body[0], len); } } } };這段代碼里有兩個點值得注意。第一CONTENT_LENGTH必須判斷是否存在因為GET請求沒有請求體這個環(huán)境變量可能壓根不存在。第二std::cin.read讀取的是二進制數(shù)據(jù)不能用操作符否則遇到空格就斷了。參數(shù)說明method決定后續(xù)走GET還是POST分支queryString是原始字符串需要進一步解析成鍵值對body在POST場景下才有效。2.2 參數(shù)解析查詢字符串與表單數(shù)據(jù)拿到queryString和body之后下一步是解析成keyvalue的形式。GET請求的參數(shù)在queryString里格式是name張三age25POST請求如果是application/x-www-form-urlencoded格式一樣只是數(shù)據(jù)在body里。解析邏輯不復(fù)雜按分割再按分割注意URL解碼。URL解碼要處理%XX和號號在查詢字符串里代表空格。// 解析 keyvaluekey2value2 格式 std::mapstd::string, std::string parseParams(const std::string data) { std::mapstd::string, std::string params; std::stringstream ss(data); std::string pair; while (std::getline(ss, pair, )) { auto pos pair.find(); if (pos std::string::npos) continue; std::string key urlDecode(pair.substr(0, pos)); std::string value urlDecode(pair.substr(pos 1)); params[key] value; } return params; } // URL 解碼%XX 轉(zhuǎn)字符 轉(zhuǎn)空格 std::string urlDecode(const std::string str) { std::string result; for (size_t i 0; i str.size(); i) { if (str[i] ) { result ; } else if (str[i] % i 2 str.size()) { int hex; std::stringstream ss; ss std::hex str.substr(i 1, 2); ss hex; result static_castchar(hex); i 2; } else { result str[i]; } } return result; }這里有個容易翻車的地方%后面必須跟兩個十六進制字符如果請求里出現(xiàn)單獨的%substr會越界。我一般會在解碼前先檢查i 2 str.size()不滿足就原樣輸出。另外std::map會自動按key排序如果業(yè)務(wù)對參數(shù)順序有要求得換成std::vectorstd::pair...。2.3 響應(yīng)構(gòu)造從標準輸出到HTTP響應(yīng)CGI進程的輸出必須遵循固定格式先輸出Content-Type頭再輸出一個空行然后是響應(yīng)體。這個庫通常會封裝一個Response類提供setHeader、write、redirect這些方法最后在析構(gòu)或者顯式調(diào)用flush的時候統(tǒng)一輸出。// response.h class Response { public: void setHeader(const std::string key, const std::string value) { headers[key] value; } void write(const std::string content) { body content; } void redirect(const std::string url) { setHeader(Location, url); statusCode 302; } void flush() { // 狀態(tài)行CGI 里通常寫 Status: 200 OK if (statusCode ! 200) { std::cout Status: statusCode OK\r\n; } // 默認 Content-Type if (headers.find(Content-Type) headers.end()) { headers[Content-Type] text/html; charsetutf-8; } for (auto kv : headers) { std::cout kv.first : kv.second \r\n; } std::cout \r\n; // 空行分隔頭和體 std::cout body; } private: std::mapstd::string, std::string headers; std::string body; int statusCode 200; };注意\r\n不能寫成\n有些Web服務(wù)器對換行符敏感用\n可能導(dǎo)致響應(yīng)頭解析失敗。另外Status頭只在非200的時候需要顯式寫200是默認值。Content-Type如果不設(shè)置瀏覽器可能把HTML當純文本渲染中文還會亂碼所以默認給text/html; charsetutf-8比較穩(wěn)妥。3. 編譯與部署讓CGI程序在服務(wù)器上跑起來3.1 編譯參數(shù)與依賴管理這個庫本身沒有第三方依賴只需要C標準庫。編譯命令很直接g -stdc11 -O2 -o hello.cgi hello.cpp request.cpp response.cpp-stdc11是底線因為用到了std::map的初始化列表和auto。-O2優(yōu)化在嵌入式場景下建議加上CGI進程每次請求都要啟動一次啟動速度直接影響響應(yīng)時間。如果目標機器是ARM架構(gòu)交叉編譯的時候記得加-static避免動態(tài)庫缺失導(dǎo)致CGI進程啟動失敗。常見做法是把編譯產(chǎn)物直接放到Web服務(wù)器的cgi-bin目錄下。以Nginx為例需要配置fastcgi_pass或者用fcgiwrap來轉(zhuǎn)發(fā)CGI請求。Apache的話ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/這一行就夠了。3.2 一個完整的Hello World示例把前面的Request和Response串起來一個最小的CGI程序長這樣// hello.cpp #include request.h #include response.h int main() { Request req; Response res; // 解析 GET 參數(shù) auto params parseParams(req.queryString); res.write(htmlbody); res.write(h1Hello, CGI!/h1); if (params.count(name)) { res.write(p你好, params[name] /p); } else { res.write(p請傳入 name 參數(shù)/p); } res.write(/body/html); res.flush(); return 0; }編譯后放到cgi-bin目錄訪問http://your-server/cgi-bin/hello.cgi?name張三就能看到頁面輸出。這個例子雖然簡單但已經(jīng)覆蓋了CGI的核心鏈路環(huán)境變量讀取、參數(shù)解析、響應(yīng)輸出。3.3 調(diào)試技巧日志往哪寫CGI程序的標準輸出被Web服務(wù)器拿走了所以std::cout不能用來打日志。調(diào)試信息只能往標準錯誤寫或者寫文件。// 調(diào)試日志寫到 stderrWeb 服務(wù)器通常會記錄到 error_log std::cerr [DEBUG] method req.method query req.queryString std::endl;如果服務(wù)器配置了error_log這些信息會出現(xiàn)在日志里。另一個辦法是寫臨時文件但要注意權(quán)限問題——CGI進程通常以www-data或nobody用戶運行寫/tmp一般沒問題寫其他目錄可能被拒。4. 避坑與常見問題排查4.1 中文亂碼Content-Type 和 URL 編碼的雙重坑現(xiàn)象頁面上的中文顯示成亂碼或者參數(shù)里的中文變成%E5%BC%A0%E4%B8%89。原因兩個地方可能出問題。一是Content-Type沒指定charsetutf-8瀏覽器按默認編碼解析二是URL編碼沒解碼參數(shù)值還是原始百分號形式。解決響應(yīng)頭里強制寫Content-Type: text/html; charsetutf-8參數(shù)解析時走一遍urlDecode。如果用的是std::cout輸出中文確保源文件保存為UTF-8編譯時不需要額外加-finput-charset但有些老編譯器默認GBK那就得顯式指定。4.2 POST 請求體讀不全CONTENT_LENGTH 的陷阱現(xiàn)象POST請求提交的表單數(shù)據(jù)只讀到一半或者干脆是空的。原因CONTENT_LENGTH環(huán)境變量在某些服務(wù)器配置下可能不存在或者值不對。另外std::cin默認是文本模式遇到\r\n會轉(zhuǎn)換讀二進制數(shù)據(jù)要用std::cin.read。解決先判斷CONTENT_LENGTH是否存在不存在就按0處理。讀取的時候用read而不是getline。如果數(shù)據(jù)量特別大比如文件上傳要考慮分塊讀取避免一次性分配太大內(nèi)存。4.3 CGI 進程啟動失敗權(quán)限與路徑問題現(xiàn)象瀏覽器返回500錯誤服務(wù)器日志顯示Permission denied或No such file or directory。原因CGI文件沒有執(zhí)行權(quán)限或者路徑配置不對。Web服務(wù)器通常以低權(quán)限用戶運行如果CGI文件在用戶主目錄下可能沒有執(zhí)行權(quán)限。解決chmod x hello.cgi給執(zhí)行權(quán)限。路徑方面Apache的ScriptAlias和Nginx的fastcgi_param SCRIPT_FILENAME都要指向正確的絕對路徑。另外SELinux開啟的情況下CGI文件需要打上httpd_sys_script_exec_t標簽這個坑在CentOS上特別常見。4.4 并發(fā)性能CGI 的天然短板現(xiàn)象并發(fā)請求一多響應(yīng)時間直線上升CPU占用飆升。原因CGI是“一個請求一個進程”的模型每個請求都要fork一個新進程進程創(chuàng)建和銷毀的開銷在高并發(fā)下非常明顯。解決如果并發(fā)量確實大可以考慮FastCGI——它讓進程常駐避免反復(fù)fork。但這個庫本身是CGI實現(xiàn)要上FastCGI得換一套接口。另一個思路是在前面加一層Nginx緩存把不常變的頁面緩存住減少CGI進程啟動次數(shù)。我一般會在壓測階段用ab或wrk跑一下看看QPS能不能接受不能接受就得上FastCGI或者換方案。5. 二次開發(fā)從能跑到好用的改造思路這個庫的代碼量不大正好適合拿來練手或者按自己的需求改造。我一般會從三個方向下手。第一個方向是路由系統(tǒng)。原生的CGI程序靠文件名區(qū)分接口hello.cgi、user.cgi、login.cgi各是一個可執(zhí)行文件。接口一多編譯產(chǎn)物就散得到處都是。改造思路是只保留一個入口index.cgi在里面根據(jù)PATH_INFO或者QUERY_STRING里的action參數(shù)做路由分發(fā)。比如/cgi-bin/index.cgi?actionuser.list在main函數(shù)里解析action然后調(diào)用對應(yīng)的處理函數(shù)。這樣編譯產(chǎn)物只有一個部署和升級都方便。// 簡易路由分發(fā) std::string action params[action]; if (action user.list) { handleUserList(req, res); } else if (action user.detail) { handleUserDetail(req, res); } else { res.setHeader(Status, 404 Not Found); res.write(h1404/h1); }第二個方向是模板渲染。直接在C代碼里拼HTML字符串短頁面還行頁面一復(fù)雜就變成字符串地獄。常見做法是引入一個輕量級模板引擎比如inja或者自己寫一個簡單的占位符替換。模板文件放在templates/目錄下運行時讀取、替換變量、輸出。這樣前端和后端能稍微解耦一點改樣式不用重新編譯C。第三個方向是JSON接口支持?，F(xiàn)在很多場景不需要返回HTML而是返回JSON給前端框架用。改造起來很簡單把Content-Type設(shè)成application/json然后手寫一個極簡的JSON序列化函數(shù)把std::map轉(zhuǎn)成JSON字符串。注意轉(zhuǎn)義雙引號和反斜杠中文不需要轉(zhuǎn)義成\uXXXX直接輸出UTF-8就行。std::string toJson(const std::mapstd::string, std::string data) { std::string json {; bool first true; for (auto kv : data) { if (!first) json ,; json \ escapeJson(kv.first) \:\ escapeJson(kv.second) \; first false; } json }; return json; }驗證改造效果的方法也很直接寫一個test.cgi用curl發(fā)請求看返回的JSON能不能被jq解析。curl -s http://localhost/cgi-bin/index.cgi?actionuser.list | jq .如果能正常格式化輸出說明JSON結(jié)構(gòu)沒問題。從那以后我每次改完CGI程序都強制走一遍“curl測接口 → 瀏覽器看頁面 → 看error_log”這三步少一步都可能漏掉編碼或者權(quán)限的坑。希望幫到你。本文還有配套的精品資源點擊獲取