运行时安全异常是沙箱主动防御的关键反馈点，用于实时感知、拦截与响应风险，将“代码出错”转化为“风险受控”；它作为权限校验最终闸门，统一捕获并结构化处理权限拒绝、资源超限等异常，实现熔断、动态风控、线程级隔离及结构化上报。
运行时安全异常不是故障信号，而是沙箱主动防御的关键反馈点。在开放平台中，它被用作实时感知、拦截与响应的触发器，把“代码出错”转化为“风险受控”的机会。
把异常当作权限校验的最终闸门
小程序调用摄像头、读取剪贴板或发起网络请求时，沙箱不会只依赖预设白名单做静态放行。它会在实际执行前插入一层运行时检查——若该小程序未被授予对应权限，系统会抛出标准化的安全异常（如 SecurityError: Permission denied for 'getLocation'），而非让原生API直接执行。这种异常由沙箱统一捕获、记录并返回结构化错误，既阻断越权行为，又避免因未处理异常导致宿主APP崩溃。
- 所有敏感端能力调用必须经过沙箱代理层，禁止绕过
- 异常类型需区分：权限拒绝、资源超限、API禁用、签名失效等，便于后台分类处置
- 对高频异常调用（如1秒内5次定位请求）自动触发临时熔断，防止探测式攻击
用异常行为建模实现动态风控
静态规则无法覆盖所有恶意模式。沙箱需在运行过程中持续采集行为日志，当检测到异常组合时启动干预。例如：
- 某小程序在无用户操作前提下频繁调用 getSystemInfo + getNetworkType + getBatteryInfo，构成设备指纹采集特征
- JS线程持续占用CPU超80%达3秒，且伴随 eval 或 new Function 调用，疑似混淆执行
- 网络请求目标域名不在备案列表，且响应体含Base64编码的二进制数据
这些行为本身不违法，但组合出现即触发沙箱级异常，可立即冻结执行、上报管控后台，并支持人工复核后永久下架。
异常隔离必须做到进程/线程级收口
一个小程序抛出未捕获异常，不能影响其他小程序或宿主APP。这要求沙箱底层具备强隔离能力：
- 每个小程序运行在独立 JS 引擎实例（如 QuickJS 隔离上下文）或独立线程（Android HandlerThread / iOS JSContextGroup）
- 主线程仅负责调度与通信，不执行业务逻辑；崩溃只终止当前上下文，不触发 APP 全局异常处理器
- 内存泄漏类异常（如闭包长期持有 DOM 引用）通过定时巡检+堆快照比对识别，超阈值则强制回收上下文
异常数据要成为运营决策依据
沙箱产生的每一条运行时异常都应结构化上报至管控平台，形成可分析的安全资产：
- 按小程序 ID、版本号、设备型号、OS 版本、异常类型、堆栈片段打标存储
- 后台配置策略：对同一异常类型单日超1000次的小程序自动暂停上线资格
- 支持按渠道来源聚合分析——若某合作方接入的多个小程序集中出现 WebView XSS 检测失败 异常，说明其前端构建流程存在共性风险
不复杂但容易忽略的是：异常本身必须可控、可追溯、可闭环。它不是沙箱的缺陷，而是你掌握第三方代码真实行为的唯一窗口。
