生产环境访问环境变量的最佳实践：不提交.env文件至仓库

核心原则 #

永远不要把包含敏感信息的.env文件提交到代码仓库——不管是公开还是私有仓库，一旦仓库泄露，凭证会直接暴露。下面是几种可落地的解决方案：

1. 利用云平台/服务器的内置环境变量管理 #

几乎所有云服务商和主流服务器管理工具都支持系统级环境变量配置：

• 云平台：比如AWS Parameter Store、Azure App Configuration，把敏感变量存在这类服务中，应用启动时通过SDK读取，或直接配置为应用的环境变量（比如AWS Elastic Beanstalk的环境配置）。
• VPS/物理服务器：Linux系统可在/etc/profile、~/.bashrc中添加export DB_PROD_USER=xxx，或在systemd服务配置文件里用Environment字段定义变量，启动应用时自动加载。
• 容器化部署：Docker通过docker run --env DB_PROD_USER=xxx或docker-compose.yml的environment字段注入变量（注意不要把敏感值写在docker-compose.yml里，可通过本地未提交的.env或命令行传递）。

对应你的Node.js代码，无需修改逻辑，只要服务器上存在这些环境变量，process.env.DB_PROD_USER就能正常读取。

2. CI/CD流程中注入环境变量 #

如果用GitHub Actions、GitLab CI、Jenkins等工具构建部署：

• 把敏感变量存在CI工具的保密变量中（比如GitHub Actions的Secrets、GitLab CI的Variables），这些变量不会暴露在日志或仓库里。
• 构建/部署阶段直接通过CI的环境变量传递给应用：前端项目（React/Vue）的构建工具会自动读取带特定前缀的变量（REACT_APP_*、VUE_APP_*）并注入打包代码；后端项目可在启动命令前用export注入，或让CI工具直接设置环境变量后启动应用。

举个GitHub Actions的简易示例：

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm install
      - name: Deploy to server
        env:
          DB_PROD_USER: ${{ secrets.DB_PROD_USER }}
          DB_PROD_PASS: ${{ secrets.DB_PROD_PASS }}
        run: npm start

3. 加密的环境变量模板（适合私有仓库团队） #

如果团队需要共享环境变量配置：

• 提交.env.example文件到仓库，只写变量名，比如：

  DB_PROD_USER=
  DB_PROD_PASS=
  DB_PROD_TABLE=
  

• 用git-crypt、blackbox等工具对真实.env文件加密后提交到私有仓库，仅授权成员可解密获取真实值。这种方式避免明文泄露，但只适合私有仓库，公开仓库不建议使用。

4. 专业密钥管理工具（大型项目） #

针对有运维团队的大型项目，可使用HashiCorp Vault、AWS Secrets Manager这类专业工具：

• 所有敏感凭证集中存储在密钥管理服务中，应用启动时通过API或SDK动态拉取所需变量。
• 支持权限控制、凭证自动轮换等高级功能，安全性更高，但学习和维护成本相对较高。

注意事项 #

• 前端项目特殊处理：前端代码会打包到浏览器，绝对不能把API密钥、数据库凭证这类敏感变量注入到前端代码中——应通过后端代理，前端仅调用后端接口，由后端从环境变量读取敏感信息后与第三方服务交互。
• 变量命名规范：建议用环境前缀区分不同环境（比如DB_DEV_USER、DB_PROD_USER），避免混淆。

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