你是否遇到過這樣一個情況: 在A項目的終端之中執(zhí)行相應的命令, 然而所實際使用的卻是B項目的數(shù)據(jù)庫連接配置, 直至花費了相當長的時間之后才發(fā)現(xiàn), 自己連接的數(shù)據(jù)庫出現(xiàn)了錯誤。這種情況是我確實存在, 并且這樣的狀態(tài)并不是僅僅發(fā)生了一次。根本原因就在于, 環(huán)境變量這一東西是屬于全局范圍的, 并且是伴隨著 shell 進程來運行的。我在同一時間打開了五六個項目, 每個項目所需要的環(huán)境變量都是不相同的, 這邊項目連接的是測試數(shù)據(jù)庫, 那邊項目連接的是開發(fā)數(shù)據(jù)庫, 各個項目的 API 密鑰也全是各不一樣。過去通常的做法是, 在每個項目目錄下放置一個 .env 文件, 或者放置一個 env.sh 腳本, 只要進入到該目錄里, 做的第一件事就是要去執(zhí)行一下 ./env.sh 這個操作。但是實際的問題是, 我總是會忘記去做這步操作。從當前這個終端標簽頁切換到其他頁面的時候, 腦子里已經(jīng)記不住具體要做什么了另外開啟一個新的瀏覽窗口后, 也因為忙碌而忘記了原本的任務當同事邀請我去協(xié)助排查某個程序錯誤時, 我在臨時切換目錄的過程中, 同樣因為環(huán)境變動而導致思緒中斷并遺忘了待辦的事情。就是來徹底根除這個“忘了”的情況的。它怎么工作總結為一句話來講, 就是當你執(zhí)行cd命令進入某個目錄的時候, 系統(tǒng)會自動地加載對應的那個目錄的環(huán)境變量信息一旦你使用 cd 命令離開那個特定的空間位置的時候, 相關的那些環(huán)境變量就會被自動地卸載掉。它的底層原理是在你的 shell 程序里掛載了一個掛鉤機制。當你每次切換工作目錄時, 這個掛鉤就會自動啟動, 去檢查當前的路徑以及它的所有父級路徑下, 是否存在一個 .envrc 文件。如果找到了這個文件存在, 它就會執(zhí)行該文件的內(nèi)容, 從而把在文件內(nèi)部定義好的所有環(huán)境變量都加載并注入到當前的 shell 環(huán)境中。一旦你離開了這個指定的目錄范圍, 該機制就會立刻撤銷之前注入的那些變量, 讓系統(tǒng)狀態(tài)恢復成原來的情況。在這樣一個過程之中, 你本人完全沒必要去做任何的操作, 僅僅只需要執(zhí)行一下cd這個命令, 整個任務就全部處理完畢了。組裝和搭配這個事情, 其實也就分成了兩步來做:# 裝mac / linuxbrew你需要把hook掛接到殼程序中, 并且要把這個操作添加到以點號開頭的zshrc文件或者以點號開頭的文件的末尾位置。eval $( hook zsh)# bash 的話換成eval $( hook bash)然后在項目目錄里面, 寫一個 .envrc:# -a/.envrc://:5432/dev-xxxxx.envrc這個東西, 它的本質(zhì), 其實就是shell這種腳本類型, 所以它能夠去處理的事情, 那就是任何那個shell腳本能夠去處理的那些事情。比如, 實現(xiàn)當某個動作觸發(fā)時, 系統(tǒng)會自動地對該虛擬環(huán)境執(zhí)行激活操作。.venv/bin/# 再一個選擇呢就是把已有的那個文件叫做.env的東西給它直接加載進來, 這樣的話就不需要去重新編寫一遍了。初次執(zhí)行 cd 命令前往該目錄時, 系統(tǒng)可能會阻攔并提示當前路徑下的 .envrc 文件尚未獲得授權, 從而要求您進行手動確認。這是一個安全機制, 這個機制的作用是為了防止在你把別人的倉庫克隆下來的時候有人利用惡意存在的 .envrc 文件來偷偷執(zhí)行代碼。allow當你把環(huán)境變量配置文件 .envrc 修改完畢之后, 你還得再多執(zhí)行一個許可授權的動作, 也就是要重新進行一次 allow 操作。allow .allow 這一步, 是它具有的關鍵性的安全防護舉措。.envrc 這個文件, 它本質(zhì)上是一種會被系統(tǒng)自動執(zhí)行的 shell 腳本。試想一下, 如果不法分子把一個帶有惡意代碼的腳本藏到了倉庫里面, 而你只是簡單地切入了到該目錄底下操作, 那么你就很有可能已經(jīng)陷入了危險的境地。所以, 系統(tǒng)設定了強制性的規(guī)則: 對于每一個 .envrc 文件, 都必須由你本人親手執(zhí)行過 allow 這一動作之后, 系統(tǒng)才會去運行該文件的代碼部分。而且, 一旦這個文件的具體內(nèi)容發(fā)生了任何變化, 你就需要再次手動確認執(zhí)行 allow 操作。對于這個安全機制, 大家千萬不要覺得它非常麻煩或者繁瑣不顧其必要性, 因為這個機制在過去確實挽救過不少關鍵的情況。在用起來比較順手之后, 會養(yǎng)成一些習慣。經(jīng)過了一段時期的運行, 我固化了幾個具體的用法。第一點是把.envrc文件提交到版本控制之中, 而.env這個用來存放真正密鑰的文件不放進版本控制里面。在我的.envrc文件內(nèi)通常寫入的是配置的結構以及那些非敏感的配置信息。對于敏感的密鑰則放置在已經(jīng)被git忽略了的.env文件中。具體的加載工作是由外部工具來完成的。這樣做的好處在于, 當團隊成員從代碼庫中克隆下來這個項目之后, .envrc文件已經(jīng)是現(xiàn)成的了, 每個人只需要各自去填寫屬于自己的敏感信息就可以了。另外一點就是, 能夠使用它來管理多個版本的開發(fā)工具鏈。因為在.envrc這個配置文件里面是可以修改PATH環(huán)境變量的, 這樣一來, 我們就能夠讓某個比較舊的項目自動去使用特定版本的node, 或者是采用特定的PATH路徑順序, 當進入該項目目錄的時候會自動進行切換, 而當我們離開該目錄時又會自動還原到原來的狀態(tài), 這種操作方式比起手動執(zhí)行nvm use命令要更加省心省力一些。第三點內(nèi)容是要去協(xié)助管理功能層面的運行環(huán)境。其內(nèi)部已經(jīng)預裝配置了一些相關的東西, 比如說像這一塊。這是一個名為強.envrc強的小工具, 它的作用非常簡單, 只需要在命令行里輸入一行指令, 就可以讓你的項目去自動使用當前所在的那個目錄底下所設置好的虛擬環(huán)境。# node 項目自動把 /.bin 加進 PATHnode在此特地給出來一個提醒。它用起來確實是挺方便的, 可是有兩處比較麻煩的地方, 我必須要在這里講一下。首先, 這個功能只會在交互式的那個 Shell 環(huán)境里面才起作用, 因為它主要是依靠那個鉤子hook來做事的。所以, 大家要是去寫一些 CI持續(xù)集成腳本, 還有 定時任務那種情況, 或者是其他那種非交互式的腳本程序里頭, 它是根本不起作用的。在那些特定的地方, 到底該怎么去傳遞環(huán)境變量, 你就還是得按照原來的規(guī)矩老老實實地去做傳參操作, 千萬不要想當然地認為 .envrc 這個東西是無所不能、放之四海而皆準的萬能鑰匙。再說第二條, 大家千萬別把它當成密鑰管理工具來看待。它實際上只是一個起到自動作用的便利工具。真正的密鑰管理工作還是應該依托于 vault 來進行。把生產(chǎn)環(huán)境下的密鑰直接硬編碼到 .envrc 文件里面去, 這是一個非常不好的做法。但是, 就關于再也再也不用記住需要手動去做這一件事情來說, 它做得那是干干凈凈。在把這個東西安裝上之后的那種咦我這個變量怎么就不生效了的這種抓狂的時刻, 基本上就從我的生活里面消失了。從今以后, 當我克隆完一個項目之后的第一件事, 就是去看一下有沒有那個 .envrc 這個文件存在, 要是沒有的話呢, 我就給它專門去建立它一個。這是一個簡單的工具, 不過它每天都幫助我解決一些問題, 把這些小問題解決掉以后積累起來就變得很多了。