diff --git a/ylgamehall/Source/Bridge/Handlers/RemoteAudioHandler.swift b/ylgamehall/Source/Bridge/Handlers/RemoteAudioHandler.swift
index 124dc07..ff35b3f 100644
--- a/ylgamehall/Source/Bridge/Handlers/RemoteAudioHandler.swift
+++ b/ylgamehall/Source/Bridge/Handlers/RemoteAudioHandler.swift
@@ -99,18 +99,24 @@ public enum RemoteAudioHandler {
 
         case .notDetermined:
             // 首次启动：弹系统权限对话框，**不**启动录音浮层（避免与 touchObserver
-            // 死锁）。用户做完选择 / 第二次按录音按钮时走 .authorized 分支正常录音。
-            //
-            // ⚠️ daoqi ifauth 在 .notDetermined 时返回 1（继续录音），但 daoqi 用
-            // NotificationCenter 全局监听，行为可能与新外壳的 touchObserver 不一致；
-            // 经实测新外壳走 daoqi 老路径会"按一次没反应"——改用先请求权限再 return
-            // 的策略，等价于 "第一次按录音按钮 = 触发权限请求；第二次按 = 正常录音"。
+            // 死锁——touchObserver 会捕获用户松手点"允许"的动作立刻 stop 录音）。
+            // 用户做完选择 / 第二次按录音按钮时走 .authorized 分支正常录音。
             _ = await withCheckedContinuation { cont in
                 AVAudioSession.sharedInstance().requestRecordPermission { granted in
                     cont.resume(returning: granted)
                 }
             }
-            // 无论用户允许/拒绝都不触发 cb（H5 端会因没收到 cb 知道本次录音未发生）
+            // ⚠️ 必须触发 cb（对齐 daoqi ifauth==1 路径行为，daoqi NewRootVC.m:322
+            // 在 [recorderVC beginRecordByFileName:] 后总是 responseCallback）。
+            //
+            // 不触发 cb 的后果：H5 业务在 callHandler 调用后通常会上"录音中"业务锁
+            // （加触摸遮罩、禁用按钮等），等收到 cb 才解锁。系统权限对话框已经把
+            // H5 的 in-flight touch 打断为 touchcancel，H5 业务的 touchcancel 处理
+            // 可能不完善 → 业务锁不释放 → 整个 H5 后续无法点击。
+            //
+            // 触发 cb 让 H5 释放业务锁，即使本次实际未录音也无害（H5 会按"无
+            // getaudiourl"的失败路径走，与 daoqi 转码失败 silent 路径等价）。
+            callback?(.string("Response from prepareaudio"))
             return
 
         case .authorized: