go运行时收到sigsegv等致命信号时直接崩溃退出，不走panic/recover流程，因其属os层硬中断，已被运行时接管且无法被signal.notify捕获或转为panic。
go 运行时不会把 sigsegv 转成 panic 后交由 recover 捕获——它直接触发运行时崩溃，打印 stack trace 并退出进程。这是底层机制决定的，不是配置或写法能绕过的。
为什么 SIGSEGV 不走 panic 流程
Go 的 SIGSEGV（段错误）是操作系统发给进程的致命信号，表示非法内存访问（如 nil 指针解引用、越界读写）。Go 运行时在收到该信号后，会立即中止当前 goroutine，并调用内部的 fatal error 处理路径，跳过所有 Go 层的 panic/recover 机制。
-
panic是 Go 语言层的控制流机制，用于显式错误传播；而SIGSEGV是 OS 层的硬中断，运行时无权“转成” panic，只能终止 - 即使你用
signal.Notify注册了syscall.SIGSEGV，也收不到——Go 运行时已提前接管并处理该信号，signal.Notify对其无效 - 试图用
recover捕获 nil 指针解引用等行为，永远失败；这类错误必须靠静态检查、测试或defer+recover在非致命 panic 场景中使用
signal.Notify 能监听哪些信号
signal.Notify 只对「可捕获且未被运行时独占」的信号有效。Go 运行时自己占用了 SIGSEGV、SIGBUS、SIGFPE、SIGPIPE 等，这些信号你注册了也收不到。
- 能安全监听的：
syscall.SIGINT、syscall.SIGTERM、syscall.SIGHUP、syscall.SIGUSR1、syscall.SIGUSR2 - 绝对不要注册：
syscall.SIGKILL（9号信号，OS 强制终止，不可捕获）、syscall.SIGSEGV（运行时已接管） - 注册空参数
signal.Notify(c)是危险操作：会监听所有可捕获信号，包括一些调试或平台相关信号（如SIGCHLD），导致行为不可预测
如何真正防御 SIGSEGV 类错误
既然无法拦截，就只能前置规避。这不是信号处理问题，而是内存安全问题。
- 启用
go build -gcflags="-d=checkptr"（仅开发期）：强制检查指针转换合法性，暴露潜在的unsafe误用 - 对所有外部输入做边界检查：切片访问前确认
len和cap，map 查找前用_, ok := m[k] - 避免裸用
unsafe.Pointer；若必须用，搭配//go:uintptr注释或通过reflect替代 - CI 中跑
go test -race和go run -gcflags="-d=checkptr"，把 segfault 风险卡在上线前
容易被忽略的关键点
很多人以为「加了 signal.Notify 就算做了信号处理」，但 SIGSEGV 根本不在这个体系里。它的存在提醒你：Go 的「优雅退出」只覆盖可控信号；真正的稳定性来自代码本身不触发致命信号——这比任何信号 handler 都重要。
