StackExchange.Redis连接字符串应设超时、重连与保活，如"localhost:6379,connectTimeout=5000,syncTimeout=5000,abortConnect=false,keepAlive=30"；ConnectionMultiplexer须单例复用；优先用StringGet()而非GetStringAsync()以避免语义混淆。
StackExchange.Redis 连接字符串怎么写才有效
直接用 ConnectionMultiplexer.Connect("localhost:6379") 最常见，但生产环境必须加超时和重连控制。不设 connectTimeout 或 syncTimeout，一卡就是几秒；不配 abortConnect=false，启动时 Redis 暂不可用会导致整个应用初始化失败。
推荐写法：
var configuration = "localhost:6379,connectTimeout=5000,syncTimeout=5000,abortConnect=false,keepAlive=30";
-
abortConnect=false是关键：允许连接器后台自动重连，而不是抛异常中断 -
keepAlive=30防止 NAT 或防火墙断掉空闲连接 - 若 Redis 启用了密码，必须加
password=xxx，且不能放在 URL 里（会误解析）
ConnectionMultiplexer 是单例还是每次 new
必须单例复用 —— 它本身是线程安全的，内部维护连接池和订阅通道。每次 new ConnectionMultiplexer 或反复 Connect() 会快速耗尽 socket、触发 SocketException 或 TimeoutException。
正确姿势：
private static readonly Lazy<ConnectionMultiplexer> LazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
return ConnectionMultiplexer.Connect(configuration);
});
public static ConnectionMultiplexer Connection => LazyConnection.Value;
- 用
Lazy<t></t>延迟初始化，避免静态构造函数阻塞 - 不要在 Web API 的每个请求里 new 一个，也不要封装成 Scoped 服务（ASP.NET Core DI 默认 Scoped 生命周期太短）
- 应用退出前调用
Connection.CloseAsync()，但通常可忽略（进程结束时 OS 会回收）
IDatabase.Get 和 GetStringAsync 区别在哪
IDatabase.StringGet() 是底层通用方法，返回 RedisValue 类型；GetStringAsync() 是扩展方法，内部调用 StringGet() 后再做 .ToString() 转换 —— 看似方便，但有隐式风险。
- 如果键不存在，
StringGet()返回RedisValue.Null，而GetStringAsync()会返回null string，容易掩盖“空值存入”和“键不存在”的语义差异 - 如果存的是非 UTF-8 编码二进制数据（比如 Protobuf），
GetStringAsync()强转会乱码或抛ArgumentException - 性能上无差别，但语义清晰性优先：建议统一用
StringGet()+ 显式判断result.IsNull
如何安全地处理 Redis 连接断开和命令失败
StackExchange.Redis 不会自动重试命令，网络闪断或主从切换期间，StringSet() 可能抛 RedisServerException、RedisConnectionException 或直接 timeout。靠 try-catch 捕获所有异常并重试是错的 —— 某些失败（如 READONLY 错误）重试毫无意义。
- 先检查
ConnectionMultiplexer.IsConnected，但注意它只反映连接状态，不保证命令可达 - 对幂等操作（如
StringSet(key, value, when: When.Always)）可加简单重试（最多 2 次），用Task.Delay()避免雪崩 - 对事务（
ITransaction）或 Lua 脚本，失败即终止，不应重试 —— 它们本身是原子的，重试可能破坏一致性 - 真正要监控的是
ConnectionMultiplexer.ErrorMessage和日志中的PhysicalConnectionFailed事件
最常被忽略的一点：默认配置下，连接器在后台检测到服务器不可达后，不会立即刷新拓扑，可能导致几分钟内持续往已下线节点发请求。启用 allowAdmin=true 并配合 CONFIG GET 心跳可缓解，但更稳的方式是结合 Redis Sentinel 或 Cluster 配置自动发现。
