如何在AWS EC2实例部署MERN应用时正确设置环境变量

先排查本地.env文件不生效的问题 #

大部分人.env不生效都是踩了下面几个基础坑，先逐个核对：

• 路径不对：.env必须和你启动Node服务时工作目录下的package.json平级。比如你后端代码在/home/ec2-user/mern/server，是cd到这个目录下执行npm start，那.env就得放在server文件夹里，不能丢在项目最外层的mern目录。
• 依赖或引入顺序错：后端读.env依赖dotenv包，先在server目录执行npm install dotenv --save确认依赖安装成功，然后在后端入口文件（一般是server.js/index.js）的最顶部加引入代码，必须放在所有路由、数据库连接等业务代码之前：

require('dotenv').config()

如果这行写在业务代码后面，加载顺序不对就拿不到变量。

• 文件权限不足：EC2上如果你的Node进程运行用户没有.env的读权限，会直接读文件失败，执行chmod 644 .env给当前运行用户分配读权限即可，不要给777权限，避免其他用户随意读取敏感内容。
• 没重启服务：改完.env必须重启Node进程才会加载新配置，用pm2托管的执行pm2 restart <你的服务名称>，直接node启动的就杀掉旧进程重新启动，旧进程会一直缓存启动时加载的变量。

无需额外AWS服务的本地配置方案 #

如果不想用.env文件，可以直接在实例或服务层面配置环境变量，稳定性更高：

• 临时测试配置：直接在启动服务的终端里执行export命令注入变量，仅当前会话生效，关终端就失效：

export MONGO_URI="你的MongoDB连接串"
export JWT_SECRET="你的JWT签名密钥"
export PORT=5000
# 执行完直接在当前终端启动node服务即可读取到上述变量

• 用户级永久配置：把上述export命令追加到当前用户家目录下的.bashrc或.bash_profile文件末尾，执行source ~/.bashrc重载配置后，该用户登录的所有会话都能读到变量。注意如果你的服务是用systemd托管开机自启，这种方式读不到用户目录下的配置，需要配在服务定义里。
• 服务级配置（最推荐本地部署用）：如果用pm2托管Node服务，直接在项目根目录创建ecosystem.config.js定义环境变量，和服务绑定不会出现读取异常：

module.exports = {
  apps: [{
    name: "mern-backend",
    script: "./server.js",
    env: {
      NODE_ENV: "production",
      MONGO_URI: "你的MongoDB连接串",
      JWT_SECRET: "你的JWT签名密钥",
      PORT: 5000
    }
  }]
}

保存后执行pm2 start ecosystem.config.js启动服务即可。如果用systemd托管服务，直接在对应的.service文件的[Service]块下添加Environment="变量名=变量值"，重载systemd配置后重启服务就生效。

注意：React前端部分的环境变量必须以REACT_APP_开头，且是在执行npm run build构建阶段就注入到静态打包文件里的，不是服务运行时读取。不管你在EC2上配多少运行时变量，只要没在构建前设置好，前端打包后都读不到，这是前端环境变量最容易踩的坑。

生产环境推荐的AWS托管配置方案 #

如果你的环境变量包含数据库密码、第三方API密钥这类敏感信息，存在本地实例上有泄露风险，可以用AWS原生服务托管，不需要在实例上存任何明文密钥：

• AWS Systems Manager Parameter Store：免费版就支持存储明文、加密的键值对，给EC2实例绑定的IAM角色分配只读权限后，Node代码里直接用AWS SDK就能读取对应参数。支持按环境（生产/测试）分层管理参数，更新参数不需要登录实例，重启服务即可加载新值，适合绝大多数场景。
• AWS Secrets Manager：适合存储高敏感级别的密钥，支持自动轮换密钥（比如自动更新RDS数据库密码，不需要手动改配置），安全性更高，按存储的密钥数量和API调用次数收费，成本极低。
  用这两个服务的时候，不要把AWS访问密钥硬编码在代码里，只要给EC2绑定对应权限的IAM角色，实例会自动获取临时凭证调用服务，不会产生额外的密钥泄露风险。

内容的提问来源于stack exchange，提问作者Ashik S Nair