网站整体迁移，先动数据库再动文件

搬站这件事，顺序颠倒了，后面就是无穷无尽的补锅。网站整体迁移无非两拨东西：一坨文件，加一个数据库。绝大多数人上手第一件事是把文件打包拖走，因为文件看得见、进度条在走、心里有底。可真正决定这次搬完能不能用的，偏偏是你摸不着的那个数据库。所以我的做法一向是先动数据库，再动文件。

你可能会问，反一下能怎样。反一下最典型的结果是：新站能打开，页面也在，但用户登录不了、评论是空的、订单对不上号。文件那边没毛病，问题全在后面导入的那份数据，比文件旧了几个小时，或者比文件新了几个小时，两边谁也不认谁。

网站整体迁移最容易翻车的不是慢，是「对不上」

慢谁都遇到过，熬一熬就过去了，客户催两句也就催了。对不上才是真麻烦，因为它不报错。程序照跑、首页照开，你甚至要等到有人打电话来问「我怎么登不上了」才知道出事了。这类锅追根溯源，基本都能落回顺序问题上。

为什么数据库必须先动

数据库是活的。只要旧站还挂着、解析还指过去，它随时都在变：有人注册、有人留言、后台有人改库存、支付回调还在往里写。你传文件的那段时间里，它一直在往前走。

而传文件这个动作，本质是给文件拍一张快照。拍完那一刻，文件停在某个时间点，数据库却已经跑到更后面去了。差得越久，两边越对不上。

所以顺序应该是：先让数据库停在一个确定的点上，把它整体取出来；再从容地把文件搬过去；最后把这个定点还原到新环境。这样文件和数据的「时间」是同一个瞬间，后面省掉一堆核对。

导之前，先把写入掐掉

停写入的方式好几种，看你站点什么架子。最土也最稳的是挂个维护页，后台先别让人进，等导出跑完再放开关。

常见的 CMS 一般自带维护模式；没有的话就在 Web 服务器层拦一下，返回 503，别让请求打到程序上。这一步别嫌麻烦——你一边导、一边有人往里写，导出来的那份就是残缺的，而且残缺得很隐蔽。

命令行这块，MySQL 系一般用 mysqldump，字符集参数、锁表还是单事务，这些不同版本行为有差别，具体以你实际用的版本和官方文档说明为准。表大的别硬来，分批导、压缩传、走内网，比什么都强。

还有一句，导完先别急着删旧库。原样留一份，出事还有得回。

文件这一步，别用 FTP 硬拖

文件看着简单，其实错得最多。几万个小文件一个个用 FTP 拖，慢不说，还容易漏、容易断，断了你都不知道从哪儿接着来。

我的习惯是先打包压缩，整包传过去再解。web 目录里的缓存、临时文件、历史日志（cache、tmp、logs 这类）别一股脑带过去，带过去大概率要出幺蛾子。

权限也得跟着走。Linux 下解包完，文件属主往往是当前登录用户，而不是 Web 进程跑的那个用户，结果就是 500 或者后台上传失败。这坑不新鲜，但年年有人踩。

还有隐藏文件。.htaccess、.user.ini、.env 这种，打包时留意别漏，很多人搬完伪静态全失效，回头查半天就是这个原因。

导入完，最容易翻车的几处

地址替换排第一。站点从老域名换到新域名，库里存的绝对地址全得跟着换。直接拿 SQL 的 replace 硬刷有风险，序列化过的数据刷完结构就烂了，还是用成熟工具或者官方推荐的方式稳一点。

第二是字符集。导出一种、导入又变成另一种，中文就成了问号或者乱码。这通常不是数据坏了，是两边编码没对齐。

第三是账号权限。数据库用户、密码、允许连接的来源地址，三样都对上，程序才连得进去。有人只改了配置文件里的密码，忘了在新库里建账号。

第四是定时任务和队列。旧机器上挂着 crontab，新机器没搬，站点看着好好的，就是数据不更新——这个最阴，往往过几天才被翻出来。

切换那天怎么少挨骂

解析的 TTL 提前调小，最好前一两天就改，别等当天才想起来。切完自己先走一遍关键路径：登录、搜索、下单、发评论、支付回调，别只看首页能不能开。

旧站别立刻关，留几天。有人本地 DNS 还没刷过来，你这边一关，对他来说就是网站挂了，解释起来很费劲。

更重要的一条：留回滚的路。最坏情况无非把解析切回去，前提是旧站的文件和库都还在原处，一根手指头都没动过。这跟前面说的先别删旧库，是一回事。

一句话，搬站的时候把心里那点「先把看得见的搬走」的冲动按下去。数据先定点，文件后跟进，最后一起放出来，顺序对了，很多看着莫名其妙的故障压根不会发生。搬完也别急着庆祝，把登录、下单、后台发布这几条路走一遍，安安静静跑两天，再考虑下线老环境。