从代码和日志里做环境变量提取:审计依赖与生成 .env.example

接手一个老项目时,我最怕的不是看不懂业务逻辑,而是没人说得清这个服务到底依赖多少个环境变量。代码里散落着 process.env.DATABASE_URL,shell 脚本里写着 $REDIS_HOST,docker-compose 里又冒出一堆 ${API_KEY}。漏配一个,服务启动就崩,而错误信息往往只是一句 undefined。

环境变量提取,本质就是把这些散落各处的引用,从一堆混杂文本里捞出来,变成一份能复核的清单。下面讲我自己常用的做法。

环境变量在代码里有哪些写法

提取之前先得知道要找什么。同一个变量,在不同地方写法完全不同:

Node / TypeScript:process.env.DATABASE_URL、process.env["API_KEY"]、解构 const { PORT } = process.env
Shell 脚本:$REDIS_HOST、${REDIS_HOST}、${PORT:-3000}(带默认值)
Dockerfile / compose:ENV NODE_ENV=production、${API_KEY}
Python:os.environ["SECRET"]、os.getenv("DEBUG")
.env 文件本身:DATABASE_URL=postgres://...

一个好的提取流程要能同时识别 $VAR、${VAR} 和 process.env.X 这几类引用形式,把变量名抠出来,把周围的引号、括号、注释丢掉。命名上,环境变量约定俗成是大写加下划线([A-Z][A-Z0-9_]*),所以小写的局部变量不会被误抓。

真实例子:一段代码抓出变量名列表

我贴一段混着配置的代码片段,看提取出来是什么:

输入:

const db = process.env.DATABASE_URL;
const port = process.env.PORT || 3000;
// fallback host
exec(`redis-cli -h $REDIS_HOST -p ${REDIS_PORT}`);
const key = process.env["STRIPE_SECRET_KEY"];

提取后的变量名列表:

DATABASE_URL
PORT
REDIS_HOST
REDIS_PORT
STRIPE_SECRET_KEY

五个引用,三种写法,注释行被忽略,3000 这种字面量不会进列表。拿到这份清单,我就能对着它写 .env.example,一行一个,后面留空给同事填。

审计配置依赖,写出可交接的 .env.example

清单的真正价值在审计。把整个项目的源码、启动脚本、CI 配置一股脑粘进去,提取出全量引用,再去重排序,你会立刻看到这个服务真实依赖哪些外部配置。

接着对照现有的 .env 文件做差集:清单里有、.env 里没有的,就是潜在的缺失变量,服务上线大概率会在这里炸。反过来,.env 里有、代码里再也没引用的,就是该清理的僵尸配置。

我习惯把提取结果导出成带行号的 CSV 留底,这样回头排查时能直接跳回源文件那一行,知道这个变量到底是谁在用。

去重和规范化为什么不能省

同一个变量在代码里出现几十次很正常,提取出来必须去重,否则清单没法看。但去重之前要先规范化:从网页或聊天记录复制来的文本常带零宽空格和不可见字符,API_KEY 和 API_KEY (尾部多个空格)在程序眼里是两个 key,不规范化就去不干净。

校验这一步也别跳过。像 MY KEY=1 这种键里带空格的,或者引号没闭合的片段,会被标成无效项保留下来,让你在它进配置前先核一眼,而不是直接当成合法变量混进去。

本地处理:不让密钥离开浏览器

环境变量里常常就是数据库密码、Stripe 密钥这类东西。这也是我坚持用本地工具的原因:环境变量提取器的所有解析、去重、导出都在浏览器里跑,上传的文本文件通过 File API 在当前标签页读取,不会发到任何服务器。审计敏感配置时,这一条几乎是底线。

如果你的清单还需要进一步校验格式是否合法,可以接着用环境变量校验逐行确认,无效项会被单独标出来。两个工具配合,从一堆乱糟糟的源码到一份干净可交接的变量清单,中间不需要手工抠名字、补引号、漏逗号。

下次你接手一个看不懂依赖的服务,别再靠启动报错一个个补。先把代码全量提一遍,清单摆在面前,缺什么一目了然。

Made by Toolora · Updated 2026-06-13