combo 服务的几大性能和功能问题，恐怕需要比较大的修改，讨论一下 #2
Description
主要问题：
- lib/combo.js:63 不应该使用
fs.readFileSync，这会极大拖慢性能。 - lib/combo.js:25 不应该使用
if-modified-since判断是否返回 304，万一 combo 上次返回了错误数据就无法补救了，判断 304 最好用ETag，一般是文本内容的 hash 值。 - lib/combo.js:34-35
??和&最好可配置，其实?参数对 CDN 不友好，如果可以的话使用 url 会更好一些。比如/combo/url/-/%2Fstatic%2Ffile1.js/%2Fstatic%2Ffile2.js，用-�代表开始，后面的/来分割文件，文件路径用 uri encoded 方式传递。当然这只是一种方案，可以考虑用其他方式实现。 - combo.js 里面
callback都是在res.end()之后才回调，而callback里面又有可能使用res写数据，这种做法是会抛异常的，应该确保res.end()在callback之后调用。 - combo.js:55 检查文件是否存在的时候，应该在文件不存在时立即退出并返回 404。
- combo.js 里文件缓存需要做 LRU 策略，否则会有内存问题。除了 LRU，我觉得还应该考虑将合并后文件写入磁盘，方便在进程崩溃后还能访问到缓存。
- combo.js 需要注意的是，
fs.readFileSync第二个参数会使用 string 来存储文件内容，而 node 默认可使用内存最大才 1.4 GB，这样做很容易就内存溢出了。正确做法是使用使用Buffer，这样才能突破内存限制。 - combo.js 返回文件内容时，应该避免做字符串拼接，直接调用
res.write来输出才最高效。 - combo.js 不支持 gzip 方式返回数据，如果要支持，需要做的事情会挺多的。
总之，感觉 combo 服务还比较不成熟，作为 CDN 源站可能勉强可用，但是值得优化的点太多了点。我们或许可以考虑用一个比较成熟的 combo 服务器，或者做一次大重构。