前端优化方案

1 优化css

1.1 避免使用CSS表达式

用CSS表达式动态设置CSS属性，是一种强大又危险的方式。从IE5开始支持，但从IE8起就不推荐使用了。例如，可以用CSS表达式把背景颜色设置成按小时交替的

尽量减少标签选择器的使用
尽可能少使用id选择器，多使用样式选择器(通用性强)
减少选择器前缀，例如.headerBox .nav .left a{} 选择器是从右向左查询的
避免使用css表达式
background-color: expression( (new Date()).getHours()%2 ? “#B8D4FF” : “#F08A00” );
复制代码

1.2 减少页面中的冗余代码

尽可能提高方法的重复使用率：“低耦合高内聚”

1.3 选择舍弃@import
前面提到了一个最佳实践：为了实现逐步渲染，CSS应该放在顶部。 在IE中用@import与在底部用效果一样，所以最好不要用它。

1.4 避免使用滤镜

IE专有的AlphaImageLoader滤镜可以用来修复IE7之前的版本中半透明PNG图片的问题。在图片加载过程中，这个滤镜会阻塞渲染，卡住浏览器，还会增加内存消耗而且是被应用到每个元素的，而不是每个图片，所以会存在一大堆问题。
最好的方法是干脆不要用AlphaImageLoader，而优雅地降级到用在IE中支持性很好的PNG8图片来代替。如果非要用AlphaImageLoader，应该用下划线hack：_filter来避免影响IE7及更高版本的用户。

1.5 把样式表放在顶部

把样式表放到文档的HEAD部分能让页面看起来加载地更快。这是因为把样式表放在head里能让页面逐步渲染。
  关注性能的前端工程师想让页面逐步渲染。也就是说，我们想让浏览器尽快显示已有内容，这在页面上有一大堆内容或者用户网速很慢时显得尤为重要。给用户显示反馈（比如进度指标）的重要性已经被广泛研究过，并且被记录下来了。在我们的例子中，HTML页面就是进度指标！当浏览器逐渐加载页面头部，导航条，顶部logo等等内容的时候，这些都被正在等待页面加载的用户当作反馈，能够提高整体用户体验。

1.6 压缩 css

使用在线网站进行压缩
使用html-minifier 对html 中的css 进行压缩
使用clean-css 对css进行压缩
webpack,gulp打包工具

2 优化图片

2.1 图片格式

尝试把GIF格式转换成PNG格式，看看是否节省空间。在所有的PNG图片上运行pngcrush（或者其它PNG优化工具）

2.2 优化CSS Sprite

采用css雪碧图(css sprit/css 图片精灵)技术，吧一些小图合并在一张大图上面，使用的时候，通过北京图片定位，定位到具体的某一张小图上

在Sprite图片中横向排列一般都比纵向排列的最终文件小
组合Sprite图片中的相似颜色可以保持低色数，最理想的是256色以下PNG8格式
“对移动端友好”，不要在Sprite图片中留下太大的空隙。虽然不会在很大程度上影响图片文件的大小，但这样做可以节省用户代理把图片解压成像素映射时消耗的内存。100×100的图片是1万个像素，而1000×1000的图片就是100万个像素了。

.pubBg{
	background:url('../img/sprit.png') no-repeat;
  background-size:x y; // 和原图的大小保持一致
}
 
.box{
	background-position:x y; // 通过背景定位，定位到具体的位置，展示不同的图片极客
}

页面中没法送一次http请求，都需要完成请求+响应这个完整的http事务，会消耗一些时间，也可能会导致http链接通道的堵塞,为了提高页面的加载速度和运行的性能，我们应该减少http的请求次数和减少请求内容的大小。

2.3 图像映射

可以把多张图片合并成单张图片，总大小是一样的，但减少了请求数并加速了页面加载。图片映射只有在图像在页面中连续的时候才有用，比如导航条。给image map设置坐标的过程既无聊又容易出错，用image map来做导航也不容易，所以不推荐用这种方式。

2.4 行内图片（Base64编码）

用data: URL模式来把图片嵌入页面。这样会增加HTML文件的大小，把行内图片放在（缓存的）样式表中是个好办法，而且成功避免了页面变“重”。但目前主流浏览器并不能很好地支持行内图片。
减少页面的HTTP请求数是个起点，这是提升站点首次访问速度的重要指导原则。

2.5 不要用HTML缩放图片

不要因为在HTML中可以设置宽高而使用本不需要的大图。如果需要

<img width="100" height="100" src="mycat.jpg" alt="My Cat" />

那么图片本身（mycat.jpg）应该是100x100px的，而不是去缩小500x500px的图片。

2.6 用小的可缓存的favicon.ico（P.S. 收藏夹图标）

favicon.ico是放在服务器根目录的图片，它会带来一堆麻烦，因为即便你不管它，浏览器也会自动请求它，所以最好不要给一个404 Not Found响应。而且只要在同一个服务器上，每次请求它时都会发送cookie，此外这个图片还会干扰下载顺序，例如在IE中，当你在onload中请求额外组件时，将会先下载favicon。
所以为了缓解favicon.ico的缺点，应该确保：

足够小，最好在1K以下
设置合适的有效期HTTP头（以后如果想换的话就不能重命名了），把有效期设置为几个月后一般比较安全，可以通过检查当前favicon.ico的最后修改日期来确保变更能让浏览器知道。

2.7 压缩image

使用雪花图
使用雪花图 www.spritecow.com/
使用矢量图
使用矢量图字体 fontawesome.dashgame.com/
使用阿里矢量图库 www.iconfont.cn/
使用矢量图转成字体 icomoon.io/
使用base64转换
使用网站压缩
使用无损压缩 tinypng.com/
png转换webp zhitu.isux.us/
合理使用格式图片
jpg有损压缩，压缩率搞，不支持透明
png支持透明，浏览器兼容好
webp压缩程度更好，在ios webview有兼容性问题
svg矢量图，代码内嵌，相对于较小，图片样式相对简单的场景
在使用webp的过程中，会产生一些浏览器兼容问题

function checkWebp() {
 
    try{
 
        return (document.createElement('canvas').toDataURL('image/webp').indexOf('data:image/webp') == 0);
 
       }catch(err) {
 
        return false;
 
       }
 
}

 
$(document).ready(function() {
 
        var webp_good = checkWebp();
 
        if(webp_good == false) {
 
            $('img').each(function() {
 
            var src = $(this).attr('src');
 
            if(typeof src != 'undefined') {
 
                src = src.replace('/format,webp', '/format,jpg'); //将webp格式转换成jpg格式
 
                $(this).attr('src', src);
 
            }
 
            var original = $(this).attr('original');        //针对用了懒加载的情况
 
            if(typeof original != 'undefined') {
 
                original = original.replace('/format,webp', '/format,jpg'); //将webp格式转换成jpg格式
 
                $(this).attr('original', original);
 
            }
 
        })
 
    }
 
})

2.8 图片懒加载

采用图片懒加载技术，在页面开始加载时候，不请求真实的图片地址，而是默认图占位，当页面加载完成后，在根据相关的条件依次加载真实的图片(减少页面首次加载http请求的次数)
真实项目中，我们开始图片都不加载，页面首次加载完成，先把第一屏幕中看见的图片进行加载，随着页面的滚动，在下面区域中能够呈现出来的图片进行加载

根据图片懒加载技术，我们还可以扩充出，数据懒加载
开始加载页面的时候，我们只把首屏或者前两屏的数据从服务器进行请求(有些网站首屏数据是后台渲染好，整体返回给客户端呈现的)

当页面下拉，滚动到哪个区域，在把这个区域需要的数据进行请求(请求回来数据绑定以及图片延迟加载等)
分页展示技术采用的也是数据懒加载思想实现的:如果我们开始请求获取的数据是很多的数据，我们最好分批请求，开始只请求第一页的数据，当页面点击第二页(微博是下拉到一定距离后，再请求第二页数据)的时候请求第二页数据。

3 优化js

3.1 去除重复脚本

页面含有重复的脚本文件会影响性能，这可能和你想象的不一样。在对美国前10大web站点的评审中，发现只有2个站点含有重复脚本。两个主要原因增加了在单一页面中出现重复脚本的几率：团队大小和脚本数量。在这种情况下，重复脚本会创建不必要的HTTP请求，执行无用的JavaScript代码，而影响页面性能。
  IE会产生不必要的HTTP请求，而Firefox不会。在IE中，如果一个不可缓存的外部脚本被页面引入了两次，它会在页面加载时产生两个HTTP请求。即使脚本是可缓存的，在用户重新加载页面时也会产生额外的HTTP请求。
  除了产生没有意义的HTTP请求之外，多次对脚本求值也会浪费时间。因为无论脚本是否可缓存，在Firefox和IE中都会执行冗余的JavaScript代码。
  避免不小心把相同脚本引入两次的一种方法就是在模版系统中实现脚本管理模块。典型的脚本引入方法就是在HTML页面中用SCRIPT标签：

<script type="text/javascript" src="menu_1.0.17.js"></script>

3.2 尽量减少DOM访问

一个复杂的页面意味着要下载更多的字节，而且用JavaScript访问DOM也会更慢。举个例子，想要添加一个事件处理器的时候，循环遍历页面上的500个DOM元素和5000个DOM元素是有区别的。
操作dom的弊端

dom存在映射在机制(js中的dom元素对象和页面中dom结构是存在映射机制的，一改则都改)，这种映射机制，是浏览器安卓w3c标准完成对js语言的构建和dom的构建(其实就是构建一个监听机制)，操作dom是同事修改两个地址，相对于一些其他的js编程来说消耗性能的。
页面中的dom结构改变或者样式改变，会触发浏览器的回流(浏览器会把dom结构重新进行计算，这个操作很耗性能)和重绘(吧一个元素的样式重新渲染)
在做dom事件绑定的时候，尽量避免一个个的事件绑定，二采用性能更高的事件委托来实现

事件委托(事件代理) 把时间板顶给外层容器，当里面的后代元素相关行为被处罚，外层容器绑定的方法也会被触发执行(冒泡传播机制导致)，通过的事件源是谁，我们做不同的操作即可

用JavaScript访问DOM元素是很慢的，所以，为了让页面反应更迅速，应该：

缓存已访问过的元素的索引
先“离线”更新节点，再把它们添到DOM树上
避免用JavaScript修复布局问题

DOM元素的数量很容易测试，只需要在控制台里输入

document.getElementsByTagName('*').length

3.3 用智能的事件处理器

有时候感觉页面反映不够灵敏，是因为有太多频繁执行的事件处理器被添加到了DOM树的不同元素上，这就是推荐使用事件委托的原因。如果一个div里面有10个按钮，应该只给div容器添加一个事件处理器，而不是给每个按钮都添加一个。事件能够冒泡，所以可以捕获事件并得知哪个按钮是事件源。

3.4 更多异步操作编译

同步编程会导致:上面东西完不成，下面任务也做不了，我们开发的时候，可以把某一个区域模块都设置为异步编程，这样只要模块之间没有必然的先后顺序，都可以独立进行加载，不会受到上面模块的堵塞影响(用的不多)
尤其是ajax数据请求，我们一般都要使用异步编程，最好是基于promise设计模式进行管理(项目中经常使用fetch、vue、axios)等插件进行ajax请求处理，因为这些插件中就是基于promise设计模式对ajax进行了封装处理
在真实的项目中，我们尽可能避免一次性循环过多数据(因为循环操作是同步编程)，尤其是要避免while导致的死循环操作

3.5 JS中避免使用eval

性能消耗大
代码压缩后，容易出现代码执行错乱问题

3.6 JS中尽量减少闭包的使用

闭包会形成一个不销毁的栈内存，过多的栈内存累积影响页面的性能
还会容易导致内存的泄露
闭包也有自己的优势:保存和保护，我们只能尽量减少，但是无法避免

3.7 尽量使用css3动替代js动画

css3的动画或者变形都开启了硬件加速，性能比js动画好

3.8 缓存做处理

对于不经常更新的数据，最好采用浏览器的304缓存做处理
例如:
第一次请求css和js下拉，浏览器会把请求的内容缓存起来，如果做了304处理，用户再次请求css和js直接从缓存中读取，不需要再去服务器获取了(减少了http请求次数)
当用户强制刷新页面(ctrl+f5)或者当前缓存的css或者js发生了变动，都会从新从服务器端拉取
对于客户端来讲，我们还可以基于localStronge来做一些本地存储，例如:第一次请求的数据或者不经常更新的css和js，我们都可以吧内容存储在本地，下一次页面加载，我们从本地中获取即可，我们设定一定的期限或者一些标识，可以控制在某个阶段重新从服务器获取

3.9 设计模式

编写js代码的时候尽可能使用设计模式来构建体系，方便后期的维护，也提高了扩充性等

3.10 把脚本放在底部

脚本会阻塞并行下载，HTTP/1.1官方文档建议浏览器每个主机名下并行下载的组件数不要超过两个，如果图片来自多个主机名，并行下载的数量就可以超过两个。如果脚本正在下载，浏览器就不开始任何其它下载任务，即使是在不同主机名下的。
  有时候，并不容易把脚本移动到底部。举个例子，如果脚本是用document.write插入到页面内容中的，就没办法再往下移了。还可能存在作用域问题，在多数情况下，这些问题都是可以解决的。
  一个常见的建议是用推迟（deferred）脚本，有DEFER属性的脚本意味着不能含有document.write，并且提示浏览器告诉他们可以继续渲染。不幸的是，Firefox不支持DEFER属性。在IE中，脚本可能被推迟，但不尽如人意。如果脚本可以推迟，我们就可以把它放到页面底部，页面就可以更快地载入。

3.11 压缩js

使用在线网站进行压缩
使用html-minifier 对html 中的css 进行压缩
使用uglifjs2对js进行压缩
webpack,gulp打包工具

4 优化html

4.1 audio或者video标签

如果当页面中出现audio或者video标签，我们最好设置它们的preload=:页面加载的时候，音视频资源不进行加载，播放的时候再开始加载(减少页面首次加载http请求的次数)

preload=auto 页面首次加载的时候就把音频资源进行加载
preload=metadata 页面首次加载的时候只能音视资源的头部信息进行加载

4.2 尽量少用iframe

用iframe可以把一个HTML文档插入到父文档里，重要的是明白iframe是如何工作的并高效地使用它。

的优点：

引入缓慢的第三方内容，比如标志和广告
安全沙箱
并行下载脚本

的缺点：

代价高昂，即使是空白的iframe
阻塞页面加载
非语义

4.3 杜绝404

HTTP请求代价高昂，完全没有必要用一个HTTP请求去获取一个无用的响应（比如404 Not Found），只会拖慢用户体验而没有任何好处。
  有些站点用的是有帮助的404——“你的意思是xxx？”，这样做有利于用户体验，，但也浪费了服务器资源（比如数据库等等）。最糟糕的是链接到的外部JavaScript有错误而且结果是404。首先，这种下载将阻塞并行下载。其次，浏览器会试图解析404响应体，因为它是JavaScript代码，需要找出其中可用的部分。

5 移动端

5.1 保证所有组件都小于25K

这个限制是因为iPhone不能缓存大于25K的组件，注意这里指的是未压缩的大小。这就是为什么缩减内容本身也很重要，因为单纯的gzip可能不够。

5.2 把组件打包到一个复合文档里

把各个组件打包成一个像有附件的电子邮件一样的复合文档里，可以用一个HTTP请求获取多个组件（记住一点：HTTP请求是代价高昂的）。用这种方式的时候，要先检查用户代理是否支持（iPhone就不支持）。

6 cookie

6.1 给Cookie减肥

使用cookie的原因有很多，比如授权和个性化。HTTP头中cookie信息在web服务器和浏览器之间交换。重要的是保证cookie尽可能的小，以最小化对用户响应时间的影响。

清除不必要的cookie
保证cookie尽可能小，以最小化对用户响应时间的影响
注意给cookie设置合适的域级别，以免影响其它子域
设置合适的有效期，更早的有效期或者none可以更快的删除cookie，提高用户响应时间

6.2 把组件放在不含cookie的域下

当浏览器发送对静态图像的请求时，cookie也会一起发送，而服务器根本不需要这些cookie。所以它们只会造成没有意义的网络通信量，应该确保对静态组件的请求不含cookie。可以创建一个子域，把所有的静态组件都部署在那儿。
如果域名是www.example.org，可以把静态组件部署到static.example.org。然而，如果已经在顶级域example.org或者www.example.org设置了cookie，那么所有对static.example.org的请求都会含有这些cookie。这时候可以再买一个新域名，把所有的静态组件部署上去，并保持这个新域名不含cookie。Yahoo!用的是yimg.com，YouTube是ytimg.com，Amazon是images-amazon.com等等。
把静态组件部署在不含cookie的域下还有一个好处是有些代理可能会拒绝缓存带cookie的组件。有一点需要注意：如果不知道应该用example.org还是www.example.org作为主页，可以考虑一下cookie的影响。省略www的话，就只能把cookie写到*.example.org，所以因为性能原因最好用www子域，并且把cookie写到这个子域下。

7 服务器

7.1 Gzip组件

前端工程师可以想办法明显地缩短通过网络传输HTTP请求和响应的时间。毫无疑问，终端用户的带宽速度，网络服务商，对等交换点的距离等等，都是开发团队所无法控制的。但还有别的能够影响响应时间的因素，压缩可以通过减少HTTP响应的大小来缩短响应时间。
从HTTP/1.1开始，web客户端就有了支持压缩的Accept-Encoding HTTP请求头。

如果web服务器看到这个请求头，它就会用客户端列出的一种方式来压缩响应。web服务器通过Content-Encoding相应头来通知客户端。

尽可能多地用gzip压缩能够给页面减肥，这也是提升用户体验最简单的方法。

7.2 避免图片src属性为空

Image with empty string src属性是空字符串的图片很常见，主要以两种形式出现：

straight HTML

JavaScript

var img = new Image(); img.src = “”;

这两种形式都会引起相同的问题：浏览器会向服务器发送另一个请求。

7.3 配置ETags

实体标签（ETags），是服务器和浏览器用来决定浏览器缓存中组件与源服务器中的组件是否匹配的一种机制（“实体”也就是组件：图片，脚本，样式表等等）。添加ETags可以提供一种实体验证机制，比最后修改日期更加灵活。一个ETag是一个字符串，作为一个组件某一具体版本的唯一标识符。唯一的格式约束是字符串必须用引号括起来，源服务器用相应头中的ETag来指定组件的ETag：

然后，如果浏览器必须验证一个组件，它用If-None-Match请求头来把ETag传回源服务器。如果ETags匹配成功，会返回一个304状态码，这样就减少了12195个字节的响应体。
GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: “10c24bc-4ab-457e1c1f”
HTTP/1.1 304 Not Modified

---

7.4 对Ajax用GET请求

邮箱团队发现使用XMLHttpRequest时，浏览器的POST请求是通过一个两步的过程来实现的：先发送HTTP头，在发送数据。所以最好用GET请求，它只需要发送一个TCP报文（除非cookie特别多）。IE的URL长度最大值是2K，所以如果要发送的数据超过2K就无法使用GET了。
POST请求的一个有趣的副作用是实际上没有发送任何数据，就像GET请求一样。正如HTTP说明文档中描述的，GET请求是用来检索信息的。所以它的语义只是用GET请求来请求数据，而不是用来发送需要存储到服务器的数据。

7.5 尽早清空缓冲区

当用户请求一个页面时，服务器需要用大约200到500毫秒来组装HTML页面，在这期间，浏览器闲等着数据到达。PHP中有一个flush()函数，允许给浏览器发送一部分已经准备完毕的HTML响应，以便浏览器可以在后台准备剩余部分的同时开始获取组件，好处主要体现在很忙的后台或者很“轻”的前端页面上（P.S. 也就是说，响应时耗主要在后台方面时最能体现优势）。
  较理想的清空缓冲区的位置是HEAD后面，因为HTML的HEAD部分通常更容易生成，并且允许引入任何CSS和JavaScript文件，这样就可以让浏览器在后台还在处理的时候就开始并行获取组件。
例如：

&emsp;<br />... <!-- css, js --><br />    </head><br />    <?php flush(); ?><br />    <body><br />      ... <!-- content --><br /> 

7.6 使用CDN（内容分发网络）

用户与服务器的物理距离对响应时间也有影响。把内容部署在多个地理位置分散的服务器上能让用户更快地载入页面。但具体要怎么做呢？
  实现内容在地理位置上分散的第一步是：不要尝试去重新设计你的web应用程序来适应分布式结构。这取决于应用程序，改变结构可能包括一些让人望而生畏的任务，比如同步会话状态和跨服务器复制数据库事务（翻译可能不准确）。缩短用户和内容之间距离的提议可能被推迟，或者根本不可能通过，就是因为这个难题。
  记住终端用户80%到90%的响应时间都花在下载页面组件上了：图片，样式，脚本，Flash等等，这是业绩黄金法则。最好先分散静态内容，而不是一开始就重新设计应用程序结构。这不仅能够大大减少响应时间，还更容易表现出CDN的功劳。
  内容分发网络（CDN）是一组分散在不同地理位置的web服务器，用来给用户更高效地发送内容。典型地，选择用来发送内容的服务器是基于网络距离的衡量标准的。例如：选跳数（hop）最少的或者响应时间最快的服务器。

7.7 添上Expires或者Cache-Control HTTP头

这条规则有两个方面：

对于静态组件：通过设置一个遥远的将来时间作为Expires来实现永不失效
多余动态组件：用合适的Cache-ControlHTTP头来让浏览器进行条件性的请求
  网页设计越来越丰富，这意味着页面里有更多的脚本，图片和Flash。站点的新访客可能还是不得不提交几个HTTP请求，但通过使用有效期能让组件变得可缓存，这避免了在接下来的浏览过程中不必要的HTTP请求。有效期HTTP头通常被用在图片上，但它们应该用在所有组件上，包括脚本、样式和Flash组件。
  浏览器（和代理）用缓存来减少HTTP请求的数目和大小，让页面能够更快加载。web服务器通过有效期HTTP响应头来告诉客户端，页面的各个组件应该被缓存多久。用一个遥远的将来时间做有效期，告诉浏览器这个响应在2010年4月15日前不会改变。

如果你用的是Apache服务器，用ExpiresDefault指令来设置相对于当前日期的有效期。下面的例子设置了从请求时间起10年的有效期：
ExpiresDefault “access plus 10 years”

7.8 减少dns查询

域名系统建立了主机名和IP地址间的映射，就像电话簿上人名和号码的映射一样。当你在浏览器输入www.shanghai70.com的时候，浏览器就会联系DNS解析器返回服务器的IP地址。DNS是有成本的，它需要20到120毫秒去查找给定主机名的IP地址。在DNS查找完成之前，浏览器无法从主机名下载任何东西。
  DNS查找被缓存起来更高效，由用户的ISP（网络服务提供商）或者本地网络存在一个特殊的缓存服务器上，但还可以缓存在个人用户的计算机上。DNS信息被保存在操作系统的DNS cache(微软Windows上的”DNS客户端服务”)里。大多数浏览器有独立于操作系统的自己的cache。只要浏览器在自己的cache里还保留着这条记录，它就不会向操作系统查询DNS。
  IE默认缓存DNS查找30分钟，写在DnsCacheTimeout注册表设置中。Firefox缓存1分钟，可以用network.dnsCacheExpiration配置项设置。(Fasterfox把缓存时间改成了1小时 P.S. Fasterfox是FF的一个提速插件)
  如果客户端的DNS cache是空的（包括浏览器的和操作系统的），DNS查找数等于页面上不同的主机名数，包括页面URL，图片，脚本文件，样式表，Flash对象等等组件中的主机名，减少不同的主机名就可以减少DNS查找。
  减少不同主机名的数量同时也减少了页面能够并行下载的组件数量，避免DNS查找削减了响应时间，而减少并行下载数量却增加了响应时间。我的原则是把组件分散在2到4个主机名下，这是同时减少DNS查找和允许高并发下载的折中方案。

7.9 避免重定向

重定向用301和302状态码，下面是一个有301状态码的HTTP头

HTTP/1.1 301 Moved Permanently Location: example.com/newuri Content-Type: text/html

浏览器会自动跳转到Location域指明的URL。重定向需要的所有信息都在HTTP头部，而响应体一般是空的。其实额外的HTTP头，比如Expires和Cache-Control也表示重定向。除此之外还有别的跳转方式：refresh元标签和JavaScript，但如果你必须得做重定向，最好用标准的3xxHTTP状态码，主要是为了让返回按钮能正常使用。
  牢记重定向会拖慢用户体验，在用户和HTML文档之间插入重定向会延迟页面上的所有东西，页面无法渲染，组件也无法开始下载，直到HTML文档被送达浏览器。
  有一种常见的极其浪费资源的重定向，而且web开发人员一般都意识不到这一点，就是URL尾部缺少一个斜线的时候。例如，跳转到www.shanghai70.com/a会返回一个重定向到www.shanghai70.com/b的301响应（注意添在尾部的斜线）。在Apache中可以用Alias，mod_rewrite或者DirectorySlash指令来取消不必要的重定向。
  重定向最常见的用途是把旧站点连接到新的站点，还可以连接同一站点的不同部分，针对用户的不同情况（浏览器类型，用户帐号类型等等）做一些处理。用重定向来连接两个网站是最简单的，只需要少量的额外代码。虽然在这些时候使用重定向减少了开发人员的开发复杂度，但降低了用户体验。一种替代方案是用Alias和mod_rewrite，前提是两个代码路径都在相同的服务器上。如果是因为域名变化而使用了重定向，就可以创建一条CNAME（创建一个指向另一个域名的DNS记录作为别名）结合Alias或者mod_rewrite指令。

7.10 Json格式传输

在客户端和服务器端进行数据通信的时候，我们尽量采用json格式进行数据传输

json格式的数据，能够清晰明了的展示出数据结构，而且也方便我们获取的操作
相对于很早以前的xml格式传输，json格式的数据更加轻量级
客户端和服务器端都支持json格式数据的处理，处理起来非常的方便
真实项目中:并不是所有的数据都基于json，我们尽可能这样做，但是对于某些特殊的需求(例如文件流的传输或者文档传输)，使用json就不合适了