html录音按钮必须用用户点击等手势触发getusermedia，否则浏览器静默拒绝；speechrecognition仅chrome/edge支持，ios safari完全不支持，需降级方案并严格管理实例生命周期与ui状态同步。
HTML录音按钮怎么触发浏览器麦克风权限
必须用用户手势（比如点击）触发 navigator.mediaDevices.getUserMedia，否则现代浏览器会静默拒绝。自动播放、定时器、页面加载完成时调用都会失败。
- 按钮必须是真实
<button></button>或带role="button"的可聚焦元素，div绑定click但没设置tabindex可能被部分浏览器视为非可信事件源 - 调用前检查
MediaDevices是否可用：if (!navigator.mediaDevices || !navigator.mediaDevices.getUserMedia)，IE11 完全不支持，需降级提示 - 权限请求只在首次有效，拒绝后再次调用不会弹窗，得引导用户手动进浏览器地址栏点摄像头图标重新授权
Web Speech API 的 SpeechRecognition 在 Chrome 外基本不可用
SpeechRecognition 是 Chrome/Edge（基于 Chromium）专属接口，Firefox 用的是实验性 webkitSpeechRecognition 别名但已废弃，Safari 完全没实现。别指望跨浏览器语音转文字开箱即用。
- 必须做运行时检测：
const SpeechRecognition = window.SpeechRecognition || window.webkitSpeechRecognition;，如果为undefined就得 fallback 到上传音频文件 + 后端 ASR（如 Whisper API） - 即使在 Chrome，
lang参数不填默认是"en-US"，中文必须显式设为"zh-CN"，否则识别率极低 - 连续识别容易断连，建议每次点击按钮都新建实例，避免
end事件未触发导致状态卡死
录音按钮状态与 DOM 更新不同步的典型表现
常见现象：点击“开始”按钮后，按钮文字没变、禁用没生效，或“停止”按钮点了没反应——本质是没同步维护 isRecording 状态和 UI 层绑定。
- 不要只靠
recognition.onresult更新文本，它只在有识别结果时触发；要用recognition.onstart和recognition.onend控制按钮状态 - 用户中途关闭麦克风权限，
onend会触发但error不一定抛出，需监听recognition.onerror并检查event.error === "not-allowed" - 转写区域建议用
contenteditable="true"的<div> 而非 <code><textarea></textarea>，方便后续插入实时气泡、高亮关键词等扩展，但要防用户误删正在识别中的占位符移动端 iOS Safari 录音失败的硬限制
iOS Safari 从不支持
SpeechRecognition，且getUserMedia在非 HTTPS 环境下完全不可用（连localhost都不行），即使本地开发也得用https://127.0.0.1或工具启 https server。- 真机调试必须走 HTTPS，HTTP 协议下
navigator.mediaDevices是undefined - 没有替代方案：iOS 原生 WebKit 引擎未开放语音识别能力，PWA 也无法绕过，只能引导用户跳转到系统备忘录/快捷指令，或接入第三方 SDK（如 Azure Speech SDK 的 wasm 模式，但延迟高、包体大）
- 别信“iOS 17 支持了”，截至 2024 年中，官方文档和实测均确认无变化
- 真机调试必须走 HTTPS，HTTP 协议下
