迁移网站而不丢失计数

把一个网站搬到新的主机商、换掉域名，或者改用一套现代的内容管理系统，都牽涉到大量结构上的调整。要保住一个用了很久的图片计数器所累积下来的历史记录，就得先弄清楚：究竟是什么东西在维持着这份不间断的计数。

总数真正挂在什么上面

整套计数机制严格地依赖于嵌在图片来源地址里的那个唯一编号。只要指向计数端点的那条具体路径在搬迁期间和搬迁之后保持一模一样，累积起来的数字就会稳稳地保留在数据库的记录里。

地址里其余的一切其实都只是装饰。送出页面的那个域名、用的是哪一种协议、新系统里的目录结构是怎么排的——这些统统不会出现在那条保存着数字的记录里。真正出现在那里的只有编号一项，而它通常也不过就是标签中间的那一小串数字罢了。

一次成功的搬迁遵循一条清楚的操作次序。在改动 DNS 记录、或者搬运底层的数据库文件之前，先确认那段计数器代码已经妥妥地复制进了新系统的模板里——这样就能避免数据意外中断。

先后之所以要紧，是因为这两半坏起来的样子并不一样。标签已经复制过去、但暂时还够不着，那只会在记录里留下几个小时的空档，这是熬得过去的。而域名在标签复制之前就先搬走了，得到的将是一个什么也不计的页面，而且没有人会察觉，一直要到两个星期以后，有人打开统计页才发现。

只要主机商那边允许，安排一小段重叠的时间就是值得的。让旧的地址和新的地址一起跑上一天，就意味着计数器无论从哪一边都够得着，记录里也不会留下一段事后还需要向别人解释的空档。

出问题通常发生在两种情况下：域名跳转配置得不对，或者在清理代码的时候把图片标签的路径结构改动过。让来源字符串保持绝对一致，才能保证从新服务器配置生效的那一刻起，历史的进程无缝地接着往下走。

大部分的损失来自两种故障。第一种是清理代码的时候，把图片地址改写进了站点自己的目录结构里——而那恰恰是唯一不能动的东西。第二种是一条跳转：它对图片请求返回的是页面，而不是图片；计数器于是收到一样它画不出来的东西，总数就此停住，而且不会给出任何看得见的报错。

这两种故障找起来是同一个办法，而且用不了一分钟：单独把那个图片地址打开，看看有没有图片真的到达。这一项检查，只要在退掉旧主机之前做上一次，就是一次搬家和一次丢失之间的全部差别。