HTML录音不直接影响媒体流，但不当实现会干扰MediaStream的可用性、延迟和资源占用；根本原因是MediaRecorder默认接收含视频的全流，应提取纯音频流、避免重复start、共用流时注意生命周期、后台切页需暂停而非停流、实时分析需另接AudioContext链路。
HTML 录音本身不直接“影响”媒体流，但不当的实现方式会严重干扰 MediaStream 的可用性、延迟和资源占用——尤其是当你同时采集、处理、传输或播放时。
为什么 MediaRecorder 一启用就卡顿或掉帧？
根本原因不是录音本身耗资源，而是默认把整个 MediaStream（含视频轨道）喂给 MediaRecorder，而浏览器对高分辨率视频编码压力极大，尤其在低端设备上。
- 只录音频？务必用
stream.getAudioTracks()单独提取音频轨道，再用new MediaStream(audioTracks)构造纯音频流传给MediaRecorder - 避免重复调用
mediaRecorder.start()：多次 start 不会叠加，但会触发内部重初始化，造成短暂流中断 - Chrome 117+ 对
MediaRecorder的audioBitsPerSecond支持有限，设太高（如 256000）可能被静默降级，建议实测用128000或96000
getUserMedia 和 MediaRecorder 能共用一个 MediaStream 吗？
能，而且推荐——但必须注意生命周期管理。共用流可避免重复权限请求和硬件通道争抢，但一旦流被 stop()，所有依赖它的对象（包括正在录音的 MediaRecorder）会立即报错 InvalidStateError: The MediaRecorder is inactive。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 不要在录音中调用
stream.getTracks().forEach(t => t.stop()) - 若需动态关闭某轨道（比如关麦），用
track.enabled = false，而非track.stop() - 页面切后台时，部分浏览器会自动 suspend 流；监听
visibilitychange，必要时暂停MediaRecorder而非停流
想边录边实时分析音频（比如 VAD）怎么办？
不能直接从 MediaRecorder 拿数据——它只输出 Blob。必须另起一路 AudioContext + MediaStreamAudioSourceNode，从同一原始流接入分析链路。
立即学习“前端免费学习笔记（深入）”；
- 用
const context = new AudioContext()创建上下文，再context.createMediaStreamSource(stream) - 避免在
onaudioprocess回调里做重操作；改用ScriptProcessorNode已废弃，应使用AudioWorklet - 注意采样率对齐：如果
getUserMedia返回的是 48kHz 流，但AudioContext默认是 44.1kHz，需显式指定new AudioContext({ sampleRate: 48000 })
真正难的不是开启录音，而是让流在多任务并行时保持稳定——尤其是移动端。很多问题出现在「以为流还活着」却没检查 track.readyState 或 mediaRecorder.state，结果在 silent failure 中浪费半天调试时间。
