2026年7月30日，.env是软件界最成功的意外之一。它最初作为三个导出命令的快捷方式。然后，它成为项目的配置架构、秘密存储、环境模型、入职指南、CI接口和部署格式。环境变量很好地完成了一项工作：将字符串传递给进程。.env把这种传递机制变成了真相源。从便利变成了架构。这就是.env的错误所在。环境变量解决了一个小问题：将值传递给正在运行的进程。应用程序可以在不知道是开发者、CI系统还是秘密管理器提供它的情况下读取DATABASE_URL。一个.env文件让这些值变得容易保存和重新加载。这很好。但是团队还使用该文件描述应用程序的需要。KEY=value无法说明一个值是否是必需的、秘密的、可以提交的、仅在生产环境中可用或仅限一个服务的。这些要求超出了任何进程和任何开发者的笔记本电脑。它们属于持久项目声明。 .env存储交付的值；它不能定义应用程序的秘密模型。考虑一个典型的示例文件：DATABASE_URL = REDIS_URL = redis://localhost:6379 STRIPE_API_KEY = DEBUG = false 该文件提出了更多问题而不是答案。空值是意味着必需还是可选？REDIS_URL是开发默认值吗？STRIPE_API_KEY仅用于生产吗？DEBUG是布尔值吗？Dotenv无法编码这些答案。Node.js文档指出每个值都变成字符串。一个关于布尔值的dotenv问题，2015年打开，仍然从对“false”是truthy感到惊讶的开发者那里收集反馈。团队将缺失的信息放在其他地方：验证代码、README、.env.example 或一个队友的记忆。这些来源漂移。该文件还使DEBUG和STRIPE_API_KEY看起来等价。一个是属于Git的普通设置。另一个则授予权限并需要访问控制和版本轮换。将它们混合使整个文件变得敏感。如果没有明确的声明，缺少值会导致延迟失败：应用程序只有在代码尝试使用它们时才会发现这些值。新的要求通常会创建另一个文件：.env .env.local .env.development .env.development.local .env.test .env.production 文件名成为环境模型。后缀定义作用域，加载顺序定义继承，复制文件变成部署。这反转了十二因子应用程序的指导原则。它的要点是环境变量应该是独立的控制，因为命名环境在部署增加时会变得脆弱。.env.production在文件名中重新创建了该分组。现在每个新值必须添加到.env.example中，在README中记录，在代码中验证，并复制到正确的真实文件中。错过一个，环境就会漂移。.env看起来标准化，但每个解析器定义了自己的格式。Node.js文档指出缺乏正式规范，python-dotenv也是如此。每个加载器都做出自己的选择。python-dotenv扩展${NAME}但不扩展$NAME。Node dotenv将变量扩展委托给另一个工具。Docker Compose支持自己的壳样式操作符。Vite甚至支持以相反顺序的引用，然后警告同一表达式在shell或Docker Compose中将无法工作。注释和引号也不同。Node dotenv在版本15中作为重大更改改变了未引用值中#的含义。一个devenv用户发现引号成为导出关键的一部分。解析器的优先级也不同。Node dotenv通常让第一个文件取胜。Docker Compose让最后一个env_file取胜，然后让环境部分覆盖它。Vite优先考虑现有的进程变量而不是它的文件。Docker Compose对两个类似名称赋予不同的行为。env_file：向容器提供变量，但不使用它们插值compose.yaml。docker compose --env-file会影响插值。在一个关闭为工作正常的议题中，维护者将该选项的名称描述为不幸的选择。优先级还取决于时机。Node dotenv的ES模块指导在导入模块在初始化期间读取环境时需要特殊处理。Vite警告Bun的自动.env加载可能会干扰Vite自己的加载顺序。VITE_*值在构建时被替换并成为客户端包的一部分。同一行可以成为运行时秘密、构建时常量或公共浏览器值。加载器根据时机和上下文做出决定。在这一点上，.env的行为就像一个小程序，控制流分布在文件名、标志、工作目录、父进程和库版本之间。dotenv项目表示不要提交.env . .gitignore防止了一个意外。它没有增加加密、访问控制、审计或撤销。该文件仍然可能出现在编辑器备份、聊天消息、档案、支持包、容器构建上下文和旧笔记本电脑中。一个devenv集成被报告复制.env内容到Nix存储中，