一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 用户授权弹窗之前，Permissions Policy 就可能禁止功能。顶层站点的响应头与 iframe allow 必须同时允许，跨源嵌入还受来源列表约束；把这类拒绝显示成“设备坏了”会误导排查。
浏览器能力由版本、权限、页面可见性和设备策略共同决定。实现需要能力探测与可解释降级，不能把某一台开发机上的 API 存在当成产品契约。
设计时必须回答的问题
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 顶层默认只开放实际需要的能力，对第三方 iframe 采用明确 allowlist。
- 启动时检测 policy 与 API 能力，错误文案区分策略禁止、用户拒绝和设备缺失。
- 全屏与剪贴板也进入嵌入契约，文档说明宿主必须添加的 allow 值。
权限策略是部署契约的一部分。先最小开放，再提供可诊断的能力检测，嵌入场景才不会靠猜测解决。
边界情况不是附加项
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 开发直开页面正常，上线被门户 iframe 嵌入后所有捕获同时失败。
- 响应头用通配来源开放敏感能力，任意嵌入方都可诱导授权。
- 策略变更只测 Chromium，其他浏览器忽略或解释差异导致界面错误。
用证据确认它真的可用
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 对同源、允许跨源和未允许跨源三种 iframe 运行完整权限矩阵。
- 分别拒绝 policy 与用户弹窗，确认日志、提示和恢复动作完全不同。
- 扫描生产响应头和嵌入文档，确保默认值、CSP 与 allow 配置一致。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。