如何安全地与团队共享 .env 文件和环境变量

"我微信发给你"

新同事入职了。配置本地开发环境时，他问了一句：

".env 文件能发我一下吗？"

接下来发生的事情再熟悉不过了。一位老同事打开微信，把数据库密码、API 密钥、各种第三方 Secret 一股脑地粘贴发送。这条消息从此永远留在聊天记录里。

这种事比想象中更常见，也比想象中危险得多。

为什么不能随意共享 .env 文件

.env 文件里装的全是敏感信息：

• 数据库连接信息 — 主机、端口、用户名、密码
• API 密钥 — Stripe、AWS、Firebase 等付费服务的密钥，被滥用就会产生费用
• 第三方 Secret — OAuth Client Secret、Webhook 签名密钥
• 内部服务 Token — 微服务间的认证令牌

用微信或 Slack 发送的消息会保存在服务器上。任何有工作区访问权限的人都能通过搜索找到它们，离职员工的设备上也可能还留着这些信息。

常见但危险的共享方式

方式	风险
微信 / Slack 私信	永久保存在服务器，可被搜索
邮件附件	留存在邮件服务器，可被转发
共享 Google Docs	链接泄露后任何人可访问，修改历史会保留内容
提交到 Git	即使删除也留在 git log 历史中，机器人几秒内就能扫描
飞书 / Notion	工作区全员可搜索

其中最致命的是误提交到 Git。推送到 GitHub 的密钥会在几秒内被自动扫描机器人发现。

安全共享 .env 文件的方法

1. 使用密钥管理服务

Doppler、HashiCorp Vault、AWS Secrets Manager 等专业工具可以集中管理环境变量，提供细粒度的权限控制和审计日志。团队规模较大时，这是最理想的方案。

2. 团队密码管理工具

1Password Teams 和 Bitwarden Organization 的共享保管库可以存储 .env 内容。只有授权成员才能查看，所有数据端到端加密。

3. 带密码的自毁备忘录

如果还没上密钥管理系统，或者只需要临时共享一次，LOCK.PUB 的秘密备忘录功能就很实用。把 .env 内容粘贴到备忘录中，设置密码和过期时间，然后把链接通过 Slack 发送，密码通过微信另外发送。过期后内容自动消失，不留任何永久记录。

4. GPG 加密文件

安全要求较高的团队可以用 GPG 加密 .env 文件后再共享。不过这需要每位成员都熟悉 GPG 密钥管理，有一定的上手门槛。

.env 管理最佳实践

1. 立即加入 .gitignore — 创建项目后第一件事就该做这个。
2. 维护 .env.example 文件 — 用占位符标明需要哪些变量，不暴露真实值。
3. 每个环境使用不同的凭据 — 开发、预发布、生产环境绝不共用同一套密钥。
4. 定期轮换密钥 — 至少每季度更新一次。
5. 离职时立即回收权限 — 成员离开后，必须立即更换该成员接触过的所有密钥。

现在就能做的配置

在 .gitignore 中添加以下内容：

# 环境变量
.env
.env.local
.env.*.local

然后创建 .env.example 作为文档：

# .env.example
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxx
FIREBASE_API_KEY=your_firebase_api_key_here
NEXT_PUBLIC_BASE_URL=http://localhost:3000

把这个文件提交到仓库。新成员一看就知道需要配置哪些变量，完全不需要暴露真实值。

别再用明文发密钥了

共享 .env 文件看似是个小事，但它是凭据泄露最常见的源头之一。不管是部署专业的密钥管理系统，还是用 LOCK.PUB 创建带过期时间的加密备忘录，关键是改掉在聊天工具里粘贴明文密钥的习惯。

现在就去搜一下你团队的微信群或 Slack 频道，试试搜 DATABASE_URL 或 API_KEY，结果可能会让你大吃一惊。