企业官网建设流程全解析

做实时音视频的同学应该都有过这种体验：第一次跑通WebRTC Demo，打开页面弹出一个摄像头授权框，点允许之后画面才出来。这个授权框看起来简单，背后却牵扯了整个浏览器内核里权限管理、设备枚举、渲染进程通信的一整套链路。作为“WebRTC源码研究”系列的第11篇，我打算把音视频设备访问权限这部分源码掰开揉碎，讲清楚从JS里调一次getUserMedia到真正打开摄像头，中间究竟发生了什么，权限失败时错误状态是怎么一层层传回来的。

这篇内容适合给三类人看：一是正在读WebRTC源码、想理清权限链路的开发者；二是做实时通信和音视频业务的客户端、前端工程师，需要排查很多听上去“玄学”的权限问题；三是只调过API但想知道为什么有些场景必须HTTPS、为什么iframe里调摄像头会被拦、为什么用户点了拒绝之后代码里再请求一次也没反应的普通开发者。读完你会对整个权限体系有更清晰的坐标系。

1. 权限访问的整体设计：为什么要有“授权”这个环节

1.1 安全沙箱与权限代理

浏览器设计Web应用访问摄像头时有一个绕不开的原因：网页代码运行在沙箱里，操作系统不会把摄像头设备直接暴露给任意网页。如果网页能直接打开摄像头，那么任何一个广告页面都能偷偷录视频。所以浏览器必须扮演中间人，把操作系统的设备访问能力和网页的调用诉求隔开，授权确认就是中间人核身的过程。

源码上，渲染进程和浏览器进程是分开的：渲染进程跑网页的JS，没有直接打开硬件设备的权限。JS调用getUserMedia后，请求会被封装成IPC消息发到浏览器进程，由浏览器进程里的权限模块先询问用户，再通过系统设备服务去打开摄像头。这里用的是“权限代理”模式，渲染进程是请求方，浏览器进程是执行方。即使网页被攻破，攻击者也只是一个渲染进程里的代码，拿不到直接操作硬件的句柄。

这个设计其实很像现实中的门禁系统。你想进机房，不是直接拿钥匙开门，而是先到前台登记，前台确认你有权限后，再帮你把门打开。网页拿到的“钥匙”只是浏览器的媒体流句柄，不是系统设备的真实句柄，所以权限被收回时，浏览器能从设备层直接把门锁死。

1.2 权限模型的分层状态

WebRTC的权限并不是简单的“同意/拒绝”，我扒源码时候发现它分了三个状态，源码里对应独立的枚举定义：

• granted：允许，可以访问设备并获取真实设备信息
• denied：拒绝，拒绝后再次调用，浏览器不会重新弹窗，直接返回NotAllowedError
• prompt：还没有决定，需要弹出授权引导

这三个状态会持久化到磁盘配置里。刷新页面、重启浏览器之后，granted和denied状态仍然保留，prompt状态通常只在当前会话内有效。源码里对这个模型的约束还体现在“状态一旦变化会通过权限观察者通知到渲染层”，所以页面在后台可以监听权限变化。

核心思路就是：把权限决策从设备访问中剥离出来，先决策后访问。这种设计的优势在于，设备的能力被隐藏在内核设备管理层后面，网页只能拿到一个媒体流句柄，拿不到设备真实路径，也拿不到物理设备之外的底层硬件信息。从隐私保护角度看，这也是渐进式授权的基础。

1.3 为什么必须是用户手势触发

WebRTC标准里有一条硬性要求：getUserMedia必须由用户手势触发，比如点击按钮。这个约束在源码实现上被拆成两部分：一是调用链路的合法性检查，二是IPC消息里会携带手势状态。浏览器进程收到请求后，会确认最近是否有用户输入事件，如果没有就拒绝。

这个设计防止的是网页在后台预加载时偷偷请求摄像头权限。我在调试时踩过坑：页面onload里直接调getUserMedia，结果必定失败，哪怕权限之前已经给过；必须把调用移动到click事件的回调里，状态才正常。审查源码时可以看到一个关键判断：请求进入权限模块前，会有专门的手势校验器检查当前引擎是否有用户激活信号，这部分逻辑在渲染进程的绑定层就完成了。

2. 源码链路拆解：一次getUserMedia调用的完整历程

2.1 JS API层到C++绑定

先从JS这边看。开发者写的是：

const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });

navigator.mediaDevices是浏览器注入页面的API对象，它的getUserMedia方法在实现上走的是WebIDL绑定，会在渲染进程创建一个MediaDevices实例，然后调用C++层对应方法。源码里的核心函数名是MediaDevices::getUserMedia。

这个函数不是直接去开设备，而是先做参数解析：解析audio和video约束，把true展开成一组默认约束，比如要求开启一个视频轨道、一个音频轨道，音频要打开回声消除等等。解析完成后，它会检查当前页面是否是安全上下文。这个安全检查是第一批判负条件：如果页面不是HTTPS或localhost，后面都不用走了，直接给NotAllowedError。

2.2 IPC到浏览器进程

参数解析通过后，渲染进程会向浏览器进程发一条IPC消息，消息类型在源码里对应RequestMediaDevicePermission。浏览器进程的MediaStreamDispatcherHost收到消息后，第一步是检查页面所在frame的权限策略，第二步是向权限管理模块查询当前网站的摄像头和麦克风权限状态。

如果权限状态是prompt，浏览器就会弹原生权限提示。注意这个提示框是浏览器进程的UI层画的，不是网页内容，所以网页无法伪装、无法拦截。用户点击允许之后，权限管理模块把状态改成granted，并且持久化到站点设置里。如果用户点击拒绝，持久化状态变成denied，后续请求将走直接判负分支。

2.3 设备打开与流创建

权限通过后，浏览器进程才会真正去枚举和打开设备。以摄像头为例，VideoCaptureManager会去系统层找设备列表，找到对应设备后，使用设备捕获API打开流，返回一个流句柄给浏览器进程。

这句话值得标出来：权限检查和设备打开是分离的。权限通过了不代表设备能打开成功。设备可能被别的程序独占、可能已经拔出、可能分辨率不支持。所以代码里会有两层错误：一是权限错误，二是设备错误。很多新手会把NotReadableError当成权限拒绝处理，其实它对应的是“设备无法被读取”。

随后浏览器进程把成功或失败的结果通过IPC回传到渲染进程，渲染进程再把结果包装成MediaStream对象或者抛出DOMException。到这里，页面里拿到的stream才真正可以往video元素上交由srcObject。整个过程是一条很长的异步链路，任何一段出问题，最终的Promise都会reject。

2.4 关键源码类关系

用一张表把涉及的关键服务理一下，我在读源码时按这张表对照着看效率很高：

这个分层关系是所有WebRTC权限问题的根。只要权限状态不对，后面所有设备层根本不会执行。所以排查问题时，第一步永远先判断是权限层的问题还是设备层的问题。

3. 设备枚举与“默认设备”背后的实现细节

3.1 enumerateDevices的权限敏感行为

源码研究里，权限对设备枚举的影响体现在一个非常微妙的地方：调enumerateDevices不需要授权，但返回的信息会“脱敏”。在用户没有授权摄像头或麦克风权限时，设备列表里每个设备的label字段是空字符串，deviceId也是基于origin混淆过的临时ID；用户授权之后，这些字段才返回真实名称。

这样做是为了防止网页在用户未授权时就通过设备名获取环境信息。比如浏览器插着一个USB摄像头，设备名可能是“某个型号的摄像头”，未授权时你拿不到这个名字。源码里实现这个逻辑的位置是MediaDeviceManager，它在返回设备列表时检查当前站的权限状态，决定要不要填充真实label。

这个脱敏策略不仅是隐私保护，也是权限引导的一部分。很多Web应用会在首页先调用enumerateDevices，此时只能拿到数量、类型、分组ID，拿不到名称。页面可以先展示“检测到1个摄像头”，引导用户点击授权，授权成功后再展示具体型号。体验设计上也要注意：授权前和授权后的设备列表结构可能不一致，不能用缓存直接替代。

3.2 临时设备ID与浏览器指纹

设备ID也是敏感信息。源码里不会把系统级的设备唯一ID直接暴露给网页，而是生成一个随机ID，并且这个ID会随着每次会话变化，防止网站通过固定设备ID追踪用户。这背后的逻辑是：设备ID如果固定，一个网站就能知道“又是同一台电脑的同一个摄像头”，跨站合谋就能做浏览器指纹。

所以你在实际开发中会发现，刷新页面可能导致deviceId变化，不要把自己的业务逻辑绑死在这个ID上。如果一定要保存用户上一次选择的设备，需要用户在授权状态下重新枚举，并且接受ID可能变化的现实。某些多设备管理场景下，可以靠label和groupID辅助判断。

这里有个源码层面的细节：分groupID是按物理设备分组的，同一台物理设备上的摄像头和麦克风会共享groupID。在做音视频通话时，可以通过groupID把摄像头和麦克风的默认选择绑定到同一个硬件设备，避免摄像头选A设备、麦克风选B设备的尴尬。

3.3 设备插拔与devicechange

源码里设备列表是动态的，系统设备变化后，浏览器会广播devicechange事件到页面。这个机制实现上依赖系统设备监听器，比如在桌面系统中监听USB热插拔。事件触发后，页面重新枚举设备列表，就能看到新增或消失的设备。

这里有个实操建议：不要一上来就全部枚举，可以在需要列出设备时才调enumerateDevices，因为每次枚举都会触发系统设备扫描，有一定开销。移动端上这个开销尤其明显。结构上要监听devicechange，但回调里只做“设备列表可能变化”的提示，再让用户点击“刷新”去真正枚举，避免频繁扫描。

我调试时发现，虚拟设备驱动会让devicechange变得更频繁，某些测试环境甚至会出现循环触发。所以监听器的回调里最好加节流，并在一段时间内只响应最后一次事件。源码里对应的事件发送中心会在收到系统通知后合并去重，但页面侧还是要自己做保护。

3.4 “default”设备的特殊处理

源码里设备列表前几个通常是default音频输出、default摄像头、default麦克风。这些不是实体设备，而是系统默认设备的一个虚拟条目，指向当前系统默认设备。当系统默认设备变化时，这个虚拟条目仍然保持唯一，但背后实际设备可能在变化。

做设备选择UI的时候要注意：如果用户选择“default”，约束里传空字符串或不传设备ID，浏览器会fallback到系统默认设备。但有些业务需求希望选择具体设备，就必须在枚举结果里排除default前缀，否则会把虚拟设备当成实体设备存配置，下次重启后可能失效。

在源码里，default条目是通过设备枚举过滤器添加的虚拟元素，它不等于系统中的某个固定设备。很多调试问题都出在把default当成真实设备存储，导致切换设备后流打不开。建议在业务层把default和具体设备分开建模，一个代表“跟随系统”，一个代表“固定选择”。

4. 权限状态管理：持久化、取消与iframe策略

4.1 权限状态写入站点配置

浏览器内核会把权限状态按origin维度存储，源码里对应site permission settings。granted和denied都会持久化，用户可以在浏览器的站点设置里看到当前网站被授予的摄像头或麦克风权限，并手动改成询问、拒绝或允许。

对开发者来说，理解持久化能解释很多现象：为什么用户点过一次“拒绝”之后，你再次调getUserMedia，不会弹窗，而是立刻失败？因为权限状态已经持久化成了denied。如果想要重新提示，需要用户在浏览器设置里把该网站的摄像头权限改回“询问”。页面侧能做的事情有限，只能检测到当前状态是denied，然后指引用户去设置。

源码里的权限持久化模块还负责处理站点数据的清除。当用户清空站点数据或者cookie时，对应origin的权限状态也会一起重置。所以“清除站点数据”也是权限问题的万能排查手段。需要注意，这个行为和普通cookie的清除是联动的，开发环境反复切换站点配置时很容易踩到。

4.2 同一网站下不同页面的权限共享

权限按origin而不是按标签页管理。所以同一个域名下，A页面授权了，B页面打开时大概率可以直接拿设备，不需要再次弹窗。这个设计的目的是减少弹窗打扰。但也带来一些边界：如果A页面拿走了摄像头，B页面再打开同一个摄像头，浏览器进程里的设备管理器会根据引用计数决定是重新打开，还是复用已有句柄。

源码里设备句柄复用逻辑是后来加的重点，它的存在让“同源多页面共享一个摄像头”成为可能，同时也带来了状态同步问题，比如一个页面释放了设备，另一个页面还在用，设备不能直接关闭。做多页面协作应用时需要清楚这套共享机制。

这个共享机制对业务的影响是：如果你在页面A开启了采集，页面B也尝试用同一个摄像头，浏览器一般不会报错，而是会把视频流复制一份给B。但如果页面A把track停止，页面B的流也会受影响，因为底层摄像头可能被真正关闭。所以多页面场景下，建议统一由一个顶层页面来管理设备生命周期，其他页面通过专有通道获取共享流。

4.3 权限策略：iframe为什么会被拦

很多开发者遇到的问题是：在iframe嵌的页面里调getUserMedia，提示被Permissions Policy阻止。这不是bug。浏览器对iframe有一套权限委托机制，默认情况下，跨源iframe不能获得摄像头权限，除非父页面在iframe标签上显式加上allow属性。

源码里权限检查是逐frame进行的，且父frame可以通过Permissions-Policy HTTP头限制子frame的能力。你可以在iframe标签上写：

<iframe src="..." allow="camera; microphone"></iframe>

这样才能把摄像头和麦克风权限委托给子frame。如果外层没有授权，子frame里再怎么调getUserMedia都会被直接拒绝，错误类型是SecurityError，错误信息里会带Permissions Policy字样。很多时候被if不能正常采集，并不是设备或权限问题，而是没有在嵌入时声明allow。

4.4 清除权限与权限更新通知

用户可以在站点设置里手动撤销权限，此时浏览器内核会触发权限变更通知，渲染进程会监听到状态更新。WebRTC规范里更新的是媒体设备枚举状态：已打开的设备可能被系统强制关闭，页面的track会进入ended状态。

源码里这个处理做得比较细：在权限被撤销后，已存在MediaStreamTrack会收到ended事件，播放中的画面会黑掉。业务代码需要监听track.onended，及时提醒用户去重新授权或者做状态埋点。很多人只处理getUserMedia的失败，忽略了运行中权限被吊销的情况，这在一些基于开源浏览器内核的定制环境中尤其重要。

5. 常见问题与排查实录

5.1 NotAllowedError：权限被拒绝或缺少用户手势

这个错误是最常见的。排查步骤我建议按顺序看：

1. 是不是在非安全上下文里调用：检查页面是否localhost或HTTPS
2. 是不是没有用户手势：确认调用在click或tap事件回调内部
3. 是不是之前被拒过：打开浏览器站点设置里查看权限状态
4. 如果是iframe场景：检查allow属性和Permissions-Policy

如果以上都没问题，可以打开浏览器日志终端看源码里的PermissionManager日志，它会打印权限检查的链路，直接能看到走到哪一个判断分支失败。我在实际排查时发现，一半的NotAllowedError都不是用户真的拒绝，而是第一次请求时不在用户手势里，导致权限请求被浏览器当作“骚扰式请求”直接屏蔽。

5.2 NotFoundError：没有找到可用设备

设备不存在或者驱动未安装时会抛NotFoundError。测试环境下最容易遇到，比如虚拟机里没有摄像头。排查时用enumerateDevices先试试能否拿到设备列表，如果列表为空，多半是系统层就没有设备。

这里有个调试技巧：在桌面端可以用虚拟摄像头驱动调试，这样即使没有真实摄像头也能模拟出设备。在做自动化测试时，浏览器内核通常会提供一组命令行启动参数，把所有设备替换成假设备，方便跑集成测试。这时候就能专注测权限和链路逻辑，而不是纠结物理设备。

5.3 NotReadableError：设备被占用

NotReadableError表示设备被其他程序占用，或者是设备打开失败。注意它和NotAllowedError的区别。我见过一个典型案例：本地摄像头被另一个会议软件占用，Web里调用getUserMedia抛NotReadableError。但用户以为是权限拒绝，反复去改权限设置，当然解决不了。

源码里这个错误来自设备打开阶段，而不是权限阶段。处理思路是提示用户关闭占用摄像头的程序，或者提供重试按钮，延迟几秒再试。如果重试仍然失败，可以尝试用前一个track的stop来释放设备句柄。源码中设备打开是有句柄计数的，页面里没有停掉之前的track就会一直占着摄像头。

5.4 页面黑屏但设备灯亮：权限回调没正确处理

有时候权限弹窗允许了，摄像头灯是亮的，但页面里没有画面。这类问题往往是约束没有正确配置或video元素srcObject没有赋值，例如：

const stream = await getUserMedia({ video: { deviceId: savedDeviceId } }); video.srcObject = stream; await video.play();

如果保存的deviceId已经失效，设备打开可能仍旧成功但流是空的。这时候建议在切换设备前先用enumerateDevices确认ID还在，再校验stream.getVideoTracks().length。源码里设备ID是临时ID，重启后会变，用旧ID去请求时会触发回退逻辑，但不同版本内核行为不同，最好自己控制。

5.5 权限状态检查API

WebRTC里没有标准API直接查询摄像头权限状态，只能用Permission API。它可以查navigator.permissions.query({ name: 'camera' })，返回granted、denied或prompt。但这个API在不同浏览器中的支持程度不同，实测中发现一部分浏览器会把camera的权限状态一直返回prompt，哪怕已经授予过。所以权限状态查询只能作为辅助，不要依赖它做唯一的UI判断。

我常用的方式是：在getUserMedia的catch里根据错误类型反向判断状态。NotAllowedError是权限层问题，再引导用户授权。这比Permission API可靠。源码里Permission API和WebRTC权限请求是两套独立的服务，虽然数据源可能相同，但更新时机和缓存策略并不总是一致，所以不要假设它们永远同步。

5.6 源码调试的三个关键断点

如果你真的想从源码角度排查问题，可以在以下位置打断点：

• MediaDevices::getUserMedia：看参数解析和用户手势检查
• MediaStreamDispatcherHost::OnRequestDevice：看IPC请求是否到达浏览器进程
• PermissionController::RequestPermission：看权限状态查询和弹窗决策

这三个断点串起来就是一次权限请求的完整生命周期。只要断点位置能走到，大概率问题出在设备打开段；如果连这会都走不到，说明权限阶段就被拦下了。断点调试过程中，最好把浏览器自带的站点权限设置面板也打开，配合观察状态是怎么从prompt变成granted或者denied的。

我最初读这块源码时，被权限模型和设备枚举状态绕了很大一圈，尤其是不理解为什么授权后deviceId还会变、为什么同一网站换个标签页摄像头还能共享。后来把“权限决策”和“设备访问”两条链路分开理解，所有现象都对上了：权限决定你能不能问设备，设备层决定你问来的时候它是空闲还是被占。实际开发里，最容易被低估的其实是运行中的权限撤销和iframe策略，这两块往往在正式环境才会暴露问题。建议你动手读源码时，先跑通一个最小页面，在断点状态里看一遍完整的IPC往返，之后再去看设备枚举那一层，印象会深很多。最后再分享一个小技巧：在本机调试时把浏览器启动参数里加上媒体流假设备开关，调试权限逻辑时就不用反复插拔摄像头，专注在链路本身，效率能提升不少。