Web Audio API 访问与音频工作流
了解 Web Audio API 的访问边界，以及播放、分析、录音和回退体验的隐私友好设计。
Web Audio API 让网页能够创建、路由、分析和渲染声音。音乐编辑器、游戏、会议工具、可视化器、无障碍功能和普通媒体播放器都可以使用它。API 本身不会授予网页麦克风、扬声器或录音存档的权限；这些能力由浏览器分别决定，并有不同的用户和安全边界。
可靠的音频功能应分开回答四个问题：用户要听到什么，网页是否需要设备输入，需要什么处理，以及结果是否会保存或发送。网页通常可以在不请求设备权限的情况下播放生成的声音。麦克风采集通常需要用户明确同意 getUserMedia() 请求。录音或分析结果属于应用数据，只有在用户理解并选择后才应保存或上传。
Web Audio 的正常使用包括访问边界、可访问控制、隐私友好处理，以及上下文或输入不可用时的恢复方式。音频指纹采集和绕过浏览器权限不属于负责任的应用流程。关于渲染输出可能带来的独立隐私问题，请阅读音频指纹概览，更广泛的浏览器隐私背景见跨界面浏览器隐私指南。
选择合适的音频上下文
AudioContext 表示实时音频图。节点可以生成音调、解码资源、调节增益、应用滤波、分析流并把结果送到输出。用户按键弹奏合成器或操作游戏对象时，这种实时图很有用。网页应围绕可见任务建立图，并提供清晰的开始、暂停和停止控制。
OfflineAudioContext 在不送到扬声器的情况下把音频图渲染成 AudioBuffer，适合导出效果、准备编辑或试听前的转换。它不能替代麦克风同意，也不会把远程录音变成本地数据。应说明缓冲区代表什么，并让用户决定是否保存或分享。
W3C 规范定义节点、连接、声道和调度，MDN 提供接口说明与示例。浏览器支持和自动播放政策仍可能不同。网页必须处理上下文处于暂停状态、节点不可用、解码失败或输出路径不可用的情况，不应保证所有浏览器都支持每个节点或接受完全相同的采样率。
用用户控制开始播放
浏览器可能要求用户手势后才允许 AudioContext 产生可听输出。页面应提供明确的播放或启用音频操作，并在该操作中按需调用 resume()。按钮应反馈成功、暂停或需要再次操作的状态。不要在加载时启动隐藏声音图，然后把被阻止的启动当作内部细节。
播放、静音、暂停和停止控制应有可访问名称、可见焦点和一致的状态。音量表不能替代静音按钮，快捷键不能成为唯一的静音方式。游戏或警报的重要信息也应有文字或视觉等价物。
播放音频不等于录音。解码文件、生成音调或把媒体元素接入音频图本身不会授予麦克风权限。请求麦克风时，应先说明用途，并在轨道活动期间持续显示录音状态。用户应能在不关闭标签页的情况下停止采集。
仅在需要时请求输入
麦克风输入通常从 navigator.mediaDevices.getUserMedia({ audio: ... }) 开始。浏览器会处理请求；用户拒绝、文档无资格、没有设备或约束无法满足时都可能失败。权限不是设备永久可用的保证。代码应把拒绝作为正常分支，并保持非录音功能可用。
请求前用清楚语言说明目的，例如“使用麦克风练习音高”或“为当前草稿录制语音便笺”。只需要音频时不要请求视频，也不要为了播放而索要麦克风。权限提示属于用户决定，不能代替页面说明。
活动流应有明确指示、停止和静音操作。停止媒体轨道与暂停应用处理并不总是相同。说明声音是留在标签页、本地保存还是发送到服务；可选上传必须是独立且明确的动作。权限可能在访问期间被撤销，设备也可能消失，因此界面要提供重试或本地替代，而不是循环提示。
构建分析和录音流程
AnalyserNode 可以为电平表、调谐器或无障碍辅助提供时域或频域数据。数据应服务当前交互；只显示当前电平时可以丢弃短暂缓冲，不应无目的地保存长期历史。录音可以使用目标浏览器支持的 MediaRecorder 等机制。开始和结束、输出格式以及文件是否上传都应告知用户，并在网络传输或持久保存前提供取消和丢弃机会。
浏览器可能使用不同声道布局、采样率或编码格式。应用应读取实际流和录音器设置，不作统一硬件保证。格式不可用时，提供已说明的替代格式或下载，不要静默生成空文件。编辑时区分原始文件和派生结果；离线效果预览与保存导出应是不同操作，并说明何时数据离开浏览器。
让音频可用且可访问
音频按钮需要可访问名称、合理焦点顺序和状态通知。波形或电平表可以补充普通按钮，但不能隐藏播放、暂停、定位、静音或录音状态。重要信息不要只通过声音提供；字幕、文字稿、错误文字或视觉节奏提示都可以提供等价路径。尊重减少动画等偏好，并允许关闭非必要的视觉效果。
音量和频率可能使部分听众不适。以合理音量开始，避免意外循环，并提供快速静音。除非另有验证，不要把浏览器输出当作校准仪器。标签应描述用户动作，例如“允许麦克风进行语音练习”，而不是“启用 AudioContext 输入”。普通术语在各语言中应完整翻译。
设定音频数据的隐私边界
音频处理可以留在本地。本地图、临时分析缓冲或离线导出不需要网络请求；需要服务时，只发送完成任务所需的最少内容，并说明原因。短语音便笺、派生文字稿和原始麦克风音频的敏感性与保留需求不同。上传应由用户选择，并说明删除或替换方式。
不要把上下文状态、采样率、节点可用性或分析值当作身份结论。浏览器和操作系统行为可能不同，能力值也可能粗略或缺失。日志应记录“录音失败”或“导出取消”等产品结果，不应悄悄积累原始音频或详细设备画像。嵌入框架还受自身权限边界约束；拒绝应被说明为平台条件，而不是可绕过的错误。
从阻断或缺失的音频中恢复
先设计失败路径再设计成功路径。播放可能要等用户手势，解码可能失败，麦克风可能被拒绝，设备可能拔出，录音可能意外停止，导出也可能内存不足。每种情况都应留下已知状态、解释下一步并尽量保留工作。播放失败时可提供普通媒体元素或下载；拒绝麦克风时可保留文字笔记、导入文件或不录音练习模式。不可用的实时测量不能标成当前数据。
测试冷启动和热启动、权限拒绝与撤销、设备移除、后台切换、慢解码、不支持格式、键盘操作、缩放、字幕和本地化标签。兼容性检查应衡量任务是否完成，而不是比较不同设备的音频样本是否相同。
每次录音结束都应停止输入轨道，并释放不再使用的临时缓冲。
页面长时间打开时，不要让旧的分析循环继续运行。
播放仍可用时，状态应明确说明采集已经停止。
返回草稿时可以恢复文件和编辑位置，但不应静默重新打开麦克风。
音量偏好与录音授权是不同的选择，应分别保存和展示。
取消导出不应删除仍在本地的原始内容。
错误消息应指出受影响的动作，而不是笼统地说音频全部不可用。
设备移除后，可让用户选择另一个文件或继续无录音模式。
权限重试应由新的、易懂的用户操作触发。
嵌入式工具也要说明自己的权限范围和数据去向。
支持人员需要能根据状态判断是再次播放、选择文件还是继续编辑。
键盘和读屏测试应覆盖与视觉测试相同的播放、录音和导出状态。
这些状态让本地处理、预览和可选上传之间的界限保持清晰。
公开来源
