最稳妥方案是全局忽略 SIGPIPE，因调试器会优先拦截导致中断，且 try/catch 无效；需在 gdb 中执行 handle SIGPIPE nostop noprint pass，并在 main 开头用 sigaction() 设置 SIG_IGN。
直接忽略 SIGPIPE 是最稳妥的方案，否则调试器会中断、进程会退出，且无法用 try/catch 捕获。
为什么 gdb 会停在 SIGPIPE 上
gdb 默认会拦截所有信号，包括 SIGPIPE，并暂停执行——哪怕你代码里已调用 signal(SIGPIPE, SIG_IGN)。这不是你的程序没生效，而是调试器“抢先一步”把信号截住了。
- 现象：
write()或send()返回 -1 且errno == EPIPE前，gdb 就弹出Program received signal SIGPIPE - 根本原因：gdb 的信号处理优先级高于进程自身的
sigaction设置 - 注意：
try/catch完全无效，因为SIGPIPE是同步信号，不是 C++ 异常
gdb 中临时禁用 SIGPIPE 中断
启动 gdb 后、运行程序前，执行以下命令：
handle SIGPIPE nostop noprint pass
这四层含义必须同时设置：
TikTok Creator Pipeline
下载
TikHub API 多平台数据爬取工具，支持抖音/TikTok/B站等。用户提及以下需求时调用：1) 爬取视频或评论；2) 获取用户信息/粉丝列表；3) 批量下载无水印视频；4) 抖音链接转文字（下载→音频→Whisper pipeline）；5) 调用 TikHubAPI。
立即学习“C++免费学习笔记（深入）”；
-
nostop：不暂停执行 -
noprint：不打印 “Received signal…” 提示 -
pass：把信号转发给被调试进程（让它走SIG_IGN路径） - 缺一不可；只写
handle SIGPIPE ignore会导致信号被 gdb 吞掉，进程收不到，write()仍会阻塞或返回 -1 但errno可能不对
代码中仍需全局忽略 SIGPIPE
仅靠 gdb 设置不够——生产环境没调试器，必须在程序启动早期（最好在 main() 开头、任何 socket 创建前）设置：
struct sigaction sa; sa.sa_handler = SIG_IGN; sa.sa_flags = 0; sigemptyset(&sa.sa_mask); sigaction(SIGPIPE, &sa, nullptr);
- 必须用
sigaction()，signal()在多线程下行为不可靠 - 若用
libevent/epoll等异步库，也要确保主线程先完成该设置；pthread 环境下还需配合pthread_sigmask(SIG_BLOCK, &set, nullptr)防止信号发到错误线程 - 忽略后，
send()第二次向已关闭连接写入会返回 -1，errno设为EPIPE（不是SIGPIPE），这才是你该检查的错误分支
替代方案：用 MSG_NOSIGNAL 避免触发
如果只控制个别 send() 调用，可改用带标志的版本：
ssize_t n = send(sockfd, buf, len, MSG_NOSIGNAL);
- 效果等价于忽略
SIGPIPE，但作用域更小，不影响其他 socket 或线程 - 仅 Linux 支持；macOS 用
SO_NOSIGPIPEsetsockopt，Windows 不适用 - 不能替代全局忽略——比如
write()、printf()到管道、dup2()后的 fd 都可能触发，仍需兜底
真正容易被忽略的是：SIGPIPE 的默认动作是终止进程，而调试器的介入会让这个动作表现为“中断”，掩盖了它本质是进程级致命信号。屏蔽必须在信号产生前完成，且要同时覆盖调试与生产两套环境。
