signal.stop仅从signal.notify的接收器列表中移除指定chan，不改变信号默认行为；需配合signal.reset恢复默认处理，或用signal.ignore静默丢弃。
signal.Stop 为什么调用后还收不到信号？
signal.Stop 不是“关闭信号监听”，而是从 signal.Notify 的接收器列表中移除指定的 chan。它本身不改变进程对信号的默认行为，也不影响其他 channel 的监听状态。
常见误解：以为调用 signal.Stop 就能让进程不再响应 SIGINT 或 SIGTERM —— 实际上，只要没显式调用 signal.Ignore 或没被系统默认终止，信号依然会触发默认行为（比如终止程序）。
- 必须先用
signal.Notify注册过该 channel，signal.Stop才有效；否则无任何作用 - 多个 goroutine 同时对同一 channel 调用
signal.Notify，signal.Stop只移除最后一次注册的关联，不是全部 - 如果 channel 已关闭，再调用
signal.Stop不报错但无效
如何真正停止监听并恢复默认信号行为？
想让某个信号回归系统默认处理（如 SIGINT 退出进程），不能只靠 signal.Stop，得配合 signal.Ignore 或直接撤销通知注册并确保 channel 不再接收。
典型安全做法是：先 signal.Stop 移除 channel 监听，再用 signal.Reset 恢复该信号的默认动作（比如终止）。注意 signal.Reset 会清除所有对该信号的 Notify 关联，并重置为 OS 默认行为。
-
signal.Reset(os.Interrupt)比signal.Stop更接近“停止监听+恢复默认”的意图 - 若只调用了
signal.Notify(ch, os.Interrupt)，之后调signal.Reset(os.Interrupt)即可彻底交还控制权给系统 -
signal.Ignore是另一种选择，但它会让信号被静默丢弃（不终止、不通知），和默认行为不同
signal.Stop 在多 channel 场景下容易踩的坑
当多个 channel 同时监听同一个信号（例如两个 goroutine 都调 signal.Notify(ch1, syscall.SIGUSR1) 和 signal.Notify(ch2, syscall.SIGUSR1)），signal.Stop 只对传入的那个 channel 生效，不影响另一个。
这意味着：即使你 stop 了 ch1，ch2 仍会继续收到 SIGUSR1；而如果你在 ch1 上已 close，又对它重复调 signal.Stop，不会出错但也没效果。
- 每个
signal.Notify调用都独立注册，signal.Stop是按 channel 值匹配，不是按信号类型 - channel 是值传递，所以用指针或全局变量管理 channel 引用时要格外小心是否指向同一个实例
- 没有 API 能列出当前所有被 Notify 的 channel，调试时建议用唯一命名 channel 或加日志辅助追踪
一个可靠释放信号监听的惯用写法
实际项目中，推荐把 signal 监听封装成可取消结构，避免裸调 signal.Stop 后遗漏清理：
type SignalWatcher struct {
ch chan os.Signal
sig os.Signal
}
func (w *SignalWatcher) Start() {
signal.Notify(w.ch, w.sig)
}
func (w *SignalWatcher) Stop() {
signal.Stop(w.ch)
close(w.ch)
}
关键点在于：stop 后立刻 close(w.ch)，防止后续 goroutine 往已停 channel 发送信号导致 panic；同时确保 Start 和 Stop 成对出现，且不要重复 Start 同一 watcher。
真正麻烦的从来不是调用 signal.Stop 这一行代码，而是搞清它到底在哪个注册上下文中起作用、有没有其他 goroutine 还拿着同一信号的另一条 channel 在监听。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
