.env 文件为何成了软件开发的噩梦
Where .env Went Wrong
.env 本只是一个简单的快捷方式，却意外演变成了项目的配置架构和秘密存储库。文章指出，环境变量仅适合传递字符串，无法定义应用所需的秘密模型或验证规则。随着项目复杂化，.env 文件开始泛滥，不同解析器对格式和优先级的处理不一致，导致配置漂移和安全漏洞。更糟糕的是，即使被 .gitignore 忽略，明文文件仍可能泄露到备份或日志中。作者建议回归本质，将声明、存储和交付分离，并介绍了 SecretSpec 如何通过声明式配置和 SDK 集成，逐步淘汰环境变量中的敏感信息，让 .env 重新回归其应有的简单角色。
一个便利的工具演变成了架构，这正是 .env 走错方向的地方。
- chis
这段文字有 92% 被检测为 AI 生成。
也许 Hacker News 该在 UI 里集成一个 Pangram 检测器了，就像 Substack 正在做的那样 :)
- eigencoder
嗯，我个人没遇到过这些问题。我们只有一个 `.env` 文件，而且只用于存放本地密钥。配置绝对不该放在 `.env` 里，理想情况下应该放在 docker compose 中，或者直接在代码里定义（我们用的是 Pydantic Settings）。
- theozero
在 varlock（https://varlock.dev -- 也是免费开源的）这边，我们同意大家熟知的 `.env` 问题多多。但我们没有弃用它，而是对其进行了演进。我们用 `.env.schema` 替换了你的 `.env.example`，利用装饰器风格的注释添加 schema 信息，并提供了加载和组合值的函数。
我们的工具与许多其他类似工具的一个重大区别在于，我们将 schema 和值设置整合在一个界面中，并支持像 cuelang 那样合并多个定义，但方式更直观。它极其灵活，甚至能为不可信的工作负载提供凭证代理（credential brokering）。
最近我很享受 secretspec 的内容，也在关注它的演进 :)
- c-hendricks
- ctippett
我相信肯定有很多比 `.env` 更好的替代方案，但它的普及程度以及跨各种工具的支持使其超级方便。
我正在使用 1Password 的 `.env` 集成 [1]，虽然用户体验有点笨拙，但我真的很喜欢。我的 API 密钥很安全，原本支持 `.env` 的工具都能直接工作，而且它还有团队共享功能（虽然我还没用过）。挺酷的。