📍 WDQWDWQD987AAAAA:216.73.217.13
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b438b714de01.html
📄

本地网站开发：网站迁移应准备哪些记录？多人协作交付清单

网站迁移前最该准备的是一份可交接的记录包，而不是只打包源码和数据库。记录包要能让接手的人在不问原开发者的情况下，还原环境、判断迁移是否成功、知道哪些改动是有意为之。对本地网站开发项目来说，关键记录包括环境版本、目录与配置、数据结构、依赖来源、域名与证书、变更历史和验证结果七类。

准备阶段：先记录“迁移前是什么样”

迁移最容易返工的原因，是新旧环境不一致却没人说得清差异在哪。准备阶段要把当前状态写成可核对的文字，而不是靠记忆。

• 运行环境版本：语言运行时、数据库、Web 服务器、包管理器的具体版本号。只写“PHP 8”不够，要写到小版本。
• 目录与文件职责：源码目录、上传目录、日志目录、临时目录分别在哪，哪些必须随迁移带走，哪些应当在新环境重新生成。
• 配置项清单：数据库连接、缓存地址、邮件发送、对象存储、第三方接口密钥的键名。密钥值不要写进文档，只记录存放位置和获取方式。
• 依赖来源：锁文件是否提交、私有包从哪里拉取、有没有需要手工安装的系统级扩展。

这一步最关键的动作是：把配置项逐条列成表格，每行写清“键名、当前值类型、新环境由谁提供”。迁移失败大多不是代码问题，而是某个配置没人知道存在。

实施阶段：记录每一步做了什么

多人协作时，实施记录的作用是让第二个人能复核第一个人的操作，而不是重新摸索。

1. 记录迁移开始时间与执行人，注明本次迁移的目标环境。
2. 记录数据导出的方式：导出命令、导出范围、是否包含用户上传文件。
3. 记录数据导入的顺序。有外键关联时，顺序错了会直接报错。
4. 记录迁移过程中做过的临时改动，例如临时关闭某项校验、临时改短缓存时间。这类改动必须单独列出，迁移后逐条还原。

如果迁移中修改了表结构或配置默认值，要写清改动前后的值，并说明为什么改。判断标准很简单：另一个没参与迁移的人，只看记录能否重复出同样的结果。做不到，就说明记录不够。

验证阶段：用检查项判断迁移是否真的完成

“页面能打开”不等于迁移成功。验证记录要覆盖功能、数据和外部依赖三层。

• 功能检查：首页、列表页、详情页、表单提交、登录与权限控制各走一遍，记录实际结果。
• 数据检查：对比迁移前后的记录条数、关键表的最大 ID、上传文件数量。数量对不上就先查清原因再继续。
• 外部依赖检查：邮件能否发出、支付或短信等接口是否指向正确的环境、定时任务是否已在新环境注册。
• 链接与资源检查：页面里有没有仍指向旧地址的硬编码链接，静态资源是否 404。

验证结果要写成“检查项 + 预期 + 实际 + 结论”，而不是只写“已测试”。发现不一致时，先判断是迁移引入的问题，还是迁移前就存在的老问题，两者处理方式不同。

维护阶段：把记录变成可延续的资产

迁移完成后，记录不应停在聊天记录里。建议把以下内容合并进项目文档：当前环境版本、配置项键名表、数据备份位置与恢复步骤、已知遗留问题、下次迁移需要注意的坑。

变更历史要持续追加，每条写清时间、改动内容、执行人、影响范围。这样下次迁移时，准备阶段的工作量会明显下降。

下一步可以做的具体动作：打开当前项目，把配置项按“键名、用途、新环境提供方”列成一张表，再对照本文的验证清单逐项打勾。凡是填不出来的行，就是迁移前必须补齐的记录。