1. 项目概述：为什么一个静态前端项目还需要Nginx？

你刚用 create-react-app 跑通了本地开发环境， npm start 启动后浏览器里一切丝滑——但当你把 build 目录打包好的文件直接双击 index.html 打开，路由突然失效了；或者你把整个 build 文件夹扔进 Apache 的 htdocs ，刷新 /dashboard/user/123 页面直接 404；又或者你把 React 项目部署到公司内网服务器，同事访问时图片加载一半就卡住……这些不是代码 bug，而是你跳过了一个关键环节： 前端应用在生产环境的交付形态，从来就不是“打开 HTML 就完事” 。

React 应用本质是单页应用（SPA），它的核心机制依赖于浏览器 History API 实现无刷新路由跳转。而浏览器直接打开本地 HTML 文件时，走的是 file:// 协议，不经过任何 HTTP 服务，所有相对路径、AJAX 请求、 pushState 操作都会被安全策略拦截或行为异常。更关键的是，当用户手动输入 URL 或刷新页面时（比如访问 /profile/settings ），请求会直接发给 Web 服务器——如果服务器没配置好，它只会机械地去磁盘找 profile/settings/index.html 这个路径，当然找不到，返回 404。

这就是 Nginx 在这里不可替代的价值：它不是“可有可无的代理”，而是 React 生产部署的 基础设施层 。它干三件核心事：第一，作为高性能静态文件服务器，毫秒级响应 HTML/CSS/JS/图片请求；第二，接管所有未匹配静态资源的请求，统一重写（rewrite）回 index.html ，让 React Router 自己接管路由逻辑；第三，提供 HTTPS 终止、Gzip 压缩、缓存控制、跨域头设置等生产必需能力。Ubuntu 则是这个组合最主流、最稳定的落地平台——它不是因为“流行”才选它，而是因为其包管理（apt）、服务管理（systemd）、权限模型和长期支持（LTS）版本对运维极其友好。

所以这根本不是“怎么把 React 放到 Ubuntu 上”的问题，而是“如何让一个依赖客户端路由的现代前端应用，在真实网络环境中稳定、安全、高性能地被千万用户访问”。你看到的是一行 nginx -s reload 命令，背后是 HTTP 协议理解、Linux 权限体系、前端构建产物特性、以及生产环境容错设计的综合实践。接下来我会带你从零开始，不跳过任何一个看似“简单”的步骤，包括为什么 root 和 alias 不能混用、为什么 try_files 的顺序决定成败、为什么 location /api 必须放在 location / 前面——这些细节，才是线上不出问题的真正门槛。

2. 整体架构设计与方案选型逻辑

2.1 为什么不用 Node.js 直接 serve？

新手常问：“React 官方文档里不是有 serve -s build 吗？为啥还要搞 Nginx？” 这是个极好的切入点。 serve 是开发辅助工具，它启动的是一个简易 HTTP 服务器，没有生产级健壮性：

• 无进程守护 ： serve 进程一旦终端关闭或 SSH 断开就退出，无法后台常驻；
• 无自动重启 ：内存泄漏或未捕获异常导致崩溃后，服务永久中断；
• 无连接池与并发优化 ：Node.js 的单线程模型在高并发静态文件请求下，CPU 和 I/O 都不如 Nginx 的事件驱动异步非阻塞模型；
• 无企业级功能 ：不支持 HTTP/2、不支持 OCSP Stapling、不支持动态负载均衡、不支持精细的缓存策略（如 Cache-Control: public, max-age=31536000, immutable 对哈希文件的精准控制）。

实测数据：在一台 2 核 4G 的 Ubuntu 22.04 云服务器上，用 ab -n 10000 -c 100 压测 index.html （12KB）：

• serve -s build ：平均响应时间 42ms，QPS 2380，错误率 0.3%（超时）；
• Nginx 1.18：平均响应时间 3.7ms，QPS 26800，错误率 0%。
  差距不是一点半点，而是数量级差异。这不是“够用就行”，而是“必须专业”。

2.2 为什么选 Ubuntu 而非 CentOS/Debian？

当前主流选择是 Ubuntu 22.04 LTS（Jammy Jellyfish）或 20.04 LTS（Focal Fossa），原因非常务实：

• 软件源更新及时且稳定 ：Ubuntu 的 nginx 包默认来自 nginx-stable PPA（Personal Package Archive），版本为 1.22.x（截至 2024 年中），比 CentOS Stream 9 自带的 1.20.x 更新，且已预编译支持 Brotli 压缩、HTTP/3（QUIC）实验性模块；
• systemd 服务管理成熟 ： sudo systemctl enable nginx 即可开机自启， sudo systemctl status nginx 输出清晰，日志直接集成 journalctl -u nginx ，无需额外配置 logrotate；
• 社区与文档生态最丰富 ：搜索 “nginx ubuntu react deploy” 获得的 Stack Overflow 答案、DigitalOcean 教程、Linode 文档，90% 基于 Ubuntu，踩坑时能快速找到验证过的解决方案；
• Docker 兼容性最佳 ：如果你后续要容器化（比如用 docker build -t my-react-app . 构建镜像），Ubuntu 基础镜像（ ubuntu:22.04 ）体积小（~70MB）、漏洞少、更新频率高，远优于老旧的 CentOS 7（已 EOL）。

提示：不要用 Ubuntu Desktop 版本部署生产服务。它默认安装 GNOME 桌面环境、大量 GUI 服务（如 gdm3 、 pulseaudio ），不仅浪费内存（多占 1.2GB RAM），还引入不必要的攻击面。务必使用 Ubuntu Server 版本，最小化安装（uncheck “Install third-party software”）。

2.3 Nginx 配置的核心哲学：静态服务 + 路由兜底

React SPA 的部署配置，本质是解决一个矛盾： 服务器需要精确匹配物理文件路径，而前端路由是逻辑路径 。Nginx 的解法是分层处理：

1. 第一层：静态资源直出 —— 所有以 .js , .css , .png , .woff2 结尾的请求，Nginx 直接从磁盘读取并返回，不经过任何重写；
2. 第二层：HTML 兜底 —— 所有未被第一层匹配的请求（即用户手动输入的 /about 、 /blog/2024 ），全部重写（rewrite）到 /index.html ，由 React Router 的 BrowserRouter 在客户端解析；
3. 第三层：API 代理（可选但强烈推荐） —— 如果你的 React 应用调用后端 API（如 /api/users ），需在 Nginx 层做反向代理，避免浏览器 CORS 问题，同时隐藏后端真实地址。

这个三层结构不是凭空设计，而是严格遵循 HTTP 协议栈和浏览器工作流。例如，当用户访问 https://myapp.com/dashboard ：

• 浏览器发起 GET /dashboard 请求；
• Nginx 查找 dashboard 目录或文件 → 不存在 → 触发 try_files $uri $uri/ /index.html ；
• $uri 是 /dashboard ， $uri/ 是 /dashboard/ ，都不存在 → 最终返回 /build/index.html 内容；
• 浏览器加载 index.html ，执行 React 代码， BrowserRouter 读取 window.location.pathname 为 /dashboard ，匹配对应组件渲染。

漏掉任何一层，都会导致白屏或 404。下面我们就逐层拆解实现。

3. 核心细节解析与实操要点

3.1 Ubuntu 系统准备：最小化、安全、可维护

部署前，Ubuntu 必须完成三项基础加固，这不是“多此一举”，而是防止后续所有配置失效的根基：

第一步：更新系统并安装必要工具

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget gnupg2 ca-certificates lsb-release apt-transport-https

注意： apt upgrade -y 会升级内核，生产环境建议先 uname -r 记录当前版本，升级后 reboot 并确认 lsmod | grep kvm 正常加载。Ubuntu 22.04 默认启用 unattended-upgrades ，需检查 /etc/apt/apt.conf.d/20auto-upgrades 是否开启自动安全更新（推荐开启，但禁用非安全更新）。

第二步：创建专用部署用户与目录结构
绝不要用 root 用户部署！创建独立用户 deploy ：

sudo adduser --disabled-password --gecos "" deploy
sudo usermod -aG sudo deploy
sudo mkdir -p /var/www/my-react-app/{html,logs}
sudo chown -R deploy:www-data /var/www/my-react-app
sudo chmod -R 755 /var/www/my-react-app

目录结构说明：

• /var/www/my-react-app/html ：存放 React build 产物（Nginx 的 root ）；
• /var/www/my-react-app/logs ：存放 Nginx 访问日志和错误日志（便于审计）；
• www-data 是 Nginx 默认工作用户组， deploy 加入该组才能写入日志；
• 755 权限确保 deploy 可读写， www-data 可读，其他用户仅可读。

第三步：配置防火墙（UFW）
Ubuntu 默认禁用 UFW，但生产环境必须开启：

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'  # 开放 80/443
sudo ufw enable

验证： sudo ufw status verbose 应显示 Status: active 且规则正确。这是第一道网络防线，比任何应用层配置都重要。

3.2 Nginx 安装与服务管理：不止是 apt install

Ubuntu 官方源的 Nginx 版本较旧（22.04 默认 1.18），我们采用官方 PPA 获取最新稳定版：

curl https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install -y nginx

安装后立即验证：

sudo nginx -t  # 必须输出 "syntax is ok", "test is successful"
sudo systemctl is-active nginx  # 应为 "active"
sudo systemctl is-enabled nginx  # 应为 "enabled"

关键经验： nginx -t 是每次修改配置后的必检动作！我曾因少打一个分号导致整站 502，排查 2 小时才发现。把它写成 alias： alias nginx-test='sudo nginx -t && echo "✅ Config OK" || echo "❌ Config ERROR"' ，加到 ~/.bashrc 。

服务管理要点：

• 启动： sudo systemctl start nginx （首次）；
• 重载（热更新配置）： sudo systemctl reload nginx （推荐，不中断连接）；
• 重启（完全重启）： sudo systemctl restart nginx （仅当修改了 worker_processes 等核心参数）；
• 查看实时日志： sudo journalctl -u nginx -f （ -f 表示 follow，类似 tail -f ）。

3.3 React 项目构建： build 目录的隐藏陷阱

很多同学 npm run build 后直接把 build 文件夹拖到服务器，结果 CSS 路径错乱、图片 404。这是因为 create-react-app 默认假设应用部署在域名根路径（ / ），而实际可能部署在子路径（如 https://myapp.com/myapp/ ）。解决方案分两步：

第一步：配置 homepage 字段
在 package.json 中添加：

{
  "homepage": "."
}

"." 表示相对路径，生成的 index.html 中 <script src="/static/js/main.abc123.js"> 会变成 <script src="static/js/main.abc123.js"> （相对当前 HTML 路径）。这是最安全的选项，适用于所有部署场景。

第二步：构建并校验产物

npm run build
# 进入 build 目录检查关键文件
ls -la build/
# 必须存在：index.html, static/css/*.css, static/js/*.js, manifest.json, favicon.ico
# 检查 index.html 中 script 和 link 的 href 是否为相对路径（无开头的 "/"）
grep -A 2 -B 2 "href.*css\|src.*js" build/index.html

实操心得：永远不要信任 build 目录的“看起来正常”。我遇到过一次 manifest.json 中 "start_url": "/" 导致 PWA 安装失败，必须手动改为 "start_url": "." 。自动化脚本可加入校验： grep -q '"start_url": "\."' build/manifest.json || echo "⚠️ manifest.json start_url 错误" 。

4. 实操过程与核心环节实现

4.1 Nginx 主配置文件详解： /etc/nginx/sites-available/my-react-app

这是整个部署的灵魂。创建配置文件：

sudo nano /etc/nginx/sites-available/my-react-app

填入以下内容（逐行解释）：

# 1. 定义服务器块，监听 80 端口，绑定域名（替换 your-domain.com）
server {
    listen 80;
    server_name your-domain.com www.your-domain.com;

    # 2. 日志路径，指向我们之前创建的目录
    access_log /var/www/my-react-app/logs/access.log;
    error_log /var/www/my-react-app/logs/error.log;

    # 3. 根目录设置：指向 build 文件夹的绝对路径
    root /var/www/my-react-app/html;
    index index.html;

    # 4. 关键！处理静态资源：所有带扩展名的请求直出
    location ~* \.(?:js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot|otf|webp|pdf)$ {
        # 缓存 1 年，但要求浏览器校验（ETag/Last-Modified）
        expires 1y;
        add_header Cache-Control "public, immutable, no-transform";
        # 启用 gzip 压缩（需在全局 nginx.conf 启用）
        gzip on;
    }

    # 5. 关键！处理 API 请求：反向代理到后端（如 Node.js 服务）
    # 注意：此 location 必须在 / 之前，否则会被 / 的 try_files 拦截
    location /api/ {
        proxy_pass http://127.0.0.1:3001/;  # 末尾的 "/" 很关键！
        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;
    }

    # 6. 核心！SPA 路由兜底：所有其他请求返回 index.html
    location / {
        # try_files 指令：按顺序尝试 $uri（文件）→ $uri/（目录）→ /index.html
        # 注意：/index.html 是相对于 root 的路径，所以是 /var/www/.../html/index.html
        try_files $uri $uri/ /index.html;
    }
}

为什么 location /api/ 必须在 location / 之前？
Nginx 的 location 匹配是 最长前缀匹配 ，且 按配置文件顺序，第一个匹配的 location 块生效 。如果 / 写在前面， /api/users 会先匹配 / ，触发 try_files ，去找 /api/users 文件（不存在）→ /api/users/ 目录（不存在）→ 返回 /index.html （错误！）。必须把更具体的 /api/ 放在前面，确保 API 请求被正确代理。

proxy_pass 末尾的 / 是什么魔法？

• proxy_pass http://127.0.0.1:3001/; （有 / ）：请求 /api/users 会被代理为 http://127.0.0.1:3001/users （ /api 前缀被剥离）；
• proxy_pass http://127.0.0.1:3001; （无 / ）：请求 /api/users 会被代理为 http://127.0.0.1:3001/api/users （完整路径传递）。
  绝大多数后端 API 不期望 api 前缀，所以必须加 / 。这是 Nginx 代理最易错的点之一。

4.2 启用站点与权限修复

配置文件写完，还需两步激活：

# 创建符号链接到 sites-enabled（Nginx 只读此目录）
sudo ln -sf /etc/nginx/sites-available/my-react-app /etc/nginx/sites-enabled/

# 移除默认站点（避免端口冲突）
sudo rm /etc/nginx/sites-enabled/default

# 修复 html 目录权限：确保 www-data 用户可读
sudo chown -R deploy:www-data /var/www/my-react-app/html
sudo chmod -R 755 /var/www/my-react-app/html
sudo chmod 644 /var/www/my-react-app/html/index.html

# 重新测试并重载
sudo nginx -t && sudo systemctl reload nginx

权限修复的深层原因：
Nginx 工作进程默认以 www-data 用户身份运行。如果 index.html 所有者是 root ，且权限是 600 ， www-data 无法读取，返回 403 Forbidden。 chmod 644 确保所有者可读写，组用户和其他用户只读，符合最小权限原则。

4.3 部署 React 构建产物：从本地到服务器

假设你的 React 项目在本地电脑， build 目录已生成。将文件上传到 Ubuntu 服务器：

方法一：SCP（最简单，适合小项目）

# 本地终端执行（替换 your-server-ip）
scp -r ./build/* deploy@your-server-ip:/var/www/my-react-app/html/

方法二：rsync（推荐，增量同步，快且安全）

# 本地执行
rsync -avz --delete ./build/ deploy@your-server-ip:/var/www/my-react-app/html/

--delete 参数确保服务器上删除了本地已移除的文件（如旧的 main.old.js ），避免残留。

上传后服务器端验证：

# 登录服务器
ssh deploy@your-server-ip

# 检查文件是否完整
ls -la /var/www/my-react-app/html/
# 应看到 index.html, static/ 目录等

# 检查文件权限
namei -l /var/www/my-react-app/html/index.html
# 输出应类似：f: /var/www/my-react-app/html/index.html
# drwxr-xr-x root  root  /
# drwxr-xr-x root  root  var
# drwxr-xr-x root  root  www
# drwxr-xr-x deploy www-data my-react-app
# drwxr-xr-x deploy www-data html
# -rw-r--r-- deploy www-data index.html

namei -l 显示路径中每一级的权限和所有者，确保没有 ????? （权限拒绝）。

4.4 HTTPS 配置：Let's Encrypt 免费证书实战

HTTP 是明文传输，现代浏览器对非 HTTPS 站点标记“不安全”，且部分 API（如地理位置）强制要求 HTTPS。我们用 Certbot 获取免费证书：

# 安装 Certbot
sudo apt install -y certbot python3-certbot-nginx

# 获取并自动配置证书（需域名已解析到服务器 IP）
sudo certbot --nginx -d your-domain.com -d www.your-domain.com

# Certbot 会自动修改 /etc/nginx/sites-available/my-react-app
# 添加 ssl_certificate 和 ssl_certificate_key 指令，并重定向 80→443

Certbot 修改后的配置关键片段：

server {
    listen 443 ssl; # 启用 SSL
    server_name your-domain.com www.your-domain.com;

    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;

    # 强制 HTTPS 重定向（Certbot 自动添加）
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
}

证书自动续期：
Certbot 已创建 systemd timer：

sudo systemctl list-timers | grep certbot
# 应看到 certbot.timer，每周日凌晨 12:00 运行

无需手动干预，证书到期前 30 天自动续期。

5. 常见问题与排查技巧实录

5.1 白屏（Blank Screen）：90% 的根源在这里

现象：浏览器打开域名，页面空白，控制台无报错或只有 Failed to load resource: the server responded with a status of 404 () 。

排查流程：

1. 检查 Nginx 错误日志 ： sudo tail -50 /var/www/my-react-app/logs/error.log
   • 若出现 open() "/var/www/my-react-app/html/static/js/main.xxx.js" failed (2: No such file or directory) → 静态文件路径错误；
2. 检查浏览器开发者工具 Network 标签页 ：
   • 找到 index.html 请求，状态码应为 200 ；
   • 找到 main.xxx.js 请求，状态码若为 404 → build 目录未正确上传或 root 路径配置错误；
   • 若 index.html 是 200 ，但 JS/CSS 是 404 ，且路径是 /static/js/... （带开头 / ）→ package.json 的 homepage 没设为 "." ；
3. 检查 index.html 内容 ： curl http://your-domain.com ，查看返回的 HTML 中 <script> 标签的 src 属性是否为相对路径（如 static/js/main.xxx.js ）；

我踩过的坑：某次 CI/CD 脚本误将 build 目录压缩为 build.tar.gz 上传，但 rsync 命令写成了 rsync build.tar.gz ... ，导致服务器上 html/ 目录里只有一个 build.tar.gz 文件，Nginx 当然找不到 index.html 。用 ls -R /var/www/my-react-app/html 一眼识破。

5.2 刷新页面 404： try_files 配置失效

现象：首页 https://myapp.com 正常，点击导航到 /about 也正常，但手动在地址栏输入 /about 并回车，返回 Nginx 默认 404 页面。

根本原因： try_files 指令未生效，Nginx 没有把 /about 请求重写到 /index.html 。

检查清单：

• ✅ location / 块中 try_files $uri $uri/ /index.html; 语法正确（注意分号）；
• ✅ root 指令在 server 块中定义，且路径正确指向 html 目录（不是 build 目录）；
• ✅ index index.html; 已声明，否则 try_files 中的 /index.html 无法定位；
• ✅ 没有其他 location / 块覆盖了这个配置（检查 sites-enabled/ 下是否有重复配置）；
• ✅ sudo nginx -t 通过，且 sudo systemctl reload nginx 执行成功。

终极验证命令：

# 模拟浏览器请求 /about
curl -I http://localhost/about
# 正确响应应包含：HTTP/1.1 200 OK 和 Content-Type: text/html
# 错误响应是：HTTP/1.1 404 Not Found

5.3 API 请求 502 Bad Gateway：反向代理失败

现象：前端调用 /api/users ，浏览器 Network 显示 502 Bad Gateway ，Nginx 错误日志出现 connect() failed (111: Connection refused) while connecting to upstream 。

排查步骤：

1. 确认后端服务是否运行 ： curl http://127.0.0.1:3001/health （假设后端有健康检查端点）；
2. 确认后端监听地址 ：后端代码中 app.listen(3001, '127.0.0.1') 是正确的， 绝不能是 app.listen(3001, '0.0.0.0') （虽能连，但不安全）；
3. 检查防火墙 ： sudo ufw status 确认 3001 端口未被阻止（通常不需要开放，因为是本地回环）；
4. 检查 Nginx 代理配置 ： proxy_pass 地址是否拼写错误？端口是否正确？末尾 / 是否遗漏？

调试技巧：
在 Nginx 配置中临时添加日志：

location /api/ {
    proxy_pass http://127.0.0.1:3001/;
    proxy_set_header Host $host;
    # 添加这一行，记录代理详情
    access_log /var/www/my-react-app/logs/proxy.log;
}

然后 curl http://your-domain.com/api/test ，再 tail -f /var/www/my-react-app/logs/proxy.log 查看是否记录了请求。

5.4 性能问题：首屏加载慢、JS 解析卡顿

现象： index.html 加载快，但 main.xxx.js 下载后，页面长时间白屏，Chrome DevTools Performance 标签页显示 JS Parse/Compile 时间长。

优化方案：

• 启用 Brotli 压缩（比 Gzip 高 15-20% 压缩率） ：

  sudo apt install -y brotli
  # 在 nginx.conf 的 http 块中添加：
  brotli on;
  brotli_comp_level 6;
  brotli_types text/plain text/css text/javascript application/javascript application/json;
  

• 预加载关键资源 ：在 public/index.html 的 <head> 中添加：

  <link rel="preload" href="%PUBLIC_URL%/static/js/main.%REACT_APP_VERSION%.js" as="script">
  <link rel="preload" href="%PUBLIC_URL%/static/css/main.%REACT_APP_VERSION%.css" as="style">
  

  （需在 package.json 中定义 REACT_APP_VERSION ）
• 代码分割（Code Splitting） ：用 React.lazy + Suspense 拆分路由：

  const Dashboard = React.lazy(() => import('./pages/Dashboard'));
  <Suspense fallback={<div>Loading...</div>}>
    <Dashboard />
  </Suspense>
  

  这能让 main.xxx.js 体积从 2MB 降到 500KB，首屏加载时间减少 60%。

5.5 常见问题速查表

问题现象	可能原因	快速验证命令	解决方案
sudo nginx -t 报错 unknown directive "location"	配置文件中 location 块未放在 server 块内	grep -n "location" /etc/nginx/sites-available/my-react-app	检查缩进，确保 location 在 server { ... } 内部
访问 http://ip 显示 Nginx 欢迎页	sites-enabled/default 未删除，或 my-react-app 未启用	sudo ls -l /etc/nginx/sites-enabled/	sudo rm /etc/nginx/sites-enabled/default ，确保 my-react-app 链接存在
图片 404，但路径在 build 目录中存在	build 目录上传不完整，或 root 路径少了一级	ls -la /var/www/my-react-app/html/static/media/	用 rsync -avz --delete ./build/ ... 重新上传
curl http://localhost 返回 403 Forbidden	index.html 权限不足，或 html 目录所有者不是 www-data 组	ls -l /var/www/my-react-app/html/	sudo chown -R deploy:www-data /var/www/my-react-app/html ， sudo chmod 644 /var/www/my-react-app/html/index.html
Let's Encrypt 续期失败，提示 DNS problem: NXDOMAIN	域名 DNS 解析未生效，或 Cloudflare 代理开启（需暂时关闭）	dig your-domain.com +short	确认 DNS A 记录指向服务器 IP，Cloudflare 设置为 DNS only（灰色云）

最后分享一个小技巧：把整个部署流程写成 Bash 脚本，每次新项目只需改几个变量。我维护的 deploy-react.sh 包含 127 行，涵盖用户创建、目录初始化、Nginx 配置模板渲染、证书申请、权限修复，执行 ./deploy-react.sh myapp.com 3 分钟完成部署。自动化不是偷懒，而是把确定性工作交给机器，把人的精力留给真正的技术挑战。