WordPress PHP 升级 QA 检查清单：预演、回滚与 SEO 验证

PHP 版本变化可能影响类型处理、弃用函数、错误报告、Extension、Memory Behavior，以及 WordPress Plugin 与外部系统的通信。即使 Admin Dashboard 可以打开，Checkout、Form、Search、Image Processing、Scheduled Publishing 或 Webhook 仍可能静默失败。

修改生产前先建立 Release Ticket，记录当前与目标 PHP 版本、Hosting Environment、关键业务 Journey、维护窗口、技术负责人、QA 负责人、回滚决策人，以及批准上线必须提供的证据。

• 确认 Hosting、当前 WordPress Core 与所有关键 Plugin Vendor 都支持目标 PHP 版本。
• 列出 Web、Worker、Cron、CLI 与 Staging Runtime，它们可能使用不同 PHP 设置。
• 定义上线前必须通过的用户 Journey 与 SEO Template。
• 升级窗口内冻结无关的 Theme、Plugin、Content Model、DNS 与 Cache 变更。

从线上 Stack 的真实证据出发，而不是只看 Plugin List。导出 Active 与 Must-use Plugin、Theme 与 Child Theme 版本、PHP Extension、WordPress Constant、Object Cache、CDN Rule、Scheduled Event、Payment Method、Form Destination、Search Integration 与 Deployment Hook。

自动兼容性工具只用于发现线索，Custom Code 仍需人工检查。Static Scanner 可能遗漏 Reflection、Dynamic Hook、Serialized Data、Vendor Library，以及只在特定 Role、Locale、Payment Method 或 Scheduled Task 中执行的代码。

• 搜索 Custom Theme、Plugin 与 Snippet 中的 Deprecated API、Dynamic Property、Loose Comparison 与参数行为变化。
• 确认目标 Runtime 具备 mbstring、intl、curl、imagick、zip 与数据库 Driver 等必要 Extension。
• 把依赖标记为 Compatible、需更新、需替换、Custom Patch 或 Retire。
• 为无人维护的 Plugin 与没有责任人的代码建立 Risk Register。

过期的 Staging 会制造虚假信心。测试前尽量刷新数据、脱敏敏感信息、保留有代表性的订单与内容结构，并匹配生产的 PHP Extension、Database Version、Cache Layer、Filesystem Permission 与 Environment Variable。

预演前和生产升级前都要创建一致的 Database 与 Filesystem Backup。只有真正执行 Restore、验证 URL 与 Media、清除 Cache，并测量恢复耗时后，备份才算回滚方案。

• 阻止 Staging 被索引，并禁止发送真实 Email、Payment、CRM、Analytics 或 Webhook 流量。
• 确认备份包含 Upload、Custom Code、Configuration、Database Table、Redirect 与 Deployment Metadata。
• 把备份恢复到隔离环境，测试 Login、Media、Permalink 与一条关键 Transaction。
• 记录备份时间、存储位置、Encryption、Retention、Restore Owner 与预计恢复时间。

按照已记录顺序在 Staging 更新 WordPress Core、Theme 与 Plugin。高风险 Stack 应一次只改变一层兼容性条件，让 Log 与 Regression Result 能准确定位引入问题的变更。

前置条件完成后再把 Staging 切换到目标 PHP。清除 Opcode、Page、Object、CDN 与 Browser Cache，重启相关 Worker，并确认 Web Request、Cron Runner 与 Command Line 都报告预期 Runtime。

• 保存每次依赖更新前后的 Version Number 与 Checksum。
• 覆盖 Custom Plugin 或 Parent Theme 修改前，必须先与 Source Control 对比。
• Database Migration 只运行一次，检查输出，并确保重复部署不会再次执行破坏性操作。
• 不要让 Debug Output 出现在页面，同时把 Warning 与 Fatal Error 写入受保护的 Log Destination。

分别以 Anonymous Visitor、Customer 或 Member、Editor、Administrator 与 Integration User 测试。覆盖 Homepage、关键 Landing Page、Search、Form、Authentication、电商或获客路径，以及由 Custom Field 或 Custom Post Type 驱动的 Template。

再测试不依赖页面访问的工作：Media Upload 与 Resize、Scheduled Publishing、Import 与 Export、Backup、Queue Worker、WP-Cron、Server Cron、REST Endpoint、Webhook、Sitemap Generation 与 CLI Maintenance Task。

• 提交每个关键 Form，并验证 Delivery、CRM Record、Autoresponse Rule、Spam Control 与 Consent Field。
• 以 Editor 身份创建、编辑、Preview、Schedule、Publish、Update 与 Unpublish 代表性内容。
• 存在电商时，测试 Payment、Tax、Shipping、Coupon、Refund、Account Email 与 Stock Update。
• 每轮测试前后对比 PHP 与 Application Log 中的 Warning、Deprecation、Timeout 与 Fatal Error。

Runtime 升级可能通过 Plugin Failure、Shortcode Error、缺少 Extension、Cache Fragmentation 或不同的 Image Processing 改变 Rendered HTML。Crawl Staging，并把 Status Code、Title、Heading、Canonical、Robots Directive、Hreflang、Structured Data、Internal Link、Redirect、Pagination 与 XML Sitemap 和已批准 Baseline 对比。

同时测量 Warm Cache 与 Cold Cache。比较 Server Response Time、Cache Hit Rate、Slow Database Query、Memory、Error Rate、LCP、CLS 与 INP。PHP Benchmark 更快，并不代表 Production Cache 与 Critical Rendering 没有回退。

• Diff Homepage、Service Page、Blog Post、Archive、Product Page 与 Localized Template 的 Server-rendered HTML。
• 确认 404、Redirect、Canonical、Noindex、Sitemap 与 robots.txt 在 Cache Clear 和 Deploy 后仍然正确。
• 验证 Schema Markup，并确保 PHP Warning 不会泄漏到 HTML、JSON-LD、Feed 或 API Response。
• 把 Crawl 与 Performance 证据绑定到确切的 Staging Build 和 PHP Version。

生产窗口前写下客观的 Go 或 No-go Gate，例如零 Fatal Error、关键 Journey 全部通过、Crawl 无异常差异、Response Time 变化在可接受范围、Cron 成功执行，并能在约定恢复目标内完成 Restore。

回滚可能包括切回 Runtime、撤销依赖更新、恢复 Database 与 File，或三者同时进行。在 Staging 预演并计时，找出不向后兼容的变化。Database Migration 可能让简单切回 PHP 版本失效。

• 指定有权停止发布的人，以及触发回滚的 Threshold。
• 在 Runbook 中保存准确的 Hosting Panel、CLI、Deploy、Cache Purge、Restore 与 Health Check 步骤。
• 确认旧 PHP Runtime 在整个回滚窗口内仍然可用。
• 提前准备 Maintenance、Degraded Service、Rollback 与 Resolution 的客户支持和 Stakeholder 消息。