Node.js ERR_SOCKET_CANNOT_SEND错误引发服务崩溃求助

• 触发崩溃的核心诱因来自UDP发送逻辑的资源泄漏：你当前的实现逻辑是，每给1个目标发1条UDP消息，就调用dgram.createSocket('udp4')新建1个临时套接字，发完之后从来没主动调用socket.close()释放资源。这类泄漏的套接字会一直占用进程的文件描述符（FD），等FD数摸到系统给单进程设的上限时，哪怕网络连通性完全正常，内核也没法给新的发送请求分配套接字资源，直接抛出ERR_SOCKET_CANNOT_SEND。这个现象和你描述的“稳定跑几千条消息才崩、重启后临时恢复”的特征完全匹配——重启操作会把所有残留的、泄漏的套接字占用的FD全部释放，自然能临时恢复运行。
• 直接把进程打崩的触发点：新建的临时UDP套接字根本没绑error事件监听器。按Node.js的事件机制规则，所有EventEmitter实例只要触发error事件时没有对应监听器，就会直接抛未捕获异常，终止整个进程。就算FD没耗光，某次发送碰到内核临时缓冲区满、目标端口临时不可达触发error事件，没有监听器兜底就直接崩。
• 顺带提两个迟早要踩的坑：当前Kafka消费的async消息回调没有全局异常捕获，如果transformationService处理逻辑抛了没接住的Promise rejection，一样会造成进程退出；现在的启动逻辑只在init().then(startConsumer)的初始化链路上加了catch，完全覆盖不到运行阶段异步逻辑的未捕获错误，等于运行期根本没有错误兜底能力。

• 彻底换掉“每次发消息都新建套接字”的写法：改成全局单例复用1个UDP套接字——本来UDP就是无连接协议，根本不需要为每个发送动作、每个目标地址单独开套接字。服务启动时初始化一次套接字实例，整个进程生命周期反复用，从根源上避免FD泄漏。
• 给复用的UDP套接字补全事件监听：至少要绑error事件的处理逻辑，把发送错误记到日志就行，别让单点异常把整个服务拖崩。
• 补全运行期的全局错误兜底：给unhandledRejection、uncaughtException事件加日志记录逻辑，把这类异常接住打日志，不要直接终止进程。
• 快速验证方法：下次服务快崩的时候登服务器，执行ls /proc/<你的Node进程PID>/fd | wc -l，数一下当前进程占了多少FD，这个数值会远高于正常服务的FD占用量，直接就能实锤泄漏问题。

// 全局单例初始化UDP套接字，仅在服务启动时执行一次
const udpSocket = dgram.createSocket('udp4');
// 必须绑定error监听，从根源避免未捕获异常崩溃
udpSocket.on('error', (err) => {
    logger.error('UDP套接字运行异常', err);
});

const udpSender = (msg, destinations) => {
    // 直接复用全局套接字发送，不再每次新建实例
    return Object.values(destinations)
        .map(({id, host, port}) => {
            return new Promise((resolve) => {
                udpSocket.send(msg, 0, msg.length, port, host, (err) => {
                    resolve({
                        id,
                        timestamp: Date.now(),
                        logs: err?.message || 'Sent succesfully',
                    });
                });
            });
        });
};

注意：如果业务需要套接字绑定固定本地端口，全局初始化的时候调用一次udpSocket.bind(你要绑定的本地端口)就行，不用每次发送都重复初始化。

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