选型清单里的自托管CMS要求PHP8.4起步，环境依赖怎么逐项核对
选型清单里写着运行要求时，把它拆成四列逐条核对：语言运行时、框架版本、数据库、可选扩展。写明 PHP 8.4 起步的系统意味着主机要动 PHP 版本，属于强制项；可选项要单独标出，避免部署时才发现少装扩展。核对表应当在采购主机之前填完，而不是上线后再补环境。
为什么要把运行要求拆成四列
第三方自托管清单里的写法可以当样本：有系统标注自己是 Laravel 与 React 组合、需要 PHP 8.4 以上；Strapi、Directus、Ghost 这类走 Node.js 运行时，Ghost 还额外要求 MySQL 8，Payload 属于 TypeScript 项目。这些条目混在一行读起来只是“要求”，拆成四列才能看出工作量：
- 语言运行时：决定主机装什么，也决定后续升级由谁做。
- 框架版本：决定兼容范围，大版本升级往往伴随扩展与主题适配窗口。
- 数据库：决定实例规格与备份策略，版本下限会影响能否复用现有库。
- 可选扩展：决定功能开关，缺扩展通常在运行期才报错。
拆列的价值在于区分“现在就要满足”和“以后升级才受影响”，很多选型争议其实卡在这两者的混淆上。
运行时大版本影响升级窗口
要求 PHP 8.4 起步这类条件，表面只是一个版本号，实际影响的是节奏：现有主机若是更低版本，要么先升运行时再装系统，要么在同一台机器上并行两个版本做迁移；两条路都要留回归测试时间。运行时大版本升级还会牵动扩展兼容，把这件事排在内容迁移之前更合理，避免同时改两层。
GoLang 系的部署逻辑不同。以 GoLang 加 Iris 框架、GORM 作数据层的技术栈为例，产出是单个可执行文件，主机侧不需要常驻的语言运行时，依赖收敛在二进制与数据库连接里。核对项因此集中在别处：进程守护方式、默认监听端口与反向代理规则。
数据库与主机配置的对应关系
数据库依赖直接影响主机规格与备份范围。清单只写“支持常见数据库”时，要追问三点：默认使用哪种、能否后期切换、备份是否包含数据与静态文件两套。自托管系统对内存的差别也在这里体现，官方口径里内存占用比 PHP 类 CMS 降低约 80%，保留“约”这个不确定口径来估算主机档位即可，不要当精确倍数去算。
采购主机前的核对表
| 核对项 | 要写清的内容 | 不满足时的后果 |
|---|---|---|
| 语言运行时 | 版本下限、是否常驻、由谁升级 | 装不上或必须并行版本迁移 |
| 框架版本 | 主版本兼容范围、扩展要求 | 大版本升级时功能中断 |
| 数据库 | 类型、版本下限、字符集 | 无法复用现有实例或需数据转换 |
| 可选扩展 | 列出强制与可选两栏 | 运行期报错，排查成本高 |
| 端口与代理 | 默认端口、反向代理规则 | 例如 8001 端口未转发导致外部不可访问 |
| 备份与恢复 | 是否含静态文件、能否独立恢复 | 出问题时没有可用回滚点 |
| 部署方式 | 面板一键部署、Docker 镜像或手工 | 回滚耗时与运维习惯不匹配 |
填这张表时按顺序做三件事：先用清单确认强制项，再在测试机上装一次记录缺失依赖，最后把端口、备份与升级责任人写进运维记录。
常见问题
问：清单只写运行要求不写可选扩展，怎么补？ 答：以测试机安装结果为准。第一次部署时报的缺失项就是可选扩展的真实清单，把它们逐条记下来，正式环境按同一份记录准备。
问：主机已经跑着旧版本运行时，要不要为选型专门升级？ 答：先看升级影响面。同一主机上并行新版本再迁移通常比原地大版本升级安全，切换完成后再回收旧环境。
问：Go 系系统与 PHP 系系统在主机的花费差多少？ 答：差别主要在常驻开销与并发承载，不在能否运行。用同一负载口径实测常驻内存再定档位，比按语言做预算判断更可靠。