go-redis 调用 WithTimeout 后，命令监控 hook 消失

Redis 命令继续执行，但给客户端加了 WithTimeout() 后，部分链路追踪、指标或命令审计突然消失。原客户端仍有记录，派生客户端直接注册的新 hook 也有记录时，应核对它是否继承了原来的命令 hook 链。

正式 go-redis v9.23.0 存在这条具体路径：WithTimeout 经由 baseClient.clone 派生客户端，复制了连接池和其他状态，却没有复制 hooksMixin。随后初始化的命令处理链因而缺少父客户端已经注册的 hook。

这里讨论 redis.Client.WithTimeout，不是 context.WithTimeout。后者派生的是 Go context，不会因为名字相似就触发同一个客户端克隆问题。

先分清漏的是哪一类 hook

受影响的是父客户端已有的 ProcessHook 和 ProcessPipelineHook。普通命令、pipeline 与事务 pipeline 都应分别核对，不能只看一次 PING 是否被记录。

保留 hook 的注册时刻和客户端的派生顺序。父客户端后来新增的 hook 是否应自动传播到已有派生对象，是另一项语义；不能把所有客户端强行共享同一个可变链来补记录。

如果原始 hook 已经执行，只是导出平台没有显示，应继续检查采样、导出和查询条件。若异常发生在拨号阶段，也要单独核对 DialHook；这条缺失不能证明共享连接池的拨号 hook 会随派生客户端独立重建。

在派生客户端上明确安装所需命令 hook

暂时仍使用 v9.23.0 时，可以在创建派生客户端的集中入口明确安装它所需的命令 hook。以下是已有函数中的配置片段：

timed := client.WithTimeout(2 * time.Second)
timed.AddHook(commandHook)

片段需要导入 time；client 是应用已有的 *redis.Client，commandHook 是符合 redis.Hook 的既有实现。hook 若包含计数器或其他可变状态，必须满足应用并发调用的要求，不能仅为共享记录就传入一个不安全的实例。

把安装动作放在客户端创建阶段，不要每执行一条命令就再 AddHook。还要核对所选版本的行为：将来客户端若已继承原链，继续无条件重复安装同一个功能，可能生成两份记录或重复拦截。

派生客户端会复用底层池状态。不要为了重建 hook，在请求结束时随手关闭共享客户端，也不要以为每个 WithTimeout 都创建了一组完全独立的连接。

更新时检查克隆，而不只看版本号

采用其他正式版本时，确认 baseClient.clone 确实保留了所需 hook 快照，并由派生客户端重新组装命令链。问题关闭或补丁合并不等于已发布的 v9.23.0 改变了；这个版本的正式源码仍缺少相应复制。

v9.23.0 要求 Go 1.26。任何依赖调整都应同时核对工具链、现有插桩及 Redis 客户端配置，不为补回一项监控而修改认证或 TLS。

验收分别让父客户端与派生客户端执行普通命令、pipeline 和事务 pipeline，确认记录各出现一次、超时配置没有串到父客户端，并核对 hook 所需的上下文。漏记录期间已经完成的写入不会因补上 hook 自动重新生成审计数据，也不能为了补日志重跑业务写入。