簡(jiǎn)介本資源是一套基于Delphi 12.3開(kāi)發(fā)的HTTP服務(wù)端與POST請(qǐng)求處理的完整示例工程面向Delphi中高級(jí)開(kāi)發(fā)者適用于構(gòu)建輕量級(jí)本地API服務(wù)、嵌入式Web接口或IoT設(shè)備通信模塊等場(chǎng)景。壓縮包共含16個(gè)文件涵蓋可執(zhí)行程序2個(gè)exe、核心單元源碼pas/ddp/dfm、編譯產(chǎn)物dcu、項(xiàng)目配置cfg/dof/dpr、資源文件res及XML配置文檔全面覆蓋從設(shè)計(jì)、編碼、編譯到運(yùn)行的全鏈路開(kāi)發(fā)要素。資源大小為37.23MB結(jié)構(gòu)清晰便于快速理解TIdHTTPServer組件在Delphi 12中的實(shí)際集成方式與POST數(shù)據(jù)解析邏輯。已有45人學(xué)習(xí)下載讀者可直接運(yùn)行示例程序觀察HTTP服務(wù)啟動(dòng)、路由響應(yīng)及文件接收行為并通過(guò)源碼深入掌握請(qǐng)求體解析、JSON/Form數(shù)據(jù)提取、異常處理及跨版本兼容性適配等關(guān)鍵實(shí)踐細(xì)節(jié)。1. 項(xiàng)目背景與核心價(jià)值最近在整理一個(gè)遺留的Delphi項(xiàng)目需要實(shí)現(xiàn)一個(gè)輕量級(jí)的HTTP服務(wù)端用來(lái)接收一些設(shè)備上報(bào)的數(shù)據(jù)。一開(kāi)始想著用現(xiàn)成的框架但考慮到部署環(huán)境的復(fù)雜性和對(duì)性能的極致要求最終還是決定回歸Delphi用自帶的THttpServer控件來(lái)搭建。這個(gè)決定讓我重新審視了Delphi 12.3在Web服務(wù)開(kāi)發(fā)上的能力特別是處理HTTP POST請(qǐng)求這個(gè)看似基礎(chǔ)、實(shí)則暗藏玄機(jī)的環(huán)節(jié)。網(wǎng)上關(guān)于Delphi HttpServer的資料要么是遠(yuǎn)古版本的要么語(yǔ)焉不詳尤其是處理表單數(shù)據(jù)、JSON POST這些現(xiàn)代Web交互時(shí)總感覺(jué)缺了臨門(mén)一腳的示例。所以我把這次實(shí)戰(zhàn)中搭建的HttpServer服務(wù)端以及配套的、用于測(cè)試各種POST請(qǐng)求的客戶端源代碼打包成了一個(gè)資源包。這個(gè)包的核心價(jià)值在于它不是一個(gè)簡(jiǎn)單的“Hello World”演示而是一個(gè)可直接用于生產(chǎn)環(huán)境參考的、處理了多種POST數(shù)據(jù)格式的完整范例。無(wú)論是處理application/x-www-form-urlencoded表單、multipart/form-data文件上傳還是解析application/json的RESTful API請(qǐng)求你都能在里面找到清晰的實(shí)現(xiàn)路徑和避坑指南。對(duì)于還在使用Delphi進(jìn)行工業(yè)控制、數(shù)據(jù)采集、內(nèi)部工具開(kāi)發(fā)的同行來(lái)說(shuō)這能省去大量重復(fù)造輪子和調(diào)試協(xié)議的時(shí)間。2. Delphi 12.3 THttpServer控件深度解析Delphi的THttpServer控件位于System.Net.HttpServer單元它是一個(gè)基于事件驅(qū)動(dòng)的、阻塞式的HTTP/1.1服務(wù)器實(shí)現(xiàn)。很多人一聽(tīng)到“阻塞式”就覺(jué)得性能不行這其實(shí)是個(gè)誤解。在連接數(shù)可控、追求極致穩(wěn)定和低延遲的工業(yè)或內(nèi)部應(yīng)用場(chǎng)景中這種簡(jiǎn)單的模型反而更可靠資源消耗也更可預(yù)測(cè)。2.1 核心架構(gòu)與工作模式THttpServer的核心是OnCommandGet和OnCommandOther事件。在早期版本通常用OnCommandGet處理GET請(qǐng)求用OnCommandOther處理POST等其他方法。但在Delphi 12.3中更推薦的做法是主要使用OnCommandOther事件并在其內(nèi)部根據(jù)ARequest.Method方法來(lái)區(qū)分GET、POST等所有HTTP動(dòng)詞。這樣做的好處是邏輯統(tǒng)一便于管理。它的工作線程模型是每個(gè)接入的客戶端連接服務(wù)器會(huì)為其分配一個(gè)獨(dú)立的工作線程。該線程會(huì)一直阻塞直到處理完當(dāng)前請(qǐng)求并返回響應(yīng)或者連接超時(shí)。這意味著如果你的某個(gè)請(qǐng)求處理函數(shù)非常耗時(shí)它會(huì)獨(dú)占一個(gè)線程導(dǎo)致該線程無(wú)法處理其他連接。因此關(guān)鍵的設(shè)計(jì)原則是在OnCommandOther事件處理函數(shù)中邏輯應(yīng)盡可能快速避免長(zhǎng)時(shí)間操作。對(duì)于耗時(shí)的任務(wù)如復(fù)雜的數(shù)據(jù)庫(kù)查詢、文件處理應(yīng)該將其放入隊(duì)列由后臺(tái)線程異步處理然后通過(guò)回調(diào)或狀態(tài)查詢的方式返回結(jié)果。2.2 關(guān)鍵屬性與實(shí)戰(zhàn)配置創(chuàng)建一個(gè)穩(wěn)定可用的HttpServer以下屬性的配置至關(guān)重要// 創(chuàng)建服務(wù)器實(shí)例 FHttpServer : THttpServer.Create(nil); try with FHttpServer do begin // 綁定地址和端口。0.0.0.0表示監(jiān)聽(tīng)所有網(wǎng)絡(luò)接口 Bindings.Add(0.0.0.0, 8080); // 服務(wù)器名稱會(huì)出現(xiàn)在HTTP響應(yīng)頭Server字段中可自定義或留空 ServerName : MyDelphiServer/1.0; // 連接超時(shí)時(shí)間毫秒。客戶端在此時(shí)間內(nèi)未發(fā)送請(qǐng)求連接將被關(guān)閉。 // 對(duì)于設(shè)備上報(bào)場(chǎng)景不宜設(shè)置過(guò)短建議30-60秒。 ConnectionTimeout : 30000; // 請(qǐng)求體最大尺寸字節(jié)。這是防止惡意超大請(qǐng)求導(dǎo)致內(nèi)存溢出的關(guān)鍵 // 必須根據(jù)業(yè)務(wù)需求明確設(shè)置。例如文件上傳設(shè)為50MB50 * 1024 * 1024 MaxRequestBodySize : 52428800; // 啟用線程池管理推薦。True時(shí)服務(wù)器會(huì)復(fù)用已完成任務(wù)的線程提升性能。 UseThreadPool : True; // 線程池最小和最大線程數(shù)。需要根據(jù)預(yù)期的并發(fā)量調(diào)整。 // 初始值可以設(shè)為CPU核心數(shù)最大值為預(yù)期最大并發(fā)數(shù)但不宜過(guò)高。 ThreadPoolSize : TThreadPoolSize.Create(4, 50); // 注冊(cè)請(qǐng)求處理事件 OnCommandOther : HandleCommandOther; // 也可以選擇性處理異常請(qǐng)求 OnException : HandleServerException; Active : True; // 啟動(dòng)服務(wù)器 end; except on E: Exception do Log(服務(wù)器啟動(dòng)失敗: E.Message); end;這里最容易踩坑的就是MaxRequestBodySize。如果不設(shè)置默認(rèn)值可能很小一旦遇到上傳文件的POST請(qǐng)求服務(wù)器會(huì)直接返回413 Request Entity Too Large錯(cuò)誤。我一開(kāi)始就忘了設(shè)調(diào)試了半天才發(fā)現(xiàn)問(wèn)題根源。3. 全面攻克HTTP POST請(qǐng)求處理處理POST請(qǐng)求的難點(diǎn)不在于接收而在于如何正確、高效地解析出請(qǐng)求體Body中的數(shù)據(jù)。HTTP協(xié)議本身只負(fù)責(zé)傳輸字節(jié)流如何解讀這些字節(jié)流取決于Content-Type請(qǐng)求頭。我們的服務(wù)器必須能識(shí)別并處理常見(jiàn)的幾種類型。3.1 解析 application/x-www-form-urlencoded這是HTML表單默認(rèn)的提交格式數(shù)據(jù)格式為key1value1key2value2并且進(jìn)行了URL編碼。在THttpServer的事件參數(shù)中我們可以直接獲取到解析好的內(nèi)容。procedure TMainForm.HandleCommandOther(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo); var ParamValue: string; i: Integer; begin if ARequestInfo.Command POST then begin // 首先檢查Content-Type if Pos(application/x-www-form-urlencoded, ARequestInfo.ContentType) 0 then begin // 方式1通過(guò)Params屬性直接獲取已自動(dòng)解析 ParamValue : ARequestInfo.Params.Values[username]; if ParamValue then Log(收到用戶名Params: ParamValue); // 方式2遍歷所有參數(shù) Log(所有表單參數(shù):); for i : 0 to ARequestInfo.Params.Count - 1 do Log( ARequestInfo.Params.Names[i] ARequestInfo.Params.ValueFromIndex[i]); // 構(gòu)建響應(yīng) AResponseInfo.ContentText : {status: ok, message: Form data received.}; AResponseInfo.ContentType : application/json; AResponseInfo.ResponseNo : 200; // OK end; end; end;注意TIdHTTPRequestInfo.Params屬性在application/x-www-form-urlencoded類型下會(huì)自動(dòng)解析。但如果你同時(shí)處理GET和POST需要注意Params也會(huì)包含URL查詢字符串?后的參數(shù)。在純POST表單處理時(shí)這通常不是問(wèn)題。3.2 解析 application/json (RESTful API)這是目前前后端交互和物聯(lián)網(wǎng)設(shè)備上報(bào)最常用的格式。THttpServer不會(huì)自動(dòng)解析JSON我們需要從原始請(qǐng)求流中讀取。procedure TMainForm.HandleCommandOther(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo); var ContentStream: TStream; Bytes: TBytes; RawJson, DeviceID, SensorValue: string; JsonObj: TJSONObject; begin if (ARequestInfo.Command POST) and (Pos(application/json, ARequestInfo.ContentType) 0) then begin ContentStream : ARequestInfo.PostStream; if Assigned(ContentStream) then begin // 將流內(nèi)容讀取到字符串 SetLength(Bytes, ContentStream.Size); ContentStream.Position : 0; ContentStream.ReadBuffer(Bytes[0], ContentStream.Size); RawJson : TEncoding.UTF8.GetString(Bytes); try JsonObj : TJSONObject.ParseJSONValue(RawJson) as TJSONObject; if Assigned(JsonObj) then try DeviceID : JsonObj.GetValue(device_id).Value; SensorValue : JsonObj.GetValue(value).Value; Log(Format(設(shè)備%s上報(bào)數(shù)據(jù): %s, [DeviceID, SensorValue])); // 處理業(yè)務(wù)邏輯... // 返回JSON響應(yīng) AResponseInfo.ContentText : {code: 0, msg: success}; AResponseInfo.ContentType : application/json; AResponseInfo.ResponseNo : 200; finally JsonObj.Free; end else begin AResponseInfo.ContentText : {code: -1, msg: Invalid JSON}; AResponseInfo.ResponseNo : 400; // Bad Request end; except on E: Exception do begin Log(JSON解析異常: E.Message); AResponseInfo.ContentText : {code: -2, msg: Server error}; AResponseInfo.ResponseNo : 500; end; end; end; end; end;關(guān)鍵點(diǎn)流的位置PostStream在讀取前務(wù)必將其Position設(shè)置為0否則可能讀不到數(shù)據(jù)。編碼確保使用正確的編碼通常是UTF-8將字節(jié)流轉(zhuǎn)換為字符串。TEncoding.UTF8是最安全的選擇。異常處理JSON解析必須放在try...except塊中?？蛻舳丝赡馨l(fā)送非法JSON字符串導(dǎo)致解析崩潰進(jìn)而使整個(gè)工作線程異常退出這是服務(wù)器不穩(wěn)定的重要原因。內(nèi)存釋放TJSONObject等對(duì)象必須記得釋放否則會(huì)造成內(nèi)存泄漏。3.3 處理 multipart/form-data (文件上傳)文件上傳是最復(fù)雜的POST類型。數(shù)據(jù)被分成多個(gè)部分Part每個(gè)部分有自己的頭和體。Delphi的TIdHTTPRequestInfo提供了Files和Params屬性來(lái)簡(jiǎn)化處理但需要正確配置。procedure TMainForm.HandleCommandOther(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo); var i: Integer; UploadedFile: TIdHTTPUploadFile; SavePath, FieldName, FieldValue: string; SaveStream: TFileStream; begin if (ARequestInfo.Command POST) and (Pos(multipart/form-data, ARequestInfo.ContentType) 0) then begin // 1. 處理上傳的文件 Log(上傳文件列表:); for i : 0 to ARequestInfo.Files.Count - 1 do begin UploadedFile : ARequestInfo.Files[i]; Log(Format( 文件名: %s, 字段名: %s, 內(nèi)容類型: %s, 大小: %d bytes, [UploadedFile.FileName, UploadedFile.FieldName, UploadedFile.ContentType, UploadedFile.Stream.Size])); // 構(gòu)建保存路徑注意安全應(yīng)避免使用原始文件名防止路徑遍歷攻擊 SavePath : .\Uploads\ TPath.GetGUIDFileName(False) ExtractFileExt(UploadedFile.FileName); // 保存文件流 ForceDirectories(ExtractFilePath(SavePath)); SaveStream : TFileStream.Create(SavePath, fmCreate); try UploadedFile.Stream.Position : 0; SaveStream.CopyFrom(UploadedFile.Stream, UploadedFile.Stream.Size); finally SaveStream.Free; end; Log(文件已保存至: SavePath); end; // 2. 處理普通的表單字段 Log(普通表單字段:); for i : 0 to ARequestInfo.Params.Count - 1 do begin FieldName : ARequestInfo.Params.Names[i]; FieldValue : ARequestInfo.Params.ValueFromIndex[i]; // 注意這里獲取的Params可能也包含了文件字段的“文件名”信息但Files列表里的才是文件內(nèi)容。 // 通常我們以Files列表為準(zhǔn)。 if ARequestInfo.Files.FindByField(FieldName) nil then // 如果不是文件字段 Log( FieldName FieldValue); end; AResponseInfo.ContentText : {status: success, files_received: IntToStr(ARequestInfo.Files.Count) }; AResponseInfo.ContentType : application/json; AResponseInfo.ResponseNo : 200; end; end;文件上傳的深坑與解決方案內(nèi)存占用大文件上傳會(huì)完全載入內(nèi)存。務(wù)必設(shè)置合理的MaxRequestBodySize并在生產(chǎn)環(huán)境考慮流式處理到磁盤(pán)的方案但這需要更底層的套接字操作。文件名安全切勿直接使用客戶端提交的UploadedFile.FileName作為保存路徑這可能導(dǎo)致路徑遍歷攻擊如文件名包含..\windows\system32\cmd.exe。應(yīng)使用GUID或時(shí)間戳生成新文件名僅保留原擴(kuò)展名。臨時(shí)文件清理THttpServer或底層庫(kù)可能會(huì)生成臨時(shí)文件需要關(guān)注服務(wù)器運(yùn)行期間的磁盤(pán)空間。4. 配套POST測(cè)試客戶端設(shè)計(jì)與源碼解讀一個(gè)健壯的服務(wù)器離不開(kāi)全面的測(cè)試。我配套編寫(xiě)的測(cè)試客戶端不是一個(gè)簡(jiǎn)單的按鈕點(diǎn)擊而是一個(gè)支持多種POST格式、可自定義Header、能保存請(qǐng)求歷史的工具這對(duì)于調(diào)試API接口至關(guān)重要。4.1 客戶端核心功能模塊客戶端使用TIdHTTP組件發(fā)送請(qǐng)求主要包含以下功能URL與方法選擇支持輸入任意URL選擇GET或POST方法。請(qǐng)求體編輯器一個(gè)多行文本框用于直接輸入JSON、XML或表單格式的字符串。Content-Type選擇下拉框快速選擇application/json、application/x-www-form-urlencoded、text/plain等。自定義請(qǐng)求頭支持添加、編輯、刪除額外的HTTP Header例如Authorization: Bearer token。文件上傳集成multipart/form-data文件選擇與上傳功能。響應(yīng)展示清晰顯示HTTP狀態(tài)碼、響應(yīng)頭和響應(yīng)體支持JSON格式化高亮。歷史記錄將每次成功的請(qǐng)求配置URL、方法、頭、體保存下來(lái)方便重復(fù)測(cè)試。4.2 發(fā)送JSON POST請(qǐng)求的代碼示例procedure TTestClientForm.btnSendJSONClick(Sender: TObject); var IdHTTP: TIdHTTP; RequestStream: TStringStream; ResponseBody: string; begin IdHTTP : TIdHTTP.Create(nil); RequestStream : TStringStream.Create(mmoRequestBody.Text, TEncoding.UTF8); try // 配置HTTP客戶端 IdHTTP.Request.ContentType : application/json; charsetutf-8; IdHTTP.Request.CharSet : utf-8; // 添加自定義頭部 IdHTTP.Request.CustomHeaders.AddValue(X-Api-Key, your-api-key-here); // 發(fā)送POST請(qǐng)求 try ResponseBody : IdHTTP.Post(edtURL.Text, RequestStream); // 顯示結(jié)果 mmoResponseBody.Text : FormatJSON(ResponseBody); // 假設(shè)有JSON格式化函數(shù) lblStatusCode.Caption : 狀態(tài)碼: IntToStr(IdHTTP.ResponseCode); LogRequestToHistory(edtURL.Text, POST, mmoRequestBody.Text, IdHTTP.Request.ContentType); except on E: EIdHTTPProtocolException do begin // 處理HTTP協(xié)議錯(cuò)誤如404, 500 mmoResponseBody.Text : E.ErrorMessage; lblStatusCode.Caption : 狀態(tài)碼: IntToStr(E.ErrorCode); end; on E: Exception do begin // 處理網(wǎng)絡(luò)等其他錯(cuò)誤 mmoResponseBody.Text : 請(qǐng)求失敗: E.Message; end; end; finally RequestStream.Free; IdHTTP.Free; end; end;客戶端開(kāi)發(fā)心得編碼一致性確保TStringStream和TIdHTTP.Request.CharSet使用相同的編碼強(qiáng)烈建議UTF-8否則中文等非ASCII字符會(huì)亂碼。異常細(xì)分EIdHTTPProtocolException是服務(wù)器返回錯(cuò)誤狀態(tài)碼400時(shí)拋出的異常其ErrorCode和ErrorMessage包含了服務(wù)器的響應(yīng)信息這對(duì)于調(diào)試API錯(cuò)誤非常有用。網(wǎng)絡(luò)超時(shí)、連接拒絕等則是其他異常類型。資源釋放TIdHTTP和TStream對(duì)象必須放在try...finally塊中確保釋放特別是在頻繁發(fā)送請(qǐng)求的客戶端程序中。4.3 模擬文件上傳請(qǐng)求procedure TTestClientForm.btnUploadFileClick(Sender: TObject); var IdHTTP: TIdHTTP; PostData: TIdMultiPartFormDataStream; ResponseBody: string; begin if not OpenDialog1.Execute then Exit; IdHTTP : TIdHTTP.Create(nil); PostData : TIdMultiPartFormDataStream.Create; try // 添加文件字段 PostData.AddFile(file, OpenDialog1.FileName, application/octet-stream); // 字段名文件路徑MIME類型 // 添加普通文本字段 PostData.AddFormField(description, 這是一個(gè)測(cè)試上傳的文件); // TIdMultiPartFormDataStream會(huì)自動(dòng)設(shè)置正確的Content-Type ResponseBody : IdHTTP.Post(edtURL.Text, PostData); mmoResponseBody.Text : ResponseBody; lblStatusCode.Caption : 狀態(tài)碼: IntToStr(IdHTTP.ResponseCode); finally PostData.Free; IdHTTP.Free; end; end;使用TIdMultiPartFormDataStream可以極大地簡(jiǎn)化文件上傳客戶端的編碼工作它內(nèi)部會(huì)處理好邊界生成和格式組裝。5. 生產(chǎn)環(huán)境部署與性能調(diào)優(yōu)實(shí)戰(zhàn)將Demo代碼轉(zhuǎn)化為一個(gè)7x24小時(shí)穩(wěn)定運(yùn)行的生產(chǎn)服務(wù)還需要考慮很多工程化細(xì)節(jié)。5.1 日志記錄與問(wèn)題排查沒(méi)有日志的服務(wù)器等于瞎子。一個(gè)基本的日志系統(tǒng)應(yīng)該記錄訪問(wèn)日志客戶端IP、請(qǐng)求時(shí)間、方法、URL、狀態(tài)碼、處理時(shí)長(zhǎng)。錯(cuò)誤日志異常堆棧信息、非法請(qǐng)求內(nèi)容。業(yè)務(wù)日志關(guān)鍵業(yè)務(wù)操作如設(shè)備數(shù)據(jù)接收成功。我通常使用一個(gè)線程安全的日志隊(duì)列工作線程將日志寫(xiě)入隊(duì)列由一個(gè)獨(dú)立的日志線程負(fù)責(zé)將其寫(xiě)入文件或數(shù)據(jù)庫(kù)避免磁盤(pán)IO阻塞請(qǐng)求處理。// 簡(jiǎn)化的線程安全日志示例 procedure LogMessage(const Msg: string); begin TThread.Queue(nil, procedure begin // 在主線程或日志線程中安全地寫(xiě)入Memo或文件 mmoLog.Lines.Add(FormatDateTime(yyyy-mm-dd hh:nn:ss.zzz, Now) - Msg); // 同時(shí)寫(xiě)入文件 WriteToFile(Msg); end); end; // 在請(qǐng)求處理中記錄 LogMessage(Format([%s] %s %s - %dms, [ARequestInfo.RemoteIP, ARequestInfo.Command, ARequestInfo.URI, ProcessingTime]));5.2 連接管理與資源釋放THttpServer在長(zhǎng)時(shí)間運(yùn)行后可能會(huì)出現(xiàn)內(nèi)存緩慢增長(zhǎng)或句柄泄漏。需要關(guān)注全局對(duì)象管理確保在OnCommandOther事件中創(chuàng)建的臨時(shí)對(duì)象如TJSONObject,TMemoryStream都被正確釋放。連接狀態(tài)監(jiān)控可以定期輸出THttpServer的ActiveConnections等屬性監(jiān)控連接數(shù)是否在正常范圍。優(yōu)雅關(guān)閉在程序退出時(shí)先將Active設(shè)為False等待一段時(shí)間讓現(xiàn)有請(qǐng)求處理完畢再銷毀THttpServer對(duì)象。5.3 性能調(diào)優(yōu)要點(diǎn)線程池配置ThreadPoolSize的Max值不是越大越好。設(shè)置過(guò)大在突發(fā)高并發(fā)時(shí)可能創(chuàng)建大量線程導(dǎo)致系統(tǒng)資源緊張和頻繁的上下文切換反而降低性能。需要通過(guò)壓力測(cè)試找到應(yīng)用的“甜蜜點(diǎn)”。請(qǐng)求處理耗時(shí)用GetTickCount或TStopwatch記錄每個(gè)請(qǐng)求在事件處理函數(shù)中的耗時(shí)。如果發(fā)現(xiàn)某些請(qǐng)求特別慢就要考慮優(yōu)化業(yè)務(wù)邏輯或?qū)⑵洚惒交?。?nèi)存池對(duì)于頻繁創(chuàng)建釋放的小對(duì)象如字符串列表、小的內(nèi)存流可以考慮使用對(duì)象池來(lái)減少內(nèi)存分配開(kāi)銷。使用更高效的JSON庫(kù)如果JSON解析是性能瓶頸可以考慮評(píng)估System.JSON以外的第三方庫(kù)如dsjson在某些場(chǎng)景下可能有更好的性能。6. 常見(jiàn)陷阱與終極調(diào)試技巧即使代碼看起來(lái)完美在實(shí)際網(wǎng)絡(luò)環(huán)境中還是會(huì)遇到各種古怪問(wèn)題。以下是我踩過(guò)的一些坑和解決方法。6.1 請(qǐng)求體為空或讀取不完整現(xiàn)象ARequestInfo.PostStream為nil或Size為0但客戶端明確發(fā)送了數(shù)據(jù)。排查首先檢查客戶端發(fā)送的Content-Length頭是否正確。如果這個(gè)頭缺失或值為0THttpServer可能不會(huì)創(chuàng)建PostStream。檢查服務(wù)器端的MaxRequestBodySize是否設(shè)置得過(guò)小導(dǎo)致請(qǐng)求被截?cái)?。在OnCommandOther事件最開(kāi)始記錄下ARequestInfo.RawHTTPCommand和所有請(qǐng)求頭與客戶端發(fā)送的原始數(shù)據(jù)對(duì)比看是否一致。6.2 中文亂碼問(wèn)題現(xiàn)象接收到的JSON或表單數(shù)據(jù)中的中文變成問(wèn)號(hào)或亂碼。解決服務(wù)器端在解析字符串時(shí)始終明確指定編碼為UTF-8。不要依賴系統(tǒng)默認(rèn)編碼。// 正確做法 RawString : TEncoding.UTF8.GetString(Bytes); // 錯(cuò)誤做法 RawString : TStringStream(ContentStream).DataString; // 可能使用默認(rèn)ANSI編碼客戶端確保TIdHTTP的Request.CharSet和Request.ContentType中聲明的編碼一致且都是utf-8。發(fā)送的TStringStream也要用TEncoding.UTF8創(chuàng)建。6.3 跨域請(qǐng)求 (CORS) 支持現(xiàn)象網(wǎng)頁(yè)通過(guò)JavaScript調(diào)用你的HttpServer API時(shí)瀏覽器報(bào)跨域錯(cuò)誤。解決需要在服務(wù)器的響應(yīng)中添加CORS頭部。// 在返回響應(yīng)前添加以下頭部 AResponseInfo.CustomHeaders.AddValue(Access-Control-Allow-Origin, *); // 生產(chǎn)環(huán)境應(yīng)指定具體域名 AResponseInfo.CustomHeaders.AddValue(Access-Control-Allow-Methods, GET, POST, OPTIONS); AResponseInfo.CustomHeaders.AddValue(Access-Control-Allow-Headers, Content-Type, Authorization); // 對(duì)于OPTIONS預(yù)檢請(qǐng)求直接返回200 if ARequestInfo.Command OPTIONS then begin AResponseInfo.ResponseNo : 200; AResponseInfo.ContentText : ; Exit; end;6.4 使用網(wǎng)絡(luò)抓包工具進(jìn)行終極調(diào)試當(dāng)邏輯排查無(wú)法解決問(wèn)題時(shí)必須祭出抓包工具。我推薦使用Wireshark或Fiddler。Fiddler配置為系統(tǒng)代理直接捕獲客戶端發(fā)出的HTTP/HTTPS請(qǐng)求原始報(bào)文。你可以清晰地看到請(qǐng)求頭、請(qǐng)求體的每一個(gè)字節(jié)與服務(wù)器端日志記錄的內(nèi)容進(jìn)行逐字節(jié)對(duì)比。這是排查編碼、格式錯(cuò)誤最直接的方法。Wireshark在更底層抓取網(wǎng)絡(luò)包。如果懷疑是網(wǎng)絡(luò)問(wèn)題如粘包、拆包或想分析TCP連接狀態(tài)Wireshark是唯一選擇。調(diào)試步驟在客戶端發(fā)起一個(gè)錯(cuò)誤請(qǐng)求的同時(shí)用抓包工具捕獲。對(duì)比工具中看到的“真實(shí)發(fā)送的數(shù)據(jù)”和你服務(wù)器代碼中ARequestInfo解析出來(lái)的數(shù)據(jù)。十有八九問(wèn)題就出在客戶端組裝請(qǐng)求或服務(wù)器解析請(qǐng)求的某個(gè)細(xì)微環(huán)節(jié)上。通過(guò)這次從零搭建Delphi HttpServer并完善其POST處理能力的全過(guò)程我再次體會(huì)到看似古老的技術(shù)棧在特定的、追求可控和穩(wěn)定的場(chǎng)景下依然有著不可替代的價(jià)值。關(guān)鍵在于深入理解其原理細(xì)致地處理邊界情況并配以完善的工具鏈進(jìn)行測(cè)試和監(jiān)控。希望這個(gè)資源包和其中的經(jīng)驗(yàn)?zāi)軒椭阍谙乱粋€(gè)Delphi網(wǎng)絡(luò)服務(wù)項(xiàng)目中少走彎路。本文還有配套的精品資源點(diǎn)擊獲取