同时对三四个项目进行维护, 每个项目的环境变量都不一样, A项目的环境变量指向本地库, B项目需要切换到测试账号, C项目还得先进入.venv/bin/。每次进入项目后如果忘记了这些, 运行过程中就会连接到错误的库, 或者部署到错误的账号；要是记住了, 离开时环境变量却仍然保留着, 会对下一个shell环境造成污染。这个坑几乎每个开发者都踩过。
今日要聊一款专门治疗此病的轻量级工具, 它能够当你进入某个目录的时候, 自动去加载该目录专属的那些环境变量, 它还能在你离开那个目录之际, 自动卸载该目录专属的环境变量, 切实达成「进入目录就处于合适状态, 离开目录就恢复干净状况」。
01 适用场景
02 实战步骤
第一步，安装并注入shell hook
macOS / Linux一条命令：
# macOS brew install direnv # Debian / Ubuntu sudo apt install direnv # 把下面这行加进 ~/.zshrc或~/.bashrc eval"$(direnv hook zsh)"# bash用户换成hook bash经由重新开启终端，或者是~/.zshrc 之后, 便着手开始对您的目录转换予以监听了。
其次, 于项目根目录之中, 书写.envrc, 用以声明此目录所独有的环境变量。
# 项目根目录下的.envrc export PROJECT_NAME='order-service' export DATABASE_URL='postgres://dev:dev@localhost:5432/order_dev' export AWS_PROFILE='dev-account' export LOG_LEVEL='debug' # 进入目录自动建并激活Python venv（direnv内置layout） layout python3第三步， allow授权并看效果
cd ~/code/order-service direnv allow # 首次需显式授权，防止恶意.envrc # 输出：direnv: export +PROJECT_NAME +DATABASE_URL +AWS_PROFILE +LOG_LEVEL获得授权之后, 变量此刻马上就会有效果；当使用cd指令离开那个目录时, 这些变量将会被进行自动撤销操作, 然后shell就会恢复到原本的状态, 是这样的情况。
03 效果演示
在三个项目间横跳不再担心串环境：
~/code/order-service $ echo $AWS_PROFILE dev-account ~/code/order-service $ cd ~/code/prod-tool direnv: unloading old environment direnv: export +AWS_PROFILE # 这里自动切到生产账号 ~/code/prod-tool $ echo $AWS_PROFILE prod-account依然会于目录当中自动创建./-*虚拟环境并且将其激活, 在借助uv亦或是pip安装依赖之后, 进入以及离开目录venv时会自动进行挂卸操作, 完全告别手动敲击.venv/bin/。
04 注意事项
切勿将含有密钥的.envrc提交至Git , 要把真实的密钥写入.envrc.local , 并在其中忽略, 仓库里仅留存不包含敏感信息的.envrc模板。
首次进到目录, 一定要 allow才行, 这就是安全闸门, 可别说烦——它能防止你不小心跑去执行别人的恶意脚本。
3. 采用系统来构建venv作为默认项, 要是运用uv执行管理操作, 就能够将其改换为使用uv。
指令；
4.跟 pyenv、nvm 共同存在的时候, 将它们的进行初始化这一行为置于 hook 以前, 防止出现 PATH 顺序方面的冲突情况。
05 总结
采用手动方式处理.env, 其本质存在的关键问题在于, 状态依赖人脑去记忆。将环境变量绑定于目录这个具体的物理边界之上, 当进入该目录时就会自动加载, 而离开时则会自动回收, 如此一来, 从根本上消除了那种因遗忘或者混淆环境而导致的低级事故。它具备较小的体积, 具有零侵入的特性, 并且几乎能够支持所有的shell, 是在工作周之中提升效率最为划算的一项投资。
