一个小网站，也有持续维护的交付责任
10月21日，PHP官方发布涉及两项严重漏洞的安全公告，并提供8.4.27等修复版本。中国创客OPC社区在10月23日完成线上运行时升级，检查记录确认实际Web进程使用8.4.27。这是一项已执行的维护工作，不是模拟客户项目。
AI辅助参与资料核对、脚本准备和结果检查；维护依据仍是官方公告、服务器实际状态与可复核输出。本文仅讨论工作方法，不公开登录资料、业务配置或可用于攻击的步骤，也不提供适用于所有网站的自动升级命令。
确认版本，要确认真正处理网页请求的程序
一次常见误判是：终端显示了新版本，就认为网页也已经升级。命令行程序、Web服务配置与仍在运行的旧进程，可能指向不同位置。本站这次除检查默认命令外，也通过私有FastCGI请求核对运行版本，并检查所有相关工作进程的实际程序路径。
对外包或协作维护，可以要求对方把“检查了什么位置”写进交付记录。只有安装回执，尚不能说明切换已经生效；只截一张版本图，也不能替代实际服务状态。
备份要能对应到升级前的状态
本次切换前保留了网站数据、运行配置和原有服务定义，随后核对网站源码清单。目的在于明确变化来自哪里，以及检查失败时能够恢复哪一部分。备份包含敏感内容，仍保存在受限位置，没有上传到公开网页目录。
小团队可以把备份时间、对应版本、完成标记和恢复负责人列成固定维护项。备份文件存在与已经验证可恢复，是两个不同结论；本文只按当次实际完成的检查记录描述，不补写此次没有执行的恢复演练。
页面正常以后，还要检查业务依赖
这次升级核对了数据库连接、测试会话连续读写、正常图片上传与图像处理，并比较原有扩展和配置。公开入口另检查首页、栏目、园区、地图、后台登录与投稿页。测试使用独立会话及非公开文件，结束后清理检查材料。
这些检查对应网站真实依赖，也有明确边界：没有在生产后台发布或删除测试文章，没有拿攻击载荷压测线上。登录页正常并不等于所有管理流程都做过验收，有限检查也不能证明服务器从未被入侵。
交付还包括下一次怎样更新
由于当时系统软件源没有提供修复包，本站采用官方源码构建独立运行时，并核对下载哈希。这解决了当次升级需要，同时带来后续维护责任：仅更新系统软件包，不一定更新实际服务的运行时。
因此，交付记录还应写明活跃程序和配置位置、更新方法、旧版本的用途及恢复限制。对准备靠AI维护自己业务系统的人，真正值得复用的是这种证据与责任安排，不能把一次顺利升级理解为长期无人维护。
延伸阅读：项目交付记录怎样连接；持续服务的验收与费用。