失败回调会再连三次

类的默认项里 maxRetries 是 3，retryDelay 是 3000，超时 30000。connect 里 uni.request 的失败回调打印错误、发出 error，然后 reconnect。重连先看次数。已经达到最大次数就发出 maxRetries 并返回。否则次数加一，延迟之后再 connect。一次失败会再排下一次，直到三次。

解析错误并没有去调用重连

回答说三次是因为数据块不是标准格式，解析失败才重试。类里处理数据块的 catch 只打印并 emit('error')，没有调用 reconnect。解析出问题不会按这段代码再连。会再连的是请求的 fail，以及定时器里「还没有 connected」时的 close 再 reconnect。

success 里才把 connected 设为真，并把重试次数清零。这个成功回调要等这次请求结束。流若一直开着，成功不会早到。连接超时的定时器用的是 30000。在此之前若失败回调已经触发，重连按 3 秒一次往上加，三次之后停。用户看到的三次，和 maxRetries: 3 是同一个数。

同一份示例里，前面的请求用 enableChunked 和 onChunkReceived。类里监听的是 onChunkedData。名字不同，分块不会进 processChunk。没有分块时，请求要么整段结束进 success，要么进 fail。进了 fail 就按上面的次数重连。类的 uni.request 这一段没有写 enableChunked。分块开关不在，回调名字也不对，生成按钮每次点击都会把一次失败变成最多三次重连。

成功要等整次结束

心跳在 success 里才启动。失败的那几次不会被心跳保住。complete 只把连接定时器置空，不改变重试次数。所以三次来自 reconnect 里的计数，不是来自解析函数。

后来的解析把不合法的 JSON 收成警告，仍不调用重连。这能避免解析抛错，改变不了 fail 里已经写上的重连。

要点一次只发一次请求，失败回调里就不要按默认的三次再连。分块要用请求上真实存在的回调，并打开分块。解析失败和重新连接是两条路径，不要写在同一次点击里。