十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
“点一下录音，App 就退出了。”这类反馈很短，也足够让我停下来重新检查自己对“已经测过”的理解。
这次问题来自日语随记的语音输入开发。代码能编译，部分测试也通过了，实际手机在请求语音权限的过程中仍然闪退。
我最后需要回答的，既包括哪段代码不合适，也包括更前面的问题：手里的崩溃记录，究竟是不是这台故障设备、这次安装版本留下的？
先把一次失败对应起来#
找一台同型号手机试一下，可以帮助复现，但不能直接代替原来的故障。系统版本、权限是否已经同意、安装构建不同，都可能改变触发路径。
我会先把设备与系统、App 版本和构建、操作步骤、崩溃时间对应起来。对外写文章只保留这些类别，不公开设备标识、用户姓名或原始诊断文件。
还要找匹配的调试符号。它像一份地址索引，帮助把崩溃中的程序位置翻译成代码位置；必须对应同一次构建，拿另一个版本的同名文件来查，可能把人带到错误方向。Apple 的符号说明解释了这种匹配关系。
这次真正的问题，出在回调回来时#
请求系统权限之后，程序会等系统把结果送回来。这个“送回来”的动作，就是回调。它不一定发生在负责更新界面的那个执行环境里。
原来的写法，对这一点作了不合适的假设。实际崩溃记录和对应构建匹配后，定位到了权限回调的执行隔离问题：系统在后台返回结果，代码却带着要求另一种执行环境的检查。
修复的方向，是把系统回调接收和界面更新分开：先在合适的上下文接住结果，再把确实需要修改界面的部分交回主执行环境。不能把所有工作一股脑搬到主线程，也不能因为某次没有崩溃就忽略回调约定。
测试也要真的走到容易出错的地方#
如果测试总在主线程直接调用逻辑，就可能避开后台回调的问题。针对这次故障，检查要能从后台触发实际使用的回调，并保留运行时隔离检查。
生命周期同样重要：用户拒绝权限、准备时取消、录音中退出、系统打断、旧结果迟到，都应该有明确结果。取消后不能再把上一段识别结果塞进新的输入框，也不能因为收尾失败一直占着麦克风。
这类测试可以用合成音频和权限夹具覆盖一部分逻辑，帮助稳定重现。它们没有真的听见用户说话，也没有证明系统识别模型在实际环境里表现良好。
修复代码之后，仍有一张真机清单#
第一次允许与拒绝权限、从设置恢复、开始与停止录音、切到后台、被电话打断、回到键盘输入，都值得在目标设备上走一遍。中文和日语的识别、噪声、长句以及资源缺失，需要按实际支持范围分别看。
我会把“原崩溃原因已定位”“代码路径已修正”“新包实际录音通过”分成不同结果。这篇整理已有记录，没有在写作时重新执行手机验收，也不公开具体故障机的诊断内容。
对我最有用的一点，是排错时先把证据对应起来，再解释原因。这样下一次收到短短一句“又闪退了”，至少知道从哪几项信息开始。