从零到一：阿里云服务器 + Nginx + GitHub Actions 自动化双发与回滚实战

单点托管静态技术站点面临两难困境：纯 GitHub Pages 虽免运维且零成本，但国内直连 RTT 普遍在 180ms ~ 350ms 波动，且无法配置自主反向代理、自定义安全策略与长连接中间件；若完全转为单点云服务器自建，又面临主机宕机、机房割接时的单点故障（SPOF）风险。为了在可控成本下兼顾国内极速直连（RTT < 35ms）与异地容灾高可用，工程上最具性价比的解法是基于同一 Git 源码版本，向 GitHub Pages 与自建阿里云 ECS 执行同源自动化双发。

本文复盘一套生产级个人站点部署架构的演进全过程：从一台纯净 Ubuntu 云服务器选型加固、Nginx 进程配置，到借助 WSL2 进行本地编译复现，最终通过 GitHub Actions 打造自动化双发流水线，并基于 Linux VFS 原子系统调用实现了零停机原子切换与自动健康探测回滚机制。

1. 总体架构与四层环境职责

在实施自动化流水线前，必须首先厘清开发、构建、调度与生产这四套异构环境的职责边界。许多部署过程中的权限冲突与网络困惑，本质上都是因为混淆了执行环境：

[本地开发终端] Windows (PowerShell / VS Code)
   │ 编写 Markdown 源码、前端脚本与样式文件
   ▼
[本地编译验证] WSL2 Ubuntu (Ruby + Bundler + Node.js)
   │ 负责本地依赖管理、Jekyll 静态编译、页面元数据与死链检查
   ▼
[远端持续集成] GitHub Actions Runner (云端临时 Ubuntu 容器)
   │ 监听 main 分支推送，一次编译产物，同时向两个目标发布
   ├───────────────────────────────┬───────────────────────────────┐
   ▼                               ▼                               ▼
[目标 A：托管平台]            [网络通道：SSH/SCP]          [目标 B：自建云服务器]
GitHub Pages                 传输发布脚本与归档包            阿里云轻量应用服务器 (Ubuntu)
                                                             │
                                                             ├─ 专用 deploy 用户解压至 releases/
                                                             ├─ 校验 index.html 完整性
                                                             ├─ mv -Tf 原子替换 current 软链接
                                                             └─ Nginx 提供公网 HTTP/HTTPS 服务

1.1 环境职责划分

1.2 异构环境回环地址（127.0.0.1）语义辨析

在跨宿主机、跨虚拟化层的部署中，127.0.0.1 极易引发心智混淆。各层网络隔离边界如下：

2. 基础设施与云服务器初始化

2.1 云服务器选型与系统基线

对于托管个人静态站点及后续演进轻量级 API 服务的场景，选型基线如下：

• 硬件配额：选择 2 vCPU / 2 GiB 内存 / 40 GiB 系统盘 的轻量应用服务器。静态 Nginx 的 Master + Worker 进程常驻内存不足 25 MB，CPU 占用率低于 0.1%，剩余超 1.8 GiB 内存完全可作为 Linux 页面缓存（Page Cache）以极速响应静态文件读取，或供后续部署容器化服务；
• 操作系统：选择官方纯净的 Ubuntu 24.04 LTS x86_64 镜像，避免预装过多云厂商控制台重型组件；
• 地域选择：优先选择物理距离离核心访客最近的可用区（如深圳、广州或杭州），降低 TCP 三次握手延迟；
• 公网带宽：云厂商标注的峰值带宽（如 200 Mbps）通常受共享流量包约束，静态资源需做好 Gzip/Brotli 压缩与 HTTP 缓存头配置以降低带宽消耗。

2.2 系统加固与包管理器维护

执行位置：云服务器终端（管理员用户 admin 或 ubuntu，具有 sudo 权限）

登录云服务器后，首先更新系统包索引并应用最新安全补丁：

# 1. 刷新软件源索引
sudo apt update

# 2. 升级已安装软件包
sudo apt upgrade -y

[!IMPORTANT] 升级 OpenSSH 时的配置保留提示 当系统升级到 OpenSSH 相关包时，终端可能会弹出 /etc/ssh/sshd_config 配置冲突提示。务必选择 keep the local version currently installed（保留本地当前版本），防止云厂商预设的密钥登录配置被覆盖导致 SSH 离线失联。

升级完成后若涉及核心内核或基础 C 库变更，执行重启以刷新运行态：

sudo reboot

2.3 安装并启动 Nginx

执行位置：云服务器终端（管理员用户）

# 安装 Nginx
sudo apt install -y nginx

# 设置开机自启并立即启动
sudo systemctl enable --now nginx

# 验证本地回环连通性
curl -I http://127.0.0.1

在云控制台的安全组/防火墙规则中，确保已放行 TCP 80（HTTP） 与 TCP 443（HTTPS） 入站端口。在外部浏览器访问服务器公网 IP，若看到 Welcome to nginx! 页面，说明外部网络链路正常打通。

3. 本地构建与手动部署验证

在把一切交给 CI 自动化之前，必须先在本地完整演练一次“编译-打包-传输-发布”的手动闭环，建立基准对照。

3.1 WSL2 环境中的静态网站构建

Windows 上的源码目录（例如 E:\mydata\work\code\blog）在 WSL2 中挂载于 /mnt/e/mydata/work/code/blog。

执行位置：本地 WSL2 Ubuntu 终端（普通用户）

# 1. 检查 Ruby 与 Bundler 依赖
bundle check || bundle install

# 2. 严格模式构建静态网页（出现 front matter 语法异常立即报错中断）
bundle exec jekyll build --strict_front_matter

# 3. 运行本地预检脚本（校验元数据、死链、Sitemap 等）
node scripts/check-site.mjs

构建生成的静态网页存放在 _site/ 目录下。

3.2 规范归档打包

打包静态资源时，需要特别注意压缩路径的层级结构，必须直接打包目录内部文件，而非外层包裹目录：

执行位置：本地 WSL2 Ubuntu 终端（普通用户）

# -C _site . 表示切入 _site 目录打包其内部所有文件（含隐藏文件）
tar -czf /tmp/personal-site.tar.gz -C _site .

[!WARNING] 目录嵌套陷阱 如果打包命令错误写成了 tar -czf site.tar.gz _site，解压到服务器后将多出一层 _site 目录（变为 /var/www/personal-site/current/_site/index.html），导致 Nginx 根路径直接返回 404 或 403 错误。

3.3 手动部署与权限基线

将压缩包上传至服务器用户家目录后，在服务器端解压并校正权限：

执行位置：云服务器终端（管理员用户）

# 1. 备份原有站点（如存在）
sudo tar -czf /home/admin/nginx-html-backup.tar.gz -C /var/www/html .

# 2. 解压新版本至 Nginx 目录，--no-same-owner 避免还原打包机的 UID/GID
sudo tar -xzf /home/admin/personal-site.tar.gz -C /var/www/html --no-same-owner

# 3. 设置生产级权限掩码：目录 755，文件 644
sudo chmod -R u=rwX,go=rX /var/www/html

[!TIP] 为什么拒绝 chmod -R 777？ u=rwX,go=rX 中大写的 X 具有特殊语义：它只给目录（以及原本就具备可执行属性的文件）赋予 +x（进入目录的遍历权限），而绝不会把普通的 HTML、CSS、JS 等静态文件变成可执行文件。这既保障了 Nginx worker 进程有权限遍历目录并读取静态资源，又严格恪守了最小权限安全防线。

4. 生产级自动化发布：GitHub Actions 与安全加固

手动上传存在操作繁琐、易遗漏校验、缺乏审计记录等痛点。我们需要将整个过程交由 GitHub Actions 驱动。

4.1 最小权限原则：创建专用 deploy 用户

自动化部署属于非交互式脚本操作，坚决不能直接使用 root 或拥有无密码 sudo 权限的日常管理账号进行 SSH 登录。

执行位置：云服务器终端（管理员用户）

# 创建禁用密码登录的 deploy 用户
sudo adduser --disabled-password --gecos "" deploy

# 创建专属部署根目录并移交属主
sudo mkdir -p /var/www/personal-site
sudo chown -R deploy:deploy /var/www/personal-site

该用户无 sudo 权限，其工作空间完全隔离在 /var/www/personal-site 之内，即使 CI 密钥发生意外泄露，攻击者的横向移动面也被限制在静态站点目录之内，无法触碰系统关键配置。

4.2 部署密钥生成与严格互信配置

认证算法权衡：为什么选用 Ed25519？

步骤一：本地生成专属 Ed25519 密钥对

执行位置：本地 WSL2 Ubuntu 终端（普通用户）

ssh-keygen -t ed25519 -C "github-actions-deploy" -f ~/.ssh/github-actions-deploy -N ""

步骤二：向云服务器安装公钥并限制能力

执行位置：云服务器终端（管理员用户）

# 创建并限制 .ssh 目录权限
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

# 追加公钥内容，并在行首加上 restrict 限制标记
sudo tee -a /home/deploy/.ssh/authorized_keys > /dev/null <<'EOF'
restrict ssh-ed25519 AAAA...你的公钥内容... github-actions-deploy
EOF

# 固化权限（OpenSSH 强制要求，权限过宽将直接拒绝认证）
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

[!NOTE] restrict 标记的安全隔离原理 authorized_keys 中的 restrict 关键字在不破坏 SCP 文件传输与远程管道命令执行的前提下，强制禁用了该密钥的 PTY 交互式终端分配、端口转发（Port Forwarding）、X11 转发 和 Agent 转发 能力，彻底剥夺了该密钥被黑客当作跳板渗透内网的可能。

步骤三：双向身份确认（Known Hosts）

SSH 登录不仅需要服务器验证客户端身份，客户端也必须验证服务器的主机指纹，以防范中间人劫持（MITM）：

# 1. 在云服务器上获取自身主机公钥指纹：
# 执行位置：云服务器终端
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# 输出示例：SHA256:NeUY3NUsk2sfCTCbxGXOSFgu5GPAysIxHkPcyLkoZSE

# 2. 在本地 WSL2 中测试连接并核对指纹无误后写入 known_hosts：
# 执行位置：本地 WSL2 Ubuntu 终端
ssh -i ~/.ssh/github-actions-deploy deploy@<SERVER_IP> 'whoami'

4.3 配置 GitHub 仓库 Secrets

在 GitHub 仓库的 Settings → Secrets and variables → Actions 中，配置如下四个 Repository Secrets：

5. 零停机原子切换与自动化回滚机制

传统部署往往采用直接覆盖旧文件的方式，这种做法在生产环境中存在三项致命缺陷：

5.1 三类静态站点发布策略权衡

5.2 版本目录拓扑设计

/var/www/personal-site/
├── current -> releases/abc1234-890123-1/    <--- 稳定入口（符号链接）
└── releases/                               <--- 历史版本隔离目录
    ├── initial/                            <--- 手工备份基线
    ├── abc1234-890123-1/                   <--- 正在运行的版本 (Git Commit + Run ID)
    └── def5678-890456-1/                   <--- 上一个稳定版本（待命回滚）

Nginx 的静态站点根目录始终配置为固定的 /var/www/personal-site/current，它本身是一个软链接。发布新版本时，在后台创建新版本目录，解压并验证无误后，通过 Linux 系统调用瞬间将 current 重定向到新版本。

5.3 Nginx 根目录适配与平滑加载

修改 /etc/nginx/sites-available/default（修改前务必先执行备份）：

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    # 关键：将 root 指向符号链接 current
    root /var/www/personal-site/current;
    index index.html index.htm;

    server_name _;

    location / {
        try_files $uri $uri/ =404;
    }
}

执行位置：云服务器终端（管理员用户）

测试配置语法并向 Nginx 发送平滑重载信号：

sudo nginx -t && sudo systemctl reload nginx

本次重载后，今后版本更新只需切换软链接，无需再触动 Nginx 进程。

5.4 生产级部署与双向校验脚本设计

在仓库中新增部署核心脚本 scripts/deploy-static-site.sh。GitHub Actions 在远端通过 SSH 管道将脚本注入目标服务器执行：

脚本路径：scripts/deploy-static-site.sh（由 CI 调度以 deploy 用户身份在云服务器执行）

#!/usr/bin/env bash
set -euo pipefail

# 1. 约束版本标识格式（Commit SHA - Run ID - Run Attempt）
RELEASE_ID="${1:?Missing release_id}"
SITE_ROOT="/var/www/personal-site"
RELEASES_DIR="${SITE_ROOT}/releases"
CURRENT_LINK="${SITE_ROOT}/current"
NEW_RELEASE="${RELEASES_DIR}/${RELEASE_ID}"
ARCHIVE_PATH="${HOME}/site-${RELEASE_ID}.tar.gz"

umask 022

# 2. 检查前置软链接是否有效，记录回滚目标
if [ ! -L "${CURRENT_LINK}" ]; then
    echo "Error: ${CURRENT_LINK} is not a valid symlink!" >&2
    exit 1
fi
PREVIOUS_TARGET="$(readlink "${CURRENT_LINK}")"

# 3. 错误捕获：任何步骤异常立即触发自动回滚
rollback() {
    local exit_code=$?
    if [ ${exit_code} -ne 0 ]; then
        echo "Deployment failed! Initiating rollback to ${PREVIOUS_TARGET}..." >&2
        ln -sfn "${PREVIOUS_TARGET}" "${CURRENT_LINK}"
        echo "Previous version successfully restored." >&2
    fi
    rm -f "${ARCHIVE_PATH}"
    exit ${exit_code}
}
trap rollback EXIT INT TERM

# 4. 创建隔离的新版本目录并解压
mkdir -p "${NEW_RELEASE}"
tar -xzf "${ARCHIVE_PATH}" -C "${NEW_RELEASE}" --no-same-owner

# 5. 校验新目录首页有效性并固化权限
test -s "${NEW_RELEASE}/index.html"
chmod -R u=rwX,go=rX "${NEW_RELEASE}"

# 6. 【核心动作】原子切换软链接 (通过 ln + mv -Tf 实现不可分割的替换)
TEMP_LINK="${SITE_ROOT}/.link-${RELEASE_ID}"
ln -s "releases/${RELEASE_ID}" "${TEMP_LINK}"
mv -Tf "${TEMP_LINK}" "${CURRENT_LINK}"

# 7. 【双向深度校验】从本机 HTTP 端口拉取页面，字节级对比新版本首页
PROBE_FILE="$(mktemp)"
curl -fsS --retry 3 --retry-connrefused "http://127.0.0.1/" -o "${PROBE_FILE}"

if ! cmp --silent "${PROBE_FILE}" "${NEW_RELEASE}/index.html"; then
    echo "Verification error: HTTP response does not match newly deployed index.html!" >&2
    rm -f "${PROBE_FILE}"
    exit 1
fi
rm -f "${PROBE_FILE}"

# 8. 成功完成，解除 trap 保护
trap - EXIT INT TERM
rm -f "${ARCHIVE_PATH}"
echo "Release ${RELEASE_ID} deployed and verified successfully."

底层原理：为什么必须用 mv -Tf 而不能直接 ln -sfn？

如果直接执行 ln -sfn "releases/${RELEASE_ID}" current，在 Linux 实现中该命令并非原子操作：它本质上是先执行 unlink("current") 删除现有软链接，再执行 symlink(...) 建立新软链接。在 unlink 与 symlink 之间存在微秒级的时间窗口，此时 current 处于不存在状态。如果高并发 HTTP 请求恰好在此瞬间到达 Nginx，Worker 进程会直接报出 404 Not Found。

而通过建立临时软链接后执行 mv -Tf "${TEMP_LINK}" "${CURRENT_LINK}"，其底层调用的是 POSIX 标准的 renameat(2) / rename(2) 系统调用。在 Linux VFS 文件系统层，rename() 在目录 inode 锁保护下瞬间完成目录项指针（dentry）替换，具备硬件级原子性：并发请求要么解析到旧版本目录，要么解析到新版本目录，绝不可能观察到中间态或空链接。

[!TIP] 为什么要用 cmp 进行字节比对，而不是仅检查 HTTP 200？ 在生产环境中，仅检查 HTTP 200 极具欺骗性。如果 Nginx Worker 进程因未平滑重载导致配置未更新、或者根路径误指到了旧目录，HTTP 响应同样会返回 200 OK，但这属于典型的假死/假成功（Phantom Success）。通过将本地 curl 抓取的实时网页与本次打包的 index.html 逐字节比对（cmp --silent），能够确保 Nginx 当前输出的内容绝对来自于本次最新构建。

5.5 换行符陷阱：.gitattributes 的必要性

Windows 开发者在本地提交 Shell 脚本时，默认可能会被 Git 的 core.autocrlf 转换为 CRLF（Windows 回车换行）。当远端 Linux 执行带有 \r 的 Bash 脚本时，会直接抛出语法崩溃：

syntax error near unexpected token $'{\r'

为了从工程规范上根除此隐患，必须在仓库根目录添加 .gitattributes：

配置文件：.gitattributes（仓库根目录）

scripts/deploy-static-site.sh text eol=lf

这确保无论在任何操作系统上检出，该脚本的行尾都严格保持 LF。

6. GitHub Actions 双发流水线编排

在 .github/workflows/site-quality.yml 中编排构建与发布任务。关键原则是：同一份构建产物进行一次编译和校验，产物打包后分别投递给 GitHub Pages 与自建服务器，避免重复编译产生的哈希不一致。

工作流文件：.github/workflows/site-quality.yml

name: Site Quality and Dual Deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: pages-$
  cancel-in-progress: false

jobs:
  build-and-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3'
          bundler-cache: true

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Build Jekyll site
        run: bundle exec jekyll build --strict_front_matter

      - name: Verify site integrity
        run: node scripts/check-site.mjs

      # 规范打包网页归档，供后续两个部署任务复用
      - name: Package website artifact
        run: tar -czf /tmp/site-dist.tar.gz -C _site .

      - name: Upload artifact for Aliyun
        uses: actions/upload-artifact@v4
        with:
          name: aliyun-site-artifact
          path: /tmp/site-dist.tar.gz
          retention-days: 1

      - name: Upload artifact for GitHub Pages
        uses: actions/upload-pages-artifact@v3
        with:
          path: _site

  # 任务 1：发布至 GitHub Pages
  deploy-github-pages:
    needs: build-and-check
    runs-on: ubuntu-latest
    permissions:
      pages: write
      id-token: write
    environment:
      name: github-pages
      url: $
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

  # 任务 2：发布至阿里云生产服务器
  deploy-aliyun:
    needs: build-and-check
    runs-on: ubuntu-latest
    timeout-minutes: 10
    env:
      ALIYUN_HOST: $
      ALIYUN_USER: $
      ALIYUN_SSH_KEY: $
      ALIYUN_KNOWN_HOSTS: $
    steps:
      - name: Checkout repository for scripts
        uses: actions/checkout@v4

      - name: Download compiled artifact
        uses: actions/download-artifact@v4
        with:
          name: aliyun-site-artifact
          path: /tmp

      - name: Configure secure SSH environment
        run: |
          mkdir -p ~/.ssh
          chmod 700 ~/.ssh
          echo "$ALIYUN_SSH_KEY" > ~/.ssh/id_deploy
          chmod 600 ~/.ssh/id_deploy
          echo "$ALIYUN_KNOWN_HOSTS" > ~/.ssh/known_hosts
          chmod 644 ~/.ssh/known_hosts

      - name: Deliver artifact and trigger atomic switch
        run: |
          RELEASE_ID="${GITHUB_SHA}-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}"
          
          # 1. 安全传输静态归档
          scp -i ~/.ssh/id_deploy -o IdentitiesOnly=yes \
            /tmp/site-dist.tar.gz \
            "${ALIYUN_USER}@${ALIYUN_HOST}:~/site-${RELEASE_ID}.tar.gz"

          # 2. 管道式远端执行部署与比对验证
          ssh -i ~/.ssh/id_deploy -o IdentitiesOnly=yes \
            "${ALIYUN_USER}@${ALIYUN_HOST}" \
            "bash -s -- '${RELEASE_ID}'" < scripts/deploy-static-site.sh

      - name: Cleanup credentials
        if: always()
        run: rm -rf ~/.ssh/id_deploy

7. 真实生产故障复盘：从“假成功”到真闭环

在流水线首次实战运行时，遇到了一个极具代表性的生产故障。

7.1 故障现象与反直觉假象

GitHub Actions 执行时，build-and-check 与 deploy-github-pages 全部呈现绿色通过；但在 deploy-aliyun 任务中，流水线在最后一步突然报错红灯：

Verification error: HTTP response does not match newly deployed index.html!
Deployment failed! Initiating rollback to releases/initial...
Previous version successfully restored.
Process completed with exit code 1

与此形成鲜明反差的是：外部浏览器直接访问自建服务器依然一切正常，页面并未宕机，返回 HTTP 200 OK。

7.2 根因排查证据链

登录服务器进行现场勘验，依照严密的证据链展开排查：

1. 软链接状态确认：执行 readlink /var/www/personal-site/current，软链接准确指回了上一个版本 releases/initial，证明部署脚本中的 trap rollback 自动自愈机制完全生效；
2. 新产物有效性确认：检查 releases/ 下新版本的目录，index.html 确实存在且内容完整无损；
3. Nginx 静态配置确认：查看 /etc/nginx/sites-available/default 中的 root 配置，确实已经被修改为了 /var/www/personal-site/current；
4. 【核心证据发现】进程时间戳与文件时间戳冲突： 查看 Nginx 运行进程的实际启动时间戳：

   执行位置：云服务器终端

   ps -eo pid,lstart,cmd | grep nginx
   

   证据显示：当前正在运行的 Nginx Worker 进程启动时间为 22:58，而修改 /etc/nginx/sites-available/default 配置文件的修改时间（mtime）是 23:34！

根因曝光：此前在服务器上修改 Nginx 配置文件后，仅执行了 nginx -t 语法检查，遗漏了 systemctl reload nginx 命令！

因此，Nginx Worker 进程依然在内存中沿用旧的 /var/www/html 根路径配置提供服务。当部署脚本通过 curl http://127.0.0.1/ 探测首页并与本次构建产物比对时，Nginx 返回的始终是旧站内容，直接触发了 cmp 字节校验失败。

这一真实故障闭环验证了：简单的 HTTP 200 探测只能发现服务存活，无法发现内容陈旧；深入到字节级哈希或内容比对，才能彻底杜绝假发布。

7.3 修复验证与真闭环

执行位置：云服务器终端（管理员用户）

在服务器上以管理员身份执行真正的平滑重载：

sudo systemctl reload nginx

随后在 GitHub Actions 中点击 Re-run failed jobs，流水线耗时 24 秒全部变绿。

执行位置：本地 WSL2 Ubuntu 终端

比对本地打包产物与线上实时输出的 SHA-256 摘要：

# 获取线上公网首页哈希与本地产物哈希对比
curl -s http://<SERVER_IP>/ | sha256sum
sha256sum _site/index.html

两份 SHA-256 哈希值完全吻合，站点正式达成同源自动化双发闭环。

8. 日常极简运维与秒级应急 Runbook

8.1 开发者日常心智负担归零（三步发布法）

执行位置：本地开发终端（Windows / WSL2）

随着双发自动化流水线落地，日常运维复杂度大幅收敛为标准 Git 动作：

# 1. 暂存变更
git add .

# 2. 提交说明
git commit -m "docs: 增加新技术专栏文章"

# 3. 推送触发自动化双发
git push origin main

推送后只需观察 GitHub 仓库的 Actions 图标变绿，GitHub Pages 与阿里云两处节点即在 1 分钟内完成全自动同步。

8.2 常用线上维护命令速查

执行位置：云服务器终端

# 1. 查看当前线上生效的版本标识
readlink -f /var/www/personal-site/current

# 2. 查看 Nginx 运行状态与 Worker 进程信息
systemctl status nginx --no-pager
ps -eo pid,lstart,cmd | grep nginx

# 3. 磁盘配额维护：仅保留最近 5 个版本，清理陈旧归档与目录
cd /var/www/personal-site/releases
ls -dt */ | tail -n +6 | xargs rm -rf

8.3 紧急手动秒级原子回滚 Runbook

如果在极端异常情况下（如新提交的文章存在逻辑漏洞但通过了构建校验），需要手工将云服务器紧急回滚到历史版本：

执行位置：云服务器终端（deploy 账号或具有对应权限的运维人员）

# 步骤 1：查看历史可用版本列表
ls -lt /var/www/personal-site/releases

# 步骤 2：确认目标稳定版本无误后，执行原子替换（无需重启 Nginx）
sudo -u deploy ln -sfn releases/<指定历史版本号> /var/www/personal-site/current

# 步骤 3：验证当前生效版本
readlink /var/www/personal-site/current

# 步骤 4：回环探测验证
curl -fsS http://127.0.0.1/ | head -n 5

执行软链接重置后，无需重启或重载 Nginx，公网访问即刻秒级切换回历史版本。

9. 生产环境交付与质量验收 Checklist

本方案在上线前需逐项对照如下质量门禁清单完成核验：