webman不提供图书借阅业务逻辑，所谓“高性能在线图书借阅系统”本质是用其承载高并发请求入口，将库存扣减、通知推送等耗时操作剥离至独立worker进程或外部服务；控制器内同步io会导致协程阻塞、qps断崖下跌。
Webman 本身不提供图书借阅业务逻辑，所谓“高性能在线图书借阅系统”，本质是用 Webman 承载高并发请求入口（如搜索、预约、借还状态查询），把真实耗时操作（如库存锁扣、通知推送、电子书解密）剥离到独立 Worker 进程或外部服务——直接在 app/controller 里调用 file_get_contents() 加载 PDF 或同步查 Redis 库存，必然导致协程阻塞、QPS 断崖下跌、用户排队超时。
为什么不能在控制器里直接处理借阅核心流程
常见错误现象：max_execution_time 超时、Redis::setex() 返回 false、Nginx 日志频繁出现 502 Bad Gateway、并发 200+ 时借书接口响应延迟从 80ms 拉长到 3s+。根本原因是借阅涉及多步原子操作（检查可借数 → 扣减库存 → 写借阅记录 → 推送消息），而 Webman 的 HTTP 请求生命周期极短，所有同步 IO 都会卡住当前协程，无法让出 CPU 给其他请求。
- 库存校验不能只靠
GET inventory:book_123：需用WATCH+MULTI+EXEC保证扣减原子性，否则超借 - 电子书文件（PDF/EPUB）绝不能由 Webman 直接
readfile()输出：应配置 Nginx 用X-Accel-Redirect中转，避免 PHP 进程长期占用连接 - 微信/短信通知不能在控制器里调
curl_exec()：必须投递到app/worker/NotificationWorker.php异步执行，否则网络抖动直接拖垮整个请求链
图书搜索必须走 MeiliSearch，别碰 MySQL LIKE
用户搜“人工智能”时，若后端用 SELECT * FROM books WHERE title LIKE '%人工智能%'，10 万册数据下平均响应超 400ms，且并发一高就触发 SQLSTATE[HY000] [2002] Connection refused ——这不是慢，是架构级失效。MySQL 的 FULLTEXT 对中文分词支持弱，ngram_token_size=2 仍会漏掉“机器学习”这类三字词。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 启动 MeiliSearch：
./meilisearch --http-addr=127.0.0.1:7700 --master-key=devkey，无需额外配置即可中文分词 - 同步数据用监听器：
app/Listener/BookSyncToSearch.php在 BookModel::saved() 后调用$index->addDocuments()，不是在 HTTP 请求里实时同步 - 搜索接口返回前加缓存：
cache_set('search:人工智能', $result, 300)，避免重复计算
借阅状态更新必须用 Redis Sorted Set + 独立定时器
用户点击“借书”后，前端轮询 /api/v1/user/borrows?status=pending 查进度，若每次请求都扫 MySQL 表，5000 用户同时借书时，数据库连接池瞬间打满。更糟的是，借阅成功后要实时推送给用户，但 server->push() 在 Webman WebSocket 里不适用（它属于 Workerman 原生 API，Webman 封装层无此方法）。
- 状态存
zset：ZADD borrow_status:{user_id} {timestamp} {book_id}，用 score 控制时效 - 心跳检测剥离为独立协程：在
onWorkerStart里启动Swoole\Coroutine\Timer::tick(30000, ...)扫描过期 pending 记录并自动取消 - 推送走 Redis Pub/Sub：借阅成功后
PUBLISH borrow:success {json}，每个 Webman 实例订阅该 channel 并只推给本机在线用户
部署时 worker_num 和 buffer_output_size 必须调优
默认配置下，Webman 单实例撑不过 3000 并发借阅请求。问题不在代码，而在 Swoole 底层参数未适配图书系统特性：大量小包（借阅状态变更、消息提醒）频繁进出，buffer 不够会触发内核重传，worker_num 过高反而加剧协程切换开销。
-
worker_num设为 CPU 核数 × 1.5（例如 8 核设 12），别盲目拉到 32 -
buffer_output_size从默认 2M 改为 64K：图书系统消息体普遍小于 2KB，大 buffer 反而浪费内存且延迟上升 - 静态资源（封面图、试读页 HTML）全部交由 Nginx
location ~* \.(jpg|png|html)$直接 serve，禁止走 PHP
真正卡住性能的往往不是算法或 SQL，而是没意识到 Webman 的协程模型要求你把“等待”从代码里彻底剔除——库存锁、文件读取、第三方通知，全得扔出去。一旦某个环节还留着 sleep() 或 usleep()，整个 Worker 就会变成单线程黑洞。
