我相信你阅读规范是正确的--没有其他引用提到error事件的引发，这意味着你将看到error事件触发的唯一时间是在WebSocket关闭期间（如果它有错误，而不是在“正常”关闭期间），并且它将总是跟随着close事件。
假设在close事件期间，您可以检查事件信息以确定它是否完全关闭，人们想知道error事件的目的是什么-似乎您只需要担心处理close事件，并查看wasClean和reason属性以确定它是否是由于错误引起的。

你可以在RFC 6455中读到这一点。在Opening handshake部分，它是这样说的：
1.如果无法打开连接，无论是因为直接连接失败还是因为使用的任何代理返回错误，那么客户端必须 * 使WebSocket连接失败 * 并中止连接尝试。
在失败的WebSocket连接部分，我们发现（强调我的）：
某些算法和规范要求端点 * 使WebSocket连接失败 *。为此，**客户端必须 * 关闭WebSocket连接 *，并可能以适当的方式向用户报告问题（这对开发人员特别有用）。同样，为此，服务器必须 * 关闭WebSocket连接 *，并应记录问题。
这似乎表明close事件将被一致地触发。然而，继续：
如果在要求端点 * 使WebSocket连接失败 * 之前 * 建立了WebSocket连接 *，则端点应发送带有适当状态代码的关闭帧（第7.4节）在继续 * 关闭WebSocket连接 * 之前。如果端点认为另一端不太可能接收和处理关闭帧，则可以省略发送关闭帧，由于导致WebSocket连接首先失败的错误的性质。在被指示 * 使WebSocket连接失败 * 之后，端点不得继续尝试处理来自远程端点的数据（包括响应的Close帧）。
如果一开始就没有建立连接（没有HTTP升级），它可能不会被触发。
结论如下：确实有可能error在没有close的情况下被触发，你可以通过打开Dev Tools（F12）在the datatracker.ietf.org website上测试它，并在控制台中运行：

try
{
    var ws = new WebSocket('wss://blabla');
    ws.onopen = () => console.log('ws open');
    ws.onerror = () => console.log('ws error');
    ws.onclose = () => console.log('ws close');
}
catch(err)
{
    console.log('new WebSocket error (bad url?)');
}

字符串
它只报告ws error和一条抱怨内容安全策略配置的消息。因此不会触发close事件。
这对于处理自动重新连接等问题来说有点烦人。特别是因为你也不能检查readyState，这在每种情况下都表示WebSocket.CLOSED（3）。任何解决方案都需要一个标志来指示已经调用了回调，或者在error事件处理程序中，你需要从close中删除回调以防止双重回调。