go runtime信号处理由底层硬编码接管，无法被用户代码解析或模拟；signal.notify仅对未被runtime屏蔽的信号（如sigusr1、sigint、sigterm）有效，而sigquit、sigsegv等由runtime强制处理且不可捕获。
Go 的 runtime 信号处理不是靠用户代码“解析”出来的，而是由 runtime 自行接管、屏蔽或转发——你无法也不应试图用“语言学习思路”去反向推导或模拟它的行为。
为什么不能在 Go 中“解析” runtime 的信号处理逻辑
Go 运行时对信号（如 SIGUSR1、SIGQUIT、SIGPROF）的处理是硬编码在 runtime/signal_unix.go（Linux/macOS）或 runtime/signal_windows.go（Windows）中的，且依赖于：
-
sigtramp汇编桩和sigfwd转发机制 - 线程本地信号掩码（
pthread_sigmask）的精细控制 - 与
g（goroutine）调度器深度耦合的信号 delivery 路径（例如SIGURG触发 netpoll 唤醒）
这意味着：你写的 Go 代码根本收不到被 runtime 抢占的信号；即使调用 signal.Notify，也只对未被 runtime 显式屏蔽/接管的信号生效（比如 SIGUSR2）。
signal.Notify 只能捕获 runtime 允许转发的信号
Go 默认屏蔽了多数系统信号，仅将部分信号转发给用户 handler。常见可捕获信号包括：
-
SIGUSR1和SIGUSR2：始终可被signal.Notify捕获（除非被runtime.LockOSThread后手动屏蔽） -
SIGHUP、SIGINT、SIGTERM：默认可捕获，但若进程已启用了os/signal的默认 handler（如go run时 Ctrl+C），则可能被 runtime 提前终止 -
SIGQUIT：默认触发 stack trace 并退出，signal.Notify无法覆盖——这是 runtime 强制行为
错误示例：
ch := make(chan os.Signal, 1) signal.Notify(ch, syscall.SIGQUIT) // 不会收到任何值，SIGQUIT 被 runtime 直接 consume
正确做法：如果需要自定义中断逻辑，用 SIGINT 或 SIGTERM，并确保主 goroutine 不退出过早。
调试 runtime 信号行为的真实路径是看源码 + strace
想确认某个信号是否被 runtime 接管？不要猜，直接查：
- 定位信号注册点：
runtime/signal_unix.go中的setsig和sigignore调用 - 查看哪些信号被设为
SIG_DFL（默认行为）、SIG_IGN（忽略）或sigtramp（runtime 处理） - 用
strace -e trace=rt_sigaction,rt_sigprocmask ./your-binary观察实际系统调用——你会看到 runtime 在启动时批量设置信号 handler 和 mask
例如：rt_sigaction(SIGQUIT, {sa_handler=0x49d8a0, ...}, NULL, 8) 中的 0x49d8a0 是 runtime 内部的 sigtramp 地址，而非你的 handler。
真正可控的信号交互只有两个出口
你在 Go 程序中能安全、稳定干预信号的路径只有两条：
- 用
signal.Notify+select响应白名单信号（SIGUSR1,SIGINT,SIGTERM等），并配合signal.Reset恢复默认行为（如需） - 通过
runtime.LockOSThread+syscall.PthreadSigmask手动操作当前 OS 线程的信号掩码——但这绕过了 runtime 管理，极易导致死锁或调度异常，仅限极少数场景（如 CGO 调用阻塞库）
所有试图“解析”或“模拟” runtime 信号分发逻辑的尝试，都会撞上 runtime 对 M/G/P 模型的私有状态封装——它不提供反射接口，也不开放 signal delivery 队列。
信号不是 API，是契约：runtime 定义了哪些信号归它管、哪些放行、哪些禁止碰。看清这个边界，比任何“学习思路”都关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
