sublime 项目级环境变量需通过 .env 文件配合 envfile 插件实现，该插件在打开含 .env 的文件夹时自动注入变量到构建命令，支持多环境 fallback 与运行时 shell 展开，但不监听文件变更，修改后须重启窗口。
Sublime 项目级环境变量靠 .env 文件 + EnvFile 插件实现
Sublime Text 本身不读取系统级或 shell 级的环境变量（比如 JAVA_HOME 或 PATH），更不会自动加载项目根目录下的 .env。想让 Build System 在运行时注入变量，必须用插件辅助——EnvFile 是目前最稳定、无需手动 reload 的方案。
它会在你打开一个含 .env 或 .env.development 的文件夹时，自动识别并注入变量到后续所有构建命令中，且支持多环境 fallback（如先读 .env.development，再 fallback 到 .env）。
- 通过
Ctrl+Shift+P→Install Package→ 搜索并安装EnvFile - 安装后无需启用或配置，只要当前窗口是“以文件夹为项目”打开（即菜单栏显示项目路径），插件就自动生效
-
.env文件必须放在项目根目录，内容格式为KEY=VALUE，不支持引号包裹或空格分隔（如API_URL=https://dev.example.com） - 若同时存在
.env和.env.production，需在 Sublime 设置里指定环境名："envfile_environment": "production"
Build System 中如何引用 .env 里的变量
EnvFile 注入的是运行时环境变量，不是 Sublime 的内置变量，所以不能在 shell_cmd 里直接写 $API_URL —— 那是 shell 层面的展开，而 Sublime 构建系统默认不调用 shell 解析。
正确做法是：把需要传给命令的变量显式拼进 shell_cmd，靠系统 shell 展开；或者改用 cmd + env 字段做硬编码注入。
- 推荐用
shell_cmd：它天然走 shell，能解析$VAR，例如"shell_cmd": "curl -X GET $API_URL/health" - 如果要用
cmd（比如调用 Python 脚本），必须加"env": {"API_URL": "$API_URL"}字段，但注意：这里的$API_URL不是 .env 值，而是 Sublime 变量——得先在env里把 .env 值映射过去，实际不可行；所以更稳的方式是放弃cmd，统一用shell_cmd - 变量值含空格或特殊字符？用双引号包住整个命令，并确保
.env里没加引号（EnvFile会自动 trim）
为什么改了 .env 文件，Build 还是用旧值？
因为 EnvFile 只在项目打开时加载一次，不会监听文件变更。这不是 bug，是设计使然——避免构建中途变量突变导致行为不一致。
- 修改
.env后，必须关闭整个 Sublime 窗口（不只是标签页），再重新用File → Open Folder打开项目 - 别依赖 “重新加载项目” 或 “刷新侧边栏”，这些操作不触发 EnvFile 重读
- 如果用终端启动 Sublime（如
subl .），也要确保终端本身已 source 过新.env（否则终端环境变量也还是旧的） - 验证是否生效：在
shell_cmd里临时加一句echo $API_URL，看输出是否符合预期
和系统 PATH 冲突时，哪个优先？
EnvFile 注入的变量会覆盖同名的系统环境变量，但仅限于 Build System 进程内部。它不影响 Sublime 主进程、插件后台任务，也不影响你手动在终端里执行的命令。
- 例如你在
.env里写了PATH=/my/custom/bin:$PATH，那么shell_cmd中的which python就会优先找/my/custom/bin/python - 但 Sublime 的语法高亮、Goto Definition、LSP 插件等仍使用原始系统 PATH，除非它们自己也集成 EnvFile 支持（目前主流 LSP 客户端都不支持）
- 真正容易被忽略的是：某些 Build System 模板里硬编码了
javac或node路径，这时.env里的PATH修改完全无效——得手动删掉硬编码，改用shell_cmd+$PATH展开
