缓存 key 必须包含租户标识，否则多租户间会数据串扰；应统一用 key 前缀（如"tenant:abc123:user:123:profile"）而非 Redis db 隔离，并确保失效、存储、穿透防护等全链路绑定租户维度。
缓存 key 必须包含租户标识
多租户场景下，如果所有租户共用同一套缓存逻辑，get_user_profile(123) 这类调用在不同租户里可能查到彼此的数据——因为 key 没区分来源。本质不是缓存系统的问题，而是 key 设计漏了租户上下文。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有缓存 key 前缀强制拼接租户 ID，比如
"tenant:abc123:user:123:profile"，而不是"user:123:profile" - 租户 ID 优先从请求上下文（如 JWT payload、中间件注入的
$tenant_id）获取，不依赖用户表字段或 session 里不可信的值 - 避免用域名、子域名自动推导租户 ID，除非你 100% 控制 DNS 和反向代理行为；否则 Nginx 重写规则一变，
$_SERVER['HTTP_HOST']就可能被绕过
Redis 数据库隔离不如 key 前缀可靠
有人会想：直接给每个租户分配一个 Redis db（比如 SELECT 1, SELECT 2），听起来很干净。但 PHP 的 Predis\Client 或 Redis 扩展默认不支持运行时切换 db，且 Redis 官方已明确表示 SELECT 不适合多租户隔离——它不提供权限控制，也不防误操作 FLUSHDB。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 放弃按
db分租户，统一用db 0，靠 key 前缀 + 应用层校验兜底 - 如果非要用多
db，必须在连接池层面为每个租户维护独立Redis实例，且禁止复用连接；否则中间件一次select(1)可能污染后续所有请求 - 检查是否启用了
redis.conf中的rename-command FLUSHDB ""，否则运维手动清库时可能误伤其他租户
APCu / Filesystem 缓存更要小心作用域泄漏
APCu 是进程级共享内存，apcu_store('user_123', $data) 在 FPM 模式下，多个租户请求若落在同一个 worker 进程，就可能读到前一个租户写入的值——尤其当没设 TTL 或 key 冲突时。Filesystem 缓存同理，cache/user_123.php 如果路径没带租户目录，就会覆盖。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- APCu key 必须带租户前缀，且建议加随机 salt（如
"t_abc123_v2_user_123"），防止不同租户恰好生成相同 key - Filesystem 缓存路径要分租户目录，例如
/var/cache/tenant/abc123/user_123.php，而非全局/var/cache/user_123.php - 禁用 APCu 的
apc.enable_cli=1（CLI 模式下无租户上下文），避免命令行脚本污染 Web 请求缓存
缓存失效逻辑必须绑定租户维度
改了租户 A 的用户资料，只清 "user:123:profile" 是错的——这个 key 在租户 B 里也可能存在。更危险的是，用通配符删 key（如 redis-cli --scan --pattern "user:123:*"）会跨租户匹配，把所有租户的 123 号用户都干掉。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 失效操作必须走完整 key，比如删
"tenant:abc123:user:123:profile"，而不是模糊匹配 - 批量失效用集合（Set）管理 key，例如
"tenant:abc123:user:123:keys"存所有相关 key，删时先取再删，避免漏删或误删 - 不要依赖缓存过期时间兜底，关键数据（如权限、配置）必须主动失效；租户停用时，立刻清空其全部 key 前缀，别等 TTL
最易被忽略的一点：缓存穿透防护（如空值缓存）也得带租户前缀。否则租户 A 查不到用户 X，缓存了 "user:X:notfound"，租户 B 接着查，就直接命中这个“假空值”了。
