ThinkPHPOA办公系统开发-ThinkPHP-PHP中文网

authcheck中间件总跳过权限校验，根本原因是未正确注册到路由或控制器：需检查app/middleware.php是否加入全局中间件数组，或对应route.php是否显式绑定；同时确保$request->pathinfo()返回路径（如/admin/user/list）与数据库oa_menu.url字段值严格一致，且缓存键role_permissions_{$roleid}中$roleid非空有效。

thinkphpoa办公系统开发

TP5的`AuthCheck`中间件为什么总跳过权限校验？

常见现象是：登录后访问后台任意URL都不报403，甚至直接拼接未配置菜单的路径也能进。根本原因通常是AuthCheck没被正确注册到路由或控制器中。

检查app/middleware.php是否已将AuthCheck::class加入全局中间件数组；若只在某个模块（如admin）使用，需确认该模块的route.php里是否显式绑定了该中间件
$request->pathinfo()返回的是不含域名和查询参数的纯路径，比如/admin/user/list，但数据库oa_menu.url字段存的是user/list还是/admin/user/list？两者不一致就会导致checkPermission始终返回false却静默放行
缓存干扰：如果权限数据从Redis读取，而缓存键设计为role_permissions_{$roleId}，但实际写入时用了role_id字段值（可能为null或0），会导致查不到权限

用`think migrate:run`执行迁移时提示`Class 'Migration' not found`

这不是PHP版本问题，而是TP5迁移类命名规范被破坏了。ThinkPHP5要求迁移类必须继承think\migration\Migration，且文件名必须严格匹配YYYYMMDDHHIISS_create_xxx_table.php格式。

ThinkPHP5.1企业站点快速开发-源码课件

ThinkPHP5.1企业站点快速开发

下载

确认database/migrations/下每个PHP文件顶部都有use think\migration\Migration;，且类定义为class CreateOaUserTable extends Migration
如果手动改过类名（比如加了Admin前缀），命令行会找不到基类——TP5的迁移扫描器只认CreateXXXTable这种命名
执行前先运行php think migrate:status看哪些迁移显示down，再针对性跑php think migrate:run --step=1，避免一次性执行全部失败

HAdmin模板里`$.post('/admin/menu/save')`一直返回`500`

前端看着是AJAX请求失败，实际90%概率卡在TP5的CSRF验证或模型层异常。HAdmin默认启用了token机制，但TP5的__token__字段校验容易被忽略。

检查表单HTML是否包含{:token()}（TP5模板语法），生成的隐藏域name必须是__token__，否则validateToken()直接抛异常
后端MenuController@save方法里，如果用了$this->validate($data, 'Menu.add')，要确认application/common/validate/Menu.php中规则是否写了'pid' => 'number'——而前端传来的pid可能是空字符串，触发验证失败却不返回具体错误信息
MySQL严格模式下，oa_menu.sort字段设为NOT NULL DEFAULT ''会导致插入失败：TP5自动填充sort时传的是0，但空字符串默认值与整型冲突，需改为DEFAULT 0

二次开发时新增的`oa_approval_flow`表，怎么让TP5自动识别关联关系？

TP5不会自动发现新表，必须显式声明关联。别指望Db::name('approval_flow')能直接调用with('steps')这类方法。

在application/common/model/ApprovalFlow.php中定义steps()方法，返回$this->hasMany('ApprovalStep', 'flow_id', 'id')，注意第二个参数是子表外键名，第三个是主表主键名
如果ApprovalStep模型里需要反向查流程标题，就在其flow()方法中写$this->belongsTo('ApprovalFlow', 'flow_id', 'id')，两个方法的字段顺序不能颠倒
调用时用ApprovalFlow::with('steps')->find($id)，而非Db::name()——后者是原生查询，不走模型关联逻辑