因为 go-redis/v9 的 PubSub 不自动重连，网络抖动或 Redis 重启会导致 *redis.PubSub 实例永久失效，ReceiveMessage 持续阻塞或 panic；且需手动处理 JSON 解析异常、并发注册冲突、频道命名隔离、消息追踪等生产级问题。
为什么不能直接用 redis.PubSub 长期监听任务？
Go 官方 redis 客户端（如 github.com/go-redis/redis/v9）的 PubSub 接口本身不自动重连，一旦网络抖动或 Redis 重启，Subscribe 返回的 *redis.PubSub 实例就永久失效，后续 ReceiveMessage 会持续阻塞或 panic。这不是 bug，而是设计使然——它只负责单次连接生命周期内的消息流转。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须自己封装重连逻辑：监听
pubsub.Channel().Err()，捕获redis.Nil或网络错误后，关闭旧实例、新建客户端、重新Subscribe - 避免在
for range pubsub.Channel()循环里直接处理耗时任务，否则会阻塞接收新消息；应把msg.Payload发到一个带缓冲的chan string中异步处理 - 订阅前确认 Redis 配置未禁用
PUBSUB命令（某些云 Redis 服务默认关闭）
json.Unmarshal 解析任务结构体时常见 panic 场景
任务消息通常是 JSON 字符串，但生产环境里你大概率会遇到字段缺失、类型错位（比如后端发了 "timeout": "30s"，而结构体定义为 Timeout time.Duration）、或空字符串被反序列化进非空字段等问题，导致 json.Unmarshal 直接 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义任务结构体时，所有字段加
json:",omitempty"标签，并用指针类型（如*string、*int64）接收可选字段 - 不要依赖
json.Unmarshal的返回值“一定成功”，始终用if err != nil判断，失败时记录完整msg.Payload和错误，然后continue跳过该条消息 - 对关键字段（如
JobID、HandlerName）做二次校验，例如if msg.JobID == "" { log.Warn("empty JobID"); continue }
如何安全地注册多个 Handler 并防止并发冲突？
调度器需支持动态注册不同任务类型的处理函数（如 "send_email"、"cleanup_cache"），但如果用全局 map 存储 handler，又没加锁，在热更新或高并发注册时极易引发 panic: concurrent map writes。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.RWMutex包裹 handler 注册/查找逻辑，读多写少场景下性能影响极小 - 注册时检查重复：若已存在同名 handler，直接返回 error，不覆盖——避免线上误覆盖导致任务静默失败
- handler 函数签名统一为
func(context.Context, []byte) error，传入原始 payload，由 handler 内部决定是否再次json.Unmarshal，解耦调度层与业务解析逻辑 - 调用 handler 前，用
context.WithTimeout包一层，超时后主动 cancel，防止某个 handler 卡死拖垮整个调度器
Redis 订阅频道名要不要加前缀？加什么？
直接用 "task" 这类裸名称订阅，在多环境（dev/staging/prod）共用一套 Redis 时必然冲突；用 "task:prod" 又不够灵活——比如灰度发布时想让部分实例只收 "task:prod:canary" 消息。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 频道名格式固定为
"{env}:{service}:task"，例如"prod:scheduler:task"，其中env和service从配置文件或环境变量读取，硬编码前缀反而难维护 - 避免使用通配符订阅（
PSUBSCRIBE task.*），因为go-redis/v9的PubSub不支持通配符 channel 的ReceiveMessage，只能用Receive+ 类型断言，代码更脆弱 - 如果真需要灰度能力，改用「任务消息内嵌 target 字段」+ handler 过滤，比依赖 Redis 频道分组更可控
真正麻烦的不是怎么连上 Redis 或怎么解包 JSON，而是当某条任务因 handler panic 而丢失时，你得能快速定位是解析错了、还是 handler 里访问了未初始化的 DB 连接池——所以每条消息的 trace_id 必须从发布端透传，且在日志里强制打全。
