Laravel 是当前最成熟、文档最全、社区最强的 PHP 框架之一，但启动开销大、内存占用高、对新手不友好，轻量场景易“杀鸡用牛刀”。
PHP 后端开发中，Laravel 并非“唯一选择”，而是当前生态里最成熟、文档最全、社区支持最强的框架之一；但它也自带明显代价——启动开销大、内存占用高、对新手不友好，尤其在轻量 API 或 CLI 工具场景下容易“杀鸡用牛刀”。
为什么 Laravel 的 artisan 命令在 Docker 容器里常报 Class 'App/Console/Commands/XXX' not found
这不是类没写，而是自动加载未刷新。Docker 构建时若把 vendor/ 和 composer autoload 缓存一并打包进去，后续修改命令类文件不会触发重生成。
- 构建镜像前，在
Dockerfile中删掉vendor/，改用RUN composer install --no-dev --optimize-autoloader保证每次构建都重生成vendor/autoload.php - 容器运行后首次执行命令前，手动运行
php artisan clear-compiled && php artisan optimize:clear（Laravel 9+ 用optimize:clear替代） - 别在
APP_ENV=production下直接改app/Console/Commands/然后跑命令——生产模式会跳过某些自动发现逻辑
Laravel 的 Queue::dispatch() 在 Supervisor 下不消费？查这三处
队列“发出去了但没执行”，大概率不是代码问题，而是环境链路断在中间。
-
QUEUE_CONNECTION配置必须和supervisor.conf中启动的php artisan queue:work命令所指定的连接一致，例如：配置是redis，但 supervisor 启动时写了--queue=emails却没配redis.queue值，默认会卡住 - Supervisor 的
autostart=true和autorestart=true要开启，且检查ps aux | grep queue:work确认进程确实在跑，不是启动即崩（常见于.env未加载或 Redis 连接超时） - 如果用了
database驱动，确认jobs表引擎是InnoDB（MyISAM 不支持行锁，会导致并发消费异常）
替代 Laravel 的轻量选项：Slim + Doctrine DBAL + League/Container 实测对比点
当项目只需 REST API、无 Eloquent 关系映射、无 Blade 渲染、无复杂中间件栈时，Laravel 的抽象层反而拖慢开发与部署。
立即学习“PHP免费学习笔记（深入）”；
-
Slim路由极简，$app->get('/users', Handler::class);就完事，无服务提供者注册负担 -
Doctrine/DBAL比 Laravel 的DBfacade 更透明——SQL 写在哪、参数绑定怎么走、事务怎么开，全部可控，调试时不会被 Query Builder 包裹层干扰 -
League/Container是 PSR-11 兼容容器，比 Laravel 的 IoC 更轻、无魔法方法调用，适合需要明确依赖注入路径的团队 - 缺点也很直白：没有
migrate:fresh --seed一键重置，没有tinker交互终端，也没有php artisan serve开箱即用的 dev server
框架选型真正难的不是功能多寡，而是边界感——Laravel 擅长“你只管写业务，其余我兜底”，但兜底的代价是它必须预设所有可能路径；一旦你的业务绕开了它的默认路径（比如用 Swoole 做长连接、用 ClickHouse 替代 MySQL、用 Protobuf 替代 JSON），那些“省下的代码”就会变成“排查三天的黑盒”。