Node.js v17版本npm run 报错 ERR_OSSL_EVP_UNSUPPORTED

问题：

解决：

出现这个错误是因为 node.js V17版本中最近发布的OpenSSL3.0,

而OpenSSL3.0对允许算法和密钥大小增加了严格的限制，可能会对生态系统造成一些影响.

在node.js V17以前一些可以正常运行的的应用程序,但是在 V17 版本可能会抛出以下异常:

方法1： 做配置（推荐）

方法2： 降低版本

方法3：.临时解决，设置环境变量 (测试无效)

前段时间要在项目中加上日志的上报，顺势了解了下怎么在node中完善错误信息的收集。

Error

 JS 中的 Error 对象，包含了错误的具体信息，包括 name、message、错误堆栈 stack 等。可以以 new Error 方式创建实例抛出，或调用 Error.captureStackTrace 为已有对象添加 stack 错误堆栈信息 而后抛出。

错误抛出几种方式

 Throw：Javascript 抛出的异常，是以 throw 方法抛出，未必都是 Error 的实例，但通过 nodeJs 或者 js 运行时发生的错误，都是 Error 的实例。

 EventEmitter：Nodejs 形式的错误回调，大部分流 &异步事件都衍生自 EventEmitter 类 || 实例，如 fs, process, stream 等。

 Process：程序运行过程中抛出的异常，或由底层库抛出，或是运行中发生的一些 SyntaxError 之类。

错误捕获几种方式

try .. catch：常用的一种捕获错误方式，浏览器 || node 环境均适用。

缺点：只针对同步异常有效。

EventEmitter 

由 Events 模块提供的 EventEmitter 类，基于 Observer 模式做的 publish/subscribe，通过 .on('error', ...)|| .addEventlistener('error', ...) 注册 subscriber，.emit() 发布事件，但会有最大的 maxListener 的限制，可更改。      

不 show 源码了，特别简单，自己去 look 一下。如 koa 的 app 就是基于 EventEmitter 的扩展，因此可以通过监听 error。

Process 

Process 进程对象也是 EventEmitter 的实例，可通过如下两事件监听 error。

unhandledRejection ：promise 的回调报错，可通过监听该事件 catch，但要注意由于 promise 的 rejection catched 不知道会在啥时候才发生，所以实际上可能在 unhandledRejection 事件触发后才 catch 了这个信息，对应有 rejectionHandled 事件监听，如下：

(承上)  uncaughtException  ：其余 js 运行中发生 || 抛出的未捕获错误，均可通过监听该事件解决，若不进行该事件的监听，发生异常时，会直接导致程序 crash。但不建议用这种方式 catch，程序运行中的错误 更应该是抛出来，所有的 error 都 catch 的话，岂不是程序都可以看成无 bug 了。but 在打错误日志的时候是需要 catch 上报日志的，但是在上报完后，需要继续把 error throw，对于 uncaughtException callback 中抛出的异常不会再捕获，而是以非 0 的状态码 exit。

小结

说了这么多，就做个小小总结吧  以上关系网可以概括为如图：

个人见解，实际处理中基于几点准则：

1、对于需要具象化的错误信息，也就是我们需要知道具体是哪一块的错误，并且在错误发生时即进行个性化处理。这一类型的错误，在程序中执行时要对可能会出错的函数进行 catch，方式有多种:  try ... catch（同步）；  或 通过 node 形式的标准错误回调 (err) =>{...}（要求所调用的方法，支持该种写法）；  或 监听 error 事件 .on('error', err =>{...})（要求所调用的对象继承自 EventEmitter 实例，并内部发生错误时，会 emit('error')）。

2、promise 形式的错误，可在 promise 实例的末尾再引入 .catch，可捕获该实例所有 then 中抛出的异常；另外 async 的引入也允许了我们可以如同步 *** 作一样捕获错误。

3、但有时候程序的运行，不可能针对所有的函数 *** 作等都去 try ... catch，也不能保证程序运行一定就无 bug，但必须要能够把这些异常都捕获并上报。因此 process 的两个大 boss:  unhandledRejection &uncaughtException，是必须引入的，在程序最外层引入，且越靠前越好。此外针对 unhandledRejection，为防止说把不必要的 rejection 上报，可以在收到事件时，先把被 reject 的 promise 和 error 存储起来，设置时间 maxTimeout ，超过 maxTimeout 仍未收到 rejectionHandled 的 promise 事件，再上报。

koa 项目为例：

源码解读

下图为 node 中对于 process 的初始化等系列流程：

node.cc 其实是 node 运行主要的文件，其中定义了三个重载函数 Start，调用顺序为 3 → 2 → 1，每个函数参数不同处理不同的逻辑；

isolate->AddMessageListener 的监听事件 OnMessage 会在 js 运行发生错误时触发，嗯，是的，只有 error 才会传递 ；这很好的解释了为什么 process 监听 uncaughtException 就可以监听到所有的抛出的非 promise 异常；

OnMessage 调用了 FatalException 函数，FatalException 引用 process.fatalException 并传入 error （env 是 env.h 中声明的 Environment 类实例，fatalexceptionstring 也是其中定义的，返回值为 'fatalException'）；  以下为 FatalException 函数的部分内容。

在调用 fatalException 函数前，先调用 v8::TryCatch::setVerbose 把 verbose 设置为 false，则运行时抛出的异常就不会再触发 FatalException ；在捕获到运行错误后，把 exitcode 设为 7，并返回；这就解释了 为什么在 uncaughtException 时抛出的异常不会再重新触发回调，要知道 EventEmitter 可没帮你做这样的事情。

_fatalException 在触发 "uncaughtException" 事件前其实是会优先检查 domain 是否存在，当 domain 不存在时才会调用 uncaughtException 的，但 domain 这个 api 已经被废除了，也就不累述了。

unhandledRejection 事件的触发整体思路也差不多，首先会调用 SetupPromises 初始化，然后调用 v8::Isolate::SetPromiseRejectCallback 进行监听 ... 并且跟 uncaughtException 不同的是 unhandledRejection 的触发只会打印 warning 并不会把整个程序给 crash 了。

END

参考网站：  https://v8.paulfryzel.com/docs/master/index.html

---