這週幾個讓人印象深刻的 bug，有一個共同特徵：它們在正常路徑跑第一筆之前根本不會出現。期貨平台的策略引擎把「計算太慢」製造成了「外部報價斷線」的假象；股票下單的兩個邊界條件，一個需要等 session 自然老化，一個需要兩個非同步寫入在毫秒內碰撞——測試環境幾乎無法複現，只有真實盤中才會觸發。另一條線是 FATE 網站在域名遷移後靜默發酵了一段時間的 SEO 問題，以及電子發票模組一個對法律合規有直接影響的設計取捨。
鎖競爭把「計算慢」偽裝成「外部服務掛掉」 #
期貨平台連續數日崩潰，日誌看起來是外部報價 API 斷線。這種歸因很自然——外部 API 不穩定是常見情況，但若停在這裡，問題永遠不會真正解決。實際上，真正的根源在平台自身，而且觸發條件是一個看似無害的參數調整。
排查後發現：策略暖身 K 棒數從 500 被調到 20,000，導致每根 K 棒收盤時策略引擎需持鎖重算兩萬根資料，耗時 33–38 秒。狀態 API 設計上同樣需要競爭同一把鎖，加上前端每 10 秒輪詢，鎖幾乎從未釋放。外部報價回呼進入等鎖佇列後，健康監控超過閾值，誤判為報價斷線，觸發重連，進而引發已知的原生元件崩潰。修正方向是解耦讀與算：狀態 API 改為讀取收盤時預算好的快取值，不再在查詢時觸發重算、不等鎖。查詢延遲從 30 秒以上降至 0.02 秒。
鎖的競爭者越多，健康監控誤觸的概率越高，愈容易把「計算慢」誤診成「外部服務故障」。設計高頻輪詢系統時，讀路徑與算路徑若共用同一把鎖，等於讓健康監控的可靠性直接依賴計算複雜度——這是一個值得在架構設計階段就隔離的耦合。
兩個只有真實下單才會踩到的邊界條件 #
量化交易系統在計畫單第一次走完真實下單路徑後，接連暴露兩個問題：送單回「未登入」、以及成交後計畫被標成未成交並跳過後續停損建單。這兩件事在回測與模擬環境中從未出現。
第一個問題：下單端只在系統啟動時登入一次，旗標永遠停在「已登入」，但券商那端的 session 會自然過期。在 ensure_login() 加入時效判斷（登入逾一定時間自動重登），讓每筆下單前強制通過此函式；若回應含登入失敗訊息則重登一次再重試，把兩條連線的 session 管理邏輯拉齊。第二個問題屬於競態：定期輪詢的成交同步比下單完成後的 finalize 步驟更早把記錄寫入資料表，finalize 後來才到，去重邏輯命中時回傳空值，呼叫端把它當「沒成交」，進而把計畫蓋成跳過並略過建停損單。翻查 Log 發現此模式數週前的賣單就曾出現，當時因方向不同無人察覺。修正是去重命中時改回傳既有的成交物件，讓呼叫端走成功分支。
Session 老化需要時間累積、競態需要兩個非同步寫入在毫秒內碰撞——這類邊界在測試環境幾乎不會出現。交易系統若只覆蓋正常路徑的整合測試，這種問題只能等真實盤中觸發後再補。處理後的驗證方式是縮短時間窗口人工重現 session 過期、以及模擬 SDK 回登入失敗，確認兩個分支都能正確走過。
域名搬家後 Google 靜默選了舊址當正本 #
FATE 網站域名遷移後，一段時間內工具頁在搜尋結果的排名沒有跟著走。文章頁沒事，但 23 個工具頁沒有宣告 canonical 標籤，Google 看到新舊兩個網址內容相同、無人指定正本，自行選了舊域名為正本，新網址反而被標為重複頁。
為 23 個工具頁各自加上指向自身新網址的 canonical，上線後逐頁抓取驗證。並針對核心工具頁送出優先爬取請求，避免等 Google 自然排程。廣告體驗方面，上線自動廣告後，手機頂端佔版廣告直接讓 AI 功能使用量歸零超過一天——這是廣告收益與用戶留存的典型取捨。頂端佔版廣告對點擊數沒有明顯提升，卻讓大量手機訪客在看到頁面內容前就離開；修正為關閉頂端動態錨定廣告，保留底部版本，並在 AI 等待期間（通常 20–60 秒）的空白時段插入廣告，不影響操作路徑。
域名遷移的 canonical 配置是最容易被遺漏的 SEO 細節之一：文章頁通常由 CMS 自動帶 canonical，但程式碼統一生成的工具頁往往沒有對應邏輯，需要逐類型確認。廣告位置的設計原則是：不讓廣告出現在用戶還沒看到核心功能的路徑上；用戶本來就在等待的空檔，才是曝光的好時機。
電子發票開錯據點：靜默回退還是當場報錯？ #
eMobile 電子發票系統新增多據點代開功能後，面臨一個設計選擇：當呼叫方指定的據點代碼不存在，或屬於不可代開的類型時，要靜默回退到預設總公司字軌，還是直接報錯？這個選擇不只是使用者體驗問題，而是法律合規問題。
選擇了「直接失敗」。據點字軌是財政部層級的法律對應，若靜默回退，外部系統拿到的發票號碼屬於錯誤據點，事後對帳或申報才會發現，修復成本遠高於當場報錯讓呼叫方重試。規格定為：帶了不存在的代碼、或帶了不可代開的類型，一律回傳失敗加說明，不消耗發票號碼。成功時回傳實際開票的據點代碼，讓外部系統可以主動核對，而非只信任請求有送出就等於開對了。驗證採資料庫複本沙盒，涵蓋五種路徑：帶正確代碼、不帶、帶空字串、帶不存在代碼、帶不允許類型，全部通過後才推正式版。
「靜默回退」在一般功能設計中是友善的，但在涉及法律義務的場景（發票字軌、報關號碼、帳務歸屬），靜默回退只是把錯誤推遲到更難修的地方。這類場景的正確預設是：查無就停、讓呼叫方知道、不消耗不可逆的資源。
本週其他進展 #
- Solar Monitor 逆變器通訊幀驗證補齊 — 延伸上週 BMS 的幀驗證修法，補上逆變器側的相同修正：送出前清殘留緩衝區、收到回應後驗 slave ID / FC / CRC 全對才接受，連線偵測改為「能讀到有效幀」才算真連線，消除重連後資料錯位問題。
- Solar Monitor pack2 假告警修復 — BMS 傳輸器 WiFi 偶發掉包導致亂碼幀觸發不存在的告警，加入 CRC 驗證後拒絕噪訊幀進資料庫，假告警問題解除。
- 寄售 Q3 封帳完成，全通路零負項 — 逐通路逐月以期初＋進貨－銷售交叉驗算，補錄 4 張 ERP 漏單後負項自然歸零，另完成 7 組分月調整單，最終全通路封閉、異常警告清單 0 筆。
- 寄售 PDF 解析器改版，支援多季格式 — 原解析器整份讀入導致多季資料混入同一月份；改版後依指定年月比對頁面標題選季，欄位定位改用表頭右緣錨定取代中心點座標，避免欄位因版面變動系統性偏移，81 個回歸測試全過。
- LINE AI 客服防插話機制改為資料庫持久化 — 原本的記憶體 10 分鐘窗口重啟即清；改為「只回第一句、6 小時內不再自動回」，狀態存資料庫，部署不會重置，確保真人接手後 AI 不再插話。
- 客戶日報假日判斷邏輯修正 — 移除「線上付款也算營業」的邏輯，改為只看門市本身（打卡或 POS 有交易）才算營業；對過去 70 天逐日回測，只有問題當天判斷結果改變，其他 69 天維持一致。
- 客戶系統新增退貨單列印功能 — A4 印上下兩聯（廠商收執＋門市存查），超過 8 品項自動改整頁單聯並提示印兩份，已作廢單自動附浮水印，退貨單號與廠商統編自動帶入。
- Invoice Lottery 手機版與重複登錄修正 — 修正手機版「活動辦法」頁面撐寬與標題圖示問題，修正重複登錄只顯示「已登錄過」的問題，審查結果通知信功能接上並在正式站實測通過。
- LCBTRAN eMobile 對接可行性評估完成 — 盤查 VFP 端僅 2 支 form 觸碰發票、實際只用 3 個第三方 API，確認「單一實例 + HTTP API」方案工作量最小；設計 4 支 API（含 preview 步驟以保留確認框體驗），回應格式設計為扁平字串以符合 VFP 無 JSON parser 限制。
- LCB 生產系統台車退回功能上線 — 燒胚室台車退回清除入室欄位、保留車上產品狀態，並發衝突以 SQL 層狀態檢查攔截；進口商品型號改為自由輸入加確認提示，查詢端同時涵蓋進貨記錄，約 300 筆歷史型號不一致完成批次修正，全部功能驗證後部署至測試站。
- 期貨平台回測移至獨立程序、封包大幅縮減 — 60 萬根 1 分 K 回測原本在主執行緒同步執行導致平台卡死；改為最多 2 個獨立程序與主服務隔離，回測結果封包從 27.6 MB 降至 1.3 KB，Log 下載時間從 155 秒降至 0.12 秒，69 筆積壓舊紀錄清理完畢。
- 期貨平台恢復流程狀態機修正 — 修正重啟恢復時重算結果蓋掉資料庫持倉、導致引擎誤以為無部位再開新單的狀態機順序 bug；改為若恢復時已存在未平倉單，部位以資料庫記錄為準，重算結果不得覆蓋。
- OMEinvn 永豐線上刷卡申請說明書完成並上線信用卡付款 — 完成永豐線上刷卡申請的網站營運說明書（PDF/Word 含截圖），網站加上信用卡付款選項，LINE Pay 審核通過後還原首頁。
- sunnypilot 橫向控制直線晃動改善 — 依 OP 要求橫向加速度判斷是否在直線，低於門檻時切換至更弱 P 增益，彎道維持原強度；建橫向閉迴路模擬以實際 Log 驗證，模擬顯示直線段手扶反推力降低 18–51% 才上車。
本週技術心得 #
這週看到一個反覆出現的工程模式：系統在某個條件下「看起來正常運作」，但底下有個狀態已經悄悄錯了，只是還沒被觸發到。期貨平台的鎖競爭讓健康監控的警報失去意義；下單系統的 session 旗標顯示已登入，但券商那端的會話早已逾期；電子發票的 fallback 邏輯讓外部系統誤以為開票成功。這些 bug 有一個共通的根治方向：讓系統「失敗得更吵」。不要讓錯誤悄悄滑過去、不要讓狀態旗標與底層現實脫鉤、不要讓靜默回退把錯誤推到下游才爆。對中小企業的 IT 系統而言，這個原則尤其重要——資源有限的情況下，真正貴的不是當場報錯，而是三週後在對帳或申報時才發現問題。在設計新功能時，值得提前問：「這個錯誤路徑如果被靜默吞掉，最晚什麼時候才會被發現？」答案越晚，設計就越需要改成當場報錯。
本文是 3Q 工程團隊的每週技術進度整理，由 Claude 協助編寫。內容聚焦技術類型與通用心得，不含客戶資訊。