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