很多人一聽到“環(huán)境變量”這四個(gè)字第一反應(yīng)多半是哦那個(gè)裝配置的小東西。其實(shí)它遠(yuǎn)遠(yuǎn)不止“裝配置”這么簡(jiǎn)單——程序啟動(dòng)時(shí)連哪個(gè)數(shù)據(jù)庫(kù)、走哪個(gè)網(wǎng)關(guān)、打哪種日志、在什么運(yùn)行環(huán)境里工作往往都被幾個(gè) KEYVALUE 的字符串拿捏得死死的。更麻煩的是環(huán)境變量和作用范圍、進(jìn)程繼承、平臺(tái)差異這些概念攪在一起之后出了問題特別難查代碼沒改動(dòng)、日志沒報(bào)錯(cuò)但行為就是不對(duì)。這篇文章我想把環(huán)境變量的作用、設(shè)置方法、常見誤區(qū)和排錯(cuò)思路一次性聊透讓你讀完能少走幾條彎路。1. 環(huán)境變量最容易被誤解的底層邏輯注入、繼承和進(jìn)程的“出廠配置”1.1 一次半夜排查出來的“玄學(xué)”問題有段工作經(jīng)歷我印象很深。一個(gè)后臺(tái)任務(wù)在服務(wù)器上跑了好幾個(gè)星期都正常某天半夜突然收到一批數(shù)據(jù)沒處理的消息。日志翻了兩三輪代碼也對(duì)比過看不出任何問題最后才發(fā)現(xiàn)配置源根本沒對(duì)上——程序讀的數(shù)據(jù)庫(kù)地址是代碼里的默認(rèn)值而那個(gè)默認(rèn)值只能在舊測(cè)試環(huán)境里勉強(qiáng)連通。為什么會(huì)讀默認(rèn)值因?yàn)槿蝿?wù)在新節(jié)點(diǎn)上啟動(dòng)時(shí)缺了一個(gè)類型為APP_ENV的環(huán)境變量。程序判斷不出“現(xiàn)在到底在哪種環(huán)境”干脆落回了兜底分支。就這么一個(gè)變量的缺失沒有任何報(bào)錯(cuò)卻讓整條數(shù)據(jù)鏈路靜悄悄地跑偏。這件事給我的沖擊挺大環(huán)境變量平時(shí)不顯山不露水但它直接決定程序抓到的是哪一套配置。缺變量不會(huì)像編譯報(bào)錯(cuò)一樣給出提示更多時(shí)候是程序老老實(shí)實(shí)用了某個(gè)默認(rèn)值反而不容易被發(fā)現(xiàn)。后來我再做排查第一反應(yīng)永遠(yuǎn)是先確認(rèn)負(fù)責(zé)接收指令的進(jìn)程它是在什么環(huán)境里出生的。1.2 環(huán)境變量到底在系統(tǒng)里長(zhǎng)什么樣要說清楚環(huán)境變量得先看操作系統(tǒng)底層的做法。進(jìn)程被創(chuàng)建時(shí)會(huì)自己攜帶一個(gè)“環(huán)境塊”這個(gè)環(huán)境塊本質(zhì)就是一串KEYVALUE的字符串集合。父進(jìn)程啟動(dòng)子進(jìn)程時(shí)會(huì)把環(huán)境塊復(fù)制一份給子進(jìn)程之后兩者就各過各的。子進(jìn)程改了環(huán)境變量父進(jìn)程不知情旁邊的兄弟進(jìn)程也一點(diǎn)都不受影響。這也是“環(huán)境變量”名字的來源它不是全局公告板而是圍繞某個(gè)進(jìn)程的“環(huán)境”。程序雖然能看到自己的環(huán)境塊但如果修改發(fā)生在進(jìn)程啟動(dòng)之后程序能不能感知到取決于語(yǔ)言和運(yùn)行時(shí)是否提供了額外接口。絕大多數(shù)編程語(yǔ)言的實(shí)現(xiàn)就是把進(jìn)程啟動(dòng)那刻的環(huán)境快照放進(jìn)字典里供程序查詢Python 里是os.getenvJavaScript 運(yùn)行時(shí)里有process.envJava 里也有System.getenv()。我當(dāng)年一直誤會(huì)環(huán)境變量是“寫到系統(tǒng)某個(gè)地方、所有程序隨時(shí)都能去讀的公共配置”。實(shí)際完全不是這樣。它是每個(gè)進(jìn)程的私有出廠配置啟動(dòng)時(shí)注入之后各自持有互不廣播。想明白這一點(diǎn)“為什么改了環(huán)境變量有些程序還是讀不到”這個(gè)問題就已經(jīng)解決一半了。1.3 為什么配置文件替換不了環(huán)境變量那干脆不用環(huán)境變量全部走配置文件行不行行但有兩個(gè)很現(xiàn)實(shí)的問題。第一一臺(tái)機(jī)器上往往跑著由多級(jí)進(jìn)程組成的任務(wù)鏈你必須把配置文件路徑一層層傳下去。某個(gè)中間環(huán)節(jié)漏傳子進(jìn)程就不知道自己該讀哪個(gè)文件。第二配置文件通常需要程序自己定義解析邏輯不同語(yǔ)言不同項(xiàng)目風(fēng)格都不一樣項(xiàng)目多了之后維護(hù)成本并不低。命令行參數(shù)也是個(gè)好辦法但參數(shù)會(huì)出現(xiàn)在進(jìn)程列表和日志里一個(gè)程序被嵌套啟動(dòng)多層時(shí)通過命令行把參數(shù)一層層傳下去的維護(hù)成本高得嚇人。環(huán)境變量的優(yōu)勢(shì)恰好在這兩點(diǎn)上它天然具備“繼承”屬性只要在父進(jìn)程這一級(jí)設(shè)置好子子孫孫都會(huì)自動(dòng)攜帶不需要額外寫傳遞邏輯同時(shí)它又不屬于進(jìn)程列表的默認(rèn)展示范圍只要控制好讀取權(quán)限暴露風(fēng)險(xiǎn)可控。所以環(huán)境變量不是配置文件的替代品而是夾在“進(jìn)程啟動(dòng)邊界”和“配置信息傳遞”之間的輕量粘合劑。它最合適放的是那些不常變動(dòng)、但會(huì)影響進(jìn)程初始行為的開關(guān)和參數(shù)。2. 分清三層作用范圍再動(dòng)手系統(tǒng)級(jí)、用戶級(jí)、臨時(shí)級(jí)的邊界與優(yōu)先級(jí)2.1 三層作用范圍各有各的“勢(shì)力范圍”剛接觸環(huán)境變量時(shí)最容易踩的坑是分不清“這臺(tái)機(jī)器都會(huì)用我的變量”和“只有我這個(gè)終端窗口能用到我的變量”。實(shí)際上按作用范圍可以分為三層系統(tǒng)級(jí)、用戶級(jí)、臨時(shí)級(jí)。系統(tǒng)級(jí)就是機(jī)器上所有用戶都能生效的配置通常適合放那些全機(jī)器共同依賴的底層路徑、默認(rèn)編輯器之類的項(xiàng)目用戶級(jí)是某個(gè)登錄用戶自己的配置比如個(gè)人常用的開發(fā)工具路徑臨時(shí)級(jí)則只在當(dāng)前 shell 會(huì)話和它后續(xù)啟動(dòng)的子進(jìn)程里生效窗口一關(guān)就沒了。作用范圍生效對(duì)象Unix/macOS 常見寫入點(diǎn)Windows 常見寫入點(diǎn)臨時(shí)級(jí)當(dāng)前 shell 會(huì)話及子進(jìn)程export、命令前綴賦值cmd 的set、PowerShell 的$env:名稱用戶級(jí)當(dāng)前用戶新啟動(dòng)的進(jìn)程~/.bashrc、~/.zshrc、~/.profile用戶環(huán)境變量對(duì)話框、setx系統(tǒng)級(jí)全機(jī)器所有用戶的新進(jìn)程/etc/environment、/etc/profile系統(tǒng)環(huán)境變量對(duì)話框、注冊(cè)表這么分層的好處是臨時(shí)調(diào)試變量不需要污染全局環(huán)境個(gè)人偏好不會(huì)影響其他同事真正全機(jī)器通用的底層配置又有一個(gè)集中入口。2.2 變量沖突時(shí)到底聽誰(shuí)的環(huán)境變量在不同層級(jí)出現(xiàn)同名時(shí)優(yōu)先級(jí)通常遵循“離目標(biāo)進(jìn)程越近越優(yōu)先”的原則。系統(tǒng)級(jí)先被注入用戶級(jí)后疊加所以用戶級(jí)一般會(huì)覆蓋系統(tǒng)級(jí)當(dāng)前 shell 里再設(shè)置一次又會(huì)覆蓋用戶級(jí)如果只是在啟動(dòng)某一條命令前臨時(shí)設(shè)置那這條命令看到的是所有層級(jí)里最新的那個(gè)值。Windows 的邏輯也類似。系統(tǒng)變量先作為底子用戶變量再疊加程序最終讀到的往往是組合后的結(jié)果。只是這里要注意Windows 環(huán)境變量名的匹配通常不區(qū)分大小寫而 Linux/macOS 是嚴(yán)格區(qū)分大小寫的所以跨平臺(tái)巡檢時(shí)要格外留意。層疊的優(yōu)先級(jí)并不難理解難的是別想當(dāng)然。不要憑直覺判斷“應(yīng)該覆蓋了”最可靠的辦法是啟動(dòng)目標(biāo)進(jìn)程后用打印命令看它實(shí)際拿到的值。2.3 共享機(jī)器上作用域惹出的麻煩有段時(shí)間我們?cè)诠查_發(fā)機(jī)上維護(hù)一個(gè)定時(shí)任務(wù)某位同事圖省事把個(gè)人的默認(rèn)編碼寫進(jìn)了/etc/profile。結(jié)果其他同事一登錄某編程語(yǔ)言的輸入輸出格式全變了一排查就莫名其妙的跑去翻代碼。最后才發(fā)現(xiàn)是系統(tǒng)級(jí)環(huán)境變量被塞進(jìn)了本該屬于用戶級(jí)的東西。這類問題的根源就是把作用范圍搞混了。我的建議是除非整個(gè)機(jī)器上的每一個(gè)用戶確實(shí)都需要否則一律不要?jiǎng)酉到y(tǒng)級(jí)即使是用戶級(jí)也盡量只放那些行為穩(wěn)定、不會(huì)讓程序運(yùn)行結(jié)果大漂移的配置。登入一臺(tái)共享服務(wù)器先用echo把關(guān)鍵變量打出來確認(rèn)一遍比出了問題再靠猜要快得多。3. Windows、macOS、Linux 下的設(shè)置方法位置找對(duì)了才算真的改了3.1 臨時(shí)設(shè)置當(dāng)前終端會(huì)話里蓋上一個(gè)小印章臨時(shí)設(shè)置是最常用也最容易理解的。在 Linux/macOS 的終端里執(zhí)行一條export只影響當(dāng)前 shell 以及從當(dāng)前 shell 新啟動(dòng)的子進(jìn)程。export APP_ENVdevelopment echo $APP_ENV終端窗口開著后面啟動(dòng)的程序都能讀到窗口一關(guān)這個(gè)變量立即消失不落盤也不影響別人。臨時(shí)設(shè)置還有一種更“收縮”的寫法變量只對(duì)緊接著的那一條命令生效。APP_ENVproduction node app.js這樣寫的妙處在于它不會(huì)污染當(dāng)前 shell 的后續(xù)命令適合手工調(diào)試某些特殊分支。Windows 下同樣有臨時(shí)設(shè)置的辦法PowerShell 用$env:前綴修改cmd 用set。$env:APP_ENV developmentset APP_ENVdevelopment臨時(shí)設(shè)置要記住一個(gè)邊界它只對(duì)“設(shè)置之后新啟動(dòng)的進(jìn)程”有效。同一個(gè)窗口里已經(jīng)跑起來的程序仍然拿著它啟動(dòng)那一刻的環(huán)境快照。3.2 永久設(shè)置寫進(jìn)對(duì)應(yīng)的“開機(jī)配置抽屜”想讓變量每次登錄都在不能只敲 export得把它寫進(jìn) shell 的配置文件里。在 Linux/macOS 上最常見的位置是~/.bashrc、~/.zshrc、~/.profile這幾個(gè)文件。把export APP_ENVdevelopment追加進(jìn)去后新開的終端會(huì)話就會(huì)自動(dòng)加載。要注意不同發(fā)行版對(duì)不同 shell 文件的讀取時(shí)機(jī)不完全一樣登錄 shell 和非交互式 shell 可能讀不同的文件。我的辦法是設(shè)完后立刻執(zhí)行一句source ~/.bashrc或?qū)?yīng)的配置文件再開一個(gè)新窗口驗(yàn)證而不是想當(dāng)然地認(rèn)為下次一定生效。Windows 永久設(shè)置最有代表性的兩種方式圖形界面操作和命令行setx。圖形操作路徑很直觀打開系統(tǒng)屬性進(jìn)入“環(huán)境變量”設(shè)置窗口里面分“用戶變量”和“系統(tǒng)變量”兩個(gè)列表改完后點(diǎn)確定即可。命令行則用setxsetx APP_ENV development需要特別提醒剛執(zhí)行完setx當(dāng)前那個(gè)終端窗口仍然是老環(huán)境必須新開一個(gè)窗口或者干脆重啟目標(biāo)程序它才能讀到新值。這一點(diǎn)和 Unix 的source概念完全不同很多人第一次用 setx 都會(huì)被坑。macOS 還要再多說一句Finder 里雙擊啟動(dòng)的圖形應(yīng)用并不是從你的 shell 里啟起來的它多半繼承的是桌面會(huì)話環(huán)境不會(huì)讀你在終端里設(shè)置的環(huán)境變量。想讓圖形應(yīng)用方便讀到要么寫進(jìn)~/.zprofile這類文件后重新登錄要么通過系統(tǒng)級(jí)的啟動(dòng)服務(wù)配置管理環(huán)境。實(shí)際項(xiàng)目中我們最常用的驗(yàn)證路徑就是“從終端啟動(dòng)應(yīng)用”至少能快速確認(rèn)程序本身讀環(huán)境變量的邏輯是正常的。3.3 跨平臺(tái)自檢小命令清單配置完環(huán)境變量最忌諱“感覺應(yīng)該生效了”。我整理了一份可以直接對(duì)照的自檢命令目的Linux/macOSWindows PowerShell查看單個(gè)變量echo $APP_ENV$env:APP_ENV查看全部變量env或export -pGet-ChildItem Env:臨時(shí)設(shè)置export APP_ENVdev$env:APP_ENVdev永久設(shè)置寫入 profile 文件后重新登錄setx APP_ENV dev后新開窗口順便提醒一句不要為了“確認(rèn)環(huán)境有沒有配好”就把所有變量全部打印到日志里。尤其是那些可能包含密鑰性質(zhì)的變量等級(jí)得守住。4. 把環(huán)境變量用起來一套配置在開發(fā)、測(cè)試、生產(chǎn)之間切換的實(shí)用做法4.1 后端服務(wù)切換環(huán)境的完整流程假設(shè)一個(gè)后端服務(wù)要連不同的數(shù)據(jù)庫(kù)開發(fā)連本機(jī)測(cè)試連測(cè)試庫(kù)生產(chǎn)連正式庫(kù)。最少需要APP_ENV、DB_HOST、DB_PORT、LOG_LEVEL這四類變量。我在項(xiàng)目里習(xí)慣放一份.env.example把需要的變量名、含義、示例值全部列清楚真正的.env文件只保存在本地不納入代碼倉(cāng)庫(kù)。啟動(dòng)腳本負(fù)責(zé)把.env里的內(nèi)容加載進(jìn)環(huán)境塊#!/usr/bin/env bash set -a if [ -f .env ]; then source .env fi set a exec python app.py這里的set -a值得單獨(dú)解釋一下它的作用是把所有加載進(jìn)來的變量自動(dòng)標(biāo)記為導(dǎo)出省去手動(dòng)寫一串export的麻煩。exec則讓后邊的程序直接接管當(dāng)前進(jìn)程避免多留一層 shell 造成信號(hào)傳遞路徑變復(fù)雜。Windows 下也可以寫一個(gè)等價(jià)的 PowerShell 啟動(dòng)腳本if (Test-Path .env) { Get-Content .env | ForEach-Object { if ($_ -match ^\s*([^#][^]*)(.*)$) { $key $matches[1].Trim() $value $matches[2].Trim() Set-Item -Path Env:$key -Value $value } } } python app.py到了生產(chǎn)環(huán)境我通常不建議再手動(dòng)拷貝.env文件。更穩(wěn)妥的方式是讓部署平臺(tái)的服務(wù)配置、配置中心或者編排系統(tǒng)把變量直接注入到進(jìn)程啟動(dòng)環(huán)境里這樣變量仍然屬于環(huán)境變量但來源是可控的、集中的也方便回滾。4.2 關(guān)鍵變量命名、默認(rèn)值與密鑰存儲(chǔ)的取舍命名方面我的習(xí)慣是“前綴_含義_用途”的結(jié)構(gòu)全部大寫。比如ORDER_QUEUE_URL、PAY_CALLBACK_TIMEOUT_SECONDS。前綴用來區(qū)分屬于哪個(gè)模塊避免多個(gè)項(xiàng)目在同一臺(tái)機(jī)器上互相撞名。名字夠清楚比注釋有用得多。默認(rèn)值的選擇也是一門學(xué)問。代碼內(nèi)部可以給普通配置提供默認(rèn)值比如日志級(jí)別默認(rèn)給到WARNING至少不會(huì)讓輸出瞬間爆炸但涉及關(guān)鍵連接、生產(chǎn)數(shù)據(jù)庫(kù)這類配置我更建議在啟動(dòng)時(shí)直接報(bào)錯(cuò)而不是“用默認(rèn)值硬著頭皮跑”。因?yàn)槟悴恢滥J(rèn)值在真實(shí)環(huán)境里會(huì)連到哪去出了事故再排查成本和風(fēng)險(xiǎn)都高得多。另外要強(qiáng)調(diào)安全環(huán)境變量不要用來保管真正的密鑰。很多教程隨口就說“把密鑰放到環(huán)境變量里”這只是一種通用做法不代表安全。同操作系統(tǒng)的同用戶權(quán)限下很多進(jìn)程都有能力讀取可訪問的環(huán)境變量。生產(chǎn)環(huán)境請(qǐng)使用專門密鑰管理服務(wù)或外部配置中心本地開發(fā)也盡量采用最小權(quán)限原則。連接字符串之類的普通配置文件放環(huán)境變量沒問題真正的憑據(jù)別這么干。4.3 給團(tuán)隊(duì)留一條“環(huán)境變量自查”的快捷通道環(huán)境變量這種配置最怕的就是大家各猜各的。我后來會(huì)在項(xiàng)目里放一個(gè)極小的啟動(dòng)前檢查腳本核心邏輯只有幾步列出必要變量檢查是否存在存在就放行不存在就明確報(bào)錯(cuò)。import os required [APP_ENV, DB_HOST, LOG_LEVEL] for key in required: value os.getenv(key) if not value: raise SystemExit(f缺少環(huán)境變量: {key}) print(f{key} 已設(shè)置)注意檢查腳本本身不要打印變量的真實(shí)值只確認(rèn)“非空”就夠了。這樣隊(duì)友換到新環(huán)境跑一遍就知道是缺配置還是程序有問題能省掉大量“你幫我看看日志”的往返溝通。5. 排錯(cuò)實(shí)錄四種“變量明明設(shè)了程序卻讀不到”的高頻原因5.1 勝負(fù)往往在“啟動(dòng)時(shí)刻”改完變量沒重啟目標(biāo)進(jìn)程最常見也最隱蔽的一種情況是在終端里設(shè)置了變量echo出來也確實(shí)有值但某個(gè)常駐服務(wù)就是讀不到。原因回到第一節(jié)說的機(jī)制環(huán)境變量復(fù)制發(fā)生在進(jìn)程創(chuàng)建瞬間。進(jìn)程一旦起來你后面再怎么改都影響不到它。所以目標(biāo)進(jìn)程必須重啟而且重啟方式要匹配變量的來源。如果服務(wù)是通過服務(wù)管理器或者編排系統(tǒng)拉起的那就應(yīng)該改服務(wù)配置里的環(huán)境變量而不是只改 shell 窗口。我自己的習(xí)慣是修改環(huán)境變量后做一次“真正意義上的全新啟動(dòng)”。這里要特別注意很多 IDE 和服務(wù)管理工具點(diǎn)“重啟”其實(shí)是在舊進(jìn)程基礎(chǔ)上做熱拉起的環(huán)境不一定更新。干脆退出全部相關(guān)進(jìn)程再拉起比什么都穩(wěn)妥。5.2 大小寫、空格和引號(hào)符號(hào)層面造成的讀不到第二類問題出在名字和賦值格式的細(xì)節(jié)上。Linux/macOS 的環(huán)境變量嚴(yán)格區(qū)分大小寫DB_HOST和db_host是兩個(gè)完全不同的變量。Windows 通常不區(qū)分大小寫但程序內(nèi)部如果用精確匹配去查也同樣可能讀不上?？缙脚_(tái)項(xiàng)目建議統(tǒng)一一套命名風(fēng)格別一會(huì)兒大寫一會(huì)兒小寫。賦值語(yǔ)句里等號(hào)兩側(cè)不能亂加空格。export A b會(huì)被 shell 解析成“執(zhí)行命令 A再傳兩個(gè)參數(shù)”結(jié)果自然是A: command not found。值里如果帶空格必須用引號(hào)包起來否則只有第一個(gè)詞被賦值進(jìn)入變量值里如果包含$這類特殊字符盡量用單引號(hào)避免 shell 在賦值前先做一輪變量展開。Windows 命令行對(duì)引號(hào)的處理比 Unix 更容易出岔子。用 cmd 時(shí)設(shè)置包含空格的路徑引號(hào)位置稍微不對(duì)變量值就被截?cái)嗔?。無論是 PowerShell 還是 cmd遇到帶空格路徑時(shí)先打出來核對(duì)一遍再往下走。5.3 桌面客戶端、服務(wù)管理器不繼承終端里設(shè)置的變量很多人在終端里配好變量然后雙擊桌面圖標(biāo)啟動(dòng)應(yīng)用發(fā)現(xiàn)讀不到。原因前面提到過圖形應(yīng)用由桌面環(huán)境啟動(dòng)繼承的是桌面會(huì)話的環(huán)境不是你的終端窗口環(huán)境。更廣義地講凡是不從你的 shell 里啟動(dòng)的進(jìn)程都不能指望它繼承 shell 配置。任務(wù)計(jì)劃程序、服務(wù)管理器、持續(xù)集成執(zhí)行器都有自己的一套環(huán)境有些甚至運(yùn)行在專用賬戶下。解決辦法就一條把變量寫進(jìn)項(xiàng)目自己的啟動(dòng)腳本里或者直接在服務(wù)配置里聲明。不要在終端設(shè)完就默認(rèn)全世界都能讀到。我還會(huì)在項(xiàng)目文檔里寫清楚“哪些入口是測(cè)試過能讀到變量的”比如“從項(xiàng)目根目錄執(zhí)行 ./start.sh 可用雙擊桌面圖標(biāo)啟動(dòng)不一定可用”。這種細(xì)節(jié)看著不起眼真出問題時(shí)能救命。5.4PATH被悄悄覆蓋命令一下子全失效最后單獨(dú)說說PATH這個(gè)特殊的環(huán)境變量。它就是用來告訴系統(tǒng)“去哪找可執(zhí)行文件”的路徑列表一旦被覆蓋ls、python、node這些命令可能全部找不到。常見事故是部署腳本里直接寫成export PATH/new/dir而不是追加到原有內(nèi)容后面。這樣一來原來的系統(tǒng)目錄全部消失后面的命令即使寫對(duì)了路徑也執(zhí)行不了。我在腳本里一律這樣追加export PATH$PATH:/new/dir多一個(gè)$PATH前綴看起來是小事能避免一大類“命令消失”問題。寫完腳本后還會(huì)加一句校驗(yàn)command -v python3 || echo PATH 可能設(shè)置有誤Windows 一樣有此隱患編輯或拼接PATH時(shí)要用分號(hào)把各目錄分隔開別把整條變量覆蓋成一個(gè)普通字符串。6. 幾年下來我沉淀出的四條環(huán)境變量使用準(zhǔn)則6.1 能局部臨時(shí)就別全局長(zhǎng)存第一能局部臨時(shí)就不要全局長(zhǎng)存。環(huán)境變量生命周期越長(zhǎng)影響面越大越容易在共享機(jī)器上誤傷別人。臨時(shí)調(diào)試用export項(xiàng)目級(jí)配置用啟動(dòng)腳本只有當(dāng)所有用戶都需要時(shí)才考慮用戶級(jí)或系統(tǒng)級(jí)。6.2 每個(gè)關(guān)鍵變量都配上默認(rèn)值和啟動(dòng)校驗(yàn)第二代碼里不要假設(shè)環(huán)境變量一定存在。給普通配置一個(gè)安全的默認(rèn)值給關(guān)鍵連接一個(gè)明確的報(bào)錯(cuò)。這樣無論環(huán)境怎么切換程序要么按預(yù)期運(yùn)行要么在啟動(dòng)第一秒就把問題暴露出來。6.3 變化要留痕把環(huán)境變量的變更寫進(jìn)項(xiàng)目文檔第三環(huán)境變量經(jīng)常游離在代碼版本控制之外很多團(tuán)隊(duì)靠口頭傳遞配置信息。建議倉(cāng)庫(kù)里長(zhǎng)期維護(hù)一份.env.example誰(shuí)要新增變量先把 example 更新了再改實(shí)現(xiàn)。這樣做的好處是換環(huán)境時(shí)有據(jù)可查不至于新同事過來兩眼一抹黑。6.4 部署前做一次“空跑巡檢”第四部署前花幾十秒做一次“空跑巡檢”。跑一個(gè)只檢查不執(zhí)行的生產(chǎn)腳本確認(rèn)關(guān)鍵變量非空、路徑拼接正確、命名大小寫一致。檢查腳本放到倉(cāng)庫(kù)里任何人任何時(shí)候都能跑比自己臨時(shí)敲命令要可靠得多。說到底環(huán)境變量并不復(fù)雜復(fù)雜的是它總是和“進(jìn)程什么時(shí)候啟動(dòng)”“變量從哪里來”這類時(shí)序問題糾纏在一起。我現(xiàn)在的習(xí)慣是碰到任何啟動(dòng)配置疑云先不急著改代碼而是問自己一句這個(gè)進(jìn)程是在什么環(huán)境里出生的這句話幫我擋下過不少?gòu)澛贰ＯＭ@篇內(nèi)容能讓你下次再配置環(huán)境變量時(shí)少踩幾個(gè)坑排錯(cuò)也更有方向。