今天想了一下，你说得对，确实是我言辞过激了。在这里对两位道歉。
1 个赞
我不知道谁举办的，但我确实收到了举办。我没管（
2 个赞
实际上 node 的 gyp 有这么严重的设计缺陷却能在几年前被普遍使用，其核心原因在于压根没有 node 程序能做到插件的热更新。你有印象中使用哪个 node 库然后支持运行到一半自己更新依赖版本的吗？
注：VSCode 是为数不多的例外，但它能做到是因为它每一个扩展都运行在隔离的进程中，并且很多情况下仍然需要彻底重启才能更新，这样的运行和使用成本其实比 Koishi 要大很多。
所以你的这个说法其实代表了一个非常常见的误区。用你自己的话来说应该是：最阴间的环境其实是热更新环境。只要你不热更新，那么这个插件就可以正常使用。然而 Koishi 还要考虑控制台用户的体验，对他们来说不能安装其他插件就已经足以标记为不安全了。
5 个赞
好，谢谢解答，我之后看看能不能重写一下依赖的逻辑把 node 丢到别的地方，主要是 canvas 速度确实快，舍不得
2 个赞
我们估计之后也会发一个安全的 canvas 服务，不过时间没定，大概一个月之内吧
2 个赞
https://github.com/Brooooooklyn/canvas/blob/31a8ff9a5295697b965ba4e48a19a30dc0f0b1d6/js-binding.js
好像只要改这里的代码兼容问题就解决了，这个 canvas 实现不依赖于任何安装脚本或者 node gyp，如果要实现 canvas 服务可以优先考虑用这个
2 个赞
是的，魔改这个文件即可解决；如果要做 canvas 服务的话我也推荐用这个，更省事
1 个赞
喜报，r6s 不安全脱帽啦！顺带修了下屎山
4 个赞
好诶！
3 个赞