抓蟲日記：DateToStr格式化陷阱——當本地化設置暗藏殺機

現場還原

客戶反饋文件上傳服務失敗，提示「服務器錯誤」。同服務其他機器正常，鎖定為客戶端環境差異。用HttpAnalyser抓包對比，請求頭無異常，模擬成功請求數據也能通過，問題鎖定在請求體數據。

根因定位

上傳接口要求傳遞文件創建時間。客戶端用Delphi DateToStr() 轉字符串，服務端解析。
關鍵發現：故障機器短日期格式設置為「yyyy-mm-dd-星期」（如「2011-06-15-星期三」），服務端解析器無法識別尾部星期字樣，導致失敗。

DateToStr的隱性依賴

DateToStr 完全依賴系統區域設置中的短日期格式。不同用戶、不同語言環境、不同自定義格式，輸出截然不同。跨機器、跨平台傳輸日期絕不能依賴默認格式化函數。

修復方案

• 客戶端改用固定格式輸出：FormatDateTime('yyyy-mm-dd', FileDate)
• 或雙端約定ISO 8601標準：YYYY-MM-DDThh:mm:ss
• 服務端解析器增強容錯（但首選統一格式）

深度教訓與體系化對策

1. 隱性環境依賴最致命：日期格式、編碼、路徑分隔符、小數點符號等本地化設置，都是跨環境兼容性的定時炸彈。
2. 經驗必須沉澱為靜態檢查規則：此類Bug曾發生過，因人員流動未形成檢查機制而復發。需建立靜態分析規則庫：禁止直接使用DateToStr、StrToDate、printf("%x")等與locale綁定的函數進行數據交換。
3. 測試需覆蓋非標準locale：CI/CD管道中加入「非標準區域設置」測試環境（如帶星期的日期格式、逗號作小數點的德語環境）。

後記

雖直接調試服務端更直觀，但服務為第三方所有，只能適配其接口契約。契約雙方必須用顯式、標準化、無歧義的格式交換數據——這是分布式系統生存的鐵律。