前端构建工具满天飞的情景下，笔者也忍不住去捣鼓了一下，真正体验一下NODEJS带来的魅力，经过一段时间规划设计，终于将平台工具捣鼓出来了。在里面也体验了express, socket.io, grunt等node插件服务，使用很流畅，并且很好的完了我的基本需求（JSCSSIMAGE的压缩和自动部署功能）。
虽然基本功能完成，但是还有一个让人容易忽略而又重要的问题来了，就是资源文件的版本号的问题。在这里用的是SeaJS来做的模块管理，也在网上搜集了一下关于这块的资料。大致有以下两种方案：
1、 配置SeaJS的map对象。很方便，集中管理，但是也存在一些问题，比如：map对象的维护、配置文件引用页面的时间戳问题。
2、 生成文件sign，替换原有文件的名。这里不用考虑页面引用的时间戳问题，但是需要对资源及页面做一次全文查找替换，这对于分散部署的情况下将会非常复杂。
看了上面两种方案后，感觉在我的场景下还存在一些不足之处。笔者想要的是不影响开发情况下，开发人员完全不用考虑文件被缓存问题，只需完成编码，提交到构建系统后，一键完成构建和部署。
确定好目标后，既然不想让开发同学关心时间戳问题，那么是否可以将这个工作交给Web服务器来做呢？那么交给服务器来做之后，如何动态的更新最新的资源文件呢？
有问题就好解决，将问题抛出来之后，方案也渐进呈现出来，不啰嗦了，直接上笔者的实现方案：
构建工具动态生成.htaccess文件，将构建的资源文件的URL重写列表同步到.htaccess文件中以达到由服务器动态获取新的资源文件。
（备注：笔者是在apache环境下，对IISNGINXTOMCATRESINJBOSS等环境还需要再研究研究。）
看了上面的方案是不是很简单，那具体是怎么做的呢？笔者也在这里列一下。
1. 构建工具在构的时候生成一个与filename.ext对应的filename.ext.sha1的文件，这个.sha1的文件存放filename.ext文件的sha1值。
2. 在构建完成后，构建工具读取.htaccess的模板，并且遍历得到所有资源文件的列表，生成一个对filename.ext对应的filename.ext.sign的文件。
3. 按规则生成RewriteCond和RewriteRule。并将规则数据写到.htaccess文件中并部署到资源文件站点的根据目录。
图一：构建工具基本结构图
图二：构建后的文件列表
图三：生成一条Rule
图四：生成后的.htaccess文件
OK，到这里基本告一段落了，资源版本号解决了。但是对于性能影响这块还需要观察，待有时间再研究。
github地址：https://github.com/zwlijun/se.build
