测试中发信号应启动独立子进程而非直接调用 syscall.Kill；需用 os/exec 启动被测二进制，通过 cmd.Process.Signal 发信号，并用 channel 或 WaitGroup 同步代替 time.Sleep；signal.Notify 的 channel 必须显式 signal.Stop 关闭以防 goroutine 泄漏。
用
启动子进程发信号最可靠
直接在测试里调用
或
很容易干扰测试进程自身，尤其并发跑时信号可能误杀测试主 goroutine。真实场景里信号是外部发给目标进程的，测试也该模拟这个路径。
实操建议：
写一个极简的被测二进制（比如只监听
并打印 "got signal"），用
编译
测试中用
启动它，拿到
启动后稍等（如
）确保它已进入信号等待状态
用
发信号，再检查 stdout 是否含预期输出
的 channel 必须手动关闭，否则 goroutine 泄漏
很多人在测试里这么写：
，但忘了在测试结束前调用
。这会导致 notify goroutine 一直挂着，下次测试可能收到上一轮残留信号。
正确做法：
立即学习
“
go语言免费学习笔记（深入）
”；
测试函数末尾加
如果用
（Go 1.16+），注意它的 context cancel 不会自动 stop notify，仍需显式调用
避免在全局变量或 init 函数里调用
，测试间状态难隔离
别用
等信号到达，改用同步 channel 或
常见错误：启动信号监听 goroutine 后，
就认为信号已处理完。实际执行时间受调度影响，CI 环境常超时或漏判。
更稳的方式：
定义一个
，在信号处理逻辑最后写
测试里用
若处理逻辑涉及多 goroutine 协作，用
计数比 sleep 更精确
Linux 和 macOS 对
、
行为不一致
Go 运行时默认忽略
，但某些场景（如管道写入已关闭的 fd）下，macOS 可能仍抛出
，而 Linux 不会。这会让跨平台测试失败。
应对策略：
测试信号逻辑时，优先选
、
这类用户自定义信号，它们行为最一致
若必须测
或
，在 CI 中固定用 Linux 容器（如
），避免混用 macOS runner
不要依赖
在所有平台都等于
—— Windows 下它是
的特殊值，不是真实信号
信号处理测试真正难的不是发信号，而是让被测代码和测试代码的生命周期彻底解耦。channel 关闭时机、goroutine 清理、跨平台信号语义差异——这些地方一松懈，测试就变成随机通过的玄学。
os/execsyscall.Killprocess.SignalSIGINTgo build -o testbin main.goos/exec.Command("./testbin")*os.Processtime.Sleep(100 * time.Millisecond)cmd.Process.Signal(syscall.SIGINT)signal.NotifysigChan := make(chan os.Signal, 1); signal.Notify(sigChan, syscall.SIGTERM)signal.Stop(sigChan)defer signal.Stop(sigChan)signal.NotifyContextsignal.Stopsignal.Notifytime.Sleepsync.WaitGrouptime.Sleep(50 * time.Millisecond)done := make(chan struct{})done select { case sync.WaitGroupSIGPIPESIGQUITSIGPIPEsignal: broken pipeSIGUSR1SIGUSR2SIGHUPSIGTERMgolang:1.22-alpineos.InterruptSIGINTos.Signal