direnv环境变量管理实战：自动加载、安全加密与跨项目继承

1. 项目概述：为什么环境变量管理成了现代开发者的隐形痛点

你有没有过这样的经历：刚切到一个新项目目录，执行npm run dev就报错说DATABASE_URL is not defined；或者在本地调试时一切正常，一推到 CI 就失败，提示API_KEY missing；又或者同事发来一句“你把.env文件里的STAGE改成staging就好了”，而你翻遍整个项目根目录也没找到这个文件——它其实在上三级父目录里，被某个老旧的 shell 脚本悄悄加载了。这些不是玄学，是环境变量管理失控的真实切片。direnv这个名字听起来像极客圈的冷门工具，但它解决的恰恰是每个写代码的人每天都在撞墙的问题：环境变量不该是手动开关，而应是随路径自动生效的上下文感知开关。它不依赖.env文件解析、不修改你的 shell 配置、不侵入应用代码，而是用最朴素的 Unix 哲学——“当前在哪，就该用哪的配置”——把环境变量从“需要记住”的状态，变成“自然存在”的状态。我从 2019 年开始在团队中推行 direnv，最初只是为了解决前端项目切换REACT_APP_ENV和后端服务切换NODE_ENV的冲突，后来发现它能统一管理 Docker Compose 的COMPOSE_PROJECT_NAME、Python 的PYTHONPATH、Go 的GOPATH，甚至临时覆盖PATH加入项目专属的 bin 目录。它不是替代dotenv，而是比dotenv更底层、更可靠——因为dotenv是应用启动时读取，而 direnv 是 shell 进入目录时加载，连git、ls、curl这些命令都能立刻感知新变量。对新手来说，它意味着少记 3 条 export 命令；对运维来说，它让多环境部署配置收敛到一个.envrc文件；对安全敏感项目，它支持 GPG 加密.envrc，避免密钥硬编码。这篇文章不讲抽象原理，只拆解 5 种真实场景下的落地方式：从最基础的静态变量注入，到动态生成 API Token，再到跨项目继承与 CI 兼容方案。每一种我都在线上跑了超过 2 年，踩过所有你能想到的坑——比如 macOS 上 zsh 的command_not_found_handler冲突、Linux 下 systemd 用户会话的权限限制、Windows WSL2 中 fish shell 的路径解析异常。现在，我们直接进入实操。

2. 核心设计逻辑与方案选型：为什么是 direnv，而不是 dotenv、shell alias 或 Makefile

2.1 环境变量管理的三类常见误用及其代价

很多团队在环境变量管理上走了弯路，不是因为技术不行，而是没想清楚“变量到底服务于谁”。我把常见错误归为三类：

• 第一类：把环境变量当配置文件用
  比如在项目根目录放一个config.env，然后写个source config.env脚本。问题在于：它无法自动触发。你必须记得每次 cd 进目录就手动 source，漏一次，后续所有命令（包括git commit -m "fix: env"）都运行在错误上下文中。更糟的是，如果config.env里写了export PATH="/usr/local/bin:$PATH"，而你忘了unset PATH就切到另一个项目，新项目的bin/目录可能永远进不了你的PATH。我见过最离谱的一次，是某团队的 CI 流水线因为缓存了上一个项目的PATH，导致yarn命令调用了系统全局的旧版本，构建出的包在生产环境崩溃。

• 第二类：把环境变量当代码逻辑用
  比如在package.json的 scripts 里写"dev": "API_KEY=abc123 NODE_ENV=development node server.js"。这看似干净，但变量只对node进程有效，它的子进程（比如child_process.exec('curl')）拿不到API_KEY。更隐蔽的是，API_KEY=abc123这种写法在 bash/zsh 下没问题，但在某些 CI 环境（如 GitLab Runner 的shellexecutor）下会被解释为命令名而非变量赋值，直接报API_KEY=abc123: command not found。

• 第三类：把环境变量当权限开关用
  比如用if [ "$ENV" = "prod" ]; then export DB_HOST="rds.amazonaws.com"; else export DB_HOST="localhost"; fi。这种逻辑应该放在应用代码里做决策，而不是塞进 shell 环境。一旦DB_HOST被错误导出，连psql -h $DB_HOST这种调试命令都会连错库，而你根本意识不到——因为 shell 不会告诉你“你正在连接生产数据库”。

direnv 的设计哲学，就是从根子上切断这三类误用。它不提供source命令，也不让你写if-else逻辑块，而是强制你把“变量定义”和“变量生效范围”绑定在一起：只有当你cd到某个目录时，该目录下的.envrc才被允许加载；一旦你cd出去，所有变量自动撤销。这个“自动加载+自动撤销”机制，是它区别于其他方案的核心。

2.2 为什么不是 dotenv？——层级、时机与作用域的本质差异

dotenv是 Node.js 生态的事实标准，但它解决的是应用层问题，而 direnv 解决的是 shell 层问题。这个差异直接决定了它们的适用边界：

举个具体例子：你在开发一个 Next.js + PostgreSQL 项目，需要同时运行前端next dev和后端npx prisma migrate dev。用 dotenv，你得确保两个进程都正确加载了各自的.env；而用 direnv，你只要在frontend/.envrc里写export NEXT_PUBLIC_API_URL="http://localhost:3001"，在backend/.envrc里写export DATABASE_URL="postgresql://user:pass@localhost:5432/mydb"，然后分别cd frontend && npm run dev和cd backend && npx prisma migrate dev—— 两个终端窗口各自拥有完全隔离、互不干扰的环境变量。你甚至可以在同一个终端里cd frontend后执行curl $NEXT_PUBLIC_API_URL/health，再cd backend后执行psql $DATABASE_URL -c "SELECT now();"，全程无需任何手动 export。

2.3 为什么不是 shell alias 或 Makefile？——可维护性与协作成本的硬约束

有人会说：“我写个 aliasalias proj-dev='export API_KEY=xxx && export ENV=dev'不就行了？” 这在单机调试时确实快，但协作时灾难立现。alias 是 shell 会话级的，无法被git、docker-compose等外部命令继承；Makefile 的export只对 Makefile 内部的 shell 有效，make dev启动的node进程拿不到变量。更重要的是，alias 和 Makefile 都是“命令式”的——你得记住proj-dev这个名字，而 direnv 是“声明式”的——你只需要cd到目录，一切自动就绪。在团队协作中，声明式意味着零学习成本：新人 clone 代码后，cd project && direnv allow，剩下的事交给工具。我们曾做过对比测试：10 人团队中，使用 alias 方案的成员平均每周因忘记执行 alias 导致的构建失败达 2.3 次；而启用 direnv 后，这个数字降为 0.1（基本都是新成员第一次direnv allow时手抖按了n）。这不是工具好坏的问题，而是人脑带宽的客观限制——人类擅长模式识别，不擅长记忆随机字符串。

2.4 direnv 的核心架构：如何做到“安全加载”与“即时撤销”

direnv 的工作流程其实非常精巧，它本质上是一个 shell hook 注入器：

1. Hook 注入阶段：安装时，direnv 会在你的~/.zshrc（或~/.bashrc）末尾追加一行eval "$(direnv hook zsh)"。这行代码的作用，是重写 shell 的cd命令——每次你输入cd xxx，实际执行的是 direnv 包装后的cd。

2. 加载决策阶段：包装后的cd会检查目标目录是否存在.envrc文件。如果存在，它不会直接执行，而是先计算该文件的 SHA256 哈希值，并与~/.direnv/allow中存储的白名单比对。只有哈希匹配，才允许执行；否则报错direnv: error .envrc is blocked. Run 'direnv allow' to approve its content.。

3. 执行与沙箱阶段：批准后，direnv 启动一个干净的 bash 子进程，执行.envrc中的命令。注意，它不使用当前 shell 的环境，而是从一个最小化环境开始，确保.envrc的输出完全可控。执行完毕后，它捕获所有export VAR=value输出，并与当前 shell 环境做 diff，只将新增或变更的变量注入当前 shell。

4. 撤销阶段：当你cd出该目录时，direnv 会回溯之前记录的环境快照，将所有本次加载的变量 unset，恢复到进入前的状态。

这个设计保证了三点：安全（必须显式 allow）、纯净（无污染当前 shell）、可逆（离开即还原）。这也是它敢处理AWS_ACCESS_KEY_ID这类高危变量的根本原因——你永远不会因为cd错目录，就把生产密钥泄露给本地调试命令。

3. 5 种实战方案详解：从入门到高阶的完整能力图谱

3.1 方案一：静态变量注入——最常用也最容易被低估的基础能力

这是 90% 的用户第一次接触 direnv 的方式，但它绝非“简单设置几个变量”这么轻量。关键在于理解.envrc的执行上下文和变量作用域。

实操步骤：

1. 在项目根目录创建.envrc文件：

# .envrc export PROJECT_NAME="my-awesome-app" export NODE_ENV="development" export REACT_APP_ENV="local"

2. 执行direnv allow授权加载（首次需要，后续自动生效）。

3. cd进入该目录，验证变量：

$ echo $PROJECT_NAME my-awesome-app $ echo $NODE_ENV development

为什么不能直接写NODE_ENV=development？
这是新手最常见的错误。NODE_ENV=development是 bash 的变量赋值语法，但变量未被export，因此不会传递给子进程。direnv的.envrc文件本质是 bash 脚本，必须显式export。你可以把它理解为：.envrc定义的是“要导出给 shell 的变量”，而不是“当前脚本内部的变量”。

进阶技巧：跨目录继承的静态变量
假设你的项目结构是：

my-project/ ├── .envrc # 定义通用变量 ├── frontend/ │ └── .envrc # 定义前端特有变量 └── backend/ └── .envrc # 定义后端特有变量

在my-project/.envrc中写：

export PROJECT_ROOT="$(pwd)" export COMMON_CONFIG_DIR="$PROJECT_ROOT/config"

在frontend/.envrc中写：

# 自动继承父目录的 PROJECT_ROOT 和 COMMON_CONFIG_DIR export REACT_APP_API_URL="http://localhost:3001" export REACT_APP_WS_URL="ws://localhost:3001"

direnv 默认启用--load-dot-envrc模式，会从当前目录向上递归查找所有.envrc并按顺序执行。这意味着cd my-project/frontend时，会先加载my-project/.envrc，再加载my-project/frontend/.envrc，变量自然继承。但要注意：后加载的.envrc可以覆盖前面的同名变量。比如my-project/.envrc设了export PORT=3000，而frontend/.envrc设了export PORT=3001，最终生效的是3001。这个特性让“环境分级”成为可能：根目录设通用配置，子目录设环境特化配置。

避坑指南：

提示：.envrc文件必须是 Unix 换行符（LF），Windows 的 CRLF 会导致direnv: error /path/to/.envrc: line 1: $'\r': command not found。用dos2unix .envrc或 VS Code 的换行符切换功能修复。

注意：不要在.envrc中写cd ..或pushd这类改变当前工作目录的命令。direnv 的执行环境是临时的，这些命令不会影响你的主 shell，反而可能因路径错误导致变量计算失败。

3.2 方案二：动态变量生成——用 shell 脚本能力突破静态配置局限

当变量值依赖于运行时状态（如当前 Git 分支、系统时间、文件内容）时，静态export就不够用了。direnv 的强大之处，在于它允许你在.envrc中写任意合法的 bash/sh 脚本。

实操案例：根据 Git 分支自动设置 API 环境

很多团队的 API 有dev、staging、prod三个后端，前端通过REACT_APP_API_URL指向不同地址。手动改.envrc极易出错，用动态生成则一劳永逸：

# frontend/.envrc # 获取当前 Git 分支名 CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null) # 根据分支名映射 API 地址 case "$CURRENT_BRANCH" in "main" | "master") export REACT_APP_API_URL="https://api.myapp.com" export REACT_APP_ENV="production" ;; "develop" | "dev") export REACT_APP_API_URL="https://api-staging.myapp.com" export REACT_APP_ENV="staging" ;; *) # 默认指向本地后端 export REACT_APP_API_URL="http://localhost:3001" export REACT_APP_ENV="local" ;; esac # 附加：打印当前环境，方便快速确认 echo "✅ Frontend environment: $REACT_APP_ENV (branch: $CURRENT_BRANCH)"

原理说明：
direnv执行.envrc时，会启动一个 bash 子进程，因此所有 bash 内置命令（git、date、jq、curl）均可调用。2>/dev/null是关键——当目录不在 Git 仓库中时，git rev-parse会报错，重定向错误输出可避免 direnv 加载失败。

实操案例：基于时间的临时密钥轮换

某些 API 要求 Token 每小时更新一次，且需包含时间戳签名。你可以让 direnv 每次cd都生成新 Token：

# backend/.envrc # 生成当前小时的时间戳（格式：YYYYMMDDHH） HOUR_STAMP=$(date -u +"%Y%m%d%H") # 调用本地脚本生成签名 Token（假设你有 ./scripts/gen-token.sh） if [[ -f "./scripts/gen-token.sh" ]]; then export API_TOKEN=$(./scripts/gen-token.sh "$HOUR_STAMP") echo "🔑 Generated API token for hour: $HOUR_STAMP" else export API_TOKEN="dummy-token-for-dev" fi

性能考量：
动态生成会增加cd延迟。实测显示，纯 bash 命令（如date、git）延迟 < 10ms；调用外部命令（如curl、jq）可能达 100-500ms。如果你的.envrc里有curl https://api.example.com/token，每次cd都会卡顿。解决方案是缓存 + 过期检查：

# 缓存 Token 到文件，10 分钟内复用 TOKEN_CACHE=".direnv_token_cache" TOKEN_EXPIRY=600 # 10 分钟，单位秒 if [[ -f "$TOKEN_CACHE" ]] && [[ $(($(date +%s) - $(stat -c "%Y" "$TOKEN_CACHE" 2>/dev/null || echo 0))) -lt $TOKEN_EXPIRY ]]; then export API_TOKEN=$(cat "$TOKEN_CACHE") else # 重新生成并写入缓存 NEW_TOKEN=$(./scripts/gen-token.sh "$(date -u +"%Y%m%d%H")") echo "$NEW_TOKEN" > "$TOKEN_CACHE" export API_TOKEN="$NEW_TOKEN" fi

避坑指南：

提示：direnv默认使用/bin/sh执行.envrc，而/bin/sh在不同系统上行为不同（macOS 的/bin/sh是dash，不支持$(())算术扩展）。为确保兼容，始终在.envrc开头声明#!/usr/bin/env bash，或使用direnv exec指定解释器。

注意：动态命令的输出会被 direnv 捕获并解析。如果脚本中写了echo "debug: $VAR"，这个debug:行也会被当成变量输出，导致direnv: error .envrc: line X: debug:: command not found。解决方案是将调试信息重定向到 stderr：echo "debug: $VAR" >&2。

3.3 方案三：GPG 加密的密钥管理——安全与便利的终极平衡

把AWS_SECRET_ACCESS_KEY、DATABASE_PASSWORD这类密钥明文写在.envrc里，是 DevOps 的大忌。direnv 原生支持 GPG 加密，让密钥既安全又可用。

实操步骤：

1. 准备 GPG 密钥对（如未安装，先brew install gpg或apt install gnupg）：

gpg --full-generate-key # 选择 RSA, 4096 bits, 永不过期，邮箱填你的工作邮箱 # 记住你设置的 passphrase

2. 创建加密的.envrc.gpg文件：

# 先写明文配置（临时文件） cat > .envrc.plain << 'EOF' export AWS_ACCESS_KEY_ID="AKIA..." export AWS_SECRET_ACCESS_KEY="abc123..." export DATABASE_PASSWORD="super-secret-pass" EOF # 用 GPG 加密（-r 参数指定你的邮箱） gpg -e -r "your-email@example.com" .envrc.plain # 重命名为 .envrc.gpg，并删除明文 mv .envrc.plain.gpg .envrc.gpg rm .envrc.plain

3. 在.envrc中解密并加载：

# .envrc # 如果存在加密文件，则解密并 source if [[ -f ".envrc.gpg" ]]; then export GPG_TTY=$(tty) # 解密并执行，错误时静默失败（避免暴露密钥存在） gpg --decrypt ".envrc.gpg" 2>/dev/null | source /dev/stdin 2>/dev/null fi

为什么这样设计？
gpg --decrypt会弹出 GUI 或 TTY 密码框，输入 passphrase 后输出明文内容。source /dev/stdin将其作为 bash 脚本执行。2>/dev/null确保解密失败（如密码错误、GPG agent 未启动）时，direnv 不报错，只是跳过密钥加载——此时你的应用会因缺少密钥而启动失败，但密钥本身从未以明文形式出现在磁盘或内存中（GPG 解密流是管道，不落盘）。

团队协作最佳实践：

• 将.envrc.gpg提交到 Git，因为它只是加密后的二进制数据；
• 在 README 中写明：“需要 GPG 密钥 ID XXXX 才能解密，请联系 DevOps 同事获取”；
• 使用gpg --list-keys查看密钥 ID，确保.envrc.gpg是用团队共享密钥加密的（多人可解密）；
• 定期轮换密钥：gpg --delete-keys旧密钥，生成新密钥，重新加密.envrc.gpg。

避坑指南：

提示：macOS 上 GPG 密码框可能不弹出，需安装gpg-suite并在系统偏好设置中启用GPG Keychain Access。Linux 下确保gpg-agent正在运行：gpg-connect-agent /bye。

注意：gpg --decrypt默认会校验签名。如果你的.envrc.gpg是用gpg -e加密的（无签名），则无需校验；但如果是gpg -s -e签名加密的，则必须用gpg --decrypt --verify，否则会失败。

3.4 方案四：跨项目环境继承——解决微服务与 monorepo 的配置复用难题

在微服务架构或大型 monorepo 中，多个子项目共享一套基础设施配置（如 Kafka 集群地址、Redis 密码、S3 Bucket 名）。为每个子项目单独维护.envrc，违背 DRY（Don't Repeat Yourself）原则，且极易出现配置漂移。

实操方案：符号链接 + 目录白名单

假设你的 monorepo 结构如下：

my-monorepo/ ├── .envrc # 全局配置入口 ├── common/ │ └── env/ │ ├── base.envrc # 基础变量（PROJECT_NAME, ROOT_DIR） │ └── secrets.envrc # 加密密钥（GPG 加密） ├── services/ │ ├── auth/ │ │ └── .envrc # 链接到 common/env/base.envrc │ └── payment/ │ └── .envrc # 同样链接 └── apps/ └── web/ └── .envrc # 链接到 common/env/base.envrc + 自定义

步骤：

1. 在my-monorepo/.envrc中定义全局加载逻辑：

# my-monorepo/.envrc # 设置 COMMON_ENV_DIR 为绝对路径，避免符号链接路径解析错误 export COMMON_ENV_DIR="$(dirname "$(realpath "$0")")/common/env" # 加载基础配置（总是加载） if [[ -f "$COMMON_ENV_DIR/base.envrc" ]]; then source "$COMMON_ENV_DIR/base.envrc" fi # 加载密钥配置（仅当存在且已授权时加载） if [[ -f "$COMMON_ENV_DIR/secrets.envrc.gpg" ]]; then export GPG_TTY=$(tty) gpg --decrypt "$COMMON_ENV_DIR/secrets.envrc.gpg" 2>/dev/null | source /dev/stdin 2>/dev/null fi

2. 在子项目中创建符号链接：

# 进入 auth 服务目录 cd my-monorepo/services/auth # 创建指向全局 .envrc 的链接（注意：不是 .envrc.gpg！） ln -sf ../../.envrc .envrc # 执行 direnv allow，此时会加载 my-monorepo/.envrc，进而加载 base.envrc direnv allow

为什么不用source ../.envrc？
因为source是相对路径，当cd到auth/src子目录时，../.envrc会变成auth/.envrc，而auth/.envrc是个链接，source会尝试加载链接目标../../.envrc，但此时$(pwd)是auth/src，dirname "$(realpath "$0")"会解析为my-monorepo，路径依然正确。符号链接方案保证了无论你在子目录的哪一层，.envrc的加载逻辑都一致。

进阶：条件化加载子项目特有配置
在my-monorepo/services/auth/.envrc中，你可以写：

# 先加载全局配置 source ../../.envrc # 再加载本服务特有配置 export AUTH_SERVICE_PORT="8080" export AUTH_JWT_SECRET="auth-specific-secret"

direnv 会按cd路径从深到浅加载：auth/.envrc→services/.envrc（不存在，跳过）→my-monorepo/.envrc。所以auth/.envrc会最后执行，覆盖全局变量。

避坑指南：

提示：符号链接的.envrc必须用direnv allow单独授权。direnv allow是按文件路径授权的，auth/.envrc和my-monorepo/.envrc是两个不同的文件路径，即使内容相同，也要分别allow。

注意：realpath命令在 macOS 上默认不存在，需brew install coreutils并用grealpath替代，或改用cd "$(dirname "$0")" && pwd组合。

3.5 方案五：CI/CD 兼容与容器化部署——让 direnv 不止于本地开发

direnv 的最大误解，是认为它只适用于本地 shell。实际上，通过合理设计，它可以无缝融入 CI 流水线和容器环境，成为统一的环境配置中枢。

CI 兼容方案：在 GitHub Actions 中模拟 direnv 行为

GitHub Actions 的 runner 是干净的 Ubuntu 环境，没有 direnv。但我们可以通过source模拟其加载逻辑：

# .github/workflows/ci.yml name: CI on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' - name: Load environment variables (simulate direnv) # 直接 source 根目录 .envrc，忽略 GPG 加密部分 run: | # 复制 .envrc 到临时文件，移除 GPG 相关逻辑 sed '/gpg --decrypt/d; /GPG_TTY=/d; /export GPG_TTY/d' .envrc > /tmp/env.sh source /tmp/env.sh echo "Loaded vars: PROJECT_NAME=$PROJECT_NAME, NODE_ENV=$NODE_ENV" - name: Install dependencies run: npm ci - name: Run tests run: npm test

关键点：

• sed命令过滤掉所有 GPG 相关行，避免 CI 中 GPG agent 缺失导致失败；
• source /tmp/env.sh直接在当前 shell 执行，变量对后续步骤生效；
• 这种方式绕过了 direnv 的安全校验，但 CI 环境本就是可信的，且.envrc中的密钥已被 GPG 加密，CI 中加载的只是公开配置。

容器化部署方案：在 Dockerfile 中嵌入 direnv 配置

对于需要在容器内运行多种环境（如开发、测试、预发）的镜像，可以将 direnv 的.envrc逻辑编译进镜像：

# Dockerfile FROM node:18-alpine # 复制项目代码 COPY . /app WORKDIR /app # 安装 direnv（用于构建时生成环境） RUN apk add --no-cache direnv # 将 .envrc 复制为 /etc/profile.d/direnv.sh，使其在容器启动时自动加载 # （注意：这需要基础镜像支持 /etc/profile.d/ 机制） COPY .envrc /etc/profile.d/direnv.sh # 但更推荐的方式：在 ENTRYPOINT 中显式加载 COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"]

#!/bin/sh # entrypoint.sh # 在容器启动时，模拟 direnv 加载逻辑 if [ -f "/app/.envrc" ]; then # source .envrc，但跳过 GPG 部分（容器内无 GPG） sed '/gpg --decrypt/d; /GPG_TTY=/d' /app/.envrc | sh fi # 执行原始命令 exec "$@"

生产环境注意事项：

• 永远不要在生产容器中加载 GPG 加密的.envrc.gpg。生产密钥应通过 Kubernetes Secrets、AWS Parameter Store 等专业方案注入；
• .envrc中的export变量，应只包含非敏感的配置（如PORT=3000,LOG_LEVEL=info），敏感项留空或设为默认值；
• 使用direnv dump命令可导出当前环境变量为 JSON，便于调试：direnv dump | jq '. | select(.PROJECT_NAME)'。

避坑指南：

提示：Docker 构建时，RUN指令是独立的 shell，.envrc不会自动生效。所有构建时需要的变量（如BUILD_VERSION），应在ARG中声明，而非依赖.envrc。

注意：Kubernetes Pod 的envFrom字段可以直接引用 ConfigMap，这比在容器内运行 direnv 更符合云原生理念。direnv 的定位是“开发者本地环境同步工具”，而非“生产配置管理工具”。混用两者会导致环境不一致。

4. 常见问题与排查技巧实录：那些官方文档不会写的血泪经验

4.1 “direnv: error .envrc is blocked” —— 授权失败的 5 种真实原因

这是新手遇到的第一个拦路虎，但背后原因千差万别。我整理了线上排查日志中最常见的 5 种情况：

独家技巧：
direnv status是你的第一诊断工具。它会输出当前 shell 的详细状态，包括：

• Current directory: 当前工作目录（确认是否是你期望的路径）
• Found .envrc: 找到的.envrc文件路径（确认是否加载了正确的文件）
• Allow rules: 已授权的文件哈希列表（确认是否包含当前.envrc）

如果Found .envrc显示的路径是/home/user/project/.envrc，但你cd的是/home/user/project/backend，说明 direnv 正在加载父目录的.envrc，这是正常行为。

4.2 “变量没生效” —— 作用域与 shell 兼容性的深度解析

变量看似设置了，但echo $VAR为空，或git命令拿不到变量。这通常不是 direnv 的 bug，而是 shell 机制的理解偏差。

原因一：子 shell 与变量继承
direnv修改的是当前 shell 的环境变量。但当你运行bash -c 'echo $VAR'时，启动了一个新的 bash 子进程，它不会自动继承父进程的所有变量——只有被export的变量才会继承。所以.envrc中必须写export VAR=value，而不是VAR=value。

原因二：fish shell 的特殊性
fish shell 不兼容 bash 语法。如果你用