signal.notify 不接受反射生成的 handler，因其签名严格要求 chan os.signal 类型通道或 signal 接口实现者，不支持函数值；反射无法构造合法信号接收器，且 go 运行时信号转发机制绕过反射调用路径。
Go 反射不能用于绑定系统信号处理函数——signal.Notify 要求传入的是 chan os.Signal 或实现了 Signal 接口的接收器，不接受反射构造的函数值，也无法用 reflect.Value.Call 替代信号注册逻辑。
为什么 signal.Notify 不接受反射生成的 handler
signal.Notify 的签名是 func(c chan，它只负责把操作系统信号转发到指定 channel；真正的“处理”必须由你从 channel 里 <code>range 或 显式读取并分发。你无法把一个 <code>reflect.Value 当作 handler 注册进去——它不是 func(os.Signal) 类型，也不满足任何接口契约。
常见误解是想用反射动态调用不同函数响应 SIGUSR1、SIGHUP 等，但实际路径只能是：信号 → channel → 字符串路由 → 显式函数映射。
- 反射无法绕过
signal.Notify的类型约束，传reflect.ValueOf(handler).Call(...)会编译失败 - 即使硬造一个
func(os.Signal)包裹反射调用，也违背了信号处理的低延迟、高确定性要求 - Go 运行时对信号处理有特殊调度（如
runtime.sigsend），反射介入会破坏信号语义一致性
正确做法：用 map[string]func() 做信号名到处理逻辑的静态映射
把信号名（如 "SIGUSR1"）作为 key，绑定预定义的无参函数，再在 channel 循环中查表调用。这样既安全又可测试，且零反射开销。
示例结构：
var signalHandlers = map[string]func(){
"SIGUSR1": func() { log.Println("reloading config...") },
"SIGHUP": func() { log.Println("rotating logs...") },
"SIGTERM": func() { shutdownGracefully() },
}
<p>c := make(chan os.Signal, 1)
signal.Notify(c, syscall.SIGUSR1, syscall.SIGHUP, syscall.SIGTERM)</p><p>for sig := range c {
name := sig.String() // 如 "syscall.SIGUSR1" → 需截取或映射
if h, ok := signalHandlers[name]; ok {
h()
} else {
log.Printf("unhandled signal: %s", name)
}
}</p>
- 注意
sig.String()返回的是"syscall.SIGUSR1"形式，不是纯"SIGUSR1"，需统一前缀处理或用syscall.Signal值做 key - 所有 handler 必须是包级导出函数或闭包，不能是未导出方法或匿名函数（否则反射也调不了，何况这里根本不用反射）
- 若 handler 需访问状态，应通过闭包捕获或传入全局变量，而非试图用反射“动态注入”
反射唯一可能的介入点：解析配置文件中的信号 handler 名称
仅当 handler 名称来自 YAML/JSON 配置（如 {"signal": "SIGUSR1", "handler": "reloadConfig"}），才需要反射做一次字符串到函数的查找——但这仍是静态绑定的延伸，且必须加严格校验。
- 必须预先注册所有合法 handler 名称到白名单 map，禁止任意字符串触发反射
- 反射调用前必须检查
value.Kind() == reflect.Func且value.CanCall()，否则 panic - handler 函数签名必须固定（如
func() error），不能依赖运行时推断 - 性能上，信号本身不高频，但滥用反射仍可能导致 SIGUSR1 触发后几十毫秒延迟，影响运维体验
真正容易被忽略的是：信号处理函数执行期间，Go runtime 会阻塞其他信号投递（除非用 signal.Ignore 或多 channel 分离）。无论是否用反射，都得确保 handler 是短时、无锁、不阻塞的——这点比“怎么调用”重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
