我这人做事情，最讨厌的就是不规范。最近接手了一个老项目，我简直想把前一个做这玩意儿的小王揪出来暴打一顿。他不是不知道域名转向怎么搞，他是知道得太多了，而且一股脑全用上了，搞得整个系统像个五毒教。
你想象一下，一个老旧的网站要迁移到新域名上。按理说，用一个统一的、标准的301永久跳转就完事儿了。结果我一扒拉代码和配置，发现五花八门的跳转方式全塞进去了。有的跳转走后端，有的走前端，有的连服务器都没进，直接在域名面板上就转了。这导致调试的时候头都大了，因为你根本不知道现在访问的页面到底是在哪一步被扭曲过去的。
我为什么要学习并实践这五种转向方式？
实话实说，我不是为了炫技，我就是被逼的。为了把小王留下的烂摊子彻底清干净，我决定把所有能实现域名转向的方法全部捋一遍，实践一遍，然后定一个统一的标准，把那些乱七八糟的野路子全部干掉。这五种，就是我总结并亲手实现过的，也是最常见的。
我们一个一个来，看我当时是怎么折腾的。
1. 服务器老大说了算：HTTP 301/302 状态码转向
这是最正规，也是我们新项目唯一允许用的方式。我当时直接动手修改了服务器的配置文件，因为我们用的是Nginx，操作起来相对直接。
我打开Nginx的配置文件，找到对应的虚拟主机配置块，然后加了几行代码。比如我要把老域名A转到新域名B，我写的就是类似这样的：
server {
listen 80;
server_name 老域名;
return 301 新域名;
我试了一下，浏览器一访问老地址，立马就跳到新地址了，而且因为用了301（永久重定向），搜索引擎就知道这个地址是永远搬家了，对SEO最如果是临时维护，我就换成302。
2. 后端脚本直接插手：程序代码控制 Header 转向
有时候服务器配置不能乱动，或者我们需要根据用户的登录状态、地区、或者访问时间来决定转不转，这时候就得让后端程序介入了。我当时用的是PHP，虽然原理都一样，就是在页面内容输出之前，直接往浏览器那里塞一个跳转指令。
我写了一个测试脚本，就几行：
- 我先告诉浏览器，这回我要给你一个跳转的地址。
- 然后我再告诉它，我们用的是301还是302。
- 我敲了一个
exit;，防止后面多余的内容输出。
这个方法的好处是灵活，但如果程序跑得慢，用户体验会稍差一点，而且要是忘记加301/302的状态码，搜索引擎可就搞不清楚了。
3. 浏览器端自己动手：JavaScript 转向
这个是小王的最爱，代码简单，在哪都能塞。但凡是后端不好改，或者他懒得动的页面，他都直接甩一个JS跳转。虽然快，但是如果用户禁用了JS，那就抓瞎了，而且搜索引擎对JS跳转的识别一直是个玄学，所以我尽量避免用它来做主页的永久跳转。
我写了个最简单的实现方法，就是在页面加载的时候，让浏览器自己跑起来：
<script>
* = '新地址';
</script>
我在测试页面里试了一下，点击链接，页面一瞬间就换了，确实很快，但这不是长久之计。
4. HTML文档里的土方法：Meta Refresh 标签转向
这个方法太老了，现在几乎没人用了，但我在小王的旧代码里发现了一堆。我只能说，这简直是老古董。它就是一段HTML代码，写在页面的头部，告诉浏览器“等X秒后，请自动跳转到新地址”。
我当时测试的代码是这样的：
<meta http-equiv="refresh" content="0;url=新地址">
我把等待时间设为0，它就实现了即时跳转。这种方法对搜索引擎非常不友而且用户体验也不因为你可能看到页面闪烁一下。我找到这些代码后，全部都给替换成了服务器端的301。
5. 共享主机的好帮手：.htaccess 文件转向 (Apache)
一种，也是我经常在一些小型共享主机项目里遇到的，就是通过修改根目录下的.htaccess文件来实现跳转。虽然我们现在主用Nginx，但以前的老项目很多都是跑在Apache上的，这个文件权限很高，能直接控制目录下的所有跳转规则。
我用测试环境试了一下，加几行代码，比如使用RewriteEngine On，然后定义跳转规则。这个好处就是不用动主配置文件，权限小，但坏处是，每访问一次，系统都要去读取这个小文件，性能稍微有点损耗。
我把这五种方法全部实践、测试了一遍，明确了它们各自的优缺点和适用的场景。我的结论是：能用301解决的，坚决不用其他方法。
折腾完这一切，我把小王留下的所有非301跳转全部清理干净，统一换成了Nginx配置里的301永久转向。整个项目立马清爽了，调试效率也上来了，再也没出现过跳转套跳转的怪异问题。
所以说，实践出真知。这回被小王逼着把所有转向方式都走了一遍，虽然痛苦，但也算是系统性地把这块硬骨头啃下来了，以后再遇到这种问题，我就知道该怎么从根源上解决了。
