ThinkPHP 高性能接口的关键是绕开框架默认开销：用 Swoole 常驻内存复用 $app 实例、WorkerStart 中初始化并配置数据库连接池、禁用 Session 与中间件、避免 ORM 重负载，实测 QPS 可达 3000+。
ThinkPHP 做高性能接口，关键不在“写得多”，而在“绕得开”——绕开框架默认的 HTTP 生命周期开销、绕开重复初始化、绕开阻塞式 I/O。真要压测到 3000+ QPS，光靠路由+控制器+模型三层堆逻辑是撑不住的。
为什么默认 TP 接口在高并发下变慢
每次 HTTP 请求都会触发完整的框架启动流程：自动加载、配置读取、数据库连接、中间件栈执行、请求解析、响应封装……哪怕你只返回 json(['code'=>0])，TP5/6 默认模式下也要走完这整套。实测单进程下，空接口平均耗时 12–18ms；Swoole 模式下可压到 0.8–1.5ms。
- PHP-FPM 每次请求都重建全部对象，
$app->initialize()被反复调用 - 数据库连接未复用，
Db::connect()默认每次新建连接（即使用了 PDO） - 日志、缓存、Session 等中间件默认启用，无差别参与每个 API 请求
-
input('post.')和input('put.')底层依赖$_POST/$_PUT全局变量，而 Swoole 不自动填充这些超全局数组
用 Swoole 启动时复用框架实例
核心是让 $app 实例常驻内存，并在 WorkerStart 阶段完成一次性初始化，而非每次请求都重来。
入口文件 swoole_server.php 中必须做三件事：
立即学习“PHP免费学习笔记（深入）”；
- 调用
$app->initialize()—— 这步漏掉，后续所有Db、Cache、Validate都会报错或失效 - 手动设置数据库连接池（不是改配置，是代码里显式调用
Db::setConfig()），否则仍走短连接 - 禁用 Session 自动启动：
ini_set('session.auto_start', 0)，避免 Swoole Worker 冲突
常见错误：Call to a member function query() on null，基本就是 Db::connect() 返回了 null，根源是没在 WorkerStart 里调 Db::setConfig()。
接口层绕过中间件和模板引擎
默认 think\App 会加载全部中间件并尝试匹配视图路径。API 场景下，这些全是冗余开销。
- 在路由定义中明确指定不走中间件：
Route::get('api/user/:id', 'api/User.read')->middleware([]) - 控制器继承
think\Controller即可，**不要继承think\Controller\RestController** —— 后者自带格式协商、状态码映射等逻辑，对纯 JSON 接口反而是负担 - 返回一律用
json()，但注意它内部会调Response::create()->send()，如果你已用 Swoole 手动$response->end()，就别再用json()，直接echo json_encode(...)+exit
性能差异实测：关闭中间件后，相同接口平均响应时间下降 35–42%，尤其在小包高频请求（如心跳、token 刷新）场景下更明显。
模型与数据库层的轻量化处理
ORM 是双刃剑。高频接口如用户信息查询、订单状态轮询，用 UserModel::find(123) 看似简洁，但背后有字段过滤、事件触发、验证器加载等隐式成本。
- 简单查询优先用
Db::name('user')->where('id', 123)->find()，跳过模型类加载和事件系统 - 批量操作避免
foreach+save()，改用Db::name('log')->insertAll($list) - 禁止在 API 控制器里调
dump()、trace()或开启调试模式（app_debug = true），Swoole 下会导致 Worker 卡死 - 缓存键建议带版本号，例如
user:info:v2:123，避免模型变更后缓存不一致
最容易被忽略的一点：Swoole Worker 进程内，Db 连接是复用的，但模型实例（如 new UserModel()）不是线程安全的。多个协程并发调同一个模型实例的 save()，可能引发数据错乱 —— 此时应改用 Db 查询构造器或加协程锁。
