DEV

.env 助手 — 生成 .env.example、扫描密钥、对比环境

从 .env 文件生成 .env.example,扫描意外提交的密钥,对比 staging 与 production。全部在浏览器中完成,无上传。

● 本地运行 · 在您的标签页中生成页面加载以来工具发出的网络请求：0 次

DEV

.env Helper

Generate .env.example, scan for known secret formats, or diff two .env files — 100% local.

● 本地运行 · 在您的标签页中生成页面加载以来工具发出的网络请求：0 次

Loading…

打开助手

.env 文件是配置 12-factor 应用最简单的方式:每行一个 KEY=value 对,注释以 # 开头,空行会被忽略,应用在启动时读取整个文件。这种格式简单到已经成为所有语言和框架开发配置的事实标准 —— Node.js、Python、Go、Ruby、PHP、Java 都有现成的库来解析 .env 文件。真正的麻烦来自文件的生命周期:本地开发用 .env,staging 服务器用 .env.staging,生产环境用 .env.production,还有一个 .env.example 会提交进仓库,让新加入的开发者知道需要设置哪些键。把这些文件保持同步,正是这个工具要解决的琐事。

.env 管理里「不那么显然」的一点是它的安全边界。包含真实值的 .env 文件永远不进版本控制 —— .gitignore 的第一行就是 .env。可以放心提交的是 .env.example:键完全相同,值替换成占位符,本质是一份配置文档。每个团队都至少会犯一次的错误,就是提交了一个带真实 API key、数据库密码或 OAuth client secret 的 .env。这里的「扫描密钥」模式正是为这个错误兜底:它用模式匹配高熵字符串和已知密钥前缀(AWS、Stripe、GitHub、Slack、Google),在任何看起来像真实凭据的内容落进公开仓库之前把它拦下来。

最后的交接:如果目标是搭建一个新项目,对你的 .env 跑一次「生成示例」并提交结果 —— 新开发者把它复制成 .env 再填上值即可。如果目标是做一次安全审计,对仓库里的每个 .env 文件都跑一遍「扫描密钥」,逐项处理高危项。如果目标是比对环境,用 staging 和 production 的 .env 文件跑一遍「对比」,确认 staging 拥有 production 的全部键,也没有 production 独有的键不小心漏进了 staging。三种模式覆盖了 .env 管理最常见的三类任务;至于日常维护,可以装一个带密钥扫描器(gitleaks、trufflehog)的 pre-commit hook,在 commit 落地之前就把问题拦下来。

使用方法

粘贴你的 .env 文件
把 .env 内容放进输入区,或者直接加载一个 .env 文件。解析器支持标准的 KEY=value 行、以 `#` 开头的注释、带引号的值,以及用引号包裹的多行值。
选择工具模式
在「生成示例」(去掉值、保留键和注释)、「扫描密钥」(标记 AWS key、Stripe key、GitHub token 等高熵字符串)和「对比环境」(并排比较两个 .env 文件)之间切换。
复制或下载结果
把生成的 .env.example、密钥扫描报告或 diff 复制到剪贴板。输出是纯文本 —— 直接粘贴到编辑器或 commit message 里就行。

常见问题

扫描器能检测哪些密钥?

扫描器结合了模式匹配和熵分析。能识别 AWS access key(AKIA...)、Stripe secret key(sk_live_...)、GitHub token(ghp_...、gho_...)、Slack token(xoxb-...)、Google API key(AIza...),以及任何看起来像密钥的 40+ 字符的 base64/hex 字符串。

「生成示例」是怎么工作的?

「生成示例」读取一个 .env 文件,并把每个值替换成占位符(空字符串、'changeme' 或 'your-key-here',取决于值的用途)生成 .env.example。键名和注释完整保留,生成结果可以放心提交到公开仓库。

环境对比会展示什么?

对比分为四部分:两个文件都有的键(值相同或不同)、只在第一个文件里的键、只在第二个文件里的键,以及值不匹配的键。常用于检查 staging 是否包含 production 的全部键,以及任一环境里没有残留的过期键。

扫描器会标记我测试用的 API key 吗?

扫描器会标记所有匹配高熵模式的字符串,包括测试用 key。如果测试 key 本来就是设计成可公开提交的(Stripe 的 `sk_test_...`、GitHub 的 `gho_test_...`),扫描器会标记为低危;生产环境的 key 则标记为高危。

工具会保存我的 .env 内容吗?

不会 —— 工具完全在浏览器中运行。.env 内容在内存中解析,不会被发送到任何服务器。浏览器标签页的内存会持有这份内容,直到你关闭标签或点击「重置」,届时会被垃圾回收。

限制说明

基于模式的检测密钥扫描器依赖正则模式叠加熵启发式判断。会有误报(长得像密钥、其实并不是密钥的随机字符串),也会有漏报(没有匹配已知模式的短密钥)。扫描器应当作为最后一道防线,而不是主要防线。
不会自动打码扫描器只标记密钥,不会改写 .env 文件。如果想得到可以放心提交的版本,可以手动替换被标记出的值,或者直接用「生成示例」,它会剥离所有值,不管看起来是不是密钥。
对比基于文本环境对比按文本方式比较键值对。重新排序的键不会被标记为差异(对比前会先排序),但列表型变量里顺序变了的值会被标记 —— 某些环境里顺序是有意义的。

平台说明

macOS: macOS Terminal 中对应的 CLI 命令是 `diff <(grep -v '^#' .env.staging | sort) <(grep -v '^#' .env.prod | sort)`。当内容是从聊天窗口、邮件或文档页粘贴过来、不想再重敲一遍时,浏览器工具更合适。
Windows: PowerShell 里对应的 CLI 命令是 `Compare-Object (Get-Content .env.staging) (Get-Content .env.prod)`。如果追求跨平台的一致性,浏览器工具是更合适的选择 —— 同样的输入在每个平台上都会产出同样的输出。
Linux: GNU coreutils 中 `comm -23 <(sort .env.staging) <(sort .env.prod)` 展示仅在 staging 中存在的键。浏览器工具把「生成」「扫描」「对比」三种模式集成在同一个界面 —— 适合不值得为它写脚本的一次性检查。
CLI: `gitleaks` 和 `trufflehog` 等 CLI 工具内置同样模式的密钥检测。浏览器工具适合对单个 .env 文件做临时检查;如果是 pre-commit hook 或 CI 流水线,这些专用的 CLI 工具更合适。
Web: 完全在客户端运行,页面加载后可离线使用。.env 内容在内存中解析,不会被发送到任何服务器 —— 用生产凭据也安全,不过「别把密钥粘贴进浏览器」这条老规矩仍然适用。