Angular 18 SSR应用部署AWS的正确方式及问题排查

首先明确：你当前的部署方式不正确。Angular SSR应用构建后会生成browser和server两个核心目录——browser是客户端静态资源，server是服务端渲染的逻辑代码。只部署browser目录等于放弃了SSR能力，退化成纯客户端渲染的应用，这也是线上出现本地没有的Bug的核心原因：本地开发时SSR的服务端逻辑在本地运行，数据获取、页面渲染流程和线上纯客户端模式完全不同，环境差异导致了Bug（比如服务端能直接访问内部API、读取特定环境变量，而客户端只能走公网请求，或者缺少服务端渲染时的预渲染数据）。

正确且更优的AWS部署方案 #

1. AWS Amplify（最省心的一键部署）

Amplify原生支持Angular SSR，无需手动拆分部署资源：

• 初始化Amplify项目：在项目根目录执行amplify init，按提示配置环境
• 启用托管：执行amplify add hosting，选择SSR模式
• 部署：amplify publish，Amplify会自动处理Angular SSR的构建产物，将服务端逻辑部署到Lambda，静态资源托管到S3+CloudFront，全程自动化，不用手动复制文件。

2. S3 + CloudFront + Lambda@Edge（兼顾CDN与SSR的经典方案）

如果需要更精细的控制，可以用这套组合：

• 将dist/projectname/browser目录的静态资源上传到S3桶，开启静态网站托管（仅作为静态资源源）
• 把dist/projectname/server目录的代码打包成Node.js Lambda函数，配置Lambda处理SSR请求（比如渲染页面、预取数据）
• 配置CloudFront，将动态请求（如非静态文件的路由）转发到Lambda@Edge，静态请求直接从S3获取，利用CloudFront的全球CDN加速。

3. EC2/ECS/EKS（自定义环境方案）

如果需要高度自定义的运行环境或者高并发场景：

• 将Angular SSR的服务端代码（server目录）打包成Docker镜像，部署到ECS容器集群或者EKS Kubernetes集群，配置负载均衡和域名解析
• 静态资源可以选择和服务端一起部署，或者放到S3通过CDN加速，适合需要自定义服务器配置、集成其他后端服务的场景。

线上Bug的排查建议 #

先补全服务端逻辑的部署，之后对比本地SSR模式和线上环境的差异：

• 检查环境变量：本地服务端和线上服务端的环境变量是否一致（比如API地址、密钥）
• 验证数据获取流程：服务端渲染时的数据预取逻辑是否能在线上正常执行
• 查看CloudWatch日志：如果用Lambda或EC2，检查服务端的错误日志，定位具体的报错点

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