條碼的幽靈：安全與現實的角力

昨天把產品管理的 CRUD 骨架穩住後，今天直接把精力放在條碼掃描的擴展。理由很簡單：如果輸入數據不可靠，後面的分析再巧都只是表面工夫。

先整理了幾個後端細節，把多餘的 SQL 彈性收斂，移除那些看似靈活、實則增加風險的參數，順手解了一些依賴問題。結論很直白：簡化後更安全，查詢也不再繞路。

真正的麻煩在測試。新增了無效檔案類型、空檔案、損壞圖片、過大檔案等案例，還做了並發掃描的壓力測試。因為 CRUD 調整後，條碼必須唯一，不然產品建立會互撞。我把條碼欄位拉到 50 個字元以支援更多格式，結果第一輪就被並發情境打臉：同時掃描時資料庫鎖衝突，只好重做索引與鎖機制，半天就這樣沒了。

不過調整之後，建立流程穩定許多。我也把分析摘要的 API 從圖片上傳改成用產品流水號生成，少了上傳複雜度，JSON 結構更一致，回傳格式就不再時好時壞。文檔同步更新，錯誤碼與備援機制一並寫清楚。

情緒上還是會懷疑「這樣折騰值不值？」但這些看似瑣碎的調整，確實讓系統更結實。接下來會盯著各模組和分析核心的互動，避免再掉進無限迴圈。

條碼掃描告一段落後，我把時間投到 ingrelens-app 的重構，希望更貼近 Next.js 的做法。原以為是小手術，實作起來才發現每改一個檔案，都牽動三個組件的路徑與依賴，像拆線頭一樣，一扯就亂。

後端加入了 API 重寫規則，讓請求能穩定地進到服務層。原本考慮 proxy，但最後選重寫：URL 乾淨、跳轉少，失敗面也比較好控。延續前一日的產品端點，新增了危險成分分析與結果回傳（BEAPI-10），把資料庫連線改用連線池，避免並發時再遇到 deadlock。

這些工事讓響應格式更一致、讀寫更順，不再為小異常耗盡耐心。README.md 和 api.md 都補完，免得之後重構再踩同一個坑。

總的來說，今天的重構不輕鬆，但骨架更穩，前後端的邊界也清楚了。離想像中的整合還有段距離，但至少走在正確方向上。