Docker Bind Mount + fsnotify 熱載入限制¶
概念概覽
核心限制¶
核心知識¶
核心限制¶
Docker bind mount 掛載的檔案，在 host 端修改時，fsnotify 在 container 內不會收到 inotify 事件，導致依賴 fsnotify 的 config 熱載入完全失效。
影響場景¶
體力恢復 bot 測試需要操控 config（如縮短恢復間隔），若依賴檔案修改觸發熱載入，在 Docker 環境下測試會靜默失敗——檔案確實被改了，但 server 完全沒收到變更通知。
正確解法¶
// setup: 直接修改記憶體中的 config 值
originalInterval := config.StaminaRecoveryInterval
config.StaminaRecoveryInterval = 1 * time.Second
// teardown: 還原，避免影響並行測試
defer func() {
config.StaminaRecoveryInterval = originalInterval
}()
優點：完全繞過 fsnotify，可控、不影響前端環境
缺點：測試的不是真實 config 載入路徑（CI 可接受的妥協）
長期方案¶
若需要真正測試熱載入，Docker compose 應改用支援 inotify 的掛載方式，或改用 polling-based config watcher（viper 支援 WatchConfig with polling）。
經驗教訓¶
-
Docker bind mount 上的 fsnotify 不觸發是已知限制，設計測試策略前必須考量此點
-
config 熱載入測試在 Docker 環境下需要改用記憶體操控 + teardown 還原模式
-
setup/teardown 中的 config 還原邏輯需驗證不影響並行測試（避免 global state 污染）
常見陷阱¶
-
在 Docker 環境下修改 bind mount 檔案後等待 config 熱載入生效，實際上 server 永遠不會收到事件
-
忘記在 teardown 還原 config，導致後續並行測試使用錯誤的 config 值
最佳實踐¶
-
bot/integration test 中需操控 config 時，優先使用記憶體直接賦值 + defer 還原
-
teardown 還原邏輯應在測試開始時捕捉原始值，而非硬寫預設值
相關概念¶
- bot-testing----dangling-------dangling---
- Docker K8s Init Script Permission Inheritance
- ECR Image Deployment Pattern
- jenkins-pipeline----dangling-------dangling---
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-20 | d9903c52-a136-4d3b-b5d9-99c8d0c4d1c1 | 發現 Docker bind mount 環境下 fsnotify 不觸發的關鍵限制，確立 bot 測試中 config 操控的正確策略 |