ConnectionMultiplexer 是单例，不是每次 new
StackExchange.Redis 的核心是
ConnectionMultiplexer，它本身线程安全、内置连接池和自动重连，**必须全局复用一个实例**。多次
new ConnectionMultiplexer会导致 socket 耗尽、TIME_WAIT 暴涨、CPU 升高，甚至 Redis 服务端拒绝新连接。
常见错误是把
ConnectionMultiplexer塞进
using或注入为 Scoped 服务——这等于每请求建一次连接，完全违背设计初衷。 ASP.NET Core 中应注册为
Singleton：用
services.AddSingleton<iconnectionmultiplexer>(sp => ConnectionMultiplexer.Connect(configuration))</iconnectionmultiplexer>连接字符串里加
abortConnect=false，避免启动失败直接崩掉进程；加
connectTimeout=5000和
syncTimeout=5000防止阻塞过久 监听
ConnectionFailed和
InternalError事件，但别在里面做重连逻辑（multiplexer 自己会重试），适合打日志或触发告警
Database 实例可随意获取，无需缓存
IDatabase是轻量级句柄，不持有连接，每次调用
connection.GetDatabase()都是 O(1) 开销。没必要把它存成字段或缓存起来——反而容易在多库（如 db0/db1）场景下搞混上下文。
注意：如果用了
defaultDatabase参数（比如
GetDatabase(1)），它只影响后续命令的默认 db 编号，不会改变底层 multiplexer 行为。 并发读写时，多个线程共用同一个
IDatabase实例完全安全 若需事务（
ITransaction）或管道（
IBatch），才需要显式创建新上下文，且必须在同一线程内完成提交 避免在异步方法中把
IDatabase当闭包变量长期持有——没坏处，但无意义
异步 API 必须用 async/await，别用 .Result 或 .Wait()
StackExchange.Redis 的所有
*Async方法（如
StringGetAsync、
HashSetAsync）底层基于
ValueTask，**同步等待（
.Result/
.Wait()）极易引发死锁**，尤其在 ASP.NET Core 同步上下文受限环境里。
典型现象：接口偶尔卡住、线程池饥饿、请求堆积。这不是 Redis 慢，是线程被自己锁死了。
Controller 或 Service 方法标记async Task<t></t>，调用链全程
await不要用
Task.Run(() => db.StringGetAsync(...)).Result—— 这只是把死锁换个地方发生 极少数无法改 async 的旧代码（如某些 Filter），可用
db.StringGet(key)同步版本，但它会阻塞线程，仅限低频、超短耗时场景
高并发下注意 CommandFlags 和连接负载均衡
默认情况下，所有命令都走主节点（即使你配了哨兵或集群）。遇到读多写少场景，可以利用
CommandFlags把只读命令发到从节点，减轻主节点压力：
await db.StringGetAsync("key", CommandFlags.DemandSlave);
但这有前提：Redis 配置了
slave-read-only yes，且 multiplexer 连接字符串里启用了
allowAdmin=true（仅开发/测试环境建议开启，生产慎用）。 集群模式（Cluster）下，
DemandSlave不生效，路由由 key hash 决定，无法手动指定节点 连接数瓶颈时，优先检查是否误用了
SyncTimeout过小（导致频繁超时重试）或
AbortOnConnectFail=false未设（启动失败静默） 用
IServer.ClientList()在 Redis CLI 查当前连接数，确认是否真由客户端连接爆炸引起，而非服务端配置限制 真正难处理的，是跨多个 Redis 实例做分布式锁或事务协调时，
ConnectionMultiplexer的健康状态感知和故障转移延迟——它不会主动通知你“这个节点已永久失联”，得靠你结合
IsConnected、
GetStatus()和业务超时做兜底。
