一次页面请求失败，先沿链路判断问题在哪一层

顾客打开美国服务器运行WooCommerce商城的商品页时，请求会先经过域名解析和 HTTPS 连接，再由 Web 服务交给 PHP、WordPress 和 WooCommerce，随后读取数据库及商品图片。部署脚本即使显示执行完成，这条链路仍可能因配置文件缺失、发布目录指错、文件权限不匹配、数据库变更或计划任务未执行而出错。

排查和发布应按同一条链路推进：先检查域名、证书和 HTTP 响应，再检查 Web 服务与服务器资源，接着核对当前代码版本、配置、数据库连接和业务任务。自动化部署则要把代码版本、服务器配置、定时任务和审计记录分别管理；发布失败时先判断是否只需切回代码，不能把恢复数据库当作默认回滚动作。

先划分发布内容，明确哪些能切换、哪些不能覆盖

自动化的关键不是把所有操作写进一个脚本，而是让代码、配置、上传文件和业务数据各自有清晰的生命周期。发布前应确认当前站点路径、运行用户、服务名称、数据库备份方式和可用的旧版本；条件不明确时先核实，不要直接执行覆盖或删除操作。

代码回滚和数据恢复不是一回事。如果发布只更新了代码且没有执行数据库迁移，可优先切回旧代码并复测。如果插件或 WooCommerce 已更改数据库结构或数据，必须先判断旧代码能否兼容当前数据库；若不能，再根据备份时间点、迁移记录和订单写入情况制定恢复方案。

让服务器配置和发布步骤可以重复执行

配置管理应覆盖 Web 服务配置、PHP 环境、站点目录、文件权限和计划任务，并记录配置版本及修改结果。重复应用相同配置时，不应反复追加相同内容、覆盖业务数据或重置密钥。不同发行版和安装方式的服务名称、站点路径及运行用户可能不同，先检查实际环境：

cat /etc/os-release
systemctl list-units --type=service | grep -E 'nginx|apache|php'
php -v
wp --info

这些命令用于常见 Linux 环境中的信息核对。若没有输出或提示命令不存在，应先确认软件是否安装、命令是否位于预期路径，不要猜测服务名称。Web 运行用户也要以实际配置为准，www-data 并非所有系统都适用。

密钥可通过受控的加密变量或服务器端密钥文件注入，并限制读取权限。修改服务配置前，先备份被修改的文件，确认回滚副本可用；配置文件检查通过后再重载服务。以 Nginx 为例：

sudo nginx -t
sudo systemctl reload nginx

只有 nginx -t 检查成功，才执行重载。若检查失败，保留当前运行配置，恢复备份文件后重新检查；不要用重启服务掩盖语法错误。PHP-FPM 的服务名应先通过服务列表核实，不能直接照搬其他主机上的名称。

用独立发布目录降低更新中断风险

原地覆盖商城文件时，脚本中断可能留下新旧文件混杂的状态。更便于回滚的方式是：每次准备一个独立发布目录，检查完成后再切换 current 符号链接。以下以 /var/www/store 为示例，执行前应按实际环境调整路径、Web 用户和域名。

/var/www/store/
├── current -> releases/某次发布
├── releases/
│   ├── 版本A/
│   └── 版本B/
└── shared/
    ├── wp-config.php
    └── uploads/

wp-config.php 和 uploads 应放在独立的持久化目录，再由各发布目录链接到对应位置。新版本准备完成后，核对配置链接、共享上传目录和文件权限。发布脚本不得清空共享上传目录，也不得用构建产物覆盖真实订单数据。

切换链接前，先记录当前目标并确认 current 是符号链接，而不是包含业务文件的真实目录。下面的命令适用于支持 GNU mv -T 的 Linux 环境，并假定新旧链接位于同一文件系统：

cd /var/www/store
readlink current
ln -s releases/新版本目录 current.next
mv -Tf current.next current

如果 current 不是预期的符号链接，停止操作并查明目录内容；不要直接删除目录后重建链接，以免误删业务文件或造成站点中断。切换后，用实际 Web 运行用户执行站点检查，例如：

sudo -u www-data wp --path=/var/www/store/current core is-installed
sudo -u www-data wp --path=/var/www/store/current plugin list

这里的 www-data 和路径仅为示例。若命令提示权限不足、找不到配置或无法连接数据库，应依次核实运行用户、符号链接、配置文件权限和数据库连接，不要通过放宽整个站点目录权限来绕过错误。

发布脚本设置检查点和审计记录

一个可复查的发布过程，应记录发布版本、开始时间、执行账号、代码来源、配置变更、每步结果和最终健康检查状态。记录应能回答“何时、由谁、从哪个版本发布、改了哪些配置、失败在哪一步”，同时不得包含数据库密码、支付凭据或完整的敏感请求内容。

发布脚本可按以下顺序设置检查点：

1. 核对前置条件。检查工作目录、磁盘空间、当前链接和站点响应；条件不满足时终止，不进入写入步骤。
2. 准备新版本。在独立目录取得指定版本代码，确认配置链接和共享上传目录存在。
3. 执行发布前检查。运行语法或依赖检查；不要在发布过程中无条件更新所有插件和主题。
4. 记录旧版本并切换。保存切换前的 current 目标，再将新版本设为当前版本。
5. 验证应用和服务。检查首页、商品页及管理端关键请求，并查看 Web 服务和 PHP 日志。
6. 按结果分支处理。检查失败且未发生不兼容的数据迁移时，切回已记录的旧版本，再运行同一组检查；保留失败版本和日志供后续定位。

HTTP 返回成功码只能证明该请求收到了响应，不能单独证明购物车、库存、支付回调或邮件流程正常。健康检查应覆盖不涉及敏感数据的页面请求，并结合业务级验证；验证方式应选择不会误触发真实订单、扣款或通知的安全操作。

数据库变更应设置单独门槛。执行 WooCommerce 或插件数据库升级前，确认备份可读取并记录变更内容；不要把数据库升级设为每次代码发布的无条件动作。如果迁移可能改变订单、库存等数据，应明确业务写入如何处理，并准备与变更相匹配的恢复方案。恢复前核对目标数据库、备份时间点和备份之后产生的数据影响，未经业务确认不要覆盖生产数据库。

将 WordPress 计划任务纳入配置管理

WordPress 默认可能由访问请求触发计划任务。若商城访问量不稳定，任务执行时间可能偏离预期。改用系统计划任务前，先确认当前站点是否已通过其他方式调度，避免两套机制重复运行。

一种做法是在站点配置中禁用访问触发的计划任务，再通过系统计划任务调用 WP-CLI。配置项应放在适合当前站点的配置位置，不能重复定义：

define('DISABLE_WP_CRON', true);

下面是写入 /etc/cron.d 文件时的示例。路径、运行用户和 WP-CLI 位置必须按实际环境核实：

*/5 * * * * www-data /usr/local/bin/wp --path=/var/www/store/current cron event run --due-now >> /var/log/store-wp-cron.log 2>&1

不要在未确认 WP-CLI 路径、PHP 环境和运行用户前直接安装任务。检查任务是否存在、是否以预期身份运行，并查看日志中的数据库连接、权限和 PHP 错误。若插件注册了任务，还要核对对应任务是否积压；系统任务正常启动，不等于每项业务任务都成功完成。

计划任务的配置、修改时间、操作者和验证结果应纳入审计记录。日志目录应可由运行用户写入，但不能通过网站公开访问。日志保留周期按业务审计要求确定，并检查是否意外记录了密钥或其他敏感信息。

按优先级从访问入口排查到应用处理

发布后遇到白屏、超时或商品数据异常时，先从低风险、外部可观察的环节开始。每一步都先解释结果，再决定是否改配置或回滚。

如果系统提供 curl，可用它确认域名当前返回的 HTTP 状态；这不等同于商城业务验证：

curl -sS -o /dev/null -w '%{http_code}\n' https://商城域名/

Ping 或单个页面请求都不能独立证明商城正常：网络连通性检查不覆盖 PHP、数据库和订单任务；首页返回正常也不一定触发插件的关键逻辑。若只有部分商品页失败，优先对照相关模板、插件和 PHP 日志；若全站同时异常，先查入口、Web 服务、资源和数据库连接；若页面正常但订单处理延迟，再查计划任务和插件队列。

回滚时先判断代码与数据是否兼容

新版本出现 PHP 错误，且确认本次发布没有数据库变更时，可将 current 切回已记录的旧发布目录，再检查首页、商品页、购物车和管理端。保留旧版本目录，直到新版本稳定且备份策略允许清理；不要在发布成功后立即删除唯一的回滚版本。

如果发布包含数据库迁移，先确认旧代码能否兼容迁移后的数据库。能兼容时，可先回切代码并验证；不能兼容时，依据迁移记录和备份制定恢复方案。恢复数据库可能改变备份时间点之后产生的订单和库存数据，因此要先确认是否暂停相关写入，或制定订单核对流程。恢复后应检查商品、库存、订单状态、支付记录及计划任务队列，不能只以首页打开作为成功标准。

复测按请求链路进行：先确认域名与 HTTPS，再看 Web 服务和服务器资源，随后验证 WordPress 页面及数据库访问，最后核对订单相关任务和关键业务流程。若某一层仍失败，结合该层日志、配置版本和发布记录继续定位；一次只处理已确认的问题，避免同时改动代码、配置和数据库而失去判断依据。