anchor.diff:  
   对纠结用户下载流量大小的人，告诉你打包下载的内容是经过 gzip 再由浏览器解开的，你可以安心了。
   
  +[[pipe_stream]]
   === 资源考虑：按流处理
   
   既然放弃压缩，省下的工作都是I/O，即搬运源文件内容到服务器，再以一个文件的形式搬运到用户手里，为什么中间要存一次文件呢？我们大可以把前后两个管道接上，拿到的每一块源文件内容都立即倒手给用户。
  
positive.code: 
  结果 Golang 语言胜出，采用 Golang 内置的 http 库由 goroutine 支持并发。
  
  === 安全考虑：secure-token auth
  
  打包下载服务授予 key pair 给服务使用者，并约定共同的hash算法，由服务使用者发出请求前做签名生成 token，之后由打包下载服务验证签名，并进一步验证是否过期以反盗链。
  
  在打包下载服务这里实际只做了验证（authentication），而没有做授权（authorization）。没错，任何签名正确且未过期的请求都可以被放行。你应该注意到了，签名请求的是服务使用者，那是你的某个使用此服务的产品，不是最终用户，对最终用户做授权是各产品自己的事，这也是为独立性的考虑。
  
  === 独立可复用考虑：独立无状态服务
  服务中必须把独立做到极致，才易复用
  
  
negative.code: 2. 打包压缩（有等待时间，压缩很耗CPU）
  3. 提供压缩包文件可对外下载（压缩包占硬盘）
  
  [[give_up_compression]]
  === 性能考虑：放弃压缩
  
  在前文列出的《要求》里，并没有着重提到打包的压缩比，其原因
  