壓縮檔準備傳給廠商，才想起來：API 金鑰有沒有一起打包出去？
壓縮檔傳出去、金鑰也跟著出去了
系統做好了，工程師說要交接、或者要打包給新廠商接手。您把整個資料夾壓縮成 ZIP，準備上傳到雲端硬碟——滑鼠停在「傳送」按鈕前，突然想起一件事：裡面有沒有 API 金鑰？資料庫密碼會不會也在裡面？
這個擔心不是多餘的。<cite index="7-3,7-4">今年五月一場大規模勒索攻擊，駭客就是靠掃描公開的 .env 檔案，取得超過 11 萬個網域的雲端帳號與社交媒體憑證，然後入侵、竊取資料、再勒索這些組織</cite>。這些 .env 檔原本該留在開發者自己的電腦上，卻因為各種原因——上傳到 GitHub、夾帶在交接壓縮檔、或直接部署到公開伺服器——變成了駭客的藏寶圖。
當您手上有個想上線或想交接的系統，這一步檢查不能跳過。
.env 檔是什麼、為什麼它這麼危險
.env 是一個純文字檔案，開發者用它來存放「會隨環境改變的設定值」。<cite index="19-3,19-4">開發時可以在專案根目錄建立一個 .env 檔來存放環境變數，例如 Node.js 應用程式可以用 dotenv 套件來載入這個檔案</cite>。裡面通常會放這些內容：
- 資料庫連線字串與帳號密碼
- 第三方服務的 API 金鑰（金流、簡訊、Email 發送服務）
- JWT 簽章密鑰
- 不同環境的伺服器網址（測試站 vs. 正式站）
這些值「不該寫死在程式碼裡」，因為開發環境、測試環境、正式環境用的資料庫不一樣、金鑰也不一樣。<cite index="23-3,23-4">不同環境絕對不要共用憑證——開發、測試、正式環境應該使用完全不同的密鑰，例如 Stripe 測試金鑰是 sk_test_... 開頭，正式金鑰則是 sk_live_... 開頭</cite>。
但危險就在這裡：因為 .env 是純文字、沒有加密，一旦外洩，就等於把整套系統的鑰匙交出去了。
上線前、交接前該檢查的三件事
1. 確認 .env 不會被版本控制系統追蹤
<cite index="19-5">請務必將 .env 加入您的 .gitignore 檔案，避免意外提交到版本控制系統</cite>。如果您用的是 GitHub、GitLab 或 Bitbucket，打開專案根目錄的 .gitignore 檔案，確認裡面有這幾行：
.env
.env.local
.env.*.local
如果您已經不小心 commit 過 .env，刪掉檔案再 commit 是不夠的——Git 的歷史紀錄裡還會留著。這時候您需要用 git filter-branch 或 BFG Repo-Cleaner 工具清除歷史紀錄，或者更直接的做法：立刻更換所有外洩的金鑰與密碼。
2. 改用 .env.example 來交接「格式」而非「內容」
<cite index="25-3">應該提交 .env.example 檔案到版本控制系統——它列出所有應用程式需要的環境變數，但使用佔位符或安全的預設值（絕不包含真實的機密資料）</cite>。交接時，您給出的是長這樣的檔案：
DATABASE_URL=postgresql://localhost:5432/myapp_dev
STRIPE_SECRET_KEY=sk_test_請向金流商申請
JWT_SECRET=請自行產生一組隨機字串
API_BASE_URL=https://您的正式網域.com
接手的人看到這個範例檔，就知道該去哪裡申請金鑰、該設定什麼格式，但不會拿到您的真實憑證。
3. 壓縮檔傳出去之前，先掃一次敏感字串
您可以用簡單的搜尋指令，在整個專案資料夾裡找出可能外洩的內容：
- macOS / Linux：
grep -r "API_KEY\|SECRET\|PASSWORD" . --exclude-dir=node_modules - Windows PowerShell：
Select-String -Path .\* -Pattern "API_KEY|SECRET|PASSWORD" -Exclude node_modules
如果搜尋結果出現 .env 或任何設定檔的真實金鑰，請在壓縮前先移除這些檔案，或者改用 .env.example 取代。
實務上，許多團隊會在 CI/CD 流程加入自動掃描工具（例如 git-secrets、TruffleHog），在每次 commit 時自動檢查有沒有意外提交的金鑰。
正式上線時，金鑰應該放在哪裡
<cite index="19-11,19-12,19-13">部署到 Heroku、Vercel 或 AWS 等平台時，絕對不要上傳 .env 檔案。這些平台提供安全的介面，讓您在它們的控制台中定義環境變數。這個做法確保機密資料經過加密，且永遠不會存在程式碼裡</cite>。
如果您是部署到自己租的主機（VPS、Docker、Kubernetes），<cite index="20-8,20-9">在 Docker 中可以透過 docker-compose.yml 或 --env-file 參數傳遞環境變數；在 Kubernetes 則從 ConfigMaps 或 Secrets 掛載環境變數，並確保敏感資料已加密存放</cite>。
簡單說：開發時用 .env 檔、但絕對不要把它推上 Git 或打包給別人；正式上線時，改用主機平台提供的環境變數設定介面。
如果已經外洩了，該怎麼辦
發現 .env 被上傳到 GitHub、或者已經壓縮傳給廠商了，該怎麼處理？
- 立刻更換所有金鑰與密碼：不要等、不要觀望，直接去服務商後台重新產生新的 API 金鑰，資料庫密碼也一併更新。
- 檢查存取紀錄：如果是雲端服務（AWS、Azure、Firebase），進後台查看最近的 API 呼叫紀錄與登入紀錄，確認有沒有異常存取。
- 通知相關人員：如果是交接情境，告知接手廠商這組金鑰已經失效、請他們改用新的；如果是公開外洩（例如 GitHub public repo），建議您同時檢查系統是否已經被入侵。
<cite index="25-4">環境變數管理並不光鮮亮麗，但它是基礎建設。一個設定錯誤的變數可能導致系統中斷、資安漏洞，或浪費數小時的工程時間</cite>。
下一步：讓交接變成可以重複執行的流程
如果您手上的系統準備交給維護廠商、或者內部 IT 同仁要接手，環境變數只是交接清單的一部分。完整的交接還包括程式碼版本庫所有權、資料庫備份與還原演練、API 文件、以及部署流程說明。
AI 上線專家提供程式碼健診服務，我們會幫您檢查專案裡有沒有意外夾帶的金鑰、哪些設定該搬到主機環境變數、以及交接文件該怎麼準備。如果您現在正準備壓縮檔、不確定裡面有沒有該刪的東西，歡迎聯絡我們預約一次 30 分鐘的免費諮詢——我們會陪您一起把這份檢查清單走完，讓交接可以安心進行。