首先要明确为什么要进行前端静态资源的版本管理，其主要目的是为了解决浏览器缓存问题，很多人会说浏览器缓存不是服务端通过设置Etag和过期时间之类的就可以吗？为什么前端还要管理缓存？还有人可能会说，缓存这么麻烦，那么可以不缓存？
带着上面的疑问，所以我们要了解浏览器缓存。
浏览器缓存基本认识
浏览器缓存能有效减轻资源服务器的请求量，提高网页或应用程序的资源访问速度，所以一个WEB应用，缓存是必不可以少的优化利器。
缓存分为：
- 强缓存
- 协商缓存
强缓存
通过服务器返回response header中的Expires或者Cache-Control的时间来决定是否从本地读取缓存资源。
| 字段 | http版本 | 说明 |
|---|---|---|
| Expires | http1.0 | 返回GMT的绝对时间 |
| Cache-Control | http1.1 | 以秒为单位的过期时间 |
协商缓存
当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中，如果协商缓存命中，请求响应返回的http状态为304。当浏览器收到304响应时，就会直接从本地缓存读取资源。
协商缓存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】这两对Header来管理的。
强缓存和协商缓存的共同点
强缓存与协商缓存的共同点是：如果命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据；区别是：强缓存不发请求到服务器，协商缓存会发请求到服务器。
前端刷新缓存
根据前面缓存的基本知识，当资源被强缓存时，而资源版本已在服务器更新，这时我们就需要刷新缓存。当文件重命名或文件URL添加参数，都可以刷新缓存。
一般通过两种方式来刷新：
- 资源重新命名，如:
index.js更新为index_a083082f.js - 资源链接添加变化的参数，如：
index.js更新为index.js?hash=a083082f
资源重新命名
从可用性角度说，大型web应用中，资源重新命名是最优的选择，因为新的资源文件不会覆盖正在运行的资源文件，比如关键逻辑的JS脚本文件。而且CDN回源需要一定的时间才能全网生效，等资源文件生效后再进行HTML文件的发布。HTML文件强制不缓存，就能很好的达到WEB应用版本更新的目的。
资源重新命名，也同时会造成大量无效旧版文件存在于CDN或版本管理服务器（SVN,GIT）。
资源链接添加变化的参数
一般添加资源更新日期或文件内容的hash值。
但不管哪种方式，手动修改文件版本号，只适用于非常小型的应用。我们需要的是一个自动化的前端工具来做这件事。
于是笔者就造了以下两个轮子：
- gulp-hash-list ，主要作用是读取资源，计算hash值，按指定的格式生成一个清单文件。
-
gulp-asset-revision
读取资源列表的清单文件，替换HTML中的js,css等资源引用地址。
gulp-hash-list和gulp-asset-revision的使用
var gulp = require('gulp');
var hash = require('gulp-hash-list');
var revision = require('gulp-asset-revision');
gulp.task('hash', function() {
return gulp.src(['./src/**/*.js','./src/**/*.css'])
.pipe(hash({
"template": "{name}{ext}?hash={hash}"
}))
.pipe(gulp.dest('./dist'))
.pipe(hash.manifest('assets.json'))
.pipe(gulp.dest('./manifest'));
});
gulp.task('revision', ['hash'], function() {
return gulp.src(['./pages/*.html'])
.pipe(revision({
hasSuffix: false,
manifest: './manifest/assets.json'
}))
.pipe(gulp.dest('./pages/'));
});
为什么要选用gulp-hash-list和gulp-asset-revision
其实Gulp生态已经有gulp-rev + gulp-rev-collector这种优秀的方案，但是它只支持生成新的文件名，不支持添加参数的形式。
而gulp-hash-list和gulp-asset-revision不仅可以支持生成新文件，同时支持添加参数的形式刷新资源版本号，以更新缓存。
