sigusr1最适合配置热加载，因它是posix标准预留的用户自定义信号，systemd等环境不占用，macos兼容性好，且仅触发配置重载而不中断连接；需早期注册、非阻塞处理、并发安全更新与零侵入生效。
用 SIGUSR1 实现配置热加载，核心是让进程在运行中响应信号、安全加载新配置，且不中断已有请求。它不是“重启服务”，而是“换配置不换命”。
为什么选 SIGUSR1 而不是其他信号
SIGUSR1 是 POSIX 标准明确保留给用户自定义用途的信号，系统和主流工具（如 systemd、supervisord、k8s）一般不会占用它。相比之下：
- SIGHUP 虽常用于重载（如 Nginx），但某些服务（如 PostgreSQL、旧版 Redis）直接忽略，或被 systemd 用于 reload 指令，语义易混淆；
- SIGUSR2 在多数生产环境（尤其是 systemd 管理的服务）中已被约定为“平滑重启”信号，若用它做配置重载，容易与运维脚本冲突；
- macOS 对 SIGUSR2 支持不完整，kill -USR2 可能报 operation not permitted，而 SIGUSR1 兼容性稳定。
关键实现步骤
热加载成败不取决于信号本身，而在于信号处理逻辑是否轻量、原子、无侵入：
-
早期注册信号监听：在 main() 开头就调用
signal.Notify(sigChan, syscall.SIGUSR1)，避免启动后漏收； - Handler 必须非阻塞：禁止同步读文件、直连数据库、调用无 timeout 的 HTTP 请求——推荐先触发 goroutine 异步加载，或用带超时的 io.ReadFull + atomic.Value 替换配置；
-
配置变量需并发安全：用
sync.RWMutex保护读写，或更优地使用atomic.Value存储整个配置结构体，reload 时Store(newConfig)，各 handler 用Load().(*Config)获取当前快照； -
不碰连接生命周期：热加载只刷新配置数据，绝不调
srv.Shutdown()、不 close listener、不中断正在执行的 HTTP handler。
如何验证和避免典型踩坑
常见失效不是信号没收到，而是 reload 后行为异常：
-
指针替换导致竞态：全局 config 指针被直接赋值
config = newConfig，但某个 handler 正在用旧 config 做鉴权，可能 panic 或返回错误响应——应确保所有读取都通过原子读取接口； -
未校验配置合法性：新配置语法错误或字段缺失，导致后续请求崩溃——建议在 reload 前先做
validate()，失败则跳过更新并记录 error 日志； - 忘记重置依赖状态：比如日志级别变了，但 logrus 实例未同步更新；限流器阈值变了，但旧 limiter 对象还在计数——reload 逻辑需显式重建或重置相关组件；
-
测试方式简单有效：启动服务后记下 PID，执行
kill -USR1 $PID，观察日志是否输出 “config reloaded”，再发请求验证新配置（如改了日志等级，看后续日志是否按新级别输出）。
