容器調試從不重建鏡像？我的真實工作流是反著來

　　遇到過這種情況嗎：寫好的 React / Vue / Svelte 應用，在本地 localhost:3000 跑得無比絲滑，一打成 Docker 鏡像再運行，迎接你的要么是刺眼的白屏，要么是幽怨的 nginx 404，要么 API 請求全都向容器內部的 localhost 飛蛾撲火。換作以前的我，第一反應一定是改一句 console.log，重新跑 docker build -t my-app .，然后 docker run……如此往復，有一次竟然重復了 47 次。但現在的我不這么干了——我有了一個完全不同的調試工作流，而且第一條鐵律聽起來像在唱反調：絕不重建你還能探查到的鏡像。

　　我的轉變源于一次頓悟：一個正在運行的容器，其實就像一臺恰好能播送 JavaScript 的實時虛擬機。你可以戳它、給它開個 shell、甚至熱替換里面的文件。于是第一件事變得出奇簡單：如果啟動階段就崩了，比如環境變量沒載入、Nginx 配置寫岔了，我干脆不讓它正常啟動。我會用 docker run -it --rm my-app /bin/sh 這樣一條命令，強行把入口點改成 shell。進到容器內部后，接下來就是偵探時間：ls -la /usr/share/nginx/html 看靜態文件到底有沒有被打進去；cat /etc/nginx/conf.d/default.conf 檢查 Nginx 配置是不是真的如我期望；env | grep VITE_ 這條命令更是救命稻草，它能一眼看穿那些構建時需要的環境變量到底還在不在。相信我，光是這一步就解開了我 80% 的“應用為何加載不了”的謎團。

　　嘗到甜頭之后，我開始反其道而行之——哪怕是在接近生產環境的測試里，我也會徹底放棄鏡像里那套靜態文件。用 docker run -p 8080:80 -v $(pwd)/dist:/usr/share/nginx/html -v $(pwd)/nginx.conf:/etc/nginx/conf.d/default.conf my-app 這樣一掛載，我就能在宿主機上眼也不眨地 rebuild dist 目錄，瀏覽器刷新一下，容器立刻就能看到新文件。更有甚者，對于 Vite、Create React App 這類開發服務器，我會把整個源碼和 node_modules 一起綁掛進去，再用一個匿名卷 /app/node_modules 來保護容器自己的 node_modules 不被宿主機系統覆蓋。這在當時像個偏方，卻讓我徹底忘了“改一行代碼就要推倒重來”的噩夢。

　　至此，我的工具包里還差一件“臟”兵器——我管它叫核選項。有時候只想驗證一行極小的修復，改完卻不想再等那該死的鏡像構建，我就會用 docker exec -it my-running-container /bin/sh 闖進正在運行的容器，然后直接在里面改動文件。當然，vi 可能壓根沒裝，但那又怎樣？用 echo 'console.log("debug")' >> /usr/share/nginx/html/index.html 這種土辦法，也能立刻把調試語句塞進頁面。這個方法確實有點臟亂，但它每次都能給我省下整整 2 分鐘的重建時間——一次都不例外。

　　網絡問題和 API 調用是前端容器化的另一座墓場。很多同行在這里翻車，都是因為在容器里說 localhost 時，指的根本不是宿主機，而是那個孤獨的容器自身。所以我養成了一個習慣：一旦 API 返回 500 或者冒出煩人的 CORS 錯誤，我立刻用 docker exec -it my-container /bin/sh 切入內部，然后嘗試直接連那個后端服務。如果 wget 還在，我就跑 wget -O- http://backend-service:8080/api/health；要是 wget 被精簡掉了，就用 cat < /dev/tcp/backend-service/8080 探測端口通不通。最關鍵的是，在折騰這些之前，我一定會先翻一翻構建后的 JS 文件——因為那些被靜態打包進去的接口地址，往往就是所有困惑的源頭。

　　這些步驟擱在一起，其實就做了一件事：把“猜—改—建—等”的死循環，替換成“進入—探查—熱改—確認”的即時環。以前我把容器當成一個需要不斷雕刻的石像，現在我卻把它當成一扇隨時能打開的窗戶。如果你也曾經深陷在 docker build 和 docker run 之間的等待地獄里，不妨下次故意打破一次“必須重建”的慣性。也許你會發現，那條看似懶散的反向路徑，恰好是解決問題的唯一快車道。