laravel本身不是瓶颈，高并发下垮掉的是数据库连接池耗尽、缓存击穿、会话阻塞、同步任务堆积；可扩展性靠分层解耦+异步化+无状态化。
直接说结论：Laravel本身不是瓶颈，高并发下垮掉的从来不是框架，而是数据库连接池耗尽、缓存击穿、会话阻塞、同步任务堆积这四类问题。可扩展性不靠换框架，靠分层解耦+异步化+无状态化。
为什么Redis用作默认缓存驱动却还是缓存穿透？
Cache::get() 返回 null 时不做兜底，直接查库，是穿透主因。Laravel 的 Cache::remember() 只解决“查不到就写”，但挡不住恶意构造的不存在 key（比如 user_profile_999999999）。
- 必须配合布隆过滤器（Bloom Filter）做前置校验，或在 Redis 层加空值缓存（
Cache::put('user_profile_999999999', null, 60)），注意设置较短过期时间防污染 - 不要把
SESSION_DRIVER=file留在生产环境——文件锁会串行化所有请求，换成SESSION_DRIVER=redis并确保REDIS_PREFIX隔离会话 key -
config/cache.php中的store配置要和.env的CACHE_DRIVER一致，否则php artisan config:clear后可能回退到 file 驱动
Laravel队列积压时，Horizon里看到“processing”但实际卡死？
常见现象是进程没崩溃，但 php artisan horizon 显示某 job 一直 processing 超过 5 分钟，ps aux | grep horizon 却看不到对应 worker 进程——本质是 PHP-FPM 子进程被信号中断后未清理，残留了僵尸 job 状态。
- 必须为每个 queue 设置
retry_after（如redis.queue.retry_after=90），避免超时 job 永久挂起 - 用
php artisan queue:work --max-jobs=100 --stop-when-empty替代常驻模式，配合 supervisor 自动拉起新进程 - 监听
JobProcessing和JobFailed事件，在失败前记录$event->job->getRawBody()，避免 Horizon 日志里只有 “Class not found” 这种模糊错误
读写分离配置生效了，但 DB::table()->where()->get() 还是从主库走？
因为 Eloquent 默认使用 default 连接，而 read / write 是配置项，不是自动路由规则。除非显式调用 on('read') 或开启 sticky 模式，否则写操作后的下一次读仍可能打到主库。
- 在
config/database.php的 mysql 配置中启用'sticky' => true，它会让本次请求后续所有读都复用刚写入的连接（适用于秒级一致性要求不高的场景） - 对报表、列表页等纯读场景，强制指定连接：
User::on('mysql_read')->with('posts')->get() - 不要依赖
DB::connection()->getPdo()判断当前连接——它返回的是连接实例，不是连接名；用DB::connection()->getName()才能确认
Event::dispatch() 后监听器没执行，但日志里没报错？
最常被忽略的是监听器注册方式：Laravel 10+ 默认启用 EventServiceProvider::$listen 的自动发现（shouldDiscoverEvents()），但它只扫描 app/Listeners 下的类，且要求命名空间严格匹配 App\Listeners。
- 检查
app/Providers/EventServiceProvider.php是否重写了shouldDiscoverEvents()并 return false —— 如果关了自动发现，又没手动在$listen数组里注册，事件就静默丢弃 - 监听器的
handle()方法参数类型必须与事件类构造函数参数完全一致，否则服务容器注入失败，Laravel 不报错也不执行，只跳过该监听器 - 在队列监听器中调用
Mail::send()前，确认MAIL_MAILER是smtp或log，别用array（开发环境默认值），否则邮件根本不会进队列
真正的扩展难点不在代码怎么写，而在“哪一层该承担什么责任”——比如缓存失效策略不该由业务代码决定，而应由事件触发后统一更新；数据库分片键不能硬编码在 Repository 里，得从请求上下文或配置中心动态获取。这些边界一旦划错，水平扩容时就会出现数据错乱或缓存不一致。
