微信小程序 audio 操作失败：access denied 常见原因有哪些？

Question

微信小程序中 `audio` 操作报“access denied”错误，常见原因包括：① **未在真机上调试**——开发者工具模拟器不触发真实权限校验，但真机需用户授权；② **未声明必要权限**——`app.json` 中未配置 `"requiredBackgroundModes": ["audio"]`（后台播放必需），或未在 `manifest.json`（若使用 uni-app）中开启音频权限；③ **用户拒绝麦克风/录音权限**（尤其调用 `wx.getRecorderManager()` 时）；④ **非用户主动触发场景下自动播放音频**——微信禁止非手势（如 `tap`、`click`）触发的 `audio.play()`，否则静音且报错；⑤ **域名未备案或未配置合法业务域名**——`wx.createInnerAudioContext()` 加载远程音频时，`src` 域名未在「小程序后台→开发管理→业务域名」中配置并 HTTPS 化。建议通过 `wx.authorize({scope: 'scope.record'})` 提前引导授权，并用 `wx.getSetting` 检查权限状态，避免静默失败。

Answer 1

```html

一、现象层：错误表征与环境误判

“access denied”并非标准 Web API 错误码，而是微信客户端在权限/上下文校验失败时抛出的统一拒绝提示。开发者工具中一切正常，真机调试却报错——这是典型的环境隔离陷阱：模拟器不执行真实系统级权限管控（如 Android 11+ 的 MANAGE_AUDIO_FOCUS、iOS 的 AVAudioSession 激活策略），仅在真机上触发完整权限链路。

二、配置层：静态声明缺失引发的隐式拦截

微信小程序对后台音频有强契约约束。若需支持锁屏播放、切后台持续播音，app.json 必须显式声明：

{
  "requiredBackgroundModes": ["audio"]
}

uni-app 开发者还需同步检查 manifest.json 中是否启用：
"mp-weixin": { "permission": { "scope.record": { "desc": "用于录音功能" } } }

三、权限层：动态授权状态的精准诊断

权限不是“一次性授予”，而是分 scope 独立管理。以下代码实现原子化检测与引导：

const checkRecordAuth = async () => {
  const res = await wx.getSetting();
  if (!res.authSetting['scope.record']) {
    const authRes = await wx.authorize({ scope: 'scope.record' });
    return authRes;
  }
  return { authSetting: { 'scope.record': true } };
};

四、交互层：用户手势驱动的硬性合规要求

微信强制要求所有 audio.play() 必须处于用户主动触发的事件流中（tap/click/confirm 等）。以下为典型违规场景：

场景	是否合规	说明
onLoad 中自动 play()	❌	无用户手势上下文
setTimeout 后 play()	❌	脱离原始事件栈
bindtap 绑定函数内 play()	✅	符合“点击即播”契约

五、网络层：域名白名单与 HTTPS 强制策略

远程音频资源加载受双重限制：

• 域名必须在小程序管理后台 → 开发管理 → 业务域名中备案
• 协议必须为 HTTPS（HTTP 域名即使备案也拒绝加载）
• 证书需由可信 CA 签发（自签名证书将触发静默失败）

六、诊断流程：结构化排错路径

graph TD
  A[出现 access denied] --> B{是否真机运行？}
  B -->|否| C[切换真机复现]
  B -->|是| D{检查 app.json requiredBackgroundModes}
  D -->|缺失| E[补全 audio 配置并重新编译]
  D -->|存在| F{调用 wx.getRecorderManager？}
  F -->|是| G[检查 scope.record 授权状态]
  F -->|否| H{audio.src 是否为远程 URL？}
  H -->|是| I[验证业务域名 + HTTPS]
  H -->|否| J[检查 play() 是否在用户手势回调内]

七、进阶实践：权限降级与优雅兜底

当 scope.record 被拒绝时，不应中断主流程。可采用渐进式策略：

1. 首次调用前用 wx.getSetting 预检
2. 拒绝后展示引导弹窗，说明录音用途（如“语音转文字需开启麦克风”）
3. 提供「去设置」按钮，跳转 wx.openSetting()
4. 本地音频（base64 / 本地临时路径）作为 fallback 方案

八、生态差异：uni-app 与原生小程序的关键分歧点

uni-app 构建的微信小程序需额外注意：

• manifest.json 中 mp-weixin.permission 配置优先级高于 app.json
• H5 端使用 uni.createInnerAudioContext，但微信端仍走 wx.createInnerAudioContext，需条件编译
• Android 真机上，部分厂商（华为 EMUI、小米 MIUI）会二次拦截录音权限，需在 manifest 中声明 <uses-permission android:name="android.permission.RECORD_AUDIO"/>

九、安全纵深：从权限到音频会话生命周期管理

高级音频控制需理解微信的 AVAudioSession 模拟机制：

• 调用 innerAudioContext.autoplay = true 无效（违反用户手势原则）
• 后台播放时，innerAudioContext.obeyMuteSwitch = false 可绕过静音开关
• 音频中断（如来电）会触发 onInterruptionBegin，需监听并暂停播放

十、生产监控：埋点与错误归因体系

建议在关键节点注入可观测性逻辑：

// 全局音频操作拦截器
const createSafeAudio = () => {
  const ctx = wx.createInnerAudioContext();
  ctx.onError((err) => {
    console.error('[AUDIO ERROR]', {
      code: err.errCode,
      message: err.errMsg,
      stack: new Error().stack,
      timestamp: Date.now(),
      permissionState: wx.getStorageSync('record_auth_state')
    });
  });
  return ctx;
};

```