Laravel 9 数据库缓存关键在精准、稳定与一致性：配置层禁硬编码，统一用 env() 和 storage_path()；查询层键名须覆盖所有变量维度并避免高基数字段直入；闭包须幂等，副作用逻辑外置；空结果需缓存且设短TTL防穿透。
规避 Laravel 9 数据库缓存常见坑点，关键不在“多缓存”，而在“缓存得准、失效得稳、读写不冲突”。重点是理清缓存层级（配置层、查询层、连接层）各自的风险点，并针对性设防。
配置缓存别硬编码路径或凭证
执行 php artisan config:cache 后数据库报 Access denied，大概率是 config/database.php 里写了死路径或直接拼接了字符串。Laravel 缓存配置时会跳过所有 env() 调用，硬编码的 SSL 证书路径、数据库密码拼接等都会固化进 bootstrap/cache/config.php，导致生产环境路径不存在或权限错误。
- ✅ 正确做法：所有动态值统一走
env('DB_SSL_CA')，并在.env中明确定义 - ✅ SSL 路径建议用
storage_path('certs/ca.pem')，避免绝对路径依赖 - ❌ 禁止写法：
PDO::MYSQL_ATTR_SSL_CA => '/var/www/app/certs/ca.pem'
查询缓存键名必须覆盖全部变量维度
Cache::remember('users', 3600, [...]) 这种泛化键名在真实接口中几乎必然失效。分页、搜索、排序、用户角色不同，结果就不同，但都往同一个 key 写，后写覆盖前写，缓存命中结果错乱。
- ✅ 键名应包含所有影响结果的参数，例如：
'users_page_'.$page.'_sort_'.$sort.'_q_'.$q - ✅ 高基数字段（如
$user->id）不直接作主键，改用Cache::tags(['users', 'admin'])分组管理 - ❌ 避免在键名中塞 JSON 字符串或未过滤的用户输入，Redis 对 key 长度和字符敏感，易静默失败
闭包逻辑必须幂等，禁止副作用
Cache::remember() 的闭包只在缓存未命中时执行一次。如果里面调用了 $user->increment('view_count') 或 Mail::send()，缓存命中后这些操作就完全跳过，行为不可预测。
- ✅ 闭包内只做纯查询：
User::where(...)->get()、DB::table(...)->first() - ✅ 副作用逻辑拆出来：先查缓存，仅当未命中时再单独执行计数、发通知等操作
- ❌ 禁止在闭包里更新数据库、触发事件、写文件、发 HTTP 请求
空结果也要缓存，且明确设置较短 TTL
用户查一个根本不存在的商品 ID，每次请求都穿透到数据库，就是典型的缓存穿透。不缓存空结果，等于主动放弃防御。
- ✅ 对
null或空集合显式缓存，例如：Cache::put('product_999', null, 300) - ✅ 空值 TTL 设为 1–5 分钟，既防穿透，又不至于长期阻塞合法数据写入
- ✅ 配合布隆过滤器（Bloom Filter）可进一步前置拦截非法 key，尤其适合高并发场景
