基于AWS部署带Node.js Express后端的React应用方案咨询

我来帮你拆解这几个部署方案的优劣，还有你提到的第三种API子域名方案的可行性：

1. 硬编码EC2公网IP到React代码 #

• 核心问题：这完全是临时测试级别的方案，不适合生产环境
  • IP变更风险极高：EC2实例重启、更换时公网IP会自动变更，你得重新修改React代码、打包、上传S3，折腾起来特别麻烦
  • 跨域与HTTPS坑多：如果S3用HTTPS（现在域名基本都是HTTPS），EC2用HTTP的话浏览器会拦截混合内容；给EC2单独配HTTPS又要额外管理证书，徒增复杂度
  • 维护性极差：硬编码的IP在团队协作、后续迭代中很容易成为隐藏隐患，新人接手大概率踩坑
• 总结：仅用于临时跑通功能测试，千万别用到生产环境

2. Nginx反向代理（域名指向EC2，转发请求到S3和后端） #

• 优势：
  • 统一域名规避跨域：前端和API共用example.com，同域名下浏览器默认允许请求，不用额外处理CORS
  • 路由控制灵活：Nginx可以轻松配置规则，比如/api开头的请求转发到Express服务，其余请求转去S3。给你个配置示例参考：

    server {
        listen 443 ssl;
        server_name example.com;
        # 这里放SSL证书配置
    
        # 转发API请求到本地Express服务
        location /api {
            proxy_pass http://localhost:3000;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    
        # 转发静态资源到S3托管桶
        location / {
            proxy_pass https://your-s3-bucket.s3.amazonaws.com;
            proxy_set_header Host your-s3-bucket.s3.amazonaws.com;
        }
    }
    

  • 统一HTTPS管理：只需要给EC2的Nginx配置一张example.com的SSL证书（比如用Let's Encrypt免费证书），前端和API就能都用上HTTPS
• 劣势：
  • 额外增加Nginx运维成本：要保证Nginx服务稳定、定期更新配置和软件
  • 静态资源多一层转发：所有前端请求都要经过EC2，会占用EC2的带宽和资源，相比直接访问S3有轻微性能损耗

3. API子域名方案（最推荐的生产级方案） #

这是架构最清晰、维护最省心的方案，具体实现思路：

• 主域名example.com直接指向S3静态托管，专门用api.example.com子域名指向EC2的Express服务（也可以配合AWS API Gateway进一步优化）
• 实操步骤：
  1. 在DNS服务商添加A记录，把api.example.com指向EC2的弹性IP（一定要用弹性IP，避免实例重启IP变更）
  2. 给Express后端配置CORS，允许主域名的请求：

     const cors = require('cors');
     app.use(cors({
         origin: 'https://example.com',
         credentials: true // 如果需要传递Cookie等凭证的话开启
     }));
     

  3. React代码里用环境变量管理API地址，比如配置REACT_APP_API_URL=https://api.example.com，代码里写fetch(${process.env.REACT_APP_API_URL}/users/1)，这样打包前可以灵活切换开发/生产环境
• 核心优势：
  • 职责完全分离：前端静态资源直接走S3的CDN，性能拉满；API服务单独用子域名，后续如果要扩容后端（比如换成ECS、Lambda），只需要修改api.example.com的DNS记录，完全不用动前端代码
  • 架构清晰易维护：子域名区分前后端，团队协作时一目了然，后续添加其他服务（比如admin.example.com）也更方便
  • HTTPS配置更清晰：S3可以配合CloudFront一键开启HTTPS，EC2上的Express可以用Nginx反向代理加Let's Encrypt证书，各自独立配置互不影响

最终推荐 #

优先选API子域名方案，它兼顾了架构清晰性、维护便捷性和性能；如果你的团队不想维护额外的子域名证书，或者EC2资源足够，Nginx反向代理方案也可以接受；硬编码IP的方案只适合临时测试，绝对不要用到生产环境。

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