@supermoonie 用的 goroutine 不是 libuv 那种。基于 go channel 的通信，不是 epoll，各有优劣。不会像 node 那样要各种侦听事件，写法基本是线性的，不会出现一大堆 callback

@xwhxbg 所以问题的关键是 puppeteer 没给你接口让你传这个 cancel 的信号进去啊，这样说你觉得还有问题吗？

@xwhxbg abort 是不可能由外部独立完成的，必然是要 task 自己轮询是否有中断机信号，这个是计算机原理的基础。promise 是 task 自己返回一个承诺，而 golang context 是向 task 传递中断信号。这个根本差异很难用一些三方库抹平，必须要改很多库的接口方式。puppeteer 是没有实现这种细粒度中断信号控制的。所以我觉得这里我表达的应该还算合理。

@xwhxbg 这个 google 一下类似关键字都可以出结果： https://stackoverflow.com/questions/29478751/cancel-a-vanilla-ecmascript-6-promise-chain

你看这个人说 bluebird 可以，然后评论的人就说的很清楚了：

this definition of canceled is just rejecting the promise. it depends on the definition of "canceled"

This is partially right, but if you have long promise chain, this approach would not work.

我觉挺清楚了啊，各种人都讨论过这个问题。

你说 ”es6 就有 abort“，能给个 ES6 官方的 spec 链接 吗？我好奇啥时候出的

@xwhxbg golang 贯穿整个系统底层的 context 概念是 nodejs 是很难比拟的: https://golang.org/pkg/context/

Promise 设计之初压根就没好好考虑 abort，草案直接放弃了这个方向的探寻。

写 puppeteer 大量重复的 async await 反复横跳于代码间。有时候写漏了 await 还不容易察觉。我个人觉得严重破坏了用 IDE 自动点点点补全的流畅感。

@xwhxbg 所以你得去了解 abort 的底层机制，bluebird 也没法解决我说的问题，它的 abort 对我来说都是虚假的 abort，实际还是在后台消耗资源。

@xwhxbg 比如这个例子 https://github.com/ysmood/yaku/issues/37

@xwhxbg 我是自己实现过 promise 库的，研究了很多 nodejs 底层工作原理的： https://github.com/ysmood/yaku

这说法其实是对比于 Go 的 context 特性来说的。大致就是指，比如一个 operation 要耗费一个小时，如果你用 nodejs 的 promise，实际上这个 operation 相关的资源还是驻留在内存的，并没有 abort 释放，只有到一个小时后才会释放。比如 cdp 的通信，由于是基于 websocket 的 frame，puppeteer 并没有实现原子级别的 abort 。你要想释放单个请求只能断开整个 websocket 链接，而 rod 这种就不用了，可以很原子的操作细节。

@playniuniu 好的，应该问题不大。还会讲解下如何利用 rod 调试复杂场景，这个也是很多人常常问的，这种就很难写文章，不录屏幕太麻烦解释了。

@playniuniu 确实，目前还没有教程，感觉最近可能会花点时间出点教程，比如录个视频或者直播之类的会对我来说负担小点，写文章比较费精力。确实是想收集大家的想法才发帖子的，有什么具体想学的吗？

@supermoonie 好奇你这个问题的出发点是啥。要在单核 CPU 上跑吗？理论上用了 Go 一个线程就够了 (green threads)，不是很清楚该如何回答你这个问题。

比如这两天我将用 rod 每小时自动置顶一次这个帖子，示例项目： https://github.com/go-rod/v2ex-example