内容：如果有可能，避免重定向；确实需要时，采用正确的方法。
场景：总是。
用法：如果需要重定向，考虑通过服务器配置来实现，而不是利用HTML或者其他基于代码的解决方案。
原因：总体来说，重定向会延迟用户进程，消耗计算资源，造成错误，不利于页面在搜索引擎中的排名。
要点：正确而且仅在必要时使用重定向。
HTTP 3xx状态码中有几段是与重定向相关的。
300多项选择（Multiple Choices）：被请求资源对应于所提供的众多来源中的某一个，用户可以优先选择其中一个。
301永久移除（Moved Permanently）：被请求的资源已经分配给一个新的永久URI，未来任何对该资源的引用应该使用返回的URI。
302页面找到（Found）：被请求的资源暂时驻留在不同的URI，但客户端可以 继续使用目前的URI来发去请求。
303参见其他（See Other）：被请求资源可以在不同的URI下找到，应该用GET去检索。该方法主要是为PRG这种模式设计的，允许POST把输出重定向到用户代理。
304未被修改（Not Modified）：如果客户端发出了具有提交的GET并且该请求得到了允许，但是文档并没有被修改，那么服务器应该以此状态码响应。
305使用代理（Use Proxy）：被请求的资源必须通过指定的代理访问
306（保留）（Unused）：在规范中此状态码已经不再使用
307临时重定向（Temporary Redirect）：请求的资源暂时驻留在不同的URI。
重定向有多种方法，性能和资源利用比较好的方法控制难度比较大。常见的重定向方法有：
1.通过页面发请求进行重定向，最简单但是浪费资源
2.代码重定向，修改请求的header部分的HTTP状态码，比较简单
3.通过服务器配置进行重定向，复杂。例如Apache服务器通过修改httpd.conf，重写URL和状态码重定向到新的服务
在日常开发中见到最多的是方法1和方法2的内容，在某家银行工作的时候，用到的是方法3进行的重定向。
