由 dawei 框架选型不是比谁的文档更炫、谁的GitHub星星更多。真实项目里，最常被忽略的其实是团队熟悉度和长期维护成本——一个新人三天学不会的框架，上线后bug率往往翻倍。
Laravel虽生态丰富，但默认配置对小流量站点过于重型：队列、广播、通知等组件全开启，服务器资源消耗陡增，而90%的中小企业官网根本用不到异步任务调度。
ThinkPHP在中文社区被高估了灵活性，实则底层耦合深，升级5.x到6.x需重写路由和中间件逻辑，许多团队因低估迁移成本，在安全补丁发布后选择“硬扛”已知漏洞。
Symfony被误认为“仅适合大厂”，其实它的HttpKernel组件可单独抽离，配合Slim搭建轻量API服务时，内存占用比Laravel低40%，响应时间快200ms以上——这对SEO和移动端用户体验至关重要。
还有一个隐形雷区：框架对PHP版本的实际兼容底线。某流行框架标称支持8.1，但其核心依赖的第三方包只适配至8.0.3，上线后遇到array_is_list()函数报错才仓促降级PHP，导致其他组件失效。
数据库抽象层也常被忽视。Eloquent默认启用延迟加载（Lazy Loading），一个未显式预加载的用户列表页，可能触发数百次N+1查询而不报警；而CodeIgniter 4的Query Builder更透明，SQL执行路径清晰可见，排查性能瓶颈更直接。
AI生成的示意图，仅供参考
别迷信“全栈框架”。内容型网站用WordPress+REST API组合，开发效率和SEO友好性远超手写后台；管理后台则可选用Livewire或Inertia.js+Laravel简化交互逻辑，而非强塞Vue SPA到传统MVC中。
最后一点残酷真相：框架本身没有银弹，但错误选型会把50%的开发时间消耗在绕过框架缺陷上——比如强行用ORM处理千万级日志表关联，不如直接写原生PDO+分页游标。技术选型的本质，是向现实妥协的艺术，而非追逐技术光环。