HelmetDetect 工地安全帽偵測平台

CHALLENGE

Picture / Result / Comment 三個 Eloquent 模型沿用了複數表名的預設,但 migration 建的是單數表;而且程式讀寫 picture.file_name,schema 裡的欄位卻叫 url。也就是說,那三個模型的每一次查詢都必定失敗。

SOLUTION

在每個模型上明確釘死 $table,並把 schema 對齊程式實際讀寫的欄位:picture.url 改名為 file_name、補上 result.result_file_name。這類錯誤靜態看程式碼看不出來,是從「哪一行讀哪一個欄位」逐條比對 migration 才浮現的。

CHALLENGE

上傳流程有兩個會在真實流量下爆掉的地方:upload() 先呼叫 store() 把暫存檔搬走,之後才用 getRealPath() 讀位元組;而 Flask 的回應直接以 $res['detection'] 取用,推論服務一旦掛掉或回傳別的東西,使用者拿到的是 undefined index。

SOLUTION

把讀取位元組與原始檔名提前到 store() 之前,並在原地留下註解說明為什麼順序不能換;Flask 回應改成先檢查 ->ok() 再檢查 detection 欄位存在,兩種失敗各自回 502。同時把 checkAction() 從隱含回傳改成明確回傳布林,並修掉 401 訊息把 "token invalid" 寫成 "token is valid" 的錯字。

CHALLENGE

準備公開時的檢查翻出一批不該外流的東西:/user/info 直接把 User 模型序列化回去、密碼雜湊跟著出去;忘記密碼流程寫的是 reset_code / reset_expires_at 這兩個 migration 根本沒建的欄位,所以整條流程不可能成功;updateUser() 會把 account 覆寫成電話號碼,登入識別直接被改掉;MailController 有寫死的 Gmail 帳密,app.py 有寫死的 MySQL 連線資訊。

SOLUTION

在 User 模型上設 $hidden 擋掉 password 與重設欄位、改用真正存在的 password_reset_code / password_reset_expires_at、刪掉那行覆寫 account 的賦值;SMTP 與 MySQL 連線資訊全部改讀環境變數並附 .env.example(只有佔位值),app.py 的 finally 區塊也補上連線從未建立時的保護。另外把 UserSeeder 補成能真的登入的樣子——原本只產 faker 使用者、account 是隨機電話,README 宣稱的「種子示範帳號」在當時並不成立。

CHALLENGE

要讓這個專案能公開展示,但推論根本跑不起來:權重檔不在 repo 裡,Flask 服務也需要一台會裝 Python 與 Ultralytics 的機器。最省事的做法是在瀏覽器裡假裝有模型。

SOLUTION

選擇不假裝。資料轉接層加一個 demo 分支,讀的是 seed 裡寫死的正規化座標,並在畫面上把這件事講清楚:標題列掛「展示模式」標籤、上傳區直接寫「展示模式會以模擬結果呈現」。場景圖也不用照片——SceneImage.jsx 以 CSS 漸層畫出工地感的底,再把框疊上去,所以畫面上不會出現任何冒充成真實推論結果的東西。真正被測試涵蓋的是這一層:34 個 vitest 案例把 demo 分支釘住,包含「合規的場景不得捏造出標註圖檔名」與「新紀錄的 id 不得和種子撞號」。