Electron+PeerJS文件传输报UDP send error35原因及修复方案

这个错误和Node.js文件读取逻辑、PeerJS上层业务代码没有关系，是Electron内置Chromium内核的WebRTC原生网络栈抛出的日志，判断依据如下：

• 日志中stun_port.cc是Chromium WebRTC实现STUN协议的源码文件，和Node.js fs模块、PeerJS的JS层逻辑完全无关。Electron主进程内置的WebRTC栈是原生编译模块，其报错会直接输出到启动应用的终端（即VS Code调试终端），不会经过JS层console封装，因此“日志出现在终端就和WebRTC无关”的判断不成立。
• 错误码35对应类Unix系统（macOS/Linux）非阻塞IO的EAGAIN返回值，含义是当前内核UDP发送缓冲区已满，暂时无法处理新的发送请求，属于网络IO临时拥塞的非致命提示——这也是文件传输功能全程正常、没有断连或文件损坏的根本原因，内核会在缓冲区排空后自动重试发送，不会丢包。
• 日志中显示发送失败的UDP包长度仅1237字节，远小于设置的512KB文件块，实际发送失败的是STUN打洞保活探测包，不是文件传输数据。触发报错的直接诱因是设置的单块传输体积过大，上层一次性向WebRTC栈塞入的数据量超过了底层UDP缓冲区的瞬时处理能力，文件数据包和STUN保活包排队时就会偶发触发缓冲区满的提示。

• 无感知场景可直接忽略：如果文件传输全程稳定、接收端文件哈希校验一致、没有出现连接意外断开的情况，这类日志属于Chromium的冗余调试输出，不会对业务功能造成任何实际影响，不处理也没有风险。
• 调整分块大小适配WebRTC传输特性：WebRTC基于SCTP的数据通道最优单块传输体积为16KB~64KB，不要使用512KB的大块配置，将分块参数修改为const chunkSize = 32 * 1024;即可大幅降低瞬时发送压力，从根源减少缓冲区拥塞的概率。
• 增加发送端流控逻辑：不要读取到文件块就立刻向数据通道写入，监听RTCDataChannel实例的bufferedamountlow事件，设置合理的缓存阈值（比如64KB），仅当通道内待发送缓存低于阈值时才读取下一个文件块发送，避免上层发送速率超过底层网络实际承载能力导致的缓冲区堆积。
• 纯日志隐藏方案：如果只是不想在终端看到这类报错，可以在启动Electron时添加环境变量ELECTRON_ENABLE_LOGGING=0屏蔽Chromium原生日志，或者在主进程启动早期过滤掉包含stun_port.cc关键字的stdout/stderr输出。注意该方案仅隐藏提示，不会解决底层瞬时拥塞问题，优先推荐调整分块和加流控的方案。

内容的提问来源于stack exchange，提问作者user3792705