PHP框架其实没那么玄乎，就是帮你少写点重复代码的工具。2026年了，还在听人吹“谁最快”“谁最潮”，真没必要。我翻了几十个框架文档、查了社区issue、看了三轮线上服务监控数据，发现选错框架最常踩的坑，不是功能少，是它根本不适合你手头这活儿。
现在随便一搜，Laravel还是排第一，但公司里真用它跑高并发IoT后台的，基本都加了Swoole和自己写的协程安全补丁。Symfony组件被抄来抄去，连Drupal和Laravel的核心HTTP处理都在用它的HttpKernel，可你去官网看文档，密密麻麻全是Interface和Contract，新手看两行就懵——不是它难，是它不替你做决定，得你自己填。Yii3现在银行和政务系统用得多，不是因为多酷，是Gii生成器真能省三天工作量，RBAC权限模块改个配置就能过等保检查，这种事不靠吹，靠审计报告盖章。
Slim和CodeIgniter 4最近反而在小团队里悄悄回潮。不是怀旧，是它们启动快、出错提示直白、改个路由不用翻五层文档。有个做设备管理后台的朋友，原用Laravel，上线后发现单请求多加载了18MB内存，换成CI4+原生PDO，OPcache一开，内存降了三分之二。他说：“不是框架不行，是咱那十个人小团队，真养不起一个全栈框架的脾气。”
国内框架里，ThinkPHP确实铺得广，很多国产ERP、CMS底层都是它。但我要部署一个跨境电商项目，想接Stripe、用OpenTelemetry埋点，翻它英文文档，API描述还停留在2022年，报错信息还是中文，debug起来得靠猜。Yaf曾经是性能标杆，C扩展写的，但GitHub上最后一版更新是2024年11月，issues里200多条没回，StackOverflow上2026年的新提问，回答基本都是“换Swoole吧”。
CLI框架才是真被低估的主力。Beanbun爬虫框架在做数据治理，CLIFramework在写自动发版脚本，连我朋友公司每天清理测试库的定时任务，都用Minicli写——就十几行，不用装框架，`php clean.php --env=staging` 就跑起来。2025年PHP开发者调研说，六成以上运维和ETL任务根本没走Web，但没人教你怎么选一个好使的命令行框架。
选型真没那么复杂。后台管理系统，别硬上Swoole；想做实时聊天，Laravel配Websocket扩展也行，但得亲自测协程数据库连接会不会漏close；新项目要长期维护，直接看LTS周期：Symfony 6.4支持到2027，Laravel 12 LTS是2028年，可CodeIgniter 4的LTS去年就结束了。文档里要是没写清楚“怎么配OPcache预加载”“协程下DB连接池怎么防泄漏”，再火的框架也别碰——生产环境不会给你重来一次的机会。
Swoole本身已经不叫“扩展”了，它提供的协程、HTTP/WS服务器、定时器、进程管理，全是原语。EasySwoole和imi现在更像是一套配置层，把Swoole的能力串起来。Laravel Octane也是同理，它没造新轮子，是把Laravel塞进Swoole的协程生命周期里。框架没消失，只是不站前台了，变成你部署时一个配置项，一个Dockerfile里的RUN指令。
无框架PHP在Serverless里越来越常见。AWS Lambda上跑纯PDO+原生路由，冷启动快、计费低，日志直接打到CloudWatch。不是框架不行，是有些场景，真不需要它多管闲事。
框架不是答案，是选择。选它之前，先想清楚：你到底要解决什么问题？谁来维护？出了事找谁？文档里有没有真实压测数据？有没有人真在用它干你这活儿？没这些，光看Star数和教程视频，不如手写个index.php。
我上周帮人调一个Laravel队列超时问题，最后发现是Redis连接没设timeout，和框架一点关系没有。问题不在框架，在人。
就这样。
