这版等v8是因为v8 在 5.9开启了新的架构（I+TF），node这里如果不推迟，直接用现在的旧架构v8（5.7）出一个LTS，v8 团队是没法保证 ABI 兼容到 6.0 的，那么 node 8 里的 v8 就只能停留在 5.8 及以下了，接下来的三年都要自己维护这个v8里老架构的代码，浪费巨大的人力资源不说，backport的难度也很高。

其实 google 已经非常配合 node 的开发计划了了，比如推迟删除旧 debugger，保证 5.8 到 6.0 的 ABI 兼容之类。

@CoderIvan v8 确实要照顾浏览器端的需求，主要是parser部分要按照前端加载的需求优化，这个在后端倒不是很重要。v8 的 API 很大程度上要照顾 chromium 的需求，各种功能实现也是要优先考虑 chromium 的需求，各种基础工具也是跟着 chromium 走，比如最近从 gyp 迁移到 gn（但是，v8 和 chromium 是两个团队，一个大部分在慕尼黑，一个大部分在美国，而且 chromium 团队其实比 v8 还要大）。v8 很多任务的优先级也是取决于前端框架的，比如 react 的大热直接提高了 Function.prototype.bind 的优化任务优先级。但是要说照顾浏览器端影响到了服务端的表现，那其实还不至于，目前为止没有明显拖累的地方。要说内存限制和GC之类的，其实很多脚本语言的引擎本身跟前端八竿子打不着边也有为了方便优化加的限制啊（比如 LuaJIT 的 2GB），纯粹是人力资源的取舍罢了，何况 google 现在可是有不少员工在给 node 交代码和帮忙维护，CTC就有两个 google 的员工，我觉得已经算是仁至义尽了……

@rwing 自己 fork 一个这个前几天才有人讨论：https://github.com/nodejs/CTC/issues/100 ，你可以看看维护者们什么反应……v8 这个体量的项目不是 node 这点维护者能够把控住的，v8 的代码体积是 node 的 10 倍，一个月的 commit 数量和代码变更行数可是 node 的好几倍，node 真正全职拿钱提交代码的人也就那几个，主要还是靠志愿者，现在最活跃的人起码一半以上是学生或者工作和 node 关系不大，跟 v8 那种多个高薪团队一大群人全职干活的项目没法比。