Idle Detection API 需满足 HTTPS、用户手势、权限授予三条件才能初始化，Chrome 112+ 默认启用，threshold 不低于 60000，须组合 userState 与 screenState 判断，并配合 visibilitychange 和服务端验证确保可靠性。
Idle Detection API 不能直接“触发标记”，必须先满足 HTTPS、用户手势、权限授予三条件，否则连初始化都会失败。
检查支持性与运行环境是否合规
很多代码一跑就报 ReferenceError: IdleDetector is not defined 或静默不触发，根本原因不是写法错，而是环境没达标：
-
'IdleDetector' in window必须为true，Chrome 112+ 才默认启用；旧版需手动打开chrome://flags/#enable-idle-detection - 页面必须是 HTTPS（
localhost和127.0.0.1是唯一例外），HTTP 下requestPermission()直接抛NotAllowedError - 调用
IdleDetector.requestPermission()必须由用户点击、按键等明确手势触发，放在DOMContentLoaded或自动执行里会被浏览器拦截 - iframe 中使用需带
allow="idle-detection"属性，且父页也得满足全部条件
申请权限并启动检测器的正确顺序
跳过权限校验或颠倒步骤，会得到 TypeError: Illegal constructor 或 DOMException: Permission denied：
- 先调
navigator.permissions.query({ name: 'idleDetection' })，检查state是否为'granted'；仅当为'prompt'时才调IdleDetector.requestPermission() -
threshold参数不能低于60000（60 秒），传30000会被自动提升，传更低会抛RangeError - 实例化后必须显式调
detector.start({ threshold: 60000 })，否则change事件永远不会触发
监听 change 事件时区分 userState 和 screenState
只看 userState === 'idle' 就执行锁定动作，大概率误判——用户可能只是盯着屏幕发呆：
-
userState只反映输入中断：值为'idle'表示 ≥60 秒无鼠标/键盘/触控，但屏幕仍亮、页面在前台 -
screenState才是离座强信号：值为'locked'表示系统级锁屏（Win+L / macOS 快捷锁屏 / 移动端息屏），此时可认为用户已物理离开 - 真实业务中应组合判断：
if (detector.userState === 'locked' || detector.screenState === 'locked')才触发敏感 DOM 锁定；仅userState === 'idle'适合暂停图表重绘、停掉轮询等低风险操作 - 注意：Chrome 94+ 在部分 Linux 桌面或虚拟机中，
screenState可能始终返回'unlocked'，需 fallback 到userState+document.visibilityState联合判断
避免后台标签页失效和状态漂移
用户切走标签页后，change 事件可能停止触发，或恢复时状态未及时更新：
- 务必监听
visibilitychange事件：页面visibilityState === 'hidden'时调detector.stop()，恢复'visible'后再start()，防止后台耗电和误判 - 不要依赖单次
change就永久标记状态；每次触发都应重新校验detector.userState和detector.screenState，因为它们是独立更新的 - 关键业务（如考试系统、银行确认页）必须叠加服务端心跳验证——前端 API 易被绕过，仅作辅助提示
最常被忽略的一点：API 返回的状态是“快照”，不是持续流。你拿到的 userState 可能已是 2 秒前的值，而用户已在 1 秒前切回页面。真正在意响应及时性时，得自己补一层 setTimeout 倒计时兜底。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
