流式加载是让你一边读一边写，x 是解压，on('entry') 的写法还是把所有的东西都读到内存里了，肯定要崩。
只是读文件列表的话用 t

一边读一边解压的话参考文档中这个写法：

fs.createReadStream('my-tarball.tgz').pipe(
tar.x({
strip: 1,
C: 'some-dir' // alias for cwd:'some-dir', also ok
})
)

https://github.com/npm/node-tar

另外 1.4G 的内存限制是 v8 给的， 通过参数能加大

前面滑板老手摔死了的好吓人。。。。
滑板确实是挺危险的， 一同事买到滑板第一天摔的软骨挫伤， 打了钢钉瘸了半年。每次有人想玩我的滑板我都讲一遍这个故事。
滑了三年了，有时候还是会在马路上被石子卡的一个踉跄，蛮危险的，注意安全吧

nodejs v0.10.28 用的 v8 版本是 3.14.5.9
https://nodejs.org/en/download/releases/

v8 升级 log 里面 [2012-09-06: Version 3.13.6 ] 这个段落里是最后一次提到 fix 了 Math.min/max 的 bug 了，所以要不是 nodejs 引入的 v8 有问题， 要不就是 3.13.6 修 bug 的时候又引入了新的 bug
http://upstream.rosalinux.ru/changelogs/v8/3.14.5.8/changelog.html

这种循环多次才出现的问题一般是 JIT 的 bug，16 年的时候还出了一次 typeof 的 bug， 也是 JIT 引发的
https://www.reddit.com/r/javascript/comments/4oxtgk/javascript_developers_be_warned_about_this_crazy/
https://bugs.chromium.org/p/chromium/issues/detail?id=604033

都是很严重的问题， 官方也说 V8 直接把 js 翻译成机器码的做法带了很多代码复杂度。还有我估计这种严重 JIT 的 bug， 就是 v8 换解释器的原因之一 。。。

想解决问题， 升级版本最简单， 附赠成倍性能提升， 而且就我之前经验来说， 当时 nodejs 4.x 的内存占用， 和垃圾回收能力比 0.x 的都好了太多倍了。。。

有人能说说日本的情况么

一楼正解

用 node 写后端,一直没怎么接触前端的路过.....

全程踩着大鱼板, 18 分钟, 到公司一身汗