数据核对：2026-10-22（GitHub API 实测 star 数、最新版本、最近提交） 本文讨论的是「选哪个框架」，各框架的具体用法见对应的入门文章。
先说结论
如果只想要一句话：
- 要生态、要招人、要长期维护 → Laravel
- 要交付速度、团队已熟、国内项目 → ThinkPHP
- 要扛并发、做常驻内存服务 → Hyperf 或 Webman
- 要不动框架就把 FPM 换成常驻模式 → FrankenPHP
选框架从来不是选「最好的」，是选「代价最小的」。下面把代价摊开算。
一、PHP 不是一层，是三层
大多数人比较框架时把不同层的东西混在一起了。先把层次拆清楚，后面所有讨论才有意义。
| 层 | 解决什么问题 | 代表 |
|---|---|---|
| 运行时层 | PHP 进程怎么跑、请求怎么进来 | PHP-FPM、FrankenPHP、Swoole、RoadRunner |
| 网络/进程库 | 常驻内存、事件循环、长连接 | Workerman、Swoole 的 Server |
| 框架层 | 路由、ORM、模板、依赖注入 | Laravel、Symfony、ThinkPHP、Hyperf、Webman |
三个最常见的混淆：
- Swoole 不是框架，是一个 C 扩展。它给 PHP 加上协程能力，本身不提供路由和 ORM。Hyperf 能跑是因为 Swoole 提供了协程运行时。
- FrankenPHP 不是框架，是用 Go 写、内嵌 Caddy 的应用服务器。它跟 Laravel 是配合关系，不是竞争关系。
- Workerman 是库，Webman 是框架。Webman 建在 Workerman 之上，补了路由、中间件、ORM 这些框架该有的东西。
搞清楚这三层，你会发现「Laravel 和 Swoole 哪个好」这种问题本身就不成立——它们是叠加使用的。
二、七个框架的真实状态
以下数据来自 GitHub API，核对时间 2026-10-22。
| 框架 | star | 最新版本 | 最近提交 | 定位 |
|---|---|---|---|---|
| Laravel | 34,972 | 13.38.0（10-20） | 10-22 | 全家桶，生态最全 |
| Symfony | 31,199 | — | 10-22 | 组件化，Laravel 的基石之一 |
| Workerman | 11,547 | 5.2.3（10-09） | 10-09 | 常驻内存网络库 |
| FrankenPHP | 11,446 | 1.13.2（10-21） | 10-21 | 应用服务器（Go 写的） |
| CakePHP | 8,788 | — | 10-22 | 老牌「约定优于配置」 |
| ThinkPHP | 7,886 | 8.1.3（2025-07-16） | 2025-07-16 | 国内中小项目主力 |
| Hyperf | 6,911 | 3.2.4（08-10） | 10-22 | 协程，高并发 |
| Webman | 2,695 | 2.2.3（02-24） | 2026-04-15 | Workerman 之上的框架 |
这张表怎么读
star 数不代表质量，但代表「遇到问题时能不能搜到答案」。 Laravel 三万四的 star 意味着你在任何问题上都能找到十篇以上的中文解答；Webman 两千七意味着很多问题只能自己读源码。
「最近提交」比「最新版本」更重要。 一个仓库可能三个月不发版，但每天都有提交——那说明在修 bug，只是没攒够一个版本。反之，最新版本是半年前、提交也是半年前，那就是真的慢下来了。
要注意 star 数和活跃度的背离。 ThinkPHP 的 star 比 Hyperf 多，但 ThinkPHP 的最后一次提交比 Hyperf 早了 15 个月。star 是历史积累，提交是当下状态。
三、逐个说清定位
Laravel
PHP 生态的事实标准。它不只是框架，是一整套约定：Eloquent ORM、Blade 模板、Artisan 命令行、队列、事件、广播、 Sanctum 认证。你能想到的 Web 开发需求，官方或第一方包基本都覆盖了。
代价：重。一个空 Laravel 项目装完依赖就上百个包，启动比 ThinkPHP 慢一个量级。团队里如果没人真正理解容器和门面（Facade）的工作方式，出了怪问题很难查。
适合：中大型项目、需要长期维护、需要招人（会 Laravel 的简历最多）。
Symfony
很多人以为 Symfony 是 Laravel 的竞争对手，其实它更像是「PHP 的标准库」。Laravel 内部大量使用 Symfony 的组件：HttpFoundation、Console、Finder、VarDumper、Process。
直接拿 Symfony 全栈框架做业务的人不多，但它的组件几乎每个 PHP 项目都在用——包括 ThinkPHP 也用了部分 Symfony 组件。
适合：需要高度定制的企业系统、需要自己组装技术栈的团队、想理解「现代 PHP 工程实践长什么样」的人。
ThinkPHP
国内中小项目的主力。中文文档完整、目录结构符合国内开发者习惯、上手快。外包项目、政企项目、需要快速交付的场景里，它的出场率极高。
必须如实说的问题：主仓最后一次版本发布是 2025-07-16，最后一次提交也是同月，至今 15 个月。这不代表它不能用——8.x 已经足够稳定，安全补丁的历史响应也正常——但意味着新特性不会再有了，遇到 PHP 新版本带来的兼容问题时要等更久。
为什么依然推荐：中小项目的核心矛盾是「交付周期」，不是「技术先进性」。ThinkPHP 在这件事上的效率优势是真实的，而且存量项目、招聘需求、教程资源都在。选它的人通常不是不知道 Laravel 更好，而是算过账。
适合：国内中小项目、快速交付、团队已熟悉、维护期不超过 3 年的系统。
Hyperf
基于 Swoole/Swow 的协程框架，常驻内存。注解路由、注解 DI、AOP、协程化的 MySQL/Redis 客户端都是内置的。国内高并发场景（秒杀、IM、网关）用得不少。
代价：心智负担重。常驻内存意味着全局变量和静态变量会在请求之间残留，这是从 FPM 转过来的人最容易踩的坑。另外协程环境下不能用普通的阻塞 IO，一不小心就把整个进程堵死。
适合：明确有高并发需求、团队愿意投入学习成本、能接受调试难度上升。
Webman
建在 Workerman 之上的框架，定位是「常驻内存，但保持 Laravel 式的开发体验」。比 Hyperf 轻，学习曲线平缓，性能比 FPM 高一个量级。
代价：生态小。遇到问题可参考的资料远少于 Laravel/ThinkPHP。目前最新版本是 2.2.3（2026-02），最近提交在 2026-04，节奏比 Hyperf 慢。
适合：想要常驻内存的收益但不想承担 Hyperf 的复杂度；做 WebSocket、TCP 服务、内部 API 网关。
Workerman
纯 PHP 的常驻内存网络库，不是框架。它提供的是事件循环、TCP/UDP/WebSocket 服务端、定时器、进程管理。Webman 就是基于它做的。
适合：需要自己控制协议层（自定义 TCP 协议、物联网接入、长连接推送）；或者只想给现有项目加一个常驻进程，不想引入整个框架。
FrankenPHP
用 Go 写、内嵌 Caddy 的 PHP 应用服务器。它把 PHP 编译进一个常驻进程，支持 worker 模式，同时自带 HTTP/2、HTTP/3、自动 HTTPS。
最有价值的用法：frankenphp run 直接跑一个 Laravel/ThinkPHP 项目，不改一行业务代码，就把「每请求启动一次」变成「常驻 worker」。这是从 FPM 迁移成本最低的常驻方案。
代价：部署形态变了（不再是 nginx + php-fpm 两个进程），运维习惯要调整；worker 模式下同样有全局状态残留问题。
适合：想试常驻内存但不想换框架；Caddy 生态的用户；单机部署想少几个组件的场景。
四、按场景选
小项目 / 快速验证（一周内要上线）
ThinkPHP 或 Laravel。
ThinkPHP 起步更快，脚手架和中文文档省时间。如果团队已经会 Laravel，就用 Laravel，切换成本比学习成本高。
不建议在这个阶段上 Hyperf——为了「以后可能的高并发」提前付复杂度，通常是亏的。
中型业务 / 团队协作（3-10 人，维护 2 年以上）
Laravel。
理由不是它技术最好，是协作成本最低：约定明确、招人容易、第三方包齐全、出问题能搜到答案。团队规模一大，「每个人都能找到资料」比「架构更优雅」重要。
高并发 / 微服务
Hyperf（要协程全家桶）或 Webman（要轻量常驻）。
先问自己一个问题：真的到瓶颈了吗？ 大多数「需要高并发」的判断是拍脑袋的。一个 FPM 站点配上 OPcache 和对象缓存，单机跑几千 QPS 并不难。真到瓶颈了再换，比一开始就上协程框架划算。
老旧系统维护
别换框架。
接手一个 ThinkPHP 5 的项目，正确做法是升级到 8.x 并补测试，不是重写成 Laravel。重写的项目 70% 会烂尾——这个数字在行业里流传很久了，我没见过反例。
五、怎么判断一个框架还活着
这是选型时最实用的一项技能。五个指标，按可靠性排序：
1. 最近提交时间（最可靠） 不是看最新版本，是看默认分支的最后一次 commit。三个月内有提交 = 活着；半年 = 放缓；一年以上 = 事实上停止演进。
2. 版本发布节奏 健康的项目有稳定节奏（Laravel 每年一个大版本，Symfony 每两年）。突然停更或突然高频，都要警惕。
3. Issue 的响应情况 不看数量（热门项目 issue 都多），看关闭率和平均响应时间。一个 issue 挂半年没人回，说明维护者已经不看仓库了。
4. 是否跟进新版本语言特性 PHP 每次大版本升级（8.1 枚举、8.2 只读类、8.3 类型化常量）都会有兼容问题。框架多久跟上，能反映维护强度。
5. 生态与招聘 有没有活跃的第三方包、社区、招聘需求。这一项对商业项目比对个人项目重要得多。
用这套标准重看上面的表：Laravel、Symfony、Hyperf、Workerman、FrankenPHP 都在第一档；Webman 第二档；ThinkPHP 第三档——但它的「生态与招聘」这一项分数很高，所以综合下来依然是可选项，只是要接受「不会再变好」这个前提。
六、四个常见误区
① 「常驻内存一定更快」
常驻内存省掉的是「每请求初始化框架」的开销，不是数据库查询的开销。如果你的瓶颈在 SQL，换 Hyperf 一点用都没有。先 profile，再换框架。
② 「Swoole 是框架」
不是。它是扩展。装了 Swoole 你依然需要一个框架来提供路由和 ORM。
③ 「ThinkPHP 更新慢 = 不能用」
更新慢影响的是「未来能不能跟上 PHP 新版本」和「有没有新特性」，不影响「现在能不能稳定跑业务」。存量项目大量在跑，这是事实。
④ 「Laravel 太重，性能不行」
Laravel 的启动开销确实大，但配上 OPcache、路由缓存、配置缓存、对象缓存之后，实际 QPS 差距没有传说中那么夸张。真正拖慢的通常是没做缓存的查询和没优化的 N+1，不是框架本身。
七、延伸阅读
- Laravel 框架入门 —— 路由、控制器、Eloquent
- ThinkPHP 8 入门 —— 国内项目的标准用法
- Hyperf 协程框架入门 —— 协程模型与常驻内存注意事项
- Workerman 常驻内存编程 —— 事件循环与协议层
- Webman 框架入门 —— Workerman 之上的框架层
- Swoole 协程运行时 —— 扩展安装与协程化客户端
- FrankenPHP 部署 PHP —— worker 模式与 Caddy 集成