webman 不能直接作为知识付费平台使用，因其仅为高性能 http 框架，缺乏用户系统、权限模型、订单状态机、支付幂等、课程解锁等业务组件；需结合 nginx 静态资源服务、独立支付中台、workerman 实时服务及幂等设计。
Webman 本身不提供知识付费功能，它只是个高性能 HTTP 框架；直接拿它当“知识付费平台”用，等于把发动机当整车开——能跑，但缺底盘、没刹车、油箱还得自己焊。
为什么不能直接用 Webman 跑课程/支付/会员逻辑？
Webman 是常驻内存的异步框架，不是 Laravel 那种带全套生态的“开箱即用”方案。它不内置用户系统、权限模型、订单状态机、支付回调幂等、课程解锁规则这些知识付费必需的业务组件。
-
app/controller/CourseController里写if ($user->isVip() && $course->isPaid())这类判断，后期改会员等级策略时，所有控制器都要改，耦合度爆炸 - 支付回调入口（如
/notify/wechat）若没做Redis分布式锁 +order_no唯一索引 +status状态校验，高并发下极易重复入账 - 视频播放页每次请求都走
CourseDetailController@show，中间件里查权限、查进度、查有效期——全在 PHP 层硬扛，Nginx 静态资源直出都没法用
课程资源该由谁 serve？
封面图、课件 PDF、MP4 视频文件绝不能经由 Webman 的 PHP 路由返回。每请求一次就触发完整 PHP 生命周期，CPU 白烧，QPS 直降。
- Nginx 配置
location ~* \.(jpg|jpeg|png|pdf|mp4|webm)$，直接root /data/courses，加expires 7d - 敏感资源（如加密 MP4 片段）用 Webman 生成临时 token，Nginx 通过
auth_request调用/api/v1/auth/check?token=xxx校验，再放行 - 绝对不要在控制器里用
readfile()或file_get_contents()输出大文件，会阻塞 worker 进程
支付和订单必须拆出去
MPAY V2 这类基于 Webman 的支付中台项目，本质是把支付能力“服务化”：Webman 只负责暴露 /api/v1/pay/create 这类标准接口，背后是独立运行的支付核心进程（含路由策略、通道轮询、对账清算）。
- 你的知识付费平台调用 MPAY 的
pay()接口创建支付单，别自己实现微信/支付宝 SDK 封装 - 退款、查单、关闭订单全部走 MPAY 提供的
refund()、query()、close()，避免各通道回调逻辑散落在多个控制器里 - 订单状态变更（如
paid → learning）触发消息队列（如 Redis Stream），由独立消费进程更新学习进度、发站内信、同步到 CRM，不卡主 HTTP 请求链路
直播与实时互动必须交给 Workerman
Webman 的 App 实例没有 on('message') 方法——这是 Workerman 的 API，不是 Webman 的。想支持“弹题”“禁言”“举手”，就得另起 WebSocket 服务。
- 前端连
ws://live.your-domain.com:2346?uid=123&token=xxx，Workerman 服务在onConnect里调 Webman 的http://127.0.0.1:8787/api/v1/user/info校验身份 - 用户进房间后，所有指令广播只读
Redis的room:1001hash 表，不反向调 Webman 接口 - 别在 WebSocket 进程里读
$_SESSION或写session_start()—— PHP session 文件在长连接里不可靠，用 JWT 或 Redis 存储登录态
最易被忽略的是：Webman 的 reload 不等于重启，改了数据库模型或中间件配置后，只 php start.php reload 不够，得 restart 才生效；而线上环境一旦 restart，正在处理的支付回调、课程解锁请求就会中断——所以关键路径必须设计成幂等、可重入、有补偿机制。
