# 你们如何确保自己的 .env 文件始终是最新的,并且整个团队都与之同步?

本页为原文的机器翻译，未经人工译者审核。历史信息可能已发生变化。

你们如何确保自己的 .env 文件始终是最新的,并且整个团队都与之同步?
我们的解决办法是重新定义"env 文件是什么":它不是某个人保管并手动更新的文件,而是每次运行应用时自动生成的 build artifact。

很长一段时间里,我们管理 env 的办法既糟糕又手动:Slack 上发一条消息。 
(如果你有同感,请举手...)
如果有人添加了一个新的环境变量并推送了代码,三天后另一个人 pull 下来运行,结果因为一个从没听说过的变量而崩溃。然后就是那条惯常的消息,或是在 Slack 消息里到处翻找。即使通过 bitwarden 这样的密钥管理器来传递,仍然会因为不同步而浪费宝贵的时间...

在我们已有几十个服务(前端和后端)的产品中,问题变得大得多,因为每个项目都有自己的 env。

所以我们的办法是转向云端 -- 现在每个服务在 Google 的 Secret Manager 中有一个 secret,以 JSON 对象的形式保存所有本地开发变量。只需在一个地方更新一个值 -- 整个团队就能获得它,并带有历史记录(顺便也能轻松回滚)。

从开发者(DevEx)的角度,同步不再是需要有人记住的命令,而是自动操作:我们为 Nx 写了一个小型 executor,并把它定义为我们每个 dev target 的依赖,这样在应用启动之前,Nx 就已经拉取了最新的 secret 并写出了新的 env。 

如果想在本地覆盖(override)怎么办?
这个我们也优雅地解决了 -- 放在 env.local 里的所有内容都会合并到从云端获取的内容之上。共享的值保持共享,你的机器依然属于你。

这有一点小代价 -- 每隔一段时间需要刷新我们与 GCP 的连接(刷新会自动发生,但仍需通过浏览器批准连接),而更新 secret 需要使用 Google 那糟糕透顶的 secret 界面(为此我也拼凑了一个浏览器扩展的方案来整理它),但自从我们这样做之后,"在我这儿能跑"就不再是环境变量的问题了。

如果你们仍在为团队同步 env 文件而苦恼,我强烈推荐采用这种工作方式,它能省去大量头痛和开发者的宝贵时间,让人专注于真正重要的事情

Original: https://ofershap.github.io/posts/linkedin-7495353124623278080/
Source: https://www.linkedin.com/posts/ofershap_%D7%90%D7%99%D7%9A-%D7%90%D7%AA%D7%9D-%D7%93%D7%95%D7%90%D7%92%D7%99%D7%9D-%D7%A9%D7%94%D7%A7%D7%95%D7%91%D7%A5-env-%D7%A9%D7%9C%D7%9B%D7%9D-%D7%99%D7%94%D7%99%D7%94-%D7%AA%D7%9E%D7%99%D7%93-activity-7495353124623278080-oV7i
Published: 2026-08-18T08:37:21.837000+03:00