必须全局单例复用ConnectionMultiplexer，禁用每次new或Scoped注入；初始化须异步+延迟加载+显式超时（connectTimeout=5000、syncTimeout=5000、abortConnect=false、keepAlive=30）；IDatabase按需获取，无需缓存。
必须用 ConnectionMultiplexer 单例，不能每次 new，也不能塞进 Scoped 生命周期的服务里——否则连接耗尽、超时、重连风暴全都会来。
ConnectionMultiplexer 初始化必须异步 + 延迟加载
同步调用 ConnectionMultiplexer.Connect() 在 DNS 解析慢、端口不通或 Redis 暂不可达时，会卡死默认 5 秒（实际是 connectTimeout=5000），Web 应用启动阶段极易引发线程池饥饿甚至 hang 住。这不是“偶尔慢”，而是确定性阻塞。
- 用
Lazy<ConnectionMultiplexer>延迟初始化，避免静态构造函数阻塞进程启动 - 别信
ConnectAsync()就万事大吉——它只是帮你异步建连，但你仍得在 DI 容器或启动逻辑里控制好生命周期 - Docker 或云环境务必把
localhost换成真实服务名（如redis:6379），并确认容器网络互通、防火墙放行 6379 端口
连接字符串关键参数一个都不能少
只写 "localhost:6379" 是生产事故的起点。默认行为在故障场景下过于激进：AbortOnConnectFail=true（已弃用别名，等价于 abortConnect=true）会让应用启动直接失败；没设 keepAlive，NAT 设备或云负载均衡器可能静默断开空闲连接。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
abortConnect=false：首次连不上不抛异常，后台持续重试 -
connectTimeout=5000：太短易失败（尤其跨网络），太长拖慢启动 -
syncTimeout=5000：同步操作上限，防止阻塞线程池（注意：不是所有地方都能用同步 API） -
keepAlive=30：每 30 秒发一次保活包，防中间设备断连 - 若 Redis 启用密码，必须加
password=xxx，且不能放在 URL 形式里（如redis://:pwd@host:6379），StackExchange.Redis 不支持这种解析
IDatabase 不是连接，别缓存它
IDatabase 是轻量无状态的“命令视图”，每次调用 conn.GetDatabase() 都返回新实例，但底层复用同一个连接池。很多人误以为要把它也单例化或注入为 Scoped 服务，结果要么错用 db index（GetDatabase(0) vs GetDatabase(1)），要么在连接重建后持有已失效的引用。
- Web API 中，每次请求内按需调用
Connection.GetDatabase(db: int?)，无需缓存 - 不要把
IDatabase存在静态字段、Scoped 服务或 HttpContext.Items 里长期复用 - 若需指定数据库编号，显式传参，例如
conn.GetDatabase(1)，别依赖默认 db=0
连接泄漏和重连失败怎么发现
连接池耗尽最典型的表现是 SocketException（连接数超限）、TimeoutException（大量 pending 连接）、或者日志里反复刷 Connection failed 却没自动恢复。这不是代码写错了，而是没监听重连事件或没配置保活。
- 监听
ConnectionFailed和ConnectionRestored事件，打日志或发告警，别让它静默失败 - 定期调用
Connection.GetStatus()查看当前连接状态（开发/调试用，别放线上高频路径） - 检查进程 socket 数：Linux 下
lsof -p <pid> | grep :6379 | wc -l，持续上涨就说明连接没被复用或没正确释放 - 别手动调用
CloseAsync()关闭ConnectionMultiplexer——进程退出时 OS 自动回收；强行关可能中断正在执行的 pipeline 或 pub/sub
真正难的不是写对第一行 ConnectionMultiplexer.Connect，而是确保它在整个应用生命周期里不被重复创建、不被意外 dispose、不因配置缺失在故障时彻底失联。这些点藏在参数细节和生命周期认知里，而不是语法糖上。
