团队协作时如何安全合规地共享.env配置文件

首先明确两个核心原则：

• 真实的.env文件包含敏感凭证，永远不要提交到任何版本控制系统，哪怕是私有仓库也不行，仓库提交历史里留存的敏感信息几乎无法彻底清除，一旦仓库权限泄露会直接造成安全事故
• 不要用普通未加密邮件、公开聊天工具直接传输.env文件，这类渠道的传输链路、服务器留存记录都有泄露风险

仓库内必须同步的配置模板 #

你需要在代码仓库里提交一份不带任何真实敏感值的配置模板文件，通常命名为.env.example，随项目版本一起迭代。文件里只保留所有配置项的键名、格式要求、值的占位说明，示例如下：

# 数据库连接配置
DB_HOST=本地数据库地址，本地开发默认填127.0.0.1即可
DB_PORT=数据库端口，默认3306
DB_USER=本地数据库账号
DB_PASSWORD=本地数据库密码
# 第三方服务配置
WECHAT_APPID=填写微信开放平台分配的AppID
WECHAT_SECRET=填写微信开放平台分配的AppSecret

所有团队成员拉取代码后，第一步先把这份模板复制重命名为本地的.env，再填入对应的真实配置值即可。后续项目新增、删除、修改配置项时，直接更新这份模板文件提交到仓库，所有成员拉取最新代码后对照模板补全本地配置就行，不用单独挨个通知配置变更。

敏感配置值的安全共享方式 #

根据团队规模选对应方案即可，不需要用邮件传文件：

• 10人以内小团队：把最新的有效配置值存在团队共用的端到端加密密码管理工具的共享文件夹里，只给当前项目参与成员开放访问权限；新成员加入时，由项目负责人通过内部加密通讯渠道直接把配置值发给对方，确认对方收到并配置完成即可，不要生成长期有效的公开分享链接。
• 中大型团队：使用专门的密钥管理服务统一存储所有敏感配置，按岗位、项目分配访问权限，开发环境的配置可以让有权限的成员按需拉取，生产环境的配置由运维人员直接在部署平台注入，普通开发人员不需要接触生产环境的真实密钥，从流程上避免泄露风险。
• 如果团队已经用容器化、云原生开发流程，可以直接把开发环境的配置托管在内部开发平台的加密配置模块，成员本地启动项目时可以通过权限校验自动拉取配置，甚至不需要在本地手动维护.env文件。

新成员入职的配置交付流程 #

不需要发邮件，按常规项目权限开通流程走就行：

1. 给新成员开通代码仓库权限，拉取代码后引导对方查看.env.example，明确需要配置的项
2. 给新成员开通密钥存储工具的对应访问权限，或者由对接人通过加密渠道发送对应环境的真实配置值，明确告知对方不得外传、不得把带真实值的.env提交到仓库
3. 等对方本地配置完成、成功启动项目验证所有配置生效，流程就结束了

补充提醒：不管用哪种共享方式，都要建立定期轮换密钥的机制，遇到成员离职、配置疑似泄露的情况，第一时间替换所有相关的密码、API密钥，不要一套密钥长期用到底。

内容的提问来源于stack exchange，提问作者user18431308