1. 项目概述：为什么我们需要Nginx反向代理

前后端分离架构现在几乎是现代Web开发的标配了，但很多朋友在项目真正要上线部署时，往往会卡在最后一步：怎么把前端（比如Vue、React打包的静态文件）和后端（比如Spring Boot、Django、Node.js的API服务）优雅地整合在一起，让用户通过一个统一的域名就能访问？直接让前端去调用后端服务器的IP和端口？那跨域问题、端口暴露、负载均衡、静态资源缓存这些头疼事就全来了。

我见过不少团队，开发时用 webpack-dev-server 的代理功能跑得好好的，一到生产环境部署就手忙脚乱。其实，解决这个问题的核心钥匙，就是 Nginx反向代理 。它不仅仅是一个“转发请求”的工具，更是生产环境部署的“瑞士军刀”。简单来说，它的工作模式是这样的：用户访问你的网站域名（比如 www.your-app.com ），这个请求首先到达Nginx服务器。Nginx就像一个智能调度员，根据你设定的规则，把请求分发给不同的“工人”。访问首页、JS、CSS、图片？Nginx直接从它管理的静态文件目录（存放着你前端打包好的 dist 文件夹）里读取并返回，速度极快。当页面需要加载数据，发起一个到 /api/xxx 的Ajax请求时，Nginx会识别出这是API请求，然后默默地将这个请求转发到你后端的应用服务器（比如运行在 localhost:8080 的Spring Boot服务），拿到结果后再返回给浏览器。对浏览器而言，它始终只和Nginx这一个“门户”打交道，完全感知不到后端复杂的技术栈和部署细节。

这么做的好处太多了： 安全上 ，后端服务的真实端口无需暴露在公网； 性能上 ，Nginx处理静态文件的能力是顶尖的，还能轻松配置缓存、Gzip压缩； 运维上 ，你可以独立地伸缩前端或后端服务，甚至在后端服务重启时，Nginx还能提供一定的缓冲和容错。接下来，我就以一个典型的 Spring Boot + Vue 项目为例，带你从零开始，一步步拆解如何用Nginx实现生产级的前后端分离部署，并分享我趟过的那些坑和总结出的最佳实践。

2. 核心思路与架构设计

在动手写配置之前，我们必须把整体的部署思路理清楚。一个清晰的设计图，能让你在后续的配置和排错中事半功倍。

2.1 部署拓扑与流量走向

我们先设想一个最经典、也最实用的单服务器部署架构。假设我们有一台云服务器，公网IP是 123.123.123.123 ，域名 www.your-app.com 已经解析到了这个IP。

  1. 后端服务 ：我们将Spring Boot项目打包成一个可执行的JAR文件，比如 myapp-backend.jar 。在服务器上，我们使用 java -jar 命令或者更专业的进程管理工具（如 systemd, Supervisor）来运行它。通常，我们会让它在服务器的 内部端口 （例如 8080 ）上监听。这个端口 不应该 被外部直接访问。
  2. 前端静态资源 ：我们将Vue项目执行 npm run build ，生成一个 dist 目录。这个目录里包含了 index.html , js , css , fonts , img 等所有静态文件。我们需要把这个 dist 目录上传到服务器的某个路径下，比如 /opt/www/myapp-frontend 。
  3. Nginx ：作为唯一的对外门户，Nginx安装在服务器上，监听标准的HTTP(80)和HTTPS(443)端口。它的核心任务有两个：
    • 静态资源服务 ：当用户请求 https://www.your-app.com/ 或任何静态文件路径（如 /js/app.xxx.js ）时，Nginx直接从 /opt/www/myapp-frontend 目录查找并返回文件。
    • API请求代理 ：当用户请求的路径以 /api/ 开头（或者你定义的其他API前缀），Nginx会将这个请求 反向代理 到 http://localhost:8080 （即我们后端服务运行的地方），然后将后端返回的结果原样递交给用户浏览器。

这样，用户访问 https://www.your-app.com 看到的是Vue构建的页面，页面中的JavaScript发起的 fetch('/api/users') 请求，会被Nginx无缝地转发到后端的 http://localhost:8080/api/users 。整个过程中，浏览器认为所有资源都来自 www.your-app.com ，完美解决了跨域问题。

注意 ：这里有一个关键点，后端应用（Spring Boot）本身不需要再配置跨域（CORS）了。因为从后端视角看，所有请求都来自同一个“客户端”——Nginx服务器（localhost）。跨域是浏览器的安全策略，现在浏览器直接和Nginx通信，不存在跨域。这比在代码里配置 @CrossOrigin 注解要干净、安全得多。

2.2 关键配置文件：nginx.conf 与 server block

Nginx的配置核心在于 nginx.conf 文件及其包含的 server 块。对于前后端分离部署，我们通常不会直接修改主配置文件，而是在 /etc/nginx/conf.d/ 目录下创建一个独立的配置文件，例如 myapp.conf ，这样管理起来更清晰。

一个最基础的、能工作的配置骨架如下。我会先给出它，然后在下一章详细拆解每一个指令的含义和配置要点。

# /etc/nginx/conf.d/myapp.conf

server {
    # 监听80端口，并启用HTTP/2（如果配置了SSL）
    listen 80;
    # 如果你的域名，多个域名用空格隔开
    server_name www.your-app.com your-app.com;

    # 强烈建议：将所有HTTP请求重定向到HTTPS（安全）
    # 暂时注释掉，等配置好SSL后再启用
    # return 301 https://$server_name$request_uri;

    # 前端静态资源根目录
    root /opt/www/myapp-frontend;
    # 默认索引文件，确保是index.html
    index index.html;

    # 核心location配置开始
    location / {
        # 尝试按顺序查找文件：$uri, $uri/, 最后回退到index.html
        # 这是支持Vue Router的history模式的关键！
        try_files $uri $uri/ /index.html;
    }

    # 代理所有以 /api/ 开头的请求到后端服务
    location /api/ {
        # 后端服务地址
        proxy_pass http://localhost:8080;
        # 以下是一组非常重要的代理头设置
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # 可选：单独处理静态资源，设置长期缓存
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        # 同样需要try_files，但通常直接由root指令处理
    }
}

# 另一个server块，用于HTTPS（需要先申请SSL证书）
# server {
#     listen 443 ssl http2;
#     server_name www.your-app.com your-app.com;
#
#     ssl_certificate /path/to/your/fullchain.pem;
#     ssl_certificate_key /path/to/your/privkey.pem;
#     # ... 其他SSL优化配置
#
#     root /opt/www/myapp-frontend;
#     index index.html;
#
#     location / {
#         try_files $uri $uri/ /index.html;
#     }
#
#     location /api/ {
#         proxy_pass http://localhost:8080;
#         proxy_set_header Host $host;
#         proxy_set_header X-Real-IP $remote_addr;
#         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#         proxy_set_header X-Forwarded-Proto $scheme;
#     }
# }

这个配置看起来简单，但里面几乎每一行都有讲究，配置不当就会导致页面白屏、接口404、刷新404、静态资源加载慢等各种问题。别急，我们接下来就把它掰开揉碎了讲。

3. 配置深度解析与实操要点

现在，我们深入到上面配置文件的每一个关键部分，理解其原理并掌握正确的配置方法。

3.1 静态资源服务与History模式路由

这是前端单页应用（SPA）部署中最容易出问题的地方。我们重点关注 location / 块里的 try_files 指令。

location / {
    try_files $uri $uri/ /index.html;
}
  • $uri ：Nginx的变量，代表当前请求的URI（不包括查询参数）。例如，请求 /css/app.css ， $uri 就是 /css/app.css 。
  • $uri/ ：尝试把请求的URI当作一个目录去查找。例如，请求 /about ，它会先看 /opt/www/myapp-frontend/about 这个文件是否存在，如果不存在，再看 /opt/www/myapp-frontend/about/ 目录下是否有默认索引文件（如index.html）。这对一些老式网站或有真实目录结构的情况有用。
  • /index.html ：如果前面两种尝试都失败（即请求的路径既不是真实文件，也不是真实目录），Nginx就会把请求“回退”到 /index.html 这个文件。

为什么这对Vue Router的history模式至关重要？ 在hash模式（URL带 # ）下，路由变化不会触发浏览器向服务器发起新请求。但在history模式下，当你访问 https://www.your-app.com/about 时，浏览器会向服务器请求 /about 这个路径。然而，你的前端项目里并没有一个叫 about 的物理文件，所有的路由都是由 index.html 里的JavaScript管理的。如果没有 try_files 指令，Nginx在 /opt/www/myapp-frontend 目录下找不到 about 文件，就会返回 404 Not Found 。

try_files $uri $uri/ /index.html; 这行配置的作用就是：当请求 /about 时，Nginx发现没有 about 这个文件，也没有 about/ 这个目录，于是它就把请求“内部重写”为 /index.html ，然后返回 index.html 的内容。浏览器拿到 index.html 后，Vue Router会根据当前的URL（ /about ）来渲染对应的组件页面。完美！

实操心得 ： try_files 指令的顺序很重要。必须是先检查真实文件( $uri )，再检查目录( $uri/ )，最后回退到 index.html 。如果把 /index.html 放在前面，那么所有请求（包括对真实存在的 app.js 的请求）都会被重写到 index.html ，导致JS、CSS文件加载失败，页面白屏。

3.2 反向代理配置的精髓

location /api/ 块负责将API请求转发给后端。这里的配置细节直接影响到后端应用能否正确接收到请求。

location /api/ {
    proxy_pass http://localhost:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

  • proxy_pass ：这是核心指令，告诉Nginx将匹配到的请求转发到哪个上游服务器。注意结尾的 / 有讲究：

    • proxy_pass http://localhost:8080; – 请求 /api/users 会被转发为 http://localhost:8080/api/users 。
    • proxy_pass http://localhost:8080/; – 如果末尾有斜杠，请求 /api/users 会被转发为 http://localhost:8080/users （ /api/ 被“吃掉”了）。 除非你后端接口路径没有 /api 前缀，否则通常不要加末尾斜杠。

  • proxy_set_header ：这组指令至关重要，它修改了Nginx转发给后端请求的HTTP头信息。

    • Host $host ：将原始请求的 Host 头（通常是你的域名）传递给后端。有些后端框架（如Spring Security）会校验这个头，如果丢失或被改为 localhost:8080 ，可能导致认证或路由问题。
    • X-Real-IP $remote_addr ：将客户端的真实IP地址放在 X-Real-IP 头中传给后端。否则，后端日志里看到的客户端IP都会是Nginx服务器的内网IP（如127.0.0.1）。
    • X-Forwarded-For $proxy_add_x_forwarded_for ：这是一个链式IP头。如果请求已经经过其他代理，这个头会记录下所有经过的代理IP，客户端真实IP在第一个。后端可以通过这个头获取原始用户IP，对于风控、审计非常重要。
    • X-Forwarded-Proto $scheme ：告诉后端原始的请求协议是 http 还是 https 。如果你的Nginx配置了HTTPS，但后端收到的请求头里 scheme 还是 http ，那么后端生成的跳转链接或重定向URL可能就是错误的HTTP链接。

踩坑记录 ：我曾经遇到过Spring Boot应用在重定向登录时，总是跳转到 http:// 地址，导致浏览器安全警告。排查了半天，就是因为Nginx配置里漏掉了 proxy_set_header X-Forwarded-Proto $scheme; 这一行。加上之后，Spring Boot的 server.forward-headers-strategy=native （或使用 X-Forwarded-* 过滤器）就能正确识别原始协议了。

3.3 静态资源缓存优化

对于前端打包生成的JS、CSS、图片、字体文件，它们的文件名通常都带有哈希值（如 app.abc123.js ），内容一旦改变，文件名就会变。这意味着我们可以给它们设置非常长的缓存时间，极大提升用户再次访问的速度。

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
  • ~* ：表示这是一个不区分大小写的正则表达式匹配。
  • expires 1y; ：告诉浏览器这个资源可以缓存1年。这是通过响应头 Expires 实现的。
  • add_header Cache-Control "public, immutable"; ：这是更现代、优先级更高的缓存控制方式。
    • public ：指示响应可以被任何缓存（浏览器、CDN）缓存。
    • immutable ：告诉浏览器，在这个资源有效期内，其内容 永远不会改变 。这可以防止浏览器在用户刷新页面时发送不必要的条件请求（ If-Modified-Since 或 If-None-Match ），进一步提升性能。这个属性特别适合带哈希的静态资源。

为什么 index.html 不能这样缓存？ 因为 index.html 是你的应用入口，它通常 不 带哈希，且需要随时更新以加载最新版本的JS/CSS文件。所以 index.html 的缓存策略应该设置为 no-cache 或很短的缓存时间，甚至由 location / 块处理，不匹配上面的缓存规则。

4. 完整部署流程与核心环节实现

理论讲完了，我们动手从头部署一个Spring Boot + Vue项目。假设你有一台干净的Ubuntu 22.04服务器。

4.1 环境准备与Nginx安装

首先，通过SSH连接到你的服务器。

  1. 更新系统并安装Nginx ：

    sudo apt update
sudo apt upgrade -y
sudo apt install nginx -y

    安装完成后，Nginx会自动启动。你可以通过 sudo systemctl status nginx 检查状态，并通过浏览器访问服务器IP，应该能看到Nginx的欢迎页面。

  2. 准备项目目录 ：

    # 创建一个目录存放你的应用，这里以 /opt/www 为例
sudo mkdir -p /opt/www/myapp-frontend
sudo mkdir -p /opt/www/myapp-backend
# 将目录所有权改为当前用户（假设你的用户名是ubuntu），方便上传文件
sudo chown -R $USER:$USER /opt/www

4.2 后端服务部署（Spring Boot）

  1. 上传与运行JAR包 ： 将你打包好的 myapp-backend.jar 上传到服务器的 /opt/www/myapp-backend/ 目录。

    # 假设你使用scp从本地传输
# scp target/myapp-backend.jar user@123.123.123.123:/opt/www/myapp-backend/

    进入该目录，以后台方式启动Spring Boot应用，并输出日志到文件。

    cd /opt/www/myapp-backend
nohup java -jar myapp-backend.jar --server.port=8080 > app.log 2>&1 &

    nohup 和 & 让进程在后台运行，即使关闭SSH连接也不会终止。 2>&1 将标准错误重定向到标准输出，一起写入 app.log 文件。

  2. 验证后端服务 ：

    # 查看进程
ps aux | grep java
# 查看日志
tail -f app.log
# 在服务器本地测试接口（确保8080端口可访问）
curl http://localhost:8080/api/health

    如果看到预期的JSON响应，说明后端服务启动成功。

重要提示 ：生产环境强烈建议使用 systemd 或 Supervisor 来管理Spring Boot进程，而不是简单的 nohup 。它们能提供进程守护、自动重启、日志轮转等强大功能。这里为了快速演示使用了 nohup 。

4.3 前端静态资源部署

  1. 构建前端项目 ： 在你的本地开发机前端项目根目录下，运行构建命令（以Vue CLI为例）：

    npm run build

    这会在项目下生成一个 dist 目录。

  2. 上传dist目录 ： 将整个 dist 目录里的内容（注意是内容，不是dist文件夹本身）上传到服务器的 /opt/www/myapp-frontend/ 。

    # 使用scp或rsync同步
# scp -r dist/* user@123.123.123.123:/opt/www/myapp-frontend/
# 或者用更高效的rsync
# rsync -avz dist/ user@123.123.123.123:/opt/www/myapp-frontend/

    上传后，确认 index.html 文件在 /opt/www/myapp-frontend/ 目录下。

4.4 配置Nginx并启用

  1. 创建Nginx站点配置文件 ： 进入Nginx的配置目录，创建我们的应用配置文件。

    sudo vim /etc/nginx/conf.d/myapp.conf

    将我们在第2章末尾提供的完整配置模板粘贴进去。 请务必修改以下关键值 ：

    • server_name : 改为你的域名，例如 server_name www.your-site.com; 。
    • root : 确认路径是否正确， root /opt/www/myapp-frontend; 。
    • proxy_pass : 确认后端地址和端口， proxy_pass http://localhost:8080; 。

  2. 测试Nginx配置语法 ： 这是一个非常重要的步骤，可以避免因配置错误导致Nginx无法启动。

    sudo nginx -t

    如果输出 syntax is ok 和 test is successful ，说明配置语法正确。

  3. 重载Nginx配置 ： 让Nginx重新加载配置文件，使新配置生效。

    sudo systemctl reload nginx
# 或者 sudo nginx -s reload

    reload 是平滑重载，不会断开现有连接，是生产环境推荐的方式。

4.5 配置HTTPS（使用Let‘s Encrypt免费证书）

在当今的Web环境下，HTTPS是必须的。我们使用Certbot工具来自动化申请和配置Let‘s Encrypt免费证书。

  1. 安装Certbot ：

    sudo apt install certbot python3-certbot-nginx -y

  2. 获取并自动配置SSL证书 ：

    sudo certbot --nginx -d www.your-app.com -d your-app.com

    按照提示操作，输入邮箱同意协议。Certbot会自动：

    • 验证你对域名的所有权（通过HTTP挑战）。
    • 从Let‘s Encrypt获取SSL证书。
    • 自动修改你的Nginx配置文件（ myapp.conf ），添加一个监听443端口的 server 块，并配置好证书路径和SSL相关参数。
    • 自动设置HTTP到HTTPS的重定向。

  3. 验证与自动续期 ： Let‘s Encrypt证书有效期为90天，Certbot会自动配置一个定时任务（cron job或systemd timer）来续期，你基本不用操心。

    # 测试自动续期
sudo certbot renew --dry-run

至此，一个具备HTTPS、前后端分离、静态资源缓存优化的生产级部署就完成了。现在，你可以通过 https://www.your-app.com 访问你的应用了。

5. 常见问题排查与进阶技巧

即使按照步骤操作，也可能会遇到一些问题。这里我总结了一些最常见的坑和解决方法。

5.1 问题排查清单

问题现象 可能原因 排查步骤
访问域名显示Nginx默认页 1. server_name 没配置对。
2. 配置文件没放在正确目录或未加载。
3. 有默认站点（ default_server ）优先级更高。		 1. sudo nginx -T 查看所有配置，确认你的 server 块被加载且 server_name 正确。
2. 检查 /etc/nginx/sites-enabled/ 下是否有默认文件，有则删除或修改。
3. 在 listen 指令后加上 default_server 明确指定（谨慎使用）。
前端页面白屏，控制台JS/CSS 404 1. root 路径错误。
2. try_files 指令顺序错误，导致JS文件也被重写到 index.html 。
3. 文件权限问题，Nginx进程无权读取。		 1. 检查 root 指向的目录是否存在 index.html 。
2. 确认 try_files 顺序是 $uri $uri/ /index.html 。
3. 检查目录和文件权限： ls -la /opt/www/myapp-frontend/ ，确保Nginx用户（通常是 www-data 或 nginx ）有读取权限。 sudo chmod -R 755 /opt/www 和 sudo chown -R www-data:www-data /opt/www （注意这会影响文件上传）。
刷新页面（非首页）出现404 Vue Router history模式，但Nginx未配置 try_files 回退到 index.html 。 确保 location / 块内有 try_files $uri $uri/ /index.html; 。
API请求返回502 Bad Gateway 1. 后端服务没启动或端口不对。
2. proxy_pass 地址错误。
3. 后端服务启动慢，Nginx超时。		 1. 在服务器上 curl http://localhost:8080/api/health 测试后端。
2. 检查 proxy_pass 的URL和端口。
3. 查看Nginx错误日志： sudo tail -f /var/log/nginx/error.log 。
API请求返回404 1. location /api/ 的匹配规则有问题。
2. proxy_pass 末尾的 / 导致路径被改写。
3. 后端应用本身没有该接口。		 1. 确认请求路径是否以 /api/ 开头。
2. 检查 proxy_pass 指令，通常不加末尾斜杠。
3. 在Nginx配置中增加调试日志：在 location /api/ 内加 proxy_set_header X-Debug-URI $request_uri; ，在后端打印这个头，看收到的路径是什么。
后端获取不到真实用户IP Nginx未正确设置 X-Forwarded-For 和 X-Real-IP 请求头。 确保 location /api/ 块内包含了 proxy_set_header X-Real-IP $remote_addr; 和 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 。在后端代码中，应从这些头中读取IP，而非直接取连接IP。

5.2 Nginx日志：你的最佳排错伙伴

Nginx的访问日志和错误日志是定位问题的金钥匙。

  • 访问日志 ( /var/log/nginx/access.log )：记录了每一个请求的详细信息，包括IP、时间、请求方法、路径、状态码、响应大小、Referer、User-Agent等。当出现奇怪的请求或想分析流量时，就看它。
  • 错误日志 ( /var/log/nginx/error.log )：记录了Nginx运行中的错误、警告信息。出现502、504等错误时，第一时间查看这里。

查看日志的常用命令：

# 实时查看错误日志
sudo tail -f /var/log/nginx/error.log
# 查看最近100行访问日志，并高亮状态码非200的请求
sudo tail -n 100 /var/log/nginx/access.log | grep -v " 200 "
# 统计某个接口的访问情况
sudo grep "/api/user" /var/log/nginx/access.log | wc -l

5.3 进阶配置与优化建议

当你的应用流量增长后，可以考虑以下优化：

  1. 启用Gzip压缩 ：在 http 块或 server 块中配置，可以显著减小文本文件（HTML, JS, CSS, JSON）的传输体积。

    gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript application/javascript application/xml+rss application/json;

  2. 调整代理超时时间 ：如果后端API响应较慢，可能需要调整。

    location /api/ {
    proxy_pass http://localhost:8080;
    proxy_connect_timeout 60s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;
    # ... 其他proxy_set_header
}

  3. 负载均衡 ：如果后端部署了多个实例，可以使用 upstream 模块。

    upstream backend_servers {
    server 127.0.0.1:8080 weight=3; # 本地实例，权重3
    server 192.168.1.10:8080; # 另一台服务器
    server 192.168.1.11:8080 backup; # 备份服务器
}
server {
    ...
    location /api/ {
        proxy_pass http://backend_servers;
        # ... 其他配置
    }
}

  4. 静态资源托管分离 ：对于超大流量应用，可以考虑将静态资源（JS/CSS/图片）托管到CDN或对象存储（如阿里云OSS、腾讯云COS），进一步减轻服务器压力。此时，前端构建时需要配置公共路径（publicPath），Nginx中则不再需要处理这些静态文件。

整个配置和部署过程，核心在于理解请求的流向以及Nginx各个指令的作用。多动手实践，多查看日志，遇到问题按部就班地排查，你很快就能熟练掌握这套高效的前后端分离部署方案。这套组合拳打下来，你的Web应用在性能、安全和可维护性上都会有一个质的飞跃。

Logo
亚马逊云科技技术品牌专区

更多推荐

Kiro Editor 开发实战：使用 Cargo 构建、测试与性能优化指南

欢迎来到这篇终极指南，我们将深入探索如何使用Rust构建高性能的终端文本编辑器Kiro Editor。无论你是Rust新手还是经验丰富的开发者，这篇完整教程将带你了解如何利用Cargo工具链进行高效的开发、测试和性能优化，打造一款快速、轻量且功能强大的UTF-8文本编辑器。## 什么是Kiro Editor？Kiro Editor是一款使用Rust编写的极简终端文本编辑器，它最初是著名编辑

avatar 亚马逊云科技技术品牌专区

2026年量化工具选择，要跟着能力基础走

读者应理解，选择工具前要先判断自己的能力基础和当前任务。工具应该帮助自己补上当前最关键的缺口，而不是替代学习顺序本身。

avatar 亚马逊云科技技术品牌专区

2026年下半年量化入门，学习表达开发验证要分开

读者应理解，一个更清楚的路径是先学习基本概念，再表达规则，再尝试开发实现，最后进行验证检查。每一阶段都有自己的任务和边界，不应提前替代下一阶段。

avatar 亚马逊云科技技术品牌专区