至少我机顶盒刷成armbian都能跑，这种阴间环境都能用应该不会有什么兼容性问题了吧，而且自带字体不使用系统自带
2 个赞
不安全插件就是不安全，和兼容性有什么关系？
是的，他没有兼容性问题，但这和不安全插件有什么关系吗？
再次重复，不安全插件本身就是不安全的，并不是因为兼容性问题。
如果你不了解「不安全」插件的话，可以查看以下帖子：
1 个赞
是我表达有误了，并且发现确实依旧是不安全的方式
3 个赞
2 个赞
不安全插件大部分不都是自动检测的吗，我觉得他想表达的意思就是检测过程会检查有没有 node-canvas 作为依赖性结果误伤了，因为 node-canvas 确实会造成兼容性问题，反应没必要那么激烈
2 个赞
我对 ta 反应比较激烈是有其他的原因，跟本帖的关系不大了。
1 个赞
那说说是什么原因!
3 个赞
r6s 在安装后存在 .node 文件，加载这些文件会导致用户安装后无法再安装、更新或卸载任何插件，因此被标记为不安全。
不是因为不安全所以无法安装，是因为无法安装所以不安全。除此以外还有其他不安全的原因。
3 个赞
不要以为只有 node-canvas 会导致无法安装插件，任何带有 .node 文件的依赖都会这样，比如下面的 @napi-rs/canvas-darwin-x64。
为什么会导致无法安装插件？
可以参考下面的文章：
如何解决我的问题？
有两种方案：
1. 不使用含有此类依赖的包
最简单的做法就是依赖 koishi-plugin-puppeteer，它直接提供了不弱于任何同类 canvas 包的 canvas 渲染能力。
2. 仍然使用 .node 但不存放于 node_modules 目录
比如依赖 koishi-plugin-downloads，将这些会占用的文件直接下载到其他地方去。
5 个赞
今天想了一下，你说得对，确实是我言辞过激了。在这里对两位道歉。
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 个赞