Webman 是 PHP 高性能 HTTP 框架，非开箱即用 HRM 系统，需自主实现模型、权限、薪酬、考勤等业务逻辑；其异步架构适合高并发 HR 场景，但分页、权限、请求解析等需针对性优化。
Webman 本身不是 HRM 系统，而是一个 PHP 高性能 HTTP 框架；直接基于它“开箱即用”跑起完整 HRM 是不现实的——你得自己建模型、写权限、配薪酬规则、处理考勤周期计算。但它的异步非阻塞架构和模块化设计，确实能让高并发查花名册、批量导入员工、实时推送审批状态这类场景稳得住。
webman 启动后访问 / 返回空白或 404 怎么办
这是最常卡住新手的第一步。webman 默认路由只绑定了 IndexController::index，且该方法会尝试读取项目根目录下的 README.md。如果文件不存在，file_get_contents() 报 warning，但默认不显示错误（display_errors=Off），看起来就是白屏。
- 先确认
public/index.php是否被正确设为 Web 服务器入口（Nginx/Apache 必须指向 public 目录，不是项目根目录） - 检查
start.php是否已执行：php start.php start -d，别只敲php start.php（那只是加载配置，没真正启服务） - 临时在
app/controller/IndexController.php的index()方法开头加die('ok');，验证控制器是否可达 - 确保
runtime/log/可写，打开日志才能看到真实报错，比如Failed to open stream: No such file or directory
员工数据分页查询慢，limit 和 offset 越往后越卡
HRM 常见场景：人事专员翻到第 200 页查离职员工，响应超 5 秒。webman 本身不干预数据库查询，但它的高性能反而会把底层 SQL 效率问题暴露得更彻底。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 避免用
offset做深分页，改用游标分页（cursor-based pagination）：按id DESC+ 上一页最后一条的id作为条件，例如WHERE id - 给常用查询字段建联合索引，比如考勤表查「某部门+某月」，索引应为
(dept_id, work_date)，而非单列 - 不要在控制器里直接写
DB::table('employees')->where(...)->paginate()，laravel-style 的 paginate() 底层仍用offset；webman 推荐手写分页逻辑或用illuminate/pagination手动构造 LengthAwarePaginator - 员工主表字段多（含简历附件路径、历史岗位 JSON 字段），查询时务必
select明确字段，别用*
support/Request 无法获取 JSON 请求体或 multipart 表单
webman 的 Request 类对 Content-Type 处理比 Laravel 更“裸”——它不会自动解析所有格式，尤其当前端用 fetch 发 application/json 但没设 header，或用 FormData 传文件时容易丢数据。
- JSON 请求必须带
Content-Type: application/json，否则$request->post()为空，要改用json_decode($request->rawBody(), true) - 上传文件需确保前端
FormData正确 append，后端用$request->file('avatar')获取，而不是$_FILES（webman 已封装） - 若用 Nginx，确认未开启
client_max_body_size限制，默认 1MB，员工批量导入 Excel 容易 413 -
Request不自动解析application/x-www-form-urlencoded以外的表单，POST 带 query string 参数时，$request->get()和$request->post()是分离的，别漏查
权限控制不能只靠中间件拦截路由
HRM 系统里，“能看自己部门员工”和“能删任意员工”是典型的数据级权限。仅靠路由中间件（如判断是否登录）远远不够，容易出现越权导出全员薪资的情况。
- 在模型查询层注入租户/部门过滤，例如
EmployeeModel::where('dept_id', $currentDeptId)->get()，别等数据查出来再用 PHParray_filter - 敏感操作（如修改薪资、删除档案）必须二次校验：记录操作人 ID、目标员工 ID、时间戳，并写入审计日志表（哪怕只是
admin_log） - webman 没有内置 RBAC，别硬套 Laravel 的
@can指令；建议用简单策略类，如Permission::canEditSalary($operatorId, $targetEmpId)，内部查组织架构树判断上下级关系 - 前端按钮显隐 ≠ 权限控制，禁用按钮可被绕过；后端接口必须每请求都鉴权，哪怕是个 GET 查详情
webman 的优势不在功能堆砌，而在可控性——你能清晰看到每个请求从入口到数据库的全链路，也正因如此，HRM 这类业务规则密集、数据敏感度高的系统，反而需要更谨慎地补全领域逻辑，而不是依赖框架“帮你兜底”。组织架构树递归查询、薪酬公式动态解析、考勤异常自动标记……这些都不是框架该干的事，但 webman 给你留出了干净的扩展位置。
