go程序必须显式调用signal.ignore(syscall.sighup)才能忽略sighup，否则未注册时仍按默认行为终止进程；sighup常由终端断开或systemd触发，忽略后可防止意外退出。
Go 程序里想忽略某个信号（比如 SIGHUP），不能靠不注册就完事——不注册 ≠ 忽略，它可能触发默认行为（如进程退出）；必须显式调用 signal.Ignore。
为什么 signal.Notify 不填某个信号，它还是会被处理？
Go 进程启动后，未被 signal.Notify 捕获的信号仍走系统默认行为：SIGHUP、SIGINT、SIGTERM 默认终止进程，SIGQUIT 默认生成 core dump 并退出。你不注册 SIGHUP，不代表它消失——尤其在 systemd 或 nohup 启动时，SIGHUP 极易被发送并直接杀掉进程。
- 只注册
syscall.SIGINT和syscall.SIGTERM，但没理SIGHUP→ 进程可能被 nohup/shell 断开时意外退出 - 想让服务后台长期运行（如 daemon），必须显式忽略
SIGHUP，否则父 shell 退出后子进程收SIGHUP就挂了 -
signal.Ignore要在signal.Notify之前或之后调用都行，但必须在信号实际到达前生效（即 main 启动早期）
signal.Ignore 的正确写法和常见误用
忽略 SIGHUP 是最典型场景，写法简单但容易错：
signal.Ignore(syscall.SIGHUP)
- ✅ 正确：调用
signal.Ignore后，SIGHUP就彻底静默，不会中断进程，也不会进任何 channel - ❌ 错误：写成
signal.Ignore(os.Interrupt)——os.Interrupt是SIGINT别名，忽略它会导致 Ctrl+C 失效，通常不是你想要的 - ❌ 错误：在 goroutine 里调用
signal.Ignore，且该 goroutine 启动晚于信号到达时间 → 信号已按默认行为处理完毕，忽略失效 - ⚠️ 注意：
signal.Ignore和signal.Notify互斥：对同一信号，不能既Notify又Ignore，后者会覆盖前者
后台运行时，SIGHUP + SIGINT + SIGTERM 怎么分工？
真实部署中这三者常共存，职责要分清：
-
SIGHUP：通常来自终端断开或 systemd reload，应忽略（signal.Ignore(syscall.SIGHUP)），避免非预期退出 -
SIGINT：来自用户 Ctrl+C，适合开发调试时触发优雅关闭，可注册进通知 channel -
SIGTERM：来自kill $pid、Docker stop、k8s termination，是生产环境主退出信号，必须注册并响应 - 别漏掉
syscall.SIGQUIT（Ctrl+\）：它不常用于退出，但若没忽略/没注册，会触发 panic + core dump，线上应至少Ignore
忽略信号后，怎么验证它真的不生效了？
光写代码不验证等于没做。实操建议：
- 启动程序后，用
kill -HUP $pid测试：如果进程没退出、没日志、没 panic，说明SIGHUP已被成功忽略 - 用
ps -o pid,ppid,sig,comm $pid查看进程当前 signal mask（需 kernel 支持），或用strace -e trace=signal ./your-binary观察系统调用级信号接收情况 - 容器环境下重点测
docker stop：它发SIGTERM，不是SIGHUP，所以忽略SIGHUP不影响 shutdown 流程 - systemd 服务要加
KillSignal=SIGTERM和RestartPreventExitStatus=SIGUSR1类配置，避免和 Go 层信号逻辑冲突
真正麻烦的从来不是写一行 signal.Ignore，而是确认它在所有部署路径（nohup / systemd / k8s initContainer / docker run -d）下都稳稳生效——信号丢了不好 debug，但信号没被忽略导致进程莫名退出，更难定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
