VSCode 不读取 .env 文件，变量注入依赖运行工具（如 node、python）及 dotenv 等库；调试需在 launch.json 中配置 envFile，终端需借助 direnv 或手动 source；代码中须显式调用 dotenv.config() 或 load_dotenv() 才生效。

先明确一个核心事实：VSCode 本身并不读取 .env 文件，更不会自动把里面的变量注入到你的运行环境里。这是很多开发者踩坑的起点，也是理解后续所有操作的关键。

为什么在 VSCode 里改了 .env 却没生效

道理其实很简单：VSCode 本质上是一个功能强大的编辑器，而不是程序的运行时环境。它不会主动去解析你项目里的 .env 文件，自然也就无法将这些 KEY=VALUE 对自动塞进你的终端、调试器或者 Node.js/Python 进程里。真正决定变量能否生效的，是你所使用的运行工具（比如 node、python 或者 npm run dev 这样的脚本）以及它们是否加载了对应的库（比如 Node.js 的 dotenv 或 Python 的 python-dotenv）。

所以，如果你遇到了下面这些情况，千万别惊讶：

• 明明在 .env 里写好了 API_URL=https://dev.example.com，但代码里 console.log(process.env.API_URL) 却输出了 undefined。
• 在 VSCode 的智能提示或者调试配置（launch.json）里，根本看不到这些环境变量的影子。
• 打开终端，输入 echo $API_URL，结果返回一片空白。

让调试器（launch.json）识别 .env 变量

想让 VSCode 的调试器认识你的 .env 文件，需要手动配置一下。调试器支持通过 envFile 字段来显式加载指定文件，但要注意：这个配置仅对当前这个调试会话生效，而且它只影响通过 VSCode 启动的调试进程，不会改变你的终端环境，也不会影响外部直接运行的命令。

具体怎么操作？记住这几个要点：

• 首先，确保你的 .env 文件放在工作区的根目录，或者在配置里用相对路径指明它的位置（比如 ${workspaceFolder}/config/.env）。
• 然后，打开项目里的 .vscode/launch.json 文件，在对应的调试配置中添加一个 envFile 字段：

  {
    "type": "node",
    "request": "launch",
    "name": "Launch with .env",
    "program": "${workspaceFolder}/index.js",
    "envFile": "${workspaceFolder}/.env"
  }

• 需要警惕的是，envFile 只会读取你指定的那一个文件，它没有自动加载 .env.local 或者处理变量覆盖的逻辑。如果你需要合并多个环境文件，要么手动处理，要么考虑使用其他插件。
• 最后，兼容性也是个问题。这个特性在 Node.js 和 Python 的调试插件中支持得比较稳定，但对于 Go、Rust 等其他语言，情况就不一定了。

终端里想自动加载 .env？别依赖 VSCode

VSCode 内置的终端，本质上就是你系统里的那个 Shell（可能是 bash、zsh 或者 PowerShell），它和 VSCode 编辑器本身是两套独立的系统。所以，别指望 VSCode 会自动帮你执行 source .env 这样的操作。

想在终端里也能方便地使用环境变量，可以试试下面这几个方案，按推荐度排序：

• 手动脚本法：在项目根目录创建一个类似 .env.sh 的脚本文件，里面写上 set -a; source .env; set +a。每次新开终端时，手动执行一下 source .env.sh。
• 工具自动化：使用 direnv 这个跨平台工具。安装后，在项目根目录运行 direnv allow，并创建一个 .envrc 文件，里面写上 source_env .env。它的好处是，进入项目目录时自动加载变量，离开时自动清理，非常干净。
• 慎用插件：市面上有一些号称能“自动加载环境变量”的 VSCode 插件，但它们通常是通过修改 Shell 启动参数来实现的，不仅不稳定，还可能无法保证所有子进程都能正确继承这些变量。
• Windows 用户注意：在 PowerShell 里直接运行 .env.ps1 脚本可能会被系统的执行策略阻止。强行绕过策略存在安全风险，需要格外小心。

代码运行时读取 .env 的正确姿势

说到底，无论你在编辑器和终端里怎么配置，最终要让程序用上这些变量，还是得靠你的代码显式地加载 .env 文件。否则，process.env 或者 os.environ 里面就永远是空的。

这才是关键所在，务必记牢：

• Node.js 项目：在你的入口文件（比如 index.js 或 app.js）的最顶部，尽早引入并调用 dotenv。而且，这个调用必须发生在任何依赖这些环境变量的模块被引入之前：

  require('dotenv').config(); // 默认读取项目根目录的 .env 文件

  你还可以通过参数控制，比如指定其他文件路径，或者决定是否覆盖系统已存在的同名变量：config({ path: '.env.local', override: true })。
• Python 项目：使用 python-dotenv 库。同样，在程序启动的入口文件（如 main.py）开头调用：

  from dotenv import load_dotenv
  load_dotenv()  # 默认读取项目根目录的 .env 文件

• 安全第一：千万不要把存有敏感信息（如 API 密钥、数据库密码）的 .env 文件提交到 Git。务必在 .gitignore 中加入 .env，同时提供一个 .env.example 文件作为模板，说明需要哪些变量。
• 环境分离：开发时用 .env 很方便，但生产环境最好别依赖它。在 Docker 或 Kubernetes 这类部署场景下，应该通过 Secret 或 ConfigMap 等更安全、更标准的方式来注入环境变量。

最后，再强调一个最容易被忽略的环节：从你编辑 .env 文件，到变量在程序中真正生效，中间没有任何一层（VSCode、Shell、运行时）会默认帮你把这条链路串联起来。每个环节都需要你自己去确认——尤其是 dotenv.config() 或 load_dotenv() 是否真的被调用了，以及调用的时机是否早于任何读取这些变量的代码。这才是解决问题的根本。