调用MediaStreamTrack.stop()后摄像头灯仍亮是因轨道非唯一使用设备或未彻底清理流；需遍历stream所有track.stop()并置空stream引用，才能真正释放硬件。
MediaStreamTrack.stop() 为什么调用后摄像头灯还亮着
直接调用 stop() 不一定立即关闭硬件采集，尤其在 Chrome 中：该方法只标记轨道为“ended”，但浏览器可能延迟释放设备（比如等待其他轨道复用同一设备）。现象是 track.readyState 变成 "ended"，但摄像头指示灯不灭、麦克风仍在被系统占用。
真正起效的前提是：该 MediaStreamTrack 是唯一使用该物理设备的轨道，且没有其他 MediaStream 持有它。常见错误是重复调用 navigator.mediaDevices.getUserMedia() 后只停了新流里的轨道，老流还在运行。
- 务必先检查
track.enabled—— 如果是false，stop()实际无副作用 - 调用
stop()后，立刻设track.onended = null避免残留监听器干扰 - 若需彻底释放，应同时调用
stream.getTracks().forEach(t => t.stop())，再置空stream引用
stop() 和 track.enabled = false 的根本区别
track.enabled = false 仅停止轨道数据输出（比如视频帧不更新、音频静音），但设备仍被占用；stop() 则声明放弃设备控制权，是释放资源的正确方式。两者不可互换。
-
enabled = false可随时恢复（设回true），适合临时静音/遮盖 -
stop()是单向操作，调用后track.readyState永远变为"ended"，不能再启用 - 对
audio轨道，仅设enabled = false无法阻止网站后台持续采集——stop()才能切断采集链路
实际停止摄像头/麦克风的可靠步骤
不能只停单个轨道，必须从流源头清理。典型安全释放流程如下：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
const videoTrack = stream.getVideoTracks()[0];
const audioTrack = stream.getAudioTracks()[0];
// ✅ 正确：先停所有轨道，再断开引用
stream.getTracks().forEach(track => track.stop());
stream = null; // 帮助 GC，避免意外重用
// ❌ 错误：只停 videoTrack，audioTrack 仍在采集
// videoTrack.stop(); // 麦克风依然工作
- 如果用
MediaRecorder，必须在其stop()后再停轨道，否则可能触发DOMException: InvalidStateError - 在
pagehide或beforeunload事件中调用清理逻辑，防止用户切页后设备仍被占用 - 移动端 Safari 对
stop()响应较慢，建议加setTimeout(() => {}, 100)做短延时兜底（非必需但更稳妥）
如何验证摄像头/麦克风是否真被释放
不能只看 track.readyState，要结合系统级反馈：
- macOS：顶栏摄像头图标消失；Windows：设置 > 隐私 > 相机/麦克风里对应网站权限显示“未使用”
- Chrome 地址栏右侧点击摄像头/麦克风图标，确认无绿色指示灯且显示“已停用”
- 用
navigator.mediaDevices.enumerateDevices()查看deviceId对应设备的label是否仍被当前页面占用（部分浏览器支持） - 若调用
stop()后再次getUserMedia报错NotAllowedError，说明前次未清理干净，很可能有轨道遗漏
最易被忽略的是：多个 MediaStream 实例可能共享同一物理设备，停掉 A 流里的轨道，B 流还在用——必须遍历所有已知流并统一清理。
