先探讨方案，后续再实现。

gulp打包前端教程配置：http://www.cnblogs.com/EasonJim/p/6209951.html

可能存在以下场景：

1、整个服务端采用接口的形式暴露给客户端，客户端全权负责前端效果及绑定数据。

2、服务端采用比如webfrom/mvc，java的模板机制绑定前端，前端最后会把做好的静态效果交给服务端进行绑定，有修改时，前端处理后又把新的静态丢给服务端做更新。

针对以上场景的具体实现方案：

1、这种方式无疑是最好管理的，各部门都有很明确的分工，每个开发都有明确工作，所以直接由前端构建好之后，自动带参数的资源文件，部署还是又前端处理；所以直接使用http://www.cnblogs.com/EasonJim/p/6209951.html。

1.1、这种方式的变现主要出自中大厂，每次发布后，观察其页面表现形式，可以发现资源文件都是带版本号的。

2、这种方式很纠结，比如前端打包号带版本号的资源文件和页面后，交付给服务端进行模板绑定，会发觉每次都必须全部页面都更新，工作量很大，所以采用第一种方式打包行不通。

2.1、改进方式：还是由客户端打包，不过是打包出不带参数的资源和静态；再交付给服务端，进行增量修改，这时服务端只需要替换资源和静态，最后提交到svn进行构建；其中构建的同时，发布到测试站点时，会再一次用gulp构建前台，不过这次构建的前台文件不再是html，而是aspx/cshtml/jsp这样的，最终的产物是，全部资源都带上参数；

2.2、从上一步会发现，把前端打包的过程中的一步：带参数过程，拿到了服务端进行。

2.3、这种方式主要出自小公司，因为小公司对于前端要求不高，只要做效果即可，最终由服务端进行绑定数据，通常都是服务端身兼多职去处理。

总结：

以上为打包方案的总结，还未正式实现，后续再实践。

为什么要加参数，很简单，对应微信浏览器为主，微信浏览器的缓存机制没有很好的体验，经常因为资源缓存的文件而出现bug。而微信上对于一些带参数的资源也不一定更新，比如：test.js?v=1234356，这样的形式有时不刷新，所以必须改用这样的方式：test-123123.js的形式。