装内容系统前先核对数据库和脚本语言版本，兼容下限写着停止维护意味着什么
安装内容系统前要求的数据库和脚本语言版本要分两件事核对：官方推荐档，和「也能跑」的兼容下限。WordPress 的要求页把两条都写了出来，推荐主机支持 PHP 8.3 及以上，数据库按 MariaDB 10.11 或 MySQL 8.0 及以上；同时说明它也能在 PHP 7.4 与 MySQL 5.5.5 以上的旧环境运行，但这些版本已过官方停止维护节点，可能让站点暴露在安全风险里。两句话的差别不在能不能装起来，而在于装起来之后由谁来兜住后续的修复。
推荐版本与可用下限是两件事
可用下限回答的是「程序用到的语法和接口在旧环境里是否还存在」，它是功能兼容问题；推荐档回答的是「这套环境还在不在维护通道里」，它是责任问题。装的时候两者都满足，运行一年之后差别才显出来：旧环境不再获得安全更新，程序侧修掉的问题在环境侧仍然是敞开的。
选型时容易把这条读反：把「也支持」当成「建议用」，或者把「建议」当成硬性门槛而忽略了升级路径。正确的读法是先确认自己的环境是否还在维护期内，再判断程序版本要不要跟着环境受限。
标注停止维护意味着什么
风险不是抽象的。停止维护意味着该版本的已知缺陷不再有人出补丁，而内容系统对外暴露的入口又恰好在这些版本上：数据库协议层、脚本运行时的解析行为、以及它们各自的扩展。程序修了一处，环境仍然留着另一处。
另一层影响是被动升级。等到必须换版本时，往往要和程序升级同批做完，两件事互相牵制，回滚也分不清是谁引起的。核对阶段把环境升级单独排一次期，比合并处理更省时间。
环境核对的顺序
| 核对项 | 看什么 | 命中下限时的处理 |
|---|---|---|
| 脚本语言运行时 | 是否仍在官方维护期 | 先升运行时，再装程序 |
| 数据库引擎与版本 | 引擎是否与程序的接入方式匹配 | 按程序支持的引擎口径确认 |
| Web 服务器与重写模块 | 伪静态与跳转是否可下发 | 补齐模块后再启用相关功能 |
| 传输加密支持 | 证书链与协议版本 | 与域名迁移分开做 |
顺序上有两个要点：一次只动一层，改完先跑回归；以及把数据库和运行时放在同一次评估里，因为程序的连接方式、字符集与排序规则会同时受两边影响。当前接入的是 MySQL，遇到带引擎限定的公告时，先确认自己的引擎是否在范围内，不在范围内不代表可以不排期。
少一层运行时的运维差别
以脚本语言为运行时的系统，环境版本是部署的一部分：换服务器要重装运行时，运行时升级要重测所有依赖扩展。Go 语言写成的程序把这一层收进了单个可执行文件，内存占用比同类的脚本型系统降低约 80%，环境核对项因此少一项，剩下的主要是数据库与反向代理。
这不等于没有版本问题。程序自身的版本仍然要跟进，只是升级对象从「运行时加程序」变成「只有程序」。用 Docker 镜像或宝塔面板这类方式部署时，把镜像版本和数据库版本一起记进变更记录，回滚时才有对照。默认端口和转发关系也要在同一份记录里写清，避免换环境后再猜一次。
常见问题
只有旧环境可用怎么办？ 先确认程序能否在旧档跑起来，再把环境升级单独排期；不要在启用新功能的同一批里换运行时。
推荐档提高了会不会影响现有站点？ 会影响的是依赖扩展，先在测试站把扩展与模板跑一遍再切生产。
兼容下限写着很多年前，能不能一直用？ 能装不等于安全，过了维护节点之后缺陷没人补，风险由站点自己承担。
数据库要不要跟着换引擎？ 除非程序的接入方式明确支持多引擎，否则把它当作一次独立迁移处理，包含备份与回滚路径。