网站开发岗位：网站迁移应准备哪些记录？交付清单与验收要点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b903b00e04e4.html
📄
网站开发岗位：网站迁移应准备哪些记录？交付清单与验收要点
网站迁移要准备的记录，核心是让接手的人不看聊天记录也能独立完成上线与回滚。建议从交付结果倒推，准备四类资料：环境与账号清单、数据与文件清单、变更与回滚记录、验收与责任记录。缺少任何一类，多人协作时就容易出现重复劳动或误操作。
先明确迁移的交付结果是什么
网站迁移的交付结果不是“文件传完了”，而是新环境能稳定提供服务，旧环境可以安全退出，出现问题时有人知道怎么退回。围绕这个结果，记录要回答三个问题：迁了什么、谁负责、怎么确认成功。
- 迁了什么：代码、数据库、图片附件、配置文件、定时任务、域名解析。
- 谁负责：每项任务的执行人和确认人分开，避免自己改自己验。
- 怎么确认：每个环节有可检查的结果，而不是“应该没问题”。
环境与账号记录：最容易漏的一类
多人协作时，账号信息往往散落在个人手里。迁移前应整理一份清单，只记录条目和归属，密码通过约定的安全渠道单独传递，不写进普通文档。
- 服务器与主机的登录方式、所在区域、配置规格。
- 数据库地址、库名、账号归属，以及是否有只读账号。
- 域名注册商、DNS 解析服务商、证书签发与到期时间。
- 对象存储、CDN、邮件发送、短信等外部服务的账号归属。
- 代码仓库地址、分支策略、部署方式（手动还是自动）。
检查项：随便找一位不参与迁移的同事，让他只看清单说出“域名在哪里改解析”。说不出来，说明记录还不完整。
数据与文件记录：用清单代替口头交接
迁移最容易返工的环节是数据。建议为每一类数据单独建一行记录，注明来源、去向、处理方式和校验方式。
- 数据库：导出方式、字符集、导出时间点、导入后的行数或关键表数量对比。
- 上传文件与静态资源：目录位置、总大小、文件数量、是否包含用户上传内容。
- 配置文件：与环境相关的项（数据库连接、缓存地址、密钥引用）如何替换。
- 定时任务与队列：任务名称、执行频率、迁移后是否需要重新注册。
- 日志与备份：旧环境保留多久、新环境日志写到哪里。
校验方式可以很简单：迁移前后各统计一次文章数、用户数、图片目录大小，数字一致再进入下一步。数字不一致时先停下排查，不要继续切换域名。
变更与回滚记录：写清楚“改了什么”
迁移过程中的每一步操作都应留下痕迹，尤其是不可逆的操作。记录至少包含时间、操作人、操作内容、影响范围。
- DNS 解析修改：改了哪条记录、原值是什么、新值是什么、TTL 设成多少。
- 数据库结构变更：执行了哪些语句、是否可逆。
- 配置修改：改了哪个文件、改前改后的关键差异。
- 回滚条件：出现什么现象就回滚，例如首页持续报错、支付回调失败。
- 回滚步骤：按顺序写清恢复 DNS、恢复数据库、恢复配置的具体动作。
适用条件：只要迁移涉及线上流量切换，就应准备回滚记录。判断结果的标准是——没参与操作的人照着步骤能执行回滚，不需要临时问人。
验收与责任记录：减少扯皮的关键
验收不是一个人点几下页面。建议按功能模块列出检查项，每项标注负责人和结果，形成可追溯的记录。
- 首页、列表页、详情页能否正常打开，状态码是否为正常值。
- 登录、注册、搜索、表单提交等交互是否正常。
- 移动端显示与桌面端是否一致，图片是否正常加载。
- HTTPS 证书是否生效，是否存在混合内容提示。
- 旧地址是否能正确跳转到新地址，避免用户看到错误页。
每项检查结果写“通过 / 不通过 / 待确认”，不通过时记录现象和发现人。多人协作时，执行人和确认人分开签字或留言确认，能显著减少“我以为你验过了”这类返工。
下一步可以怎么做
拿现有迁移计划对照上面四类记录，缺哪类先补哪类。最优先补的是回滚步骤和验收清单，因为这两项直接决定出问题时能否快速恢复、交付时能否说清责任。补完后找一位不参与本次迁移的同事试读一遍，能独立复述流程，记录就算合格。
