簡介Indy 10.6.3.3 是面向 Delphi 與 CBuilder 開發(fā)者的跨平臺網(wǎng)絡組件庫源碼包適合需要快速實現(xiàn) TCP/IP、HTTP、FTP 等通信功能的中高級開發(fā)者。它把多種互聯(lián)網(wǎng)協(xié)議封裝成可直接拖放的組件包含連接管理與網(wǎng)頁請求等常用部件并支持異步執(zhí)行和事件回調(diào)可用于郵件客戶端、Web 服務、文件傳輸與聊天程序等場景。壓縮包共 2000 個文件約 9.67MB以 pas 源碼、dpk 包文件、dproj 工程、bmp 與 ico 資源以及 txt、rc、res 等說明和構建文件為主目錄兼顧編譯安裝、示例參考與資源生成。包內(nèi)保留核心協(xié)議單元、設計期包與多版本工程文件便于在 RAD Studio 中按需編譯和二次開發(fā)完整源碼也方便按項目需求裁剪、修改和擴展協(xié)議實現(xiàn)并對照組件結構排查連接、收發(fā)與超時等問題。已有 362 人學習適合作為 Delphi 網(wǎng)絡應用開發(fā)的基礎組件資料對理解組件化網(wǎng)絡編程與協(xié)議封裝亦有參考價值。1. 解壓先別急著點 InstallIndy 10.6.3.3 換掉的是 Delphi 12 的整套網(wǎng)絡底座Delphi 控件里最容易被低估的一類是那種平時看不見、一旦出問題就全盤停擺的底層庫Indy 就是典型。IndyInternet Direct本來是 Delphi 12 安裝包里自帶的網(wǎng)絡組件集TIdHTTP、TIdFTP、TIdSMTP、TIdTCPClient、TIdTCPServer 這一批控件全出自它而隨 IDE 預裝的那份版本往往偏舊碰上 TLS 1.3、新版 SSL 運行庫或者某些服務端不常見的握手方式就容易出問題。這份 Indy-10.6.3.3 給的是完整源碼加設計期包覆蓋上去等于給整個網(wǎng)絡層換發(fā)動機——協(xié)議實現(xiàn)和 SSL 后端都更新了代價是 IDE 本身也依賴這套包裝錯順序連 Delphi 都打不開。它適合手里有存量 Delphi 項目、被 HTTPS 或長連接折騰過、又不想引入第三方網(wǎng)絡框架的人。2. 編譯與安裝六個包的設計期與運行期順序不能亂Indy 不是一個 dpk 包打包全部而是按「基礎 → 核心 → 協(xié)議」切成三層每層再分運行期包和設計期包。很多人解壓后直接在 IDE 里雙擊 dclIndyProtocols.dpk 點 Install然后報一堆「Cannot load package」原因幾乎都是跳過了下層的運行期包。這一章先把包組結構拆清楚再給一套可以照著敲的命令行編譯流程最后才是 IDE 里掛包和清 DCU。2.1 包組結構與依賴方向先把解開后的目錄看一眼Core、System、Protocols 三個源碼目錄配上根目錄下若干 dpk/dproj。它們的依賴是單向的編譯順序不能反。包文件類型依賴主要內(nèi)容IndySystem.dpk運行期無IdGlobal、IdException、IdStack、IdResourceStrings 等基礎單元IndyCore.dpk運行期IndySystemIdTCPClient、IdTCPServer、IdIOHandler、IdContext、IdThreadIndyProtocols.dpk運行期IndyCoreIdHTTP、IdFTP、IdSMTP、IdPOP3、IdSSLOpenSSL 等協(xié)議單元dclIndySystem.dpk設計期IndySystem.bpl注冊基礎控件到工具面板dclIndyCore.dpk設計期IndyCore.bpl注冊 TIdTCPClient、TIdTCPServer 等dclIndyProtocols.dpk設計期IndyProtocols.bpl注冊 TIdHTTP、TIdFTP、TIdSSLIOHandlerSocketOpenSSL 等三條判斷依據(jù)值得記住。第一運行期包產(chǎn)出的是 .bpl程序運行時要么靜態(tài)鏈接要么帶著這些 bpl 走所以它必須先于設計期包編譯出來。第二設計期包只負責把組件注冊進 IDE它自己不包含實現(xiàn)代碼只是引用運行期包所以 IDE 位數(shù)決定設計期包只能編 Win32。第三Indy 的單元之間存在大量隱式引用比如 IdHTTP 引用了 IdIOHandler、IdSSLOpenSSL 又引用 IdSSLOpenSSLHeaders如果只編了 IndyProtocols 而 IndyCore 的 DCU 是舊版鏈接階段就會報「Unit IdIOHandler was compiled with a different version of IdGlobal」。2.2 用命令行把三個運行期包先編出來比在 IDE 里點 Build 更可控的做法是走 msbuild尤其當你需要同時出 Win32 和 Win64、或者要寫自動化腳本的時候。Delphi 安裝時會往系統(tǒng)環(huán)境里寫一個 BDS 變量指向 Studio 的安裝根目錄rsvars.bat 就在它的 bin 下作用是初始化編譯所需的環(huán)境變量。:: 1) 初始化編譯環(huán)境BDS 由安裝程序?qū)懭霙]寫就手動 set 一下 call %BDS%\bin\rsvars.bat :: 2) 嚴格按依賴順序編譯路徑切到解壓后的 Indy 根目錄 cd /d D:\src\Indy-10.6.3.3 :: 3) 先基礎層再核心層最后協(xié)議層 msbuild IndySystem.dproj /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild IndyCore.dproj /t:Build /p:ConfigRelease /p:PlatformWin32 msbuild IndyProtocols.dproj /t:Build /p:ConfigRelease /p:PlatformWin32這三條命令的邏輯是串行的IndyCore 編譯時需要讀 IndySystem 產(chǎn)出的 .dcu 和 .bpl所以上一條不成功就不要往下走。參數(shù)上ConfigRelease是為了讓設計期掛進 IDE 的那份包體積小、斷言少調(diào)試信息留給項目自己的 Debug 配置PlatformWin32是因為 Delphi 12 的 IDE 進程本身是 32 位設計期包必須是 Win32運行期包才可以按目標平臺再編一遍 Win64。如果你只關心 64 位程序也要先把 Win32 的三個運行期包和設計期包編出來否則 IDE 里根本拖不出 TIdHTTP。編譯完檢查輸出目錄應該能看到 IndySystem.bpl、IndyCore.bpl、IndyProtocols.bpl 以及對應的 .dcp。少了任何一個下一步掛設計期包一定失敗。2.3 在 IDE 里掛設計期包并清掉舊 DCU命令行編完只是有了文件IDE 還不知道。掛載這一步有幾個順序上的講究第一步關掉所有打開的項目先備份%BDS%\bin目錄下所有 Indy 開頭的 bpl。Delphi 12 的 IDE 自身就鏈接了 Indy替換失敗會導致 IDE 啟動報錯有備份才不至于重裝。第二步Component → Install Packages在列表里把已有的 Indy 相關設計期包逐個 Remove。這一步不做新包和舊包會同時注冊同名組件工具面板上出現(xiàn)兩個 TIdHTTP編譯時報「Duplicate identifier」。第三步Add依次選 dclIndySystem.bpl、dclIndyCore.bpl、dclIndyProtocols.bpl。順序不能反因為 dclIndyProtocols 加載時會去解析對 IndyProtocols.bpl 的引用而 IndyProtocols.bpl 又依賴 IndyCore.bpl。第四步Tools → Options → Language → Delphi → Library把 System、Core、Protocols 三個源碼目錄加到 Library path 的最前面。放在最前面是關鍵否則編譯器會優(yōu)先命中 IDE 自帶路徑下的舊 DCU編譯通過但行為還是舊版。第五步清 DCU。搜一遍項目目錄和公共 DCU 輸出目錄把 Id 開頭的 .dcu 全刪掉。Indy 的單元名很集中Id*.dcu通配基本不會誤傷。清完重新 Build All再拖一個 TIdHTTP 到空窗體上能編譯、能出現(xiàn)屬性編輯器安裝就算過了。3. TIdTCPClient 與 TIdTCPServer一條能收發(fā)的閉環(huán)怎么搭Indy 里最容易被新手跳過的其實是 TCP 這一層大家都直奔 TIdHTTP因為 HTTP 簡單。但只要涉及長連接、私有協(xié)議、需要服務端主動推送最后還是要回到 TIdTCPClient/TIdTCPServer。這兩個組件看似只有幾個屬性真正會出問題的地方集中在三處超時、報文邊界、以及 OnExecute 到底跑在哪個線程里。3.1 長連接場景為什么優(yōu)先選 TCP 組件而不是 HTTP選型上有個樸素判斷如果你的交互是「客戶端發(fā)一次、服務端答一次然后結束」用 TIdHTTP 最省事它幫你處理了連接復用、重定向、分塊傳輸。但如果服務端需要在沒有請求的時候主動下發(fā)消息或者一次交互里有多輪往返鑒權、訂閱、心跳HTTP 就要靠輪詢或長輪詢?nèi)ツM成本和不確定性都上去了。TIdTCPClient 給的是裸的字節(jié)流好處是完全可控什么時候連、連多久、發(fā)什么、等多久、斷了怎么重連全在你手里。代價是報文邊界要自己定。TCP 本身是字節(jié)流沒有消息的概念一次 WriteLn 發(fā)出去的內(nèi)容對端可能分兩次收到也可能和下一次的內(nèi)容粘在一起。這就是為什么 Indy 提供了 ReadLn 這種帶終止符的讀法——它在幫你把字節(jié)流切回消息。還有個實際因素TIdTCPServer 自帶連接上下文管理、最大連接數(shù)限制、線程池調(diào)度這些在 TIdHTTP 里是隱藏的。你需要看「當前有多少個客戶端連著」的時候IdTCPServer1.Contexts.LockList一句就能拿到比在 HTTP 層自己數(shù)會話簡單得多。3.2 客戶端超時、編碼與連接生命周期客戶端的坑幾乎全在超時上。TIdTCPClient 有兩個獨立超時ConnectTimeout 管建連ReadTimeout 管讀阻塞。默認值給得比較寬松在弱網(wǎng)或者對端假死的時候一個 Read 能掛很久。uses IdTCPClient, IdGlobal, IdException; function TcpPing(const AHost: string; APort: Integer): string; var Client: TIdTCPClient; begin Client : TIdTCPClient.Create(nil); try Client.Host : AHost; Client.Port : APort; Client.ConnectTimeout : 3000; // 建連上限含 DNS 解析時間 Client.ReadTimeout : 5000; // 單次 Read 阻塞上限超時拋 EIdReadTimeout try Client.Connect; try // 顯式指定 UTF-8避免中文在兩端編碼不一致時變成亂碼 Client.IOHandler.WriteLn(PING, IndyTextEncoding_UTF8); Result : Client.IOHandler.ReadLn(LF, Client.ReadTimeout, 4096, IndyTextEncoding_UTF8); finally Client.Disconnect; end; except on E: EIdConnectTimeout do Result : CONNECT_TIMEOUT on E: EIdReadTimeout do Result : READ_TIMEOUT on E: EIdSocketError do Result : SOCKET_ERROR: IntToStr(E.LastError); end; finally Client.Free; end; end;這段代碼有幾個點值得說明。ConnectTimeout單位是毫秒它覆蓋的不只是三次握手DNS 解析也在這個預算里所以填 3000 意味著解析慢的域名會直接判超時。ReadLn的四個參數(shù)依次是終止符、超時、單行最大字節(jié)數(shù)、文本編碼把AMaxLineLength填成 4096 是一種防御防止對端發(fā)來一條幾十兆、沒有換行的「臟數(shù)據(jù)」把內(nèi)存打滿。異常類型上連接超時拋 EIdConnectTimeout讀超時拋 EIdReadTimeout兩者都繼承自 EIdException但分開捕獲能讓你在日志里一眼看出是網(wǎng)絡沒通還是對端不回。連接生命周期上Connect和Disconnect要成對出現(xiàn)而且 Disconnect 放在內(nèi)層 finallyFree 放在外層 finally。原因是 Connect 拋異常時連接根本沒建立此時調(diào) Disconnect 雖然無害但沒意義而一旦連上無論讀寫是否異常都必須斷開否則套接字句柄會泄漏。3.3 服務端OnExecute 在哪個線程里跑這是 Indy 新手翻車率最高的一點。TIdTCPServer 的 OnExecute 不是主線程回調(diào)而是在每條連接自己的上下文線程里執(zhí)行。也就是說你在這個事件里碰任何 VCL 控件改 Label.Caption、往 Memo 里追加日志、彈 MessageBox輕則界面卡住重則訪問違例或者隨機崩潰——因為 VCL 的窗口句柄有線程親和性。uses IdContext, IdTCPConnection, IdGlobal, IdException; procedure TForm1.FormCreate(Sender: TObject); begin IdTCPServer1.Bindings.Clear; with IdTCPServer1.Bindings.Add do begin IP : 0.0.0.0; // 監(jiān)聽所有網(wǎng)卡只給本機用就填 127.0.0.1 Port : 9000; end; IdTCPServer1.MaxConnections : 200; // 超過直接拒絕防止連接打滿 IdTCPServer1.ListenQueue : 50; // 已完成握手但未被取走的隊列長度 IdTCPServer1.TerminateWaitTime : 5000; // 停服時等各線程收尾的上限 IdTCPServer1.Active : True; end; procedure TForm1.IdTCPServer1Execute(AContext: TIdContext); var Req: string; begin try // 讀一行5 秒沒等到換行就按超時處理單行上限 4KB Req : AContext.Connection.IOHandler.ReadLn(LF, 5000, 4096, IndyTextEncoding_UTF8); except on E: EIdReadTimeout do Exit; // 客戶端連上不發(fā)數(shù)據(jù)直接放棄這條連接 end; if SameText(Trim(Req), PING) then AContext.Connection.IOHandler.WriteLn(PONG, IndyTextEncoding_UTF8) else AContext.Connection.IOHandler.WriteLn(ERR UNKNOWN, IndyTextEncoding_UTF8); // 需要更新界面時必須切回主線程不能直接寫控件屬性 TThread.Queue(nil, procedure begin Memo1.Lines.Add(recv: Req); end); end;邏輯上有幾處需要展開。Bindings是監(jiān)聽地址列表默認可能綁在 127.0.0.1 上做成服務端給別的機器連就會發(fā)現(xiàn)連不通所以先 Clear 再顯式 Add 是穩(wěn)妥寫法。MaxConnections是硬上限超過之后新連接會被直接關掉不給 OnConnect 機會這在被掃描或者被壓測的時候很有用。ListenQueue對應底層 listen 的 backlog短連接高并發(fā)場景下如果偏小會出現(xiàn)客戶端已經(jīng)握手成功但服務端遲遲不取的情況。異常處理那一層是必須的。OnExecute 里拋出的異常如果不捕獲Indy 會把它吞掉并斷開連接表面看是「客戶端莫名其妙掉了」日志里什么都沒有。顯式捕獲 EIdReadTimeout 并 Exit至少能讓「對端連上不發(fā)數(shù)據(jù)」這種情況可控。TThread.Queue 那一段是線程安全的寫法Queue 是異步投遞不阻塞工作線程對應的 TThread.Synchronize 是同步等待在主線程忙的時候會把工作線程一起拖住連接數(shù)一多就雪崩。所以除了極小規(guī)模的工具都建議用 Queue。3.4 報文邊界ReadLn 的終止符與最大長度ReadLn 的兩個參數(shù)——終止符和最大長度——決定了你的協(xié)議能不能穩(wěn)定工作。終止符默認是 LF#10但很多設備端發(fā)的是 CRLF#13#10。這時候如果兩邊不約定清楚服務端會讀到「PING」后面跟一個 #13Trim之后才能比對上一旦業(yè)務數(shù)據(jù)里本身包含 #13切分就亂了。常見做法是協(xié)議頭里帶長度字段或者用定長頭 變長體。如果堅持用行協(xié)議務必在兩邊統(tǒng)一成 LF服務端讀到的內(nèi)容末尾不要做隱式 Trim 之外的任何處理。最大長度一定要設置Indy 允許傳 -1 表示不限這在實際部署里等于給了一個內(nèi)存炸彈——對端只要持續(xù)發(fā)不含終止符的字節(jié)緩沖區(qū)就一直漲。大包場景不適合 ReadLn。行讀取是逐字節(jié)掃描找終止符幾 MB 的報文用它會明顯變慢正確做法是用ReadBytes或者ReadStream先讀 4 字節(jié)長度頭再按長度讀體。4. TIdHTTP 與 SSL把 HTTPS 請求真正跑通的參數(shù)清單TIdHTTP 是 Indy 里使用頻率最高的組件也是「看起來一行就能跑、實際各種報錯」的典型。它本身的封裝很薄幾乎所有行為都由 IOHandler 和 Request 上的屬性決定。這一章按「歸屬權 → 參數(shù) → 落地代碼 → SSL 運行庫」的順序走前三步?jīng)Q定你的代碼會不會崩第四步?jīng)Q定 HTTPS 能不能通。4.1 IOHandler 的歸屬權一個 double free 的經(jīng)典現(xiàn)場TIdHTTP 自己會創(chuàng)建一個默認的 IOHandler純 socket不帶 SSL。當你要訪問 HTTPS就必須手動掛一個 TIdSSLIOHandlerSocketOpenSSL 上去。問題出在釋放上TIdHTTP 的析構函數(shù)里會 Free 掉當前的 IOHandler所以如果你在 finally 里既Http.Free又SSL.Free第二次釋放就是訪問違例而且崩的位置往往在程序退出時堆?？粗?HTTP 毫無關系。正確做法是要么把 SSL 的 Owner 設成 HttpTIdSSLIOHandlerSocketOpenSSL.Create(Http)要么創(chuàng)建時 Owner 給 nil、但只 Free Http。兩種都行核心原則是同一個對象只能有一個釋放者。我一般用前者因為對象樹清晰出問題看 Owner 就知道誰管誰。順帶一提給Http.IOHandler賦值時Indy 內(nèi)部會把舊的默認 handler 釋放掉所以你不需要也不應該自己去釋放它。4.2 關鍵參數(shù)表下面這張表是我在幾個項目里反復調(diào)出來的常用值具體數(shù)字按你的服務端 SLA 調(diào)整但項目別留空。參數(shù)常用取值說明ConnectTimeout3000 ~ 5000建連階段上限含 DNS單位毫秒ReadTimeout15000 ~ 30000單次讀阻塞上限超時拋 EIdReadTimeoutHandleRedirectsTrue自動跟隨 301/302注意 POST 被重定向后可能退化成 GETRedirectMaximum5重定向次數(shù)上限防止循環(huán)跳轉(zhuǎn)Request.ContentTypeapplication/json; charsetutf-8POST 時必須顯式設置否則服務端可能按表單解析Request.Acceptapplication/json影響服務端的內(nèi)容協(xié)商Request.UserAgent自定義字符串留空會被部分網(wǎng)關直接拒絕SSLOptions.SSLVersions[sslvTLSv1_2, sslvTLSv1_3]不要留空留空走庫默認值可能協(xié)商到不再被接受的舊協(xié)議SSLOptions.ModesslmClient客戶端固定這個值SSLOptions.VerifyMode[sslvrfPeer]空集合等于不校驗服務端證書生產(chǎn)環(huán)境不要這么干SSLOptions.VerifyDepth3證書鏈校驗深度SSLOptions.RootCertFileCA 證書路徑留空則用系統(tǒng)證書存儲IOHandler.Deflate.CompressionLevel0 或 6開啟 gzip 壓縮服務端支持時能顯著減小正文SSLVersions這一項值得單獨說。很多人為了「兼容性」把 SSLv3、TLSv1.0 全塞進去結果服務端反而拒絕握手因為現(xiàn)代網(wǎng)關會直接拒掉低版本協(xié)議。反過來只寫 sslvTLSv1_3 也不行一些內(nèi)網(wǎng)服務還停留在 1.2。給 [sslvTLSv1_2, sslvTLSv1_3] 是最穩(wěn)的起點。4.3 GET 與 POST 的落地寫法先看一個帶 JSON 體的 POST涵蓋超時、頭部、編碼三件事。uses IdHTTP, IdSSLOpenSSL, IdSSL, IdGlobal, SysUtils, Classes; function HttpPostJson(const AUrl, AJson: string; out AStatus: Integer): string; var Http: TIdHTTP; SSL: TIdSSLIOHandlerSocketOpenSSL; Src: TStringStream; begin Http : TIdHTTP.Create(nil); try // Owner 交給 Http由 TIdHTTP 在析構時統(tǒng)一釋放避免 double free SSL : TIdSSLIOHandlerSocketOpenSSL.Create(Http); SSL.SSLOptions.Mode : sslmClient; SSL.SSLOptions.SSLVersions : [sslvTLSv1_2, sslvTLSv1_3]; SSL.SSLOptions.VerifyMode : [sslvrfPeer]; Http.IOHandler : SSL; Http.ConnectTimeout : 5000; Http.ReadTimeout : 20000; Http.HandleRedirects : True; Http.RedirectMaximum : 5; Http.Request.ContentType : application/json; charsetutf-8; Http.Request.Accept : application/json; Http.Request.UserAgent : DelphiClient/1.0; Http.Request.CustomHeaders.Values[X-Trace-Id] : demo-0001; // TStringStream 顯式指定 UTF-8中文才不會按 ANSI 發(fā)出去 Src : TStringStream.Create(AJson, TEncoding.UTF8); try Result : Http.Post(AUrl, Src); AStatus : Http.ResponseCode; finally Src.Free; end; finally Http.Free; // IOHandler 隨 Http 一起釋放不要再 Free SSL end; end;幾個參數(shù)的作用ReadTimeout設 20 秒是因為不少接口在冷啟動時首字節(jié)要等十幾秒設太短會頻繁誤判超時CustomHeaders用來塞鏈路追蹤 ID排查跨服務問題時能對上日志TStringStream的編碼參數(shù)不能省默認會用系統(tǒng) ANSI 頁JSON 里只要有中文服務端收到的就是一堆問號。GET 加查詢參數(shù)時不要手動拼字符串用TIdURI.ParamsEncode做轉(zhuǎn)義否則參數(shù)里帶、、中文就會把請求拆壞。下載文件用Http.Get(AUrl, AFileStream)的重載配合OnWork事件可以拿到進度在OnWork里判斷超時或者用戶取消拋一個自定義異常就能中斷傳輸這是 Indy 提供的少數(shù)幾個中斷點之一。4.4 SSL 運行庫放哪、怎么確認加載成功HTTPS 報「Could not load SSL library」幾乎是必踩的一關。原因通常只有三種位數(shù)不對、文件名不對、搜索路徑不對。位數(shù)上32 位程序必須配 32 位運行庫64 位配 64 位。文件名上Indy 會按一串候選名去試3.x 系列是 libssl-3.dll / libcrypto-3.dll64 位版本帶 -x64 后綴1.1 系列是 libssl-1_1.dll 這一類。搜索路徑上最省事的做法是把兩個 DLL 放到 exe 同目錄這樣不依賴系統(tǒng)目錄部署也好打包。確認是否加載成功別靠猜uses IdSSLOpenSSLHeaders; procedure TForm1.CheckSSL; begin if not LoadOpenSSLLibrary then raise Exception.Create(SSL 運行庫加載失敗: WhichFailedToLoad); Memo1.Lines.Add(SSL 版本: OpenSSLVersion); end;WhichFailedToLoad會直接告訴你它試過的候選名里哪些失敗了對著這個名字去補 DLL 就行比反復重啟程序快得多。另外還有一個容易忽略的點如果程序目錄里同時存在 1.1 和 3.x 兩套 DLLIndy 會按內(nèi)部順序挑一個可能出現(xiàn)「本機好好的、客戶機器上握手失敗」統(tǒng)一成一套、刪掉多余的能省掉很多玄學問題。5. 避坑與排查五個讓我返工的現(xiàn)場前面幾章講的是「怎么裝、怎么寫」這一章講「為什么照寫了還是不對」。下面五條都是我在實際項目里返工過的按「現(xiàn)象 → 原因 → 解決」寫遇到癥狀對得上的可以直接跳。5.1 編譯報「compiled with a different version of IdGlobal」現(xiàn)象新裝的包新建空項目拖一個 TIdHTTP編譯立刻報單元版本不一致提示的卻是 IdGlobal 這種基礎單元。原因舊 DCU 殘留。Delphi 的編譯緩存是按單元名找的項目搜索路徑、公共 DCU 輸出目錄、IDE 自帶路徑里任意一處有舊版 IdGlobal.dcu編譯器就可能先命中它然后和新建的 IndyCore.dcp 對不上。解決先把 Library path 里 Indy 的三個源碼目錄頂?shù)阶钋懊嬖偃P搜Id*.dcu刪掉最后 Project → Build All不是 CompileCompile 不會重新鏈接。如果還不行檢查是不是同時裝了 32 位和 64 位包而當前編譯目標選錯了平臺。5.2 裝完設計期包IDE 啟動報「Cannot load package dclIndyCore」現(xiàn)象包在 IDE 里點 Install 成功了關掉重開 Delphi彈窗說某個 Indy 包加載失敗工具面板上組件全沒了。原因設計期包的加載順序或者依賴沒滿足。Indy 的設計期包依賴對應的運行期 bpl如果運行期 bpl 沒在系統(tǒng)能找到的路徑里通常是 IDE 的 bin 目錄加載時解析不到依賴就失敗。另一種情況是 32 位和 64 位混裝把 Win64 的 bpl 塞進了 32 位 IDE。解決先備份%BDS%\bin下所有 Indy 開頭的 bpl再把編譯出來的三個運行期 bpl 復制進去設計期包只放 Win32 版本。然后用%BDS%\bin\bds.exe -rXXX起一個干凈注冊表配置驗證確認是包的問題還是注冊表殘留。這一步別嫌麻煩直接在主配置上反復試很容易把 IDE 搞到起不來。5.3 服務端 OnExecute 里更新界面跑一會兒就崩現(xiàn)象單客戶端測試完全正常壓到幾十個連接后隨機訪問違例崩的位置在 VCL 內(nèi)部堆棧看不出和網(wǎng)絡有關。原因OnExecute 在連接上下文線程里執(zhí)行直接寫 Label.Caption 或者 Memo.Lines 屬于跨線程操作 VCL。單連接時主線程恰好空閑看起來沒事并發(fā)一上來就撞車。解決所有界面更新走 TThread.Queue參數(shù)在進入 Queue 之前拷貝好閉包里捕獲的是變量引用循環(huán)里尤其容易出錯。如果只是記日志干脆別碰界面寫到一個線程安全的隊列里主線程用 Timer 批量刷。5.4 ReadLn 一直阻塞到超時對端明明發(fā)了數(shù)據(jù)現(xiàn)象服務端 ReadLn 每次都在 5 秒后拋 EIdReadTimeout抓包看數(shù)據(jù)確實到了。原因終止符不匹配。對端發(fā)的是 CRLF你按 LF 讀讀到的內(nèi)容里帶著 #13長度也偏一位或者對端壓根沒發(fā)換行只是發(fā)了一段定長報文。解決先抓一次原始字節(jié)確認結束符再決定用 ReadLn(LF) 還是 ReadLn(#13#10)。定長報文改用ReadBytes(N)。還有一種隱蔽情況是緩沖區(qū)里殘留了上一次的數(shù)據(jù)導致下一次讀到的「第一行」其實是上次的尾巴這種要在協(xié)議層加序號或者長度頭來兜底。5.5 HTTPS 在本機能跑到客戶機器上報 SSL 加載失敗現(xiàn)象開發(fā)機一切正常部署到現(xiàn)場機器上所有 HTTPS 請求全部失敗錯誤是 Could not load SSL library。原因DLL 沒跟著發(fā)布或者發(fā)布的是位數(shù)不對的版本。開發(fā)機上系統(tǒng)目錄里恰好有運行庫所以「看起來能跑」。解決把兩個 DLL 和 exe 放同一目錄一起打包用WhichFailedToLoad打印實際嘗試的文件名做交叉驗證。部署腳本里加一條校驗文件缺失就直接在啟動時報錯別等到第一次發(fā)請求才暴露。6. 進階心跳、重連與線程池把 Indy 用成能上線的樣子裝好、跑通只是及格線。真正上線要解決的是「斷了怎么辦」和「連太多怎么辦」。我的習慣是把 TCP 客戶端封在一個常駐線程里用短超時做心跳探測斷線走指數(shù)退避重連而不是在按鈕點擊里裸調(diào) Connect。type TTcpWorker class(TThread) private FHost: string; FPort: Integer; protected procedure Execute; override; public constructor Create(const AHost: string; APort: Integer); end; procedure TTcpWorker.Execute; var Client: TIdTCPClient; Backoff: Integer; begin Backoff : 1000; // 首次重連間隔 1 秒 while not Terminated do begin Client : TIdTCPClient.Create(nil); try Client.Host : FHost; Client.Port : FPort; Client.ConnectTimeout : 3000; Client.ReadTimeout : 8000; try Client.Connect; Backoff : 1000; // 連上就重置退避 while (not Terminated) and Client.Connected do begin Client.IOHandler.WriteLn(PING, IndyTextEncoding_UTF8); if Client.IOHandler.ReadLn(LF, 8000, 256, IndyTextEncoding_UTF8) PONG then Break; // 應答不對主動斷開重連 Sleep(15000); // 心跳間隔 end; except on E: EIdException do ; // 斷線統(tǒng)一落到重連邏輯 end; finally Client.Free; end; if Terminated then Break; Sleep(Backoff); Backoff : Min(Backoff * 2, 30000); // 指數(shù)退避封頂 30 秒 end; end;這段骨架的關鍵在三個數(shù)字心跳間隔 15 秒、讀超時 8 秒、退避封頂 30 秒。讀超時要小于心跳間隔否則上一次讀還沒返回下一次寫就排隊了退避要封頂不然服務端故障恢復之后客戶端還在一分鐘一次的節(jié)奏上慢慢爬。Terminated在每個可能長阻塞的位置都檢查一次是因為 Sleep 和 ReadLn 都不會響應線程終止信號不加檢查就會出現(xiàn)「關了程序進程還在」的情況。服務端側(cè)如果連接數(shù)上到幾百默認的「一連接一線程」會開始吃內(nèi)存這時候換 TIdSchedulerOfThreadPool把IdTCPServer1.Scheduler指向一個線程池實例配好MaxThreads和MinThreads空閑線程會被復用上下文切換成本明顯下降。配置項單機工具建議值對外服務建議值MaxConnections50500 ~ 2000ListenQueue20100TerminateWaitTime300010000Scheduler默認每連接一線程TIdSchedulerOfThreadPoolMaxThreads不適用CPU 核數(shù) × 4有一件事我一直保持任何走 Indy 的對外接口上線前必須做一次「拔網(wǎng)線」測試——物理斷網(wǎng)、服務端假死、DNS 解析失敗三種場景各跑一遍看客戶端會不會卡死、會不會無限重連打滿 CPU、日志里能不能看出是哪一層超時。這套檢查我吃過虧早期一個版本只測了正常路徑現(xiàn)場網(wǎng)絡抖動時客戶端卡在 ReadLn 里整整一個下午界面完全無響應。從那以后我每次封網(wǎng)絡組件都強制走一遍斷網(wǎng)、假死、拒絕連接三連測才算完。希望幫到你。本文還有配套的精品資源點擊獲取