桂林网站开发，网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /93303e82cf42.html
📄
桂林网站开发，网站迁移应准备哪些记录
网站迁移前最该准备的记录，是一份能完整还原旧站运行状态的清单：域名与DNS、服务器与数据库、程序与插件版本、页面与URL结构、内容与媒体文件、账号权限、统计与外部服务、备份与回滚方案。缺少任何一项，迁移后就可能出现页面打不开、样式错乱、数据丢失或无法回退的问题。下面用一份假设的迁移记录表，说明该记什么、怎么用，以及两种常见处理方案的适用条件。
假设例子：一个桂林本地企业站的迁移记录表
假设某桂林企业要把运行了三年的展示型网站，从旧虚拟主机迁到新服务器。迁移前整理出下面这份记录表（表中内容为假设示例，不是真实项目数据）：
- 域名：主域名、解析服务商、当前A记录与CNAME记录、TTL值
- 服务器：操作系统版本、Web服务器类型与版本、PHP或运行环境版本
- 数据库：类型与版本、库名、字符集、导出文件大小与校验值
- 程序：CMS名称与版本、主题名称与版本、插件清单及各自版本
- 页面：栏目结构、页面总数、每个页面的URL、页面标题与描述
- 内容：文章数、图片数、附件目录、上传目录路径
- 账号：后台管理员、数据库账号、FTP或SSH账号（只记用途，密码另行安全保存）
- 外部服务：统计代码、地图接口、表单接收邮箱、证书到期时间
- 备份：旧站完整备份位置、数据库备份位置、最近一次可恢复备份的时间
这份表的作用不是存档，而是让迁移前后能逐项对照。记录越细，出问题时越容易定位是哪一层出了偏差。
两种处理方案的比较与适用条件
迁移时常见两种做法，适用条件不同：
- 整站打包迁移：把程序文件、数据库、上传目录一起搬到新环境，再改配置。适合程序版本较新、插件依赖清晰、页面URL不需要大改的站点。优点是速度快、内容完整；风险是旧环境里的隐藏依赖（比如某个扩展、某个绝对路径）在新环境不存在，迁移后才会暴露。
- 重建加内容导入：在新环境装好同版本程序，再导入数据库和上传目录，逐项恢复主题与插件。适合旧站程序版本过旧、插件来源不明、或想顺便清理无用插件的情况。优点是新环境干净、可控；缺点是工作量大，栏目和URL容易在重建时被改动。
判断依据可以看三点：旧程序是否还能获得安全更新；插件是否都有明确来源和版本；页面URL是否需要保持原样。如果三点都偏向“保持原样”，整站打包更省事；如果旧环境已经混乱，重建更稳妥。无论选哪种，迁移记录表都要先完成，否则两种方案都会在中途失去对照基准。
迁移前后必须核对的检查项
迁移不是文件复制完就结束，下面这些检查项要逐条走一遍：
- 首页、栏目页、内容页能否正常打开，状态码是否为200
- 页面样式、图片、字体是否正常加载，有无404资源
- 表单提交、搜索、分页等动态功能是否可用
- 数据库连接是否正常，后台能否登录并发布测试内容
- 旧URL是否全部可访问，改过结构的URL是否做了对应处理
- 统计代码、证书、外部接口是否仍然生效
- 备份是否能在新环境恢复，回滚路径是否明确
常见错误有三类：只备份了文件没备份数据库；迁移后直接改DNS，没在新环境用临时地址验证；忘记记录插件版本，新环境装了不兼容的新版本。前两类会导致数据或访问中断，第三类往往在迁移后几天才显现。
记录该保存成什么形式
建议用一份纯文本或表格文件保存，字段固定，迁移前后各填一次。密码、密钥不要写进这份文件，单独用密码管理工具保存，文件里只写“数据库密码：见密码库条目X”。这样即使记录文件被看到，也不会直接泄露凭据。记录完成后，先在新环境用临时访问地址完整验证一遍，确认无误再切换域名解析，这是把风险压到最低的顺序。
下一步可以做的，是拿现有站点对照上面的清单，把缺失的字段补上，尤其是数据库版本、插件清单和最近一次可恢复备份的时间。这三项补齐后，再决定用整站打包还是重建导入。
