部署Webpack构建的React应用时静态资源404问题解决咨询

我之前在生产环境处理过几乎一模一样的场景，咱们先把问题根源理清楚：你遇到的404本质是新旧容器的静态资源hash完全不兼容——旧容器只有a1/a2的资源，新容器只有b1/b2的资源。虽然开了1分钟粘性会话，但在部署切换的窗口里，要么旧会话过期后用户请求跳到新容器（但浏览器还拿着旧index.html里的旧hash资源路径），要么新请求因为粘性会话的“过期窗口”误跳到旧容器，导致资源找不到。

下面是几个经过生产验证的解决方案，按推荐程度排序：

1. 静态资源完全迁移到CDN（最优解） #

这是从根源上解决问题的方案，把Webpack打包的所有静态资源（JS、CSS、图片等）和容器彻底解耦：

• 配置Webpack的publicPath为你的CDN域名前缀（比如https://your-cdn.com/static/），这样打包出来的index.html里，资源引用全是CDN地址，不再依赖容器内的静态文件。
• 在Codeship构建流程里，新增一步：把Webpack打包好的静态资源上传到对象存储（比如S3），再通过CDN（比如CloudFront）做分发。
• 好处：不管ECS怎么切换新旧容器，静态资源都存在CDN上，新旧hash的资源可以共存（你可以设置对象存储的生命周期规则，比如30天后自动删除旧版本资源），同时CDN还能提升资源加载速度，降低容器的带宽压力。

2. 容器内保留新旧版本静态资源（过渡方案） #

如果暂时没法上CDN，可以在构建Docker镜像时，让新镜像同时包含新旧版本的静态资源：

• 修改你的构建脚本：在打包当前版本资源前，先拉取上一个生产镜像里的静态资源目录（比如用docker cp把旧镜像的/static目录复制到构建上下文），然后再执行Webpack打包，把新资源也放到/static目录里。
• 这样新镜像里同时有a1/a2和b1/b2的资源，不管用户请求是来自旧会话还是新会话，容器都能找到对应的资源。
• 注意：这个方案会让镜像体积逐渐变大，适合短期过渡，长期还是推荐CDN方案。

3. 优化ECS部署策略与ALB粘性会话 #

调整部署流程，给用户足够的时间完成页面刷新：

• 在ECS服务配置里，把最小健康百分比设为100%，最大百分比设为200%。这样部署时会先启动所有新容器，等新容器通过健康检查后，再销毁旧容器，新旧容器会短暂共存一段时间。
• 把ALB粘性会话的超时时间从1分钟延长到5-10分钟，同时在部署完成后，不要立即销毁旧容器，留5-10分钟的“过渡窗口”再删除。这样旧会话的用户有足够时间刷新页面，获取新的index.html和资源路径。

4. 前端添加资源加载失败的兜底重试 #

作为最后一道防线，在React应用里添加全局资源加载错误处理：

• 在应用的入口文件（比如index.js）里，监听全局的资源加载错误：

  let reloadAttempts = 0;
  window.addEventListener('error', (e) => {
    const target = e.target;
    // 只处理脚本和样式资源的404错误
    if ((target.tagName === 'SCRIPT' || target.tagName === 'LINK') && reloadAttempts < 2) {
      reloadAttempts++;
      // 强制刷新页面，获取最新的index.html
      window.location.reload(true);
    }
  });
  

• 这样当用户遇到资源404时，页面会自动刷新，获取新容器的index.html，从而加载正确的新hash资源。

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