.env 解析与验证工具

粘贴一个 .env 文件——或者把它拖到输入框上——即可拿回解析、检查并附带说明的结果：每个键都列在表格里且值已脱敏，每个问题都连同行号一起列出。重复的键、无效的名称、根本不是赋值语句的行、会悄悄覆盖默认值的空值。它完全在你的浏览器中运行，文件绝不会被上传，因为生产环境的 .env 就是一捆秘密，应当按秘密来对待。

检查什么，为什么

.env 格式是一种约定，而不是标准，这正是文件悄悄腐坏的原因。每个加载器都认同 KEY=VALUE，却在其他一切问题上各执一词：是否剥离 export 前缀、是否认可引号、行内注释是否终结一个值，以及——最危险的——同一个键的两个定义中哪一个胜出。本验证器采用最大公约数规则，并报告加载器们产生分歧的地方：一个键被定义了两次并给出两个行号、一个任何 shell 都不会接受的名称、一个只开不闭的引号、一行连等号都没有的内容。空值会被标记而不是判为失败，因为 KEY= 是合法的——但它会用空字符串覆盖应用的任何默认值，而这正是服务在一台机器上能跑、在另一台上跑不起来的最常见原因。

隐私设计本身就是功能。一个生产 .env 把数据库密码、API 密钥和会话秘密集中在一个小文件里，而最自然的调试动作——把它粘贴到某处求助——恰恰就是泄漏。AI 聊天、问题跟踪系统和团队频道都会保留副本，往往可搜索，往往永久保存。因此本工具遵循与 日志解析器 和 证书生成器 相同的规则：敏感输入永不离开浏览器，值在屏幕上脱敏显示，唯一的导出是你主动下载的文件。配套文章 env 文件是秘密泄漏之地 讲述了文件本身的卫生习惯——什么该放进去、什么不该、以及文件一旦外泄该怎么办。

常见问题

把生产环境的 .env 粘贴到这里安全吗？

安全——这正是本工具的意义所在。解析完全在你的浏览器中运行：没有上传，没有服务器往返，你粘贴的任何内容都不会被传输或存储到任何地方。值在屏幕上默认脱敏，因此屏幕共享或截图也不会泄漏它们。把 .env 粘贴进 AI 聊天、工单或团队消息则完全不同，那些地方都会保留副本——关于 env 文件与秘密泄漏 的文章解释了更安全的习惯。

既然最后一个胜出，重复键为什么还重要？

因为编辑文件的人不知道哪一个胜出。他们改了第 4 行的值，重新部署，然后眼睁睁看着什么都没发生——加载器悄悄用了第 41 行。更糟的是，有些框架取第一个定义，有些取最后一个，于是同一个文件在整套技术栈里的行为都不一样。一个键、一行、一个值：验证器会把每个重复键连同两个行号一起列出，好让失效的那一行被删掉。

我的应用读取了一个 .env 里没有的变量。怎么找出它们？

把你的代码或配置粘贴到用法输入框里。解析器会提取每一个被引用的名称——process.env.X、process.env[’X’]、import.meta.env.X、${X} 和 $X——并双向报告：代码引用了但文件从未定义的名称（这些会在运行时变成 undefined，通常还是在最糟糕的时刻），以及文件定义了但没有任何地方引用的键（死配置，而且出乎意料地常常还保存着有效的秘密）。

什么算无效的键？

任何不是以字母或下划线开头、后面跟着字母、数字和下划线的内容。以数字开头、包含连字符或点号、或带有多余空格的键，会被许多加载器和 shell 丢弃或弄坏——一个在 bash 里能干净加载的文件，可能正因为这个原因在 Node 加载器里失败。验证器会连同行号一起标记它们；条目表里仍会显示这一行，让你看到会丢失什么。

导出的文件包含真实值吗？

包含。JSON 和 YAML 下载以及复制的 JSON 都是真实配置——脱敏是显示层面的保护，而不是对你自己数据的删减。请像对待 .env 本身一样对待导出文件：绝不要提交到公开仓库，绝不要附在工单里。如果需要一个可以安全分享的版本，分享脱敏后的截图或键列表即可。