排查步骤
从审批到门口，七个环节
前五步在授权层面，管理权限教师也能看；第六步涉及设备，需要系统管理员。
- 01确认这扇门真的批了
- 授权申请 › 我的申请展开这份申请：一次申请多扇门时，系统按门的责任人拆成几张子单，逐门显示「已授权」「待批」「被拒」。申请状态是「部分已授权」时，只有已授权的那几扇门能进，其余还在对应责任人那里。学生申请先要导师背书；高敏感房间另有一张安全复核子单。审批人选择「已通过（有调整）」时只能收紧，卡片上会写明实际批准到哪天。
- 02对这一人一门做一次时空检查
- 授权中心 › 检查器 › 时空检查选择人员、房间和要检查的时间点。结论是「无法通行」时，原因会落到具体分支：授权尚未生效或已过期、授权未成功下发到设备、命中不可通行例外、授权仅在工作日或周末生效、超出授权时段。空间页的房间上还有一个「虚拟刷卡测试」，它只验证当前授权，不会触发真实开门。
- 03核对有效期与时段
- 授权中心 › 按人展开来源为「申请」的那条授权，看生效与到期时间、生效的星期和小时段。时段按「星期 + 小时段」判定：只在工作日生效的授权，周末去刷就是刷不开，检查器会直接写出「授权仅工作日生效」和检查时间。
- 04看是否撞上例外日
- 角色组详情 › 组级时段策略 › 时段例外授权来自角色组时，组上可以配置时段例外，例如节假日禁止通行或允许通行。日期落在「禁止通行」的例外里，平时的时段再宽也不放行；多条例外重叠时，以后配置的那条为准。
- 05看下发状态
- 授权中心 › 按人 / 批量授权结果页每条授权都带下发状态：待下发、已下发、下发失败。刷卡是控制器拿自己的权限表比对，授权没有成功下发就刷不开；扫码是系统收到上报后判定，再向设备下发开门指令，不依赖控制器上的权限表。只有刷卡不行、扫码可以时，优先查这一项。批量授权的结果页会单列「授权已保存但未同步到设备」的条目，可以重试。
- 06看设备在线与端口绑定
- 设备管理 / 实时监控设备列表里每台设备有「在线」「响应慢」「离线」状态，离线时显示已离线多久；实时监控把离线设备排在最前。打开设备详情的「端口」，确认门禁端口关联的是这间房；端口没有关联房间时，判定结果就是「门禁端口未绑定房间」。房间被系统管理员设为「禁用通行」时，按房间视图会标出「该房间已禁用通行」。
- 07对照这次通行记录
- 通行日志 › 记录详情找到这次刷卡或扫码的记录，详情里的授权链路区给出命中了哪条授权；被拒的记录写明具体原因与失败环节，可以和第 2 步的检查结论对照。
适用条件与边界
审批、授权、下发、开门是四件事
- 判定只有一个口径
- 后台的授权检查和现场开门判定走同一段逻辑，顺序是：有效期 → 下发状态 → 例外日 → 星期与时段。所以检查器给出的拒绝原因，就是现场会遇到的那一条。
- 可通行不等于门一定开
- 后台结论说明系统层面放行；门最终打不打得开，还取决于控制器、读头、门锁和现场接线，需要实机验证。
- 设备排查要系统管理员来做
- 设备管理、实时监控只有系统管理员能看。院系或实验室负责人查到下发失败、设备离线时，需要转给系统管理员处理。
- 撤回只撤未决部分
- 撤回申请只撤回还没处理的部分，已经生效的门授权保持不变。
- 访客码另走一套判定
- 访客通行码由邀请的有效期、开门次数和房间范围共同约束，不在这条排查路径里。访客页会提示邀请尚未生效、已过期、次数已用尽或已撤销。
常见问题
「批了还进不去」常见的四种情况
- 审批通过了，检查器却说「授权未成功下发到设备」？
- 授权已经建立，但还没有成功写入控制器。刷卡依赖控制器上的权限表，需要先排除设备离线等下发失败原因，再重试下发。
- 扫码能开、刷卡开不了，是怎么回事？
- 两种方式的判定路径不同：扫码由系统判定后下发开门指令，刷卡由控制器按已下发的权限表比对。只有刷卡不行时，先查这条授权的下发状态。
- 一份申请里有的门能进、有的门进不去？
- 多门申请按门的责任人拆成子单，逐门生效。申请显示「部分已授权」时，其余的门还在对应责任人或安全复核那里待批。
- 工作日能进，周末或节假日进不去？
- 多半是授权时段只覆盖工作日，或者日期命中了角色组上「禁止通行」的时段例外。检查器的时空检查会写明是哪一条。
相关页面
接着看
多门申请与审批
按门的责任人拆成子单、逐门生效，高敏感房间追加安全复核。
通行日志与操作审计
每条通行记录都能展开成授权链路，被拒时给出具体原因。
删了一个授权来源，为什么他还能进
反过来的问题：多来源授权怎么查、怎么收。