AWS S3中SPA子页面404问题求助

绝对遇到过！这是单页应用（SPA）部署到静态存储服务（比如S3）时的经典坑，我帮你理清楚原因和靠谱的解决办法：

问题根源 #

Angular是单页应用，所有路由逻辑都是在浏览器端处理的——本地的Webpack Dev Server会自动帮你做路由重写，不管访问哪个子路径，都会返回根目录的index.html，然后由Angular的前端路由去解析。但S3只是个静态文件存储服务，它只会严格按照请求路径找对应的文件：当你直接访问/subpage时，S3会去根目录找名为subpage的文件/文件夹，找不到就直接返回404了。

解决办法 #

方案1：搭配CloudFront（推荐，适合在意SEO的场景） #

如果你的S3站点用了CloudFront做CDN，只需要配置错误页面重定向即可：

• 登录CloudFront控制台，找到你的分发，进入「错误页面」设置
• 添加一个自定义错误响应：
  • HTTP错误代码选择404
  • 自定义响应页面路径填/index.html
  • HTTP响应代码选择200
• 保存后，记得触发CloudFront缓存失效，不然新配置不会立刻生效

这样用户直接访问子页面时，CloudFront会返回index.html并带上200状态码，Angular的前端路由就能正确解析路径了。

方案2：仅用S3静态托管（简单但有状态码瑕疵） #

如果不想用CloudFront，可以修改S3静态网站托管的错误文档设置：

• 进入S3桶的「静态网站托管」配置
• 把「错误文档」也设置为index.html

这种方式下，S3会返回404状态码但内容是index.html，大部分情况下Angular路由能正常工作，但如果你的应用依赖正确的HTTP状态码（比如SEO、某些前端逻辑），这个方案就不太合适。

方案3：改用Hash路由（零服务器配置，但URL带#） #

如果不想折腾服务器/CDN配置，可以在Angular项目里启用Hash路由：

• 打开app-routing.module.ts（或AppModule里的路由配置）
• 在RouterModule.forRoot()的配置里加上{useHash: true}，示例：

RouterModule.forRoot(routes, { useHash: true })

这样路由会变成/#/subpage的形式，所有请求都会指向根目录的index.html，S3能正确返回，浏览器会解析#后面的部分作为前端路由。缺点是URL带#，对SEO不太友好。

额外提醒 #

• 不管用哪种方案，部署前记得运行ng build --prod生成生产环境的打包文件，再上传到S3
• 如果用了CloudFront，确保分发的源是S3的静态网站托管域名，而不是S3桶的直接访问链接

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