Webman不是ThinkPHP升级版或Laravel平替，而是基于Workerman的常驻内存、事件驱动高性能服务框架，与传统FPM架构的ThinkPHP存在根本性运行模型差异：前者请求共享Worker进程资源，后者每次请求独占进程；迁移核心是心智转换而非语法替换。
Webman 不是 ThinkPHP 的“升级版”，也不是 Laravel 的平替。它和 ThinkPHP 属于不同架构范式的产物：一个是常驻内存、事件驱动的高性能服务框架，另一个是面向传统 FPM 请求生命周期的 MVC 框架。迁移不是“换壳”，而是运行模型的切换——你得先接受「请求不再独占进程」这个前提，否则后续所有问题都会绕回阻塞、内存泄漏、定时任务失效这些坑里。
Webman 的 onWorkerStart 和 ThinkPHP 的 App::beforeStart 本质不同
ThinkPHP 的启动钩子（比如 App::beforeStart）在每次请求开始前执行，适合做请求级初始化（如日志上下文、权限检查）。而 Webman 的 onWorkerStart 是 Worker 进程启动时只执行一次，它跑在常驻内存上下文中，所有后续请求共享其变量和资源。
- 误把数据库连接、Redis 实例放在这里初始化但没做连接池管理，会导致连接数暴涨甚至被服务端拒绝
- 在
onWorkerStart中写死一个全局数组存用户状态？别忘了这是多进程模型，每个 Worker 进程都有自己的副本，A 进程改了，B 进程看不到 - 想复用 ThinkPHP 的
config('database')？Webman 没有运行时配置重载机制，config()返回的是启动时加载的快照，动态改配置项无效
路由和中间件写法相似，但执行时机和生命周期完全不同
Webman 路由注册方式和 ThinkPHP 几乎一样，get('/user', [UserCtrl::class, 'index']) 这种写法看着亲切，但背后行为差异极大：
- ThinkPHP 的中间件是请求进入后、控制器执行前逐层调用，每请求一次完整走一遍；Webman 的中间件也如此，但它的“请求上下文”是轻量对象，不带任何自动销毁逻辑
- ThinkPHP 的
Session::start()在每次请求自动触发；Webman 默认不启用 Session，要手动集成webman/session插件，且 session 文件或 Redis 存储必须显式配置，否则session_start()会静默失败 - 使用
$request->cookie()或$request->header()没问题，但别指望$request->file()能像 ThinkPHP 那样自动移动临时文件——Webman 不处理上传文件落地，得自己用move_uploaded_file()或流式保存
从 ThinkPHP 迁移时最容易卡住的三个阻塞点
ThinkPHP 项目里习以为常的写法，在 Webman 里就是性能断崖：
立即学习“PHP免费学习笔记（深入）”；
-
file_get_contents('https://api.example.com')：同步 HTTP 请求会直接卡住整个 Worker 进程，必须换成webman/http-client的异步调用，或封装成协程（需额外引入 Swoole 扩展） -
mysqli_query($conn, "SELECT * FROM users")：原生 MySQLi 是阻塞的，Webman 官方推荐用webman/database（基于 PDO + 连接池），否则并发一上来就报“Too many connections” - 在控制器里直接
sleep(1)或循环等待某个条件？这等于主动让这个 Worker 拒绝其他所有请求 1 秒，千万别试
迁移真正的难点不在语法，而在心智转换：ThinkPHP 是“每个请求自成世界”，Webman 是“所有请求共用一个世界”。变量要不要全局、连接要不要复用、状态要不要持久化——每个决定都得带着进程模型去判断，而不是凭经验抄代码。
