📝 .env.example 生成器

粘贴真实 .env,工具会自动将值替换为安全占位符,同时保留注释与结构。

完全免费无需注册浏览器内完成 5 种语言深色模式

🔒 隐私最优先

・输入的 .env 绝不上传服务器
・所有转换均在浏览器内通过 JavaScript 执行
・无存储日志、无历史记录、无数据库
・如有顾虑,可断网使用

预设保留注释生成随机示例值

📥 输入 (.env)

📤 .env.example

➕ 从表单添加

选择键名和类别以追加到 .env.example。

📖 常见的坑

粘贴真实的 .env，它会在保留注释与结构的前提下把值替换为安全的占位符，生成可提交进 Git 的 .env.example。处理全部在浏览器内完成，输入不会被传输。「替换了值」与「没留下机密」是两回事——写在注释里的真实值会原样进入输出。提交之前，请务必自己把生成结果读一遍。

情形	会发生什么	怎么处理
真实的值留在了注释里	替换的对象是 `KEY=VALUE` 中的值，因此以 `#` 开头的行会原样输出。而真实的 `.env` 里，往往含有以注释形态存在的机密：`# 生产环境用 sk-live-abc123`、`# 旧密钥：xoxb-...`、`# 连接到 postgres://user:pass@prod-db.internal:5432`。注释是当作备忘写下的，因此比值字段更缺乏防备。同理，键名本身也可能承载信息——`ACME_CORP_API_KEY` 这个名字就把客户的名称公开了。	提交之前，请把生成的 `.env.example` 从头到尾读一遍——开启了「保留注释」时尤其必须。要看三件事：注释里是否写着真实的值、键名中是否嵌着客户名或内部系统名、主机名或端口是否暴露了内部拓扑。注释是用来写「为什么需要这个键」的地方，而不是写值的地方——想把真实值记在某处，那个地方是 `.env` 本身或密码管理器。转换之前先审一遍原 `.env` 的注释，就能省去事后在示例文件里删除的功夫。
只列出键名，新人还是跑不起来	`.env.example` 的目的是传达「要跑起这个项目需要配置什么」。可只有键名与占位符的文件，几乎传达不了任何必要信息：`STRIPE_SECRET_KEY=your_key_here` 这一行，既没说去哪里申请、也没说是测试密钥还是正式密钥，更没说它是否必填。结果就是，新人只能去问老成员，而 `.env.example` 的存在本身流于形式。	请在每个键上方写一行注释，说明去哪里获取、是否必填、值的格式这三点。像 `# Stripe 控制台 > 开发者 > API 密钥。开发环境用以 sk_test_ 开头的那个。必填。`这样一行，就足以让新人自行解决。可选的键请一并写出默认值——例如 `# 缺省为 3000`。这项工作的价值，其实对老成员更大：半年后重建环境、或复查生产配置时来读它的，通常正是当初写它的人。你以为是「为新人而写」的东西，最终帮到的多半是你自己。
示例文件做好了，真的 .env 却被提交了	在 `.gitignore` 里写上 `.env`，对已被跟踪的文件毫无作用——`.gitignore` 是「忽略尚未被跟踪的文件」的规则，因此凡是你曾经 `git add` 过的文件，其变更仍会被持续跟踪。另一个常见问题是排除模式的写法：写成 `.env` 会把 `.env.example` 也一并忽略，你辛苦做好的模板压根提交不上去——「仓库里没有 `.env.example`」的状况，多半就是这个配置失误*。	排除请写成两行——在 `.env` 的下一行写 `!.env.example`（顺序很重要；否定写在排除之前无效）。若文件已被跟踪，用 `git rm --cached .env` 仅解除跟踪，本地文件仍保留。用 `git ls-files \| grep env` 来确认最为可靠：只出现 `.env.example` 才是正确状态。还有最重要的一点：若 `.env` 曾出现在过去的提交里，改写历史并不构成补救。它仍留在 fork、CI 日志、他人的本地克隆以及 GitHub 的缓存中，因此唯一正确的应对是吊销该密钥并重新签发——在发现的当下就去做，先于整理历史。*

也值得了解 .env 这套机制本身的局限。首先，它无法表示含换行的值——想放私钥或证书，必然卡在这里（变通办法是转成 Base64 压成一行，但那是承认了局限之后的妥协）。其次，它没有类型：一切都是字符串，因此 DEBUG=false 是字符串 "false"，在多数语言中会被判定为真。第三，它没有管理环境间差异的机制——为开发、预发布、生产各自维护一份 .env，就意味着每新增一个键都要手工同步全部文件。生产环境请使用密钥管理服务而非 .env——AWS Secrets Manager、Google Secret Manager、HashiCorp Vault——因为访问控制、审计日志、自动轮换这些 .env 在原理上不具备的能力，通常只在生产环境才被需要。开发环境继续用 .env 完全没问题。

📖 使用方法

1

粘贴真实 .env

将真实 .env 粘贴到左侧文本框。也可从预设开始。
2

自动消毒

含 PASSWORD/SECRET/TOKEN/KEY 的键变为随机占位符;URL 变 example.com;端口变 3000 等典型值。
3

获得可提交文件

复制右侧输出或下载为 .env.example,然后 git add 并提交。

❓ 常见问题

我的 .env 真的不会上传吗?

是的。一切都在浏览器内由 JavaScript 处理。可在 Network 标签验证。也可离线使用。

哪些键被识别为密钥?

名称含 PASSWORD、SECRET、TOKEN、KEY、API_KEY、PRIVATE、CREDENTIAL 的键自动作为密钥处理。

保留注释和空行吗?

是的。分组用的注释和空行会保留。关闭"保留注释"可移除。

🔗 相关工具

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。