小程序开发者工具卡在paused in Debugger到底怎么

发布时间：2026-09-26 10:19:21 丨 浏览次数：0

上周去业主家复尺，刚把卷尺收回来，女主人指着儿童房那扇平开窗说：「孩子老爱扒这儿看楼下，我总怕锁不住。」她家先生站在旁边，手机还开着小程序开发者工具，屏幕停在 `paused in Debugger`，他抬头问我：「你们做工程的，平时调试网络设备也这么卡吗？我点一下断点，整个工具就僵住了，跟这窗户似的，看着能锁，其实没锁死。」 我说，这俩事还真像。你怕窗户锁不住，是怕物理上没卡准。他怕 `小程序开发者工具:paused in Debugger`，是怕逻辑上没跑通。有人问，这提示到底啥意思？说白了，就是代码跑到你设的断点那儿，工具主动把执行按了暂停，等你发指令。不是崩了，是「蹲那儿等你呢」。可很多人一看界面灰了、按钮点不动，就以为死机，直接杀进程，结果断点还在，下次进来又停。 具体来说，有人追问，那为啥有时候没打断点也停？我说，你检查一下有没有开「异常时暂停」或者网络请求断点。工程现场调路由器，最怕有人把「调试暂停」当成「设备离线」。小程序开发者工具里，网络面板如果勾了「XHR/fetch 断点」，每次请求都会 `paused in Debugger`，看着像卡住，其实是等你放行。这点很多人忽略了——不是工具慢，是它太听话。 再说个细节。有次帮一个做智能家居的团队看调试，他们死活找不到「小程序开发者工具 paused in Debugger 解决」的办法。最后发现是 sourcemap 映射错位，断点打在压缩后的代码行上，工具找不到对应源码，就停在半路。这种情况，你按 F八继续也没用，得先把 sourcemap 关掉，或者重新构建。行业里有个妥协点：为了线上包体积小，压缩混淆是必须的，但调试时就得忍受这种「错位暂停」。别小看这个，它跟窗户锁点一个道理——你为了密封好，胶条压得紧，可执手转起来就费劲，得找平衡。 从实际操作来看，还有人问，那我直接关掉所有断点行不行？行，但你就失去了「蹲点抓 bug」的能力。我一般建议：先看 Call Stack，确认停在哪一层。如果是自己的业务代码，就查变量。如果是框架或库，按 F10单步跳过。实在不行，在控制台敲 `disableBreakpoints()` 或者点那个「停用断点」的按钮，别硬杀进程。 结尾给你个具体动作：下次再看到 `小程序开发者工具:paused in Debugger`，先别关窗口。看一眼右下角有没有「Resume script execution」的蓝色按钮，点它。如果点了还停。就去 Sources 面板把「Breakpoints」里所有勾去掉，再刷新。要是还不行，把 Network 面板的「XHR/fetch Breakpoints」也清空。这一点很关键。现场调窗户，我会让师傅拿张纸片夹在锁点处，关窗抽纸——抽不动才算锁住。你调小程序，就照这个法子，先放行，再排查，别跟它较劲。 关于小程序开发者工具:paused in Debugger能聊的还很多，这篇先说到这儿。后面会继续分享实际项目里遇到的一些特殊情况和处理办法，有疑问的可以留言交流。