网站迁移步骤详解，5步里3步最容易漏

网站迁移步骤详解这类内容网上一抓一大把，可大部分只讲怎么把文件拖过去、怎么把数据库导出来，真正的坑全藏在“顺手就做了”和“以为不用做”之间。5个步骤里，有3步是最容易漏的，而且漏了当场不一定报错，等过几天出毛病，你都想不起来是迁移那天埋下的。所以别急着开干，先把这个顺序在脑子里过一遍。

网站迁移步骤详解：5步的顺序别弄反

大致这么走：盘家底、数据落脚、切流量、逐项验证、旧环境保留观察。听着平平无奇，但顺序一乱就得返工。见过有人先把解析切了，再回头去打包文件，结果新站上是个空架子，搜索引擎当天就来抓了一轮，抓到的全是404。这种损失不是修一修就能补回来的，只能等，等到下一次抓取周期。

第一步最容易被跳过：没人愿意盘家底

盘家底这事枯燥，所以最常被省略。程序版本、PHP扩展、数据库版本和字符集、伪静态规则、定时任务、SSL证书、还有那些接在站上的第三方服务：支付回调地址、短信接口的IP白名单、对象存储的跨域设置。这些东西在老站上跑得好好的，你平时根本注意不到，一搬家全露出来。

尤其定时任务，很多人压根忘了自己配过。老服务器上还有个脚本每天凌晨跑一遍，把采集来的内容写进数据库。新站上线之后两个脚本同时跑，数据重复、库存对不上，查半天才想起来是这儿。

数据分两路走，别一锅端

文件和数据最好分开处理。文件用压缩包传，注意保留目录结构和权限；数据库用导出工具，字符集要跟原来一致，现在多数是 utf8mb4。导入报错十有八九不是数据坏了，而是老库里带了视图或存储过程，带着定义者信息，新库没有那个账号，直接卡住。要么单独处理，要么导入时跳过。

还有个隐形的：Linux区分大小写，Windows不区分。老站跑在Windows上，模板里写图片路径大小写混着来也能显示，搬到Linux上就是一片裂图。这种问题上线前用工具跑一遍链接检查，比人工点快得多。

切流量那半小时，最考验耐心

解析改之前，把TTL调小，等原来的缓存过期再动。这一步很多人嫌麻烦省了，改完一看没生效，以为操作失误，反复改来改去，最后自己都搞不清哪条记录是对的。真要省事，就提前一天把TTL降下来，第二天再切，改动一次到位。

如果是带CDN的站，别忘了回源地址也得跟着换，不然源站已经搬走了，CDN还在朝老IP要内容，缓存里那点旧东西能撑好一阵，看着像是迁移失败，其实是链路没理顺。

第三处最容易漏：旧主机没真正停掉

新站跑起来了，老服务器还开着，这是最典型的情况。老站上的队列、定时任务、缓存目录全都活着，还在往同一个数据库里写东西。有的人更省事，直接把老机器一关，结果发现邮件发不出去、附件下载不了，原来附件目录还挂在那台机器上。

正确做法是先停服务、断开写入，观察一段时间再关机，最好留一份快照或者整站备份。真要回滚，有备份和没备份是两种心情。这里涉及具体停哪些服务，各家架构不一样，拿不准就按服务商或官方页面的说明来，别凭印象操作。

验证别只看首页能不能打开

首页能开，很多人就认为迁移完成了。实际上首页往往是最不容易出问题的页面，因为它被缓存得最狠、被检查得最多。真正要挨个点的是：后台登录、表单提交、搜索、分页、伪静态地址、图片和附件下载、Robots和站点地图、还有那些老地址的跳转规则。

日志是另一个信息源。打开错误日志看一眼，PHP的warning、nginx的404、数据库的慢查询，迁移之后那几小时的信息量比平时一天都大。有次就是靠日志发现某个目录的属主不对，程序能读不能写，前台看着一切正常，用户一上传就失败。

权限和属主这种小事，能耗掉半宿

文件传上去之后，属主和权限基本都得重新设。Web进程跑在哪个用户下，上传目录、缓存目录、日志目录得给写权限，其余目录别给太宽。这一步有人图快，直接给个很宽松的权限，图省事的代价是安全上留了门，后面再回头收紧就麻烦了，得一个个目录试，试错一圈天都亮了。

缓存也要手动清。程序自己的缓存目录、opcache、Redis里那堆key，不清的话页面还在读老数据，你改十遍代码都看不到变化，很容易误判成迁移失败。

回滚预案，写了才知道值钱

预案不用写得多正式，几行字就够：什么情况下回滚、回滚要改哪几个地方、域名解析的旧记录留多久、旧服务器什么时候才能释放。写的时候觉得多余，真出事的时候这几行字能顶大用，至少不用一边冒汗一边翻控制台找老IP。

最后留个提醒：迁移完成后的一周内，别同时做改版、别加新功能、别调模板。出了问题你分不清是搬家搬坏的还是新改动引起的，排查成本翻倍。等平稳跑过一段时间，该丢的日志都看过了，再动别的。