Webman不内置排课算法，仅负责存储结果、提供API、校验冲突；遗传算法须在独立CLI进程或异步任务中运行，Webman仅投递任务并返回task_id，避免HTTP请求阻塞。
Webman 本身不内置排课算法，也不能直接调度实验室资源——它只负责把遗传算法算出的课表存进数据库、提供 API 给前端查、校验教师/教室冲突。真正在后台跑排课逻辑的，得是独立的 CLI 进程或异步任务服务。
排课核心逻辑不该放在 Webman HTTP 请求里
把遗传算法塞进 CourseScheduleController@generate 是最典型的反模式：一次请求可能耗时 15 秒以上，PHP 进程卡死、Nginx 触发 proxy_read_timeout、用户看到 502，还拖垮整个服务。
- 遗传算法需要反复迭代、交叉变异，必须脱离 HTTP 生命周期，在 CLI 模式下运行（如
php app/command/ScheduleGenerator.php） - Webman 只暴露触发接口（如
POST /api/v1/schedule/generate），该接口只做参数校验 + 投递任务到 Redis 队列，立刻返回{"task_id": "sch_abc123"} - 用 Workerman 的
workerman/crontab或webman/async-task启动独立 worker 进程监听队列，执行实际计算 - 计算完成后写入
schedules表，并通过 Redis Pub/Sub 通知 Webman 更新缓存或推送 WebSocket 消息
如何让 Webman 正确返回结构化排课数据
前端（Vue）需要的是带时间格、教室号、教师名、实验设备清单的二维课表，不是 raw SQL 结果。直接 return $schedule->toArray() 会漏掉关联字段、格式混乱、字段命名不一致。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 定义专用 Resource 类（如
app/resource/ScheduleResource.php），统一处理字段映射：time_slots展开为数组、lab_equipment关联预加载、teacher_name替代teacher_id - 控制器中调用
ScheduleResource::collection($schedules)，而非裸数据json() - 对高频查询（如“本周所有实验室课表”）加 Redis 缓存，键名用
schedules:week:2026-W25:lab_302，过期设为 1 小时，避免重复计算 - 禁止在 Resource 中调用
DB::transaction()或发起新 HTTP 请求——它只做数据整形，不承担业务逻辑
为什么用 Webman 做排课系统要格外注意中间件顺序
排课涉及多角色（学生/教师/管理员）、多权限（查看/编辑/发布）、跨域请求（Vue 前端在 https://lab.example.com），中间件错位会导致 404 或越权。
-
CorsMiddleware必须放在最前，否则预检OPTIONS请求被AuthMiddleware拦截，返回 401 而非 204 -
AuthMiddleware要区分接口类型：对/api/v1/schedule/generate要求role=admin，对/api/v1/schedule/student只需登录态即可 - 路由定义不能写成
Route::get('/schedule/{id}', ...)->middleware('auth')，而要用数组形式：->middleware([AuthMiddleware::class, RoleMiddleware::class])，确保 RoleMiddleware 在 AuthMiddleware 之后执行 - 静态课表导出（如
/export/schedule.pdf）别走 Webman，用 Nginx 直接返回生成好的文件，否则 PDF 渲染库占用内存会拖慢整个服务
排课结果冲突检测必须绕过 Webman ORM
Webman 的 Db::table('schedules')->where(...)->exists() 在高并发下容易漏检——两个请求同时查“周三上午 8 点 教室 A 是否空闲”，都返回 true，然后都插入，造成冲突。
- 冲突检测必须用数据库原生约束：在
schedules表上建联合唯一索引UNIQUE KEY `uk_lab_time` (`lab_id`, `day_of_week`, `start_hour`, `end_hour`) - 插入时捕获
SQLSTATE[23000]: Integrity constraint violation异常，而不是靠 PHP 层判断 - 用
INSERT ... ON DUPLICATE KEY UPDATE替代先查后插，减少竞态窗口 - 不要在事务里嵌套多个
Db::insert()—— Webman 默认连接不是长事务安全的，子进程 fork 后连接句柄复用可能导致锁表
真正难的不是写遗传算法，而是让 Webman 在不崩的前提下，稳稳托住那个算法输出的结果——它不生产课表，只做课表的搬运工、质检员和快递员。任何想让它“顺便算一算”的念头，都会在压测时露出破绽。
