刚好之前研究过类似的场景，我来给你理清楚这个问题的核心和可行的方向：

核心结论：纯Web方案（含PWA）目前无法突破锁屏限制 #

你遇到的情况是移动端系统和浏览器的统一安全/资源管控规则，不是代码问题：

• 系统层面：安卓、iOS在锁屏后都会优先限制前台应用的资源占用，媒体设备（麦克风）属于高权限资源，会被直接切断以节省电量、保护隐私。
• 浏览器API限制：navigator.mediaDevices.getUserMedia() 是绑定到页面前台上下文的，一旦页面进入后台（锁屏、切换到其他App），浏览器会主动暂停并释放媒体流，这是Chrome、Safari、三星互联网等所有主流移动端浏览器的标准行为，你测试的几个平台表现一致也验证了这点。

现有Web技术栈里的尝试方向都不可行 #

你提到的几个备选思路，实际用起来都绕不开核心限制：

• PWA Service Worker：Service Worker是后台脚本，但它的权限被严格限制，只能处理网络请求、推送通知这类任务，完全没有访问麦克风等媒体设备的能力，没法帮你持续捕获音频。
• WebRTC：WebRTC的媒体流本质还是依赖getUserMedia或同类捕获API，同样受限于前台上下文，锁屏后流会被立即切断，解决不了问题。
• 浏览器实验性Flags/特殊权限：安卓Chrome确实有一些实验性的调试Flags，但这些都是给开发者测试用的，普通用户不会去开启，而且稳定性极差；iOS则完全没有开放这类权限的入口，完全不适合面向普通用户的生产环境。

可行的替代方案（Workarounds） #

如果你的业务必须实现锁屏后录音，目前只有这些务实的方向：

• 安卓端混合开发方案：把你的React PWA打包成TWA（可信Web活动），或者用Capacitor、Cordova这类跨平台框架套一个原生壳。在原生层申请安卓的RECORD_AUDIO权限和后台录音权限，由原生代码在后台持续捕获音频，再把数据传给Web层的React应用处理。这个方案需要一点原生安卓开发的基础，或者用跨平台框架的现成插件来简化开发。
• 临时妥协方案：引导用户在需要持续录音时开启「屏幕常亮」功能，安卓在「显示设置」里，iOS在「辅助功能-自动锁定」里选「永不」。虽然不是完美解决，但能在不改动技术栈的情况下满足部分用户的需求。
• 分段录音逻辑优化：如果业务允许，设计成分段自动保存的逻辑——每次检测到页面进入后台（可以监听visibilitychange事件），立即保存当前录制的音频片段；解锁回到页面后自动恢复录制。这样即使锁屏切断了流，也不会丢失之前的录制内容，体验上会顺畅很多。

最后总结 #

纯Web应用（包括PWA）受限于系统和浏览器的安全资源管控，目前无法实现锁屏后持续访问麦克风。如果这个功能是核心需求，只能结合原生层的能力做混合开发；如果可以妥协，那分段录音或引导用户开屏幕常亮是更务实的选择。