Page Visibility API 仅通知页面可见状态，不提供加密能力；需通过模糊化日志、限制监听器、HTTPS 安全上下文、多信号校验等措施保障隐私与安全。
HTML5 页面可见性变化（Page Visibility API）本身不提供加密能力，它只是通知页面是否处于前台或后台的简单状态变更。所谓“加密可见性数据”，实际是指在监听 visibilitychange 事件时，对相关行为或敏感信息进行安全处理，防止被恶意脚本窃取、滥用或用于用户追踪。核心不是加密 API 数据本身，而是控制数据使用方式与上下文安全性。
避免在 visibilitychange 中暴露敏感状态逻辑
页面是否可见常被用于触发关键操作（如暂停视频、停止轮询、释放资源），但若这些操作间接暴露用户行为模式（例如：检测用户离开页面即自动提交未加密表单、记录精确切换时间戳用于画像），就构成隐私风险。
- 不要将 visibilitychange 作为唯一判断依据来执行身份验证、支付确认或会话续期等高敏操作
- 避免在事件回调中直接拼接并发送含用户标识、停留时长、切换频率的明文日志到第三方统计服务
- 如需上报，应对时间戳做模糊化（如四舍五入到分钟级）、对页面路径脱敏（如 /user/profile/123 → /user/profile/:id）
限制 visibilitychange 事件监听器的执行权限
恶意第三方脚本可能劫持或伪造 visibilitychange 行为。应确保监听逻辑运行在受信上下文中，并最小化依赖外部输入。
- 使用
addEventListener('visibilitychange', handler, { once: true })或手动移除监听器，避免内存泄漏与重复绑定 - 敏感 handler 函数内避免调用不受控的全局函数或 eval 类动态执行代码
- 在 Content Security Policy（CSP）中禁用
unsafe-inline和unsafe-eval，防止 XSS 注入伪造事件
结合 HTTPS 与 Secure Context 要求
Visibility API 在非安全上下文（HTTP）中部分功能受限，且明文传输 visibility 状态易被中间人篡改或监听。必须确保：
立即学习“前端免费学习笔记（深入）”；
- 页面通过 HTTPS 加载，所有资源（包括 iframe 内嵌页）也需为 HTTPS，否则
document.visibilityState可能返回visible即使实际不可见 - 检查
isSecureContext属性，仅在安全上下文中启用依赖可见性的关键功能（如 WebRTC 唤醒、加密密钥派生） - Service Worker 中监听 visibilitychange 需谨慎——SW 无法直接访问 document，应通过 postMessage 与主页面通信，并验证消息来源
不依赖 visibilitychange 做唯一安全边界
该 API 易被绕过（如浏览器调试工具强制修改 document.hidden、插件屏蔽事件、移动端分屏/画中画场景下状态不准确）。不能将其作为防录屏、防截图、防复制的核心机制。
- 涉及版权内容展示时，应叠加 DRM（如 EME）、水印、Canvas 混淆等多层防护，而非仅靠隐藏页面就认为“数据已保护”
- 需要强用户专注验证的场景（如考试系统），应结合键盘/鼠标活动、焦点状态、屏幕共享检测等多信号交叉判断
- 后端需校验前端传来的可见性相关标记（如 “page_active”: true），不可盲信，应与会话心跳、设备指纹等联合风控
不复杂但容易忽略：visibilitychange 是轻量级提示，不是加密开关，也不是访问控制门禁。真正要“加密”的，是开发者对这个信号的理解方式和后续动作设计。
