必须做Ping验证，否则首次rdb.Get()失败才暴露连接问题，易致线上雪崩；初始化需用带超时的context调rdb.Ping()，禁用context.Background()，PoolSize应≤单机maxclients×0.8÷实例数，建议10–30起步。
go-redis v9 客户端初始化必须做 Ping 验证
不验证连接就直接用 rdb.Get()，第一次调用失败才暴露问题，线上服务会因 Redis 不可用而雪崩式报错。初始化时必须用带超时的 context 调用 rdb.Ping()，且不能用 context.Background() —— 后者没 deadline，可能卡死 goroutine。
常见错误是 PoolSize 设得过大（比如 200），导致 Redis 服务端连接数打满（默认 maxclients=10000），但客户端日志只报 timeout，很难定位。建议从 10 开始，按 QPS 逐步上调；若并发请求集中在少数 key，PoolSize 10–30 通常够用。
- 初始化后立即执行
rdb.Ping(ctx).Err()，失败则 panic 或退出 -
PoolSize值应 ≤ 单机 Redis 的maxclients× 0.8 ÷ 服务实例数 - 别在 handler 里新建
*redis.Client，全局复用一个实例即可
空值缓存 + 随机 TTL 是防穿透最简有效手段
查不到 DB 数据时，如果直接返回空，攻击者反复刷不存在的 key（如 /user/999999999），就会穿透缓存直打 DB。解决方案不是加布隆过滤器，而是写入一个空值，并设随机过期时间（比如 5–10 分钟），既避免热点 key 集中过期，又防止恶意刷空 key。
注意：空值不能只存 ""，要存结构化占位符（如 {"exists":false}），否则和业务真实空响应混淆；反序列化时需显式判断该字段，而非靠 error 判定。
立即学习“go语言免费学习笔记（深入）”；
- 写缓存前先检查 DB 是否真无数据，再写
rdb.Set(ctx, key, placeholder, randomTTL) - TTL 建议用
time.Duration(rand.Int63n(5*60e9) + 300e9)，避免全量 key 同时失效 - 读缓存时若命中空值，直接返回 404，不再查 DB
slices.Contains 和 slices.Sort 在编译期完成泛型实例化
Go 1.21+ 的 slices 包函数（如 slices.Contains、slices.Sort）不是运行时反射，而是在编译期根据实际类型生成专用代码。这意味着它们零分配、无类型断言开销，比手写循环或旧版第三方库更安全高效。
但要注意：如果切片元素类型是 interface{}，slices.Contains 就退化为运行时比较（因为无法静态推导 == 行为），性能反而不如手写循环。真正受益的是具体类型，比如 []string、[]int64。
- 优先用
slices.Contains([]string{"a","b"}, "c")，而非strings.ContainsAny或自定义 loop -
slices.Sort对[]int的排序比sort.Ints更统一，且支持自定义 comparator - 避免把 slice 转成
interface{}再传给slices函数，会丢失类型信息
内存对齐影响 struct 序列化体积与 GC 压力
struct 字段顺序直接影响内存布局和序列化后字节数。Go 编译器会自动填充 padding 以满足对齐要求（如 int64 必须在 8 字节边界），但如果把小字段（bool、int8）穿插在大字段（int64、string）中间，padding 会增多，导致单个 struct 占用更多内存，GC 扫描压力上升，序列化后 payload 变大。
典型反例：type User { Name string; Active bool; ID int64 } 比 type User { ID int64; Name string; Active bool } 多出至少 7 字节 padding（取决于平台）。这个差异在百万级对象缓存场景下就是几十 MB 内存浪费。
- 按字段大小降序排列：先放
int64/float64/string，再放int32/bool/byte - 用
unsafe.Sizeof和unsafe.Offsetof验证实际布局 - protobuf 生成的 struct 默认已对齐，但手写 DTO 时必须人工调整
