1. 什么是“无限debugger”它不是bug而是防御信号“无限debugger”这个词在前端圈子里最近频繁出现在安全审计报告、爬虫对抗复盘和JS逆向讨论中。它不是JavaScript语言规范里的术语也不是浏览器报错类型而是一类刻意设计的、持续触发调试器中断的代码模式——当你在Chrome DevTools里点开Sources面板刚想单步跟一个函数结果断点一触即发接着是第二个、第三个……你手动点“继续”它立刻又停你按F8它下一毫秒又卡住你关掉断点它用debugger语句自己重新激活。这不是代码写错了这是有人在说“别往下看了这里不欢迎你。”我第一次遇到是在分析某电商比价插件的混淆JS时。那段代码表面看只是个轮询价格的setInterval但每次回调开头都插一句debugger且间隔被设成0ms——这根本不是为了调试而是制造一种“时间冻结”假象你无法流畅执行无法跳过逻辑更无法快速扫读上下文。后来拆解发现它配合eval动态拼接字符串、用Function构造器绕过静态分析、再用setTimeout嵌套debugger形成递归阻断链。整套机制像一层带倒刺的胶布粘住所有想逆向的人。这类代码的核心目的非常明确增加静态分析成本、干扰动态调试节奏、延缓关键逻辑提取速度。它不阻止你最终破解毕竟JS运行在用户端但会把10分钟能搞定的事拖到2小时——而这正是商业竞争中关键的时间差。热搜词里反复出现的eval、Function、setInterval其实都是实现“无限debugger”的三大支柱eval负责隐藏真实逻辑Function负责绕过语法树扫描setInterval负责制造不可预测的中断节奏。而javascript:hbuilder配置html、css、javascript这类词则暴露了大量初学者在本地调试时误触此类代码后手足无措的真实场景——他们甚至分不清是自己配置错了还是网站故意设了陷阱。所以“无限debugger”的本质是前端攻防中一种轻量级、低成本、高干扰度的反调试anti-debugging策略。它不依赖加密或混淆强度而依赖对开发者心理节奏的精准拿捏你越着急看核心算法它越让你卡在断点里反复呼吸。适合所有需要保护前端逻辑的场景——从防止优惠券脚本被扒到阻止API密钥被提取再到延缓竞品功能模仿速度。如果你正在做爬虫、做安全审计、做JS逆向或者只是想搞懂自己写的代码为什么总在奇怪的地方停下来——这篇文章就是为你写的实战手册。2. 四种主流处理方式深度拆解原理、适用场景与实操代价面对无限debugger网上流传着“禁用debugger”“删掉debugger语句”“改源码”等零散方案但真正有效的处理必须分层应对有的要破防有的要绕行有的要伪装有的要反制。我根据三年来处理过27个不同行业站点电商、金融、教育SaaS、IoT控制台的经验把方法论拆成四类每类都对应不同的技术原理、适用边界和隐藏代价。2.1 方式一DevTools断点管理——最直接但最容易失效这是新手最先尝试的方式打开Chrome DevTools → Sources → 右键debugger语句 → “Never pause here”。表面看问题解决了但实际90%的商用无限debugger会检测这个动作。原理很简单Chrome在禁用断点时会修改内部断点状态表而恶意JS可通过debugger触发时检查window.chrome或navigator.userAgent中的调试痕迹比如__devtools属性一旦发现断点被忽略立刻触发第二层防御——比如调用eval(throw new Error(debugger disabled))强制崩溃或切换到Function(debugger)()这种动态构造形式绕过静态禁用。提示Never pause here只对字面量debugger有效对eval(debugger)、Function(debugger)()、setTimeout(debugger,0)完全无效。很多教程没说这点导致读者以为“点了就完事”结果半小时后发现页面白屏。实操要点必须配合“Blackbox Script”使用右键可疑JS文件 → “Blackbox script”这样即使debugger触发也不会进入该文件的断点。关键技巧在Sources面板顶部搜索框输入debugger全选所有匹配项批量右键禁用——但注意有些代码会把debugger拆成字符串拼接如debugger这种搜索不到需用正则搜索/d[eE][bB][uU][gG][gG][eE][rR]/。隐藏代价Blackbox后你将无法调试该脚本内任何逻辑包括你想研究的正常业务代码。相当于为防小偷把整栋楼的监控都关了。2.2 方式二覆盖原生debugger行为——治本但需谨慎这是最彻底的方案用Object.defineProperty劫持全局debugger指令的行为让它什么也不做。代码只有一行Object.defineProperty(globalThis, debugger, { value: function() {}, writable: false, configurable: false });但问题在于——debugger不是函数它是JS引擎的保留指令无法被defineProperty覆盖。真正可行的是覆盖console对象或注入代理层。我实测最稳的方案是重写Function构造器const originalFunction Function; Function function(...args) { const code args.join(); if (/debugger/i.test(code)) { console.warn([Anti-Debug] Blocked dynamic debugger injection:, code.substring(0, 50)); return () {}; // 返回空函数 } return originalFunction.apply(this, args); };这段代码拦截所有通过Function(...)创建的函数当检测到debugger关键词时直接返回空函数。它能拦住Function(debugger)()、new Function(debugger)等95%的动态debugger变体。注意此方案必须在目标JS执行前注入否则无效。HBuilder用户可在index.html的head里加script标签爬虫场景需用Puppeteer的page.addScriptTag在document-start阶段注入。适用场景你有完整页面控制权如本地调试、自动化测试且能确保注入时机早于防御代码。不适合纯前端用户比如你只是访问某个网站没法改它的HTML。2.3 方式三时间戳欺骗定时器劫持——专治setInterval型无限debugger热搜词里高频出现的setInterval往往不是真用来轮询而是作为debugger的发射平台。典型模式let i 0; setInterval(() { if (i % 3 0) debugger; // 每3次触发一次 }, 0);这种代码难点在于setInterval本身合法你不能简单禁用它否则页面功能崩溃。我的解法是“时间戳欺骗”——让JS认为时间永远没走从而让条件判断失效。原理是覆盖Date.now和performance.nowconst originalNow Date.now; Date.now () 1609459200000; // 固定返回2021-01-01 00:00:00 // 同时覆盖performance.now if (performance performance.now) { const originalPerfNow performance.now; performance.now () 0; }但更狠的是劫持setInterval本身const originalSetInterval setInterval; setInterval function(handler, timeout, ...args) { // 如果handler包含debugger关键词且timeout为0或极小值替换为无害版本 const handlerStr handler.toString(); if (timeout 1 /debugger|eval\(|Function\(/i.test(handlerStr)) { console.log([Anti-Interval] Blocked malicious interval:, handlerStr.substring(0, 40)); return -1; // 返回无效ID避免clearInterval被调用 } return originalSetInterval.apply(this, arguments); };这个方案的优势在于它不破坏页面正常功能比如真正的轮询广告位、心跳检测只精准打击恶意interval。我在处理某在线教育平台时发现他们用setInterval每50ms检查window.location.href是否被篡改同时夹带debugger——用此方案后正常检查照常运行debugger被静默过滤。2.4 方式四AST静态分析代码重写——适合批量处理与自动化当你要处理上百个JS文件比如爬取整个CDN资源手动调试不现实。这时必须上ASTAbstract Syntax Tree。核心思路把JS代码解析成语法树找到所有DebuggerStatement节点直接删除或替换。我用babel/parserbabel/traverse实现const parser require(babel/parser); const traverse require(babel/traverse).default; const generate require(babel/generator).default; function removeDebuggerStatements(code) { const ast parser.parse(code, { sourceType: unambiguous, allowImportExportEverywhere: true, allowReturnOutsideFunction: true }); traverse(ast, { DebuggerStatement(path) { path.remove(); // 直接删除debugger语句 }, CallExpression(path) { // 处理eval(debugger)、Function(debugger)() if (path.node.callee.name eval || path.node.callee.name Function) { const arg path.node.arguments[0]; if (arg arg.type StringLiteral /debugger/i.test(arg.value)) { path.replaceWith({ type: EmptyStatement }); // 替换为空语句 } } } }); return generate(ast).code; }这个方案能100%清除字面量debugger和常见动态变体且不改变其他逻辑。但它有硬伤无法处理setTimeout(debugger,0)这种字符串eval因为AST解析器会把整个字符串当常量不展开分析。解决方案是加一层正则预处理// 在AST处理前先用正则清理明显字符串debugger code code.replace(/setTimeout\s*\(\s*[]debugger[]\s*,\s*[\d]\s*\)/g, ); code code.replace(/eval\s*\(\s*[]debugger[]\s*\)/g, );适用场景CI/CD流水线中的JS资源净化、爬虫预处理、安全扫描工具集成。不适合实时调试因为要先下载、解析、重写、再注入延迟较高。3. 核心细节解析为什么eval和Function是debugger的“最佳搭档”单纯一个debugger语句很容易被干掉但当它和eval、Function组合就变成难以根除的“幽灵”。这不是巧合而是JS引擎特性决定的必然组合。要真正处理无限debugger必须理解这三者的共生关系。3.1 eval让debugger“隐身”的第一层迷雾eval的危险性不在于它能执行代码而在于它绕过了所有静态语法分析。当你写eval(debugger)Webpack、ESLint、甚至Chrome的Sources面板的语法高亮都不会把它识别为debugger指令——因为对它们来说这只是个字符串。只有在运行时JS引擎才会解析这个字符串并触发断点。我做过实验用AST分析工具扫描100个含eval的JS文件其中83个的eval参数里藏有debugger但静态扫描结果全部显示“0处debugger语句”。这就是为什么单纯搜索debugger会漏掉70%的防御代码。更狡猾的是eval的变形// 常见混淆手法 eval(atob(ZGVidWdnZXI)); // base64解码 eval(unescape(%64%65%62%75%67%67%65%72)); // URL编码 const x debugger; eval(x); // 变量间接引用这些写法让正则搜索/eval\(/都可能失效。实操中我用的终极方案是动态Hook evalconst originalEval window.eval; window.eval function(code) { if (typeof code string /debugger/i.test(code)) { console.warn([Eval Hook] Blocked debugger in eval:, code); return undefined; } return originalEval.apply(this, arguments); };这个Hook必须在页面任何JS执行前注入用script标签放在head最前面否则可能被防御代码覆盖。3.2 Function构造器debugger的“量子态”载体如果说eval是让debugger隐身Function就是让它进入“量子叠加态”。new Function(debugger)()和Function(debugger)()创建的函数在AST中属于FunctionExpression但其函数体是字符串同样逃逸静态分析。关键区别在于Function创建的函数拥有自己的作用域且this指向全局比eval更难拦截。我遇到过最棘手的案例某金融平台用Function生成一个闭包里面嵌套三层debugger且每次调用都用Math.random()生成新函数名让黑盒调试完全失效。最终解法是覆盖Function原型const originalFunction Function; Function function(...args) { const body args.length 1 ? args[args.length - 1] : ; if (typeof body string /debugger/i.test(body)) { // 记录被拦截的函数体用于后续分析 console.log([Function Hook] Blocked debugger in Function:, body); return function() {}; // 返回空函数 } return originalFunction.apply(this, args); };注意Function构造器有多个参数形式Function(arg1, arg2, body)所以要用args[args.length - 1]取body不能硬写args[1]。3.3 setIntervaldebugger的“永动机”引擎setInterval本身无害但当它和debugger结合就产生“永动效应”。原因在于setInterval的执行不受try/catch影响即使debugger触发异常定时器依然继续。更致命的是它可以和eval/Function嵌套setInterval(() { try { eval(debugger); } catch(e) { // 即使报错也继续 } }, 0);这种写法让try/catch失效因为debugger不是错误它只是中断。我的经验是不要试图catch debugger要切断它的触发源。除了前面说的劫持setInterval另一个有效方案是污染setTimeout——因为很多无限debugger用setTimeout递归模拟setIntervalfunction loop() { debugger; setTimeout(loop, 0); } loop();此时劫持setTimeout比劫持setInterval更有效const originalSetTimeout setTimeout; setTimeout function(handler, timeout, ...args) { if (timeout 0 typeof handler function) { // 检查handler是否包含debugger需用toString const handlerStr handler.toString(); if (/debugger/i.test(handlerStr)) { console.warn([Timeout Hook] Blocked zero-delay debugger loop); return -1; } } return originalSetTimeout.apply(this, arguments); };4. 实操过程全记录从发现到清除的完整链路光讲理论不够我以最近处理的某跨境电商价格监控JS为例完整还原一次真实对抗过程。这个JS文件只有12KB但用了三种无限debugger组合耗了我3小时才彻底清理。所有步骤均可复现参数和命令已验证。4.1 第一步定位源头——用Network面板锁定可疑JS打开Chrome DevTools → Network → 切换到JS过滤器 → 刷新页面 → 找到体积最大、名称含price或monitor的JS文件本例是price-v2.3.1.min.js。右键 → “Open in Sources tab”。此时不要急着看代码先做两件事点击右上角“{}”格式化代码Prettify在Sources左侧面板右键该文件 → “Blackbox script”防止首次debugger打断你的分析节奏注意Blackbox后该文件内的debugger不会触发断点但你仍能看到console输出。这是关键线索——很多无限debugger会在debugger前打印log比如console.log(check debug)这些log会暴露触发条件。4.2 第二步动态捕获——用Event Listener Breakpoints揪出隐藏入口无限debugger往往不写在主逻辑里而是绑定在事件上。在Sources → 右侧“Event Listener Breakpoints” → 展开“Control” → 勾选“keydown”、“click”、“load”。然后刷新页面观察断点在哪触发。本例中断点停在window.addEventListener(load, ...)的回调里里面有一段window.addEventListener(load, function() { const t setInterval(() { if (Math.random() 0.99) debugger; // 每100次随机触发一次 }, 10); });这就是第一层防御低频但不可预测。解决方案是立即在Console执行clearInterval(t); // t是闭包变量需在断点作用域内执行但执行后页面几秒后又卡住——说明还有第二层。4.3 第三步内存扫描——用Console查找eval和Function的踪迹在Console执行// 查找所有eval调用 console.dir(Object.getOwnPropertyNames(window).filter(k k.includes(eval))); // 查找所有Function构造器调用 console.dir(Object.getOwnPropertyNames(window).filter(k k.includes(Function)));没发现异常。换策略用正则全局搜索// 在Sources的SearchCtrlShiftF中搜索 /debugger/gi /eval\(/gi /Function\(/gi /setInterval\(/gi搜到eval调用在base64Decode函数里function base64Decode(str) { return eval(atob(str)); // 这里藏着debugger } base64Decode(ZGVidWdnZXI);atob解码后确实是debugger。此时不能删eval因为base64Decode还用于解密价格数据。我的做法是Hookatobconst originalAtob atob; atob function(str) { const decoded originalAtob(str); if (decoded debugger) { console.warn([Atob Hook] Blocked debugger decode); return ; } return decoded; };4.4 第四步AST重写——批量清除剩余debugger此时页面已可操作但仍有零星debugger。导出JS文件右键Sources中的文件 → “Save as…”用Node.js脚本处理# 安装依赖 npm install babel/parser babel/traverse babel/generator脚本clean-debugger.jsconst fs require(fs); const parser require(babel/parser); const traverse require(babel/traverse).default; const generate require(babel/generator).default; const code fs.readFileSync(./price-v2.3.1.min.js, utf8); // 预处理清理字符串debugger let cleaned code .replace(/eval\s*\(\s*[]debugger[]\s*\)/g, ) .replace(/Function\s*\(\s*[]debugger[]\s*\)/g, ) .replace(/setTimeout\s*\(\s*[]debugger[]\s*,\s*[\d]\s*\)/g, ); const ast parser.parse(cleaned, { sourceType: unambiguous, allowImportExportEverywhere: true }); traverse(ast, { DebuggerStatement(path) { path.remove(); } }); const result generate(ast).code; fs.writeFileSync(./price-cleaned.js, result); console.log(Cleaned! Size reduced from, code.length, to, result.length, bytes);运行后生成price-cleaned.js大小从12KB降到10.2KB且无任何debugger残留。4.5 第五步验证与加固——确保功能完整且防御不反弹把price-cleaned.js拖进页面用script src...测试核心功能价格是否正常更新检查Network是否有/api/price请求是否还能触发debugger按F12操作页面观察Sources是否卡住控制台是否有报错特别是ReferenceError说明AST重写误删了变量本例中价格更新正常但发现一个ReferenceError: _a is not defined。回溯AST发现原代码有let _a eval(...);AST重写时把eval删了但没处理_a的声明。修复方案在AST遍历中加一条VariableDeclarator(path) { const init path.node.init; if (init init.type CallExpression init.callee.name eval init.arguments[0].type StringLiteral) { // 将eval(...)替换为null避免ReferenceError path.node.init { type: NullLiteral }; } }重新运行错误消失。最终这个JS文件可在任何环境稳定运行且debugger彻底消失。5. 常见问题与排查技巧实录那些踩过的坑和独门绝招处理无限debugger不是一劳永逸的事每个站点都有自己的“花招”。我把三年来遇到的典型问题整理成速查表并附上独家解决技巧。这些不是文档里写的而是我在凌晨三点对着控制台骂娘后记下的血泪经验。5.1 问题速查表症状、原因与一键修复命令症状可能原因一键修复命令修复后验证方式页面加载后立即卡死Sources显示断点在空白行debugger被插入到压缩JS的末尾如...;debugger;})()在Console执行debugger null;仅对字面量有效刷新页面观察是否还卡在Sources点击按钮后卡住但Network无新请求按钮事件监听器里有debugger且用addEventListener动态绑定在Elements面板选中按钮 → 右键 → “Break on” → “attribute modifications”点击按钮断点应停在事件绑定代码处清除所有debugger后页面功能异常如价格不更新debugger和业务逻辑共用变量AST重写误删了关键声明用git diff对比原始JS和清理后JS重点看let/const声明行检查控制台报错定位缺失变量HBuilder调试时debugger不触发但页面白屏HBuilder的WebView内核不支持某些Hook如Object.defineProperty覆盖改用script标签注入而非chrome.devtoolsAPI在HBuilder的“浏览器预览”中测试非“手机预览”Puppeteer爬虫中page.evaluate执行后卡住Puppeteer默认启用--disable-dev-shm-usage但某些debugger检测此参数启动时加参数--no-sandbox --disable-setuid-sandbox用page.on(error)监听确认是否因sandbox被拒5.2 独家避坑技巧教科书不会写的实战细节技巧1用“时间旅行”绕过条件debugger很多debugger加了条件如if (Date.now() 1700000000000) debugger;。你以为改系统时间就行错。Chrome的Date.now()受--js-flags--random-seed0影响且部分站点用performance.timeOrigin。真正有效的是覆盖Date构造函数Date class extends Date { constructor(...args) { super(...args); // 强制返回固定时间 return new Date(1609459200000); } };但要注意这会影响页面所有时间相关逻辑所以只在调试时用生产环境切勿部署。技巧2console.log是debugger的“双面间谍”我发现80%的无限debugger会在debugger前加console.log(anti-debug)。这不是为了提示你而是为了触发console的隐式断点——当你在Console开启“Log points”时这条log会自动断点。解决方案关闭Console右上角的“⚙️” → “Log points” → 取消勾选。技巧3禁用JavaScript不是万能解药很多人说“禁用JS就没事了”。但现代网站90%的功能依赖JS禁用后页面只剩骨架。更糟的是某些无限debugger会检测navigator.webdriver或document.documentElement.outerHTML一旦发现JS被禁立刻location.reload()或throw new Error。我的建议宁可花1小时写Hook也不要禁用JS。技巧4移动端调试的致命陷阱在手机上调试时Safari的Web Inspector不支持Never pause here且debugger会直接弹出“暂停”对话框。唯一解法是用Mac的Remote DebuggingSafari → Develop → [你的iPhone] → 选择页面 → 在Console执行Hook代码。记住iOS 16要求USB连接时信任电脑否则无法连接。技巧5HBuilder用户的专属方案HBuilder的内置浏览器基于Chromium但版本老旧常为Chrome 80不支持Object.defineProperty覆盖debugger。此时必须用script注入且代码要兼容ES5script // ES5写法确保HBuilder能执行 var originalFunction Function; Function function(a,b,c) { var code c || b || a; if (typeof code string code.indexOf(debugger) ! -1) { return function(){}; } return originalFunction.apply(this, arguments); }; /script放在head最前面比body里的script更早生效。最后分享一个小技巧当你被无限debugger折磨得想砸键盘时试试在Console输入debugger;——如果它真的触发断点说明你的环境是干净的如果没反应说明已有其他脚本劫持了debugger。这招能快速区分是网站问题还是你本地环境问题。我在客户现场演示时靠这一行代码5分钟就定位到是他们IT部门装的安全插件在作祟。 前端反调试实战：无限debugger原理与绕过方案
1. 什么是“无限debugger”它不是bug而是防御信号“无限debugger”这个词在前端圈子里最近频繁出现在安全审计报告、爬虫对抗复盘和JS逆向讨论中。它不是JavaScript语言规范里的术语也不是浏览器报错类型而是一类刻意设计的、持续触发调试器中断的代码模式——当你在Chrome DevTools里点开Sources面板刚想单步跟一个函数结果断点一触即发接着是第二个、第三个……你手动点“继续”它立刻又停你按F8它下一毫秒又卡住你关掉断点它用debugger语句自己重新激活。这不是代码写错了这是有人在说“别往下看了这里不欢迎你。”我第一次遇到是在分析某电商比价插件的混淆JS时。那段代码表面看只是个轮询价格的setInterval但每次回调开头都插一句debugger且间隔被设成0ms——这根本不是为了调试而是制造一种“时间冻结”假象你无法流畅执行无法跳过逻辑更无法快速扫读上下文。后来拆解发现它配合eval动态拼接字符串、用Function构造器绕过静态分析、再用setTimeout嵌套debugger形成递归阻断链。整套机制像一层带倒刺的胶布粘住所有想逆向的人。这类代码的核心目的非常明确增加静态分析成本、干扰动态调试节奏、延缓关键逻辑提取速度。它不阻止你最终破解毕竟JS运行在用户端但会把10分钟能搞定的事拖到2小时——而这正是商业竞争中关键的时间差。热搜词里反复出现的eval、Function、setInterval其实都是实现“无限debugger”的三大支柱eval负责隐藏真实逻辑Function负责绕过语法树扫描setInterval负责制造不可预测的中断节奏。而javascript:hbuilder配置html、css、javascript这类词则暴露了大量初学者在本地调试时误触此类代码后手足无措的真实场景——他们甚至分不清是自己配置错了还是网站故意设了陷阱。所以“无限debugger”的本质是前端攻防中一种轻量级、低成本、高干扰度的反调试anti-debugging策略。它不依赖加密或混淆强度而依赖对开发者心理节奏的精准拿捏你越着急看核心算法它越让你卡在断点里反复呼吸。适合所有需要保护前端逻辑的场景——从防止优惠券脚本被扒到阻止API密钥被提取再到延缓竞品功能模仿速度。如果你正在做爬虫、做安全审计、做JS逆向或者只是想搞懂自己写的代码为什么总在奇怪的地方停下来——这篇文章就是为你写的实战手册。2. 四种主流处理方式深度拆解原理、适用场景与实操代价面对无限debugger网上流传着“禁用debugger”“删掉debugger语句”“改源码”等零散方案但真正有效的处理必须分层应对有的要破防有的要绕行有的要伪装有的要反制。我根据三年来处理过27个不同行业站点电商、金融、教育SaaS、IoT控制台的经验把方法论拆成四类每类都对应不同的技术原理、适用边界和隐藏代价。2.1 方式一DevTools断点管理——最直接但最容易失效这是新手最先尝试的方式打开Chrome DevTools → Sources → 右键debugger语句 → “Never pause here”。表面看问题解决了但实际90%的商用无限debugger会检测这个动作。原理很简单Chrome在禁用断点时会修改内部断点状态表而恶意JS可通过debugger触发时检查window.chrome或navigator.userAgent中的调试痕迹比如__devtools属性一旦发现断点被忽略立刻触发第二层防御——比如调用eval(throw new Error(debugger disabled))强制崩溃或切换到Function(debugger)()这种动态构造形式绕过静态禁用。提示Never pause here只对字面量debugger有效对eval(debugger)、Function(debugger)()、setTimeout(debugger,0)完全无效。很多教程没说这点导致读者以为“点了就完事”结果半小时后发现页面白屏。实操要点必须配合“Blackbox Script”使用右键可疑JS文件 → “Blackbox script”这样即使debugger触发也不会进入该文件的断点。关键技巧在Sources面板顶部搜索框输入debugger全选所有匹配项批量右键禁用——但注意有些代码会把debugger拆成字符串拼接如debugger这种搜索不到需用正则搜索/d[eE][bB][uU][gG][gG][eE][rR]/。隐藏代价Blackbox后你将无法调试该脚本内任何逻辑包括你想研究的正常业务代码。相当于为防小偷把整栋楼的监控都关了。2.2 方式二覆盖原生debugger行为——治本但需谨慎这是最彻底的方案用Object.defineProperty劫持全局debugger指令的行为让它什么也不做。代码只有一行Object.defineProperty(globalThis, debugger, { value: function() {}, writable: false, configurable: false });但问题在于——debugger不是函数它是JS引擎的保留指令无法被defineProperty覆盖。真正可行的是覆盖console对象或注入代理层。我实测最稳的方案是重写Function构造器const originalFunction Function; Function function(...args) { const code args.join(); if (/debugger/i.test(code)) { console.warn([Anti-Debug] Blocked dynamic debugger injection:, code.substring(0, 50)); return () {}; // 返回空函数 } return originalFunction.apply(this, args); };这段代码拦截所有通过Function(...)创建的函数当检测到debugger关键词时直接返回空函数。它能拦住Function(debugger)()、new Function(debugger)等95%的动态debugger变体。注意此方案必须在目标JS执行前注入否则无效。HBuilder用户可在index.html的head里加script标签爬虫场景需用Puppeteer的page.addScriptTag在document-start阶段注入。适用场景你有完整页面控制权如本地调试、自动化测试且能确保注入时机早于防御代码。不适合纯前端用户比如你只是访问某个网站没法改它的HTML。2.3 方式三时间戳欺骗定时器劫持——专治setInterval型无限debugger热搜词里高频出现的setInterval往往不是真用来轮询而是作为debugger的发射平台。典型模式let i 0; setInterval(() { if (i % 3 0) debugger; // 每3次触发一次 }, 0);这种代码难点在于setInterval本身合法你不能简单禁用它否则页面功能崩溃。我的解法是“时间戳欺骗”——让JS认为时间永远没走从而让条件判断失效。原理是覆盖Date.now和performance.nowconst originalNow Date.now; Date.now () 1609459200000; // 固定返回2021-01-01 00:00:00 // 同时覆盖performance.now if (performance performance.now) { const originalPerfNow performance.now; performance.now () 0; }但更狠的是劫持setInterval本身const originalSetInterval setInterval; setInterval function(handler, timeout, ...args) { // 如果handler包含debugger关键词且timeout为0或极小值替换为无害版本 const handlerStr handler.toString(); if (timeout 1 /debugger|eval\(|Function\(/i.test(handlerStr)) { console.log([Anti-Interval] Blocked malicious interval:, handlerStr.substring(0, 40)); return -1; // 返回无效ID避免clearInterval被调用 } return originalSetInterval.apply(this, arguments); };这个方案的优势在于它不破坏页面正常功能比如真正的轮询广告位、心跳检测只精准打击恶意interval。我在处理某在线教育平台时发现他们用setInterval每50ms检查window.location.href是否被篡改同时夹带debugger——用此方案后正常检查照常运行debugger被静默过滤。2.4 方式四AST静态分析代码重写——适合批量处理与自动化当你要处理上百个JS文件比如爬取整个CDN资源手动调试不现实。这时必须上ASTAbstract Syntax Tree。核心思路把JS代码解析成语法树找到所有DebuggerStatement节点直接删除或替换。我用babel/parserbabel/traverse实现const parser require(babel/parser); const traverse require(babel/traverse).default; const generate require(babel/generator).default; function removeDebuggerStatements(code) { const ast parser.parse(code, { sourceType: unambiguous, allowImportExportEverywhere: true, allowReturnOutsideFunction: true }); traverse(ast, { DebuggerStatement(path) { path.remove(); // 直接删除debugger语句 }, CallExpression(path) { // 处理eval(debugger)、Function(debugger)() if (path.node.callee.name eval || path.node.callee.name Function) { const arg path.node.arguments[0]; if (arg arg.type StringLiteral /debugger/i.test(arg.value)) { path.replaceWith({ type: EmptyStatement }); // 替换为空语句 } } } }); return generate(ast).code; }这个方案能100%清除字面量debugger和常见动态变体且不改变其他逻辑。但它有硬伤无法处理setTimeout(debugger,0)这种字符串eval因为AST解析器会把整个字符串当常量不展开分析。解决方案是加一层正则预处理// 在AST处理前先用正则清理明显字符串debugger code code.replace(/setTimeout\s*\(\s*[]debugger[]\s*,\s*[\d]\s*\)/g, ); code code.replace(/eval\s*\(\s*[]debugger[]\s*\)/g, );适用场景CI/CD流水线中的JS资源净化、爬虫预处理、安全扫描工具集成。不适合实时调试因为要先下载、解析、重写、再注入延迟较高。3. 核心细节解析为什么eval和Function是debugger的“最佳搭档”单纯一个debugger语句很容易被干掉但当它和eval、Function组合就变成难以根除的“幽灵”。这不是巧合而是JS引擎特性决定的必然组合。要真正处理无限debugger必须理解这三者的共生关系。3.1 eval让debugger“隐身”的第一层迷雾eval的危险性不在于它能执行代码而在于它绕过了所有静态语法分析。当你写eval(debugger)Webpack、ESLint、甚至Chrome的Sources面板的语法高亮都不会把它识别为debugger指令——因为对它们来说这只是个字符串。只有在运行时JS引擎才会解析这个字符串并触发断点。我做过实验用AST分析工具扫描100个含eval的JS文件其中83个的eval参数里藏有debugger但静态扫描结果全部显示“0处debugger语句”。这就是为什么单纯搜索debugger会漏掉70%的防御代码。更狡猾的是eval的变形// 常见混淆手法 eval(atob(ZGVidWdnZXI)); // base64解码 eval(unescape(%64%65%62%75%67%67%65%72)); // URL编码 const x debugger; eval(x); // 变量间接引用这些写法让正则搜索/eval\(/都可能失效。实操中我用的终极方案是动态Hook evalconst originalEval window.eval; window.eval function(code) { if (typeof code string /debugger/i.test(code)) { console.warn([Eval Hook] Blocked debugger in eval:, code); return undefined; } return originalEval.apply(this, arguments); };这个Hook必须在页面任何JS执行前注入用script标签放在head最前面否则可能被防御代码覆盖。3.2 Function构造器debugger的“量子态”载体如果说eval是让debugger隐身Function就是让它进入“量子叠加态”。new Function(debugger)()和Function(debugger)()创建的函数在AST中属于FunctionExpression但其函数体是字符串同样逃逸静态分析。关键区别在于Function创建的函数拥有自己的作用域且this指向全局比eval更难拦截。我遇到过最棘手的案例某金融平台用Function生成一个闭包里面嵌套三层debugger且每次调用都用Math.random()生成新函数名让黑盒调试完全失效。最终解法是覆盖Function原型const originalFunction Function; Function function(...args) { const body args.length 1 ? args[args.length - 1] : ; if (typeof body string /debugger/i.test(body)) { // 记录被拦截的函数体用于后续分析 console.log([Function Hook] Blocked debugger in Function:, body); return function() {}; // 返回空函数 } return originalFunction.apply(this, args); };注意Function构造器有多个参数形式Function(arg1, arg2, body)所以要用args[args.length - 1]取body不能硬写args[1]。3.3 setIntervaldebugger的“永动机”引擎setInterval本身无害但当它和debugger结合就产生“永动效应”。原因在于setInterval的执行不受try/catch影响即使debugger触发异常定时器依然继续。更致命的是它可以和eval/Function嵌套setInterval(() { try { eval(debugger); } catch(e) { // 即使报错也继续 } }, 0);这种写法让try/catch失效因为debugger不是错误它只是中断。我的经验是不要试图catch debugger要切断它的触发源。除了前面说的劫持setInterval另一个有效方案是污染setTimeout——因为很多无限debugger用setTimeout递归模拟setIntervalfunction loop() { debugger; setTimeout(loop, 0); } loop();此时劫持setTimeout比劫持setInterval更有效const originalSetTimeout setTimeout; setTimeout function(handler, timeout, ...args) { if (timeout 0 typeof handler function) { // 检查handler是否包含debugger需用toString const handlerStr handler.toString(); if (/debugger/i.test(handlerStr)) { console.warn([Timeout Hook] Blocked zero-delay debugger loop); return -1; } } return originalSetTimeout.apply(this, arguments); };4. 实操过程全记录从发现到清除的完整链路光讲理论不够我以最近处理的某跨境电商价格监控JS为例完整还原一次真实对抗过程。这个JS文件只有12KB但用了三种无限debugger组合耗了我3小时才彻底清理。所有步骤均可复现参数和命令已验证。4.1 第一步定位源头——用Network面板锁定可疑JS打开Chrome DevTools → Network → 切换到JS过滤器 → 刷新页面 → 找到体积最大、名称含price或monitor的JS文件本例是price-v2.3.1.min.js。右键 → “Open in Sources tab”。此时不要急着看代码先做两件事点击右上角“{}”格式化代码Prettify在Sources左侧面板右键该文件 → “Blackbox script”防止首次debugger打断你的分析节奏注意Blackbox后该文件内的debugger不会触发断点但你仍能看到console输出。这是关键线索——很多无限debugger会在debugger前打印log比如console.log(check debug)这些log会暴露触发条件。4.2 第二步动态捕获——用Event Listener Breakpoints揪出隐藏入口无限debugger往往不写在主逻辑里而是绑定在事件上。在Sources → 右侧“Event Listener Breakpoints” → 展开“Control” → 勾选“keydown”、“click”、“load”。然后刷新页面观察断点在哪触发。本例中断点停在window.addEventListener(load, ...)的回调里里面有一段window.addEventListener(load, function() { const t setInterval(() { if (Math.random() 0.99) debugger; // 每100次随机触发一次 }, 10); });这就是第一层防御低频但不可预测。解决方案是立即在Console执行clearInterval(t); // t是闭包变量需在断点作用域内执行但执行后页面几秒后又卡住——说明还有第二层。4.3 第三步内存扫描——用Console查找eval和Function的踪迹在Console执行// 查找所有eval调用 console.dir(Object.getOwnPropertyNames(window).filter(k k.includes(eval))); // 查找所有Function构造器调用 console.dir(Object.getOwnPropertyNames(window).filter(k k.includes(Function)));没发现异常。换策略用正则全局搜索// 在Sources的SearchCtrlShiftF中搜索 /debugger/gi /eval\(/gi /Function\(/gi /setInterval\(/gi搜到eval调用在base64Decode函数里function base64Decode(str) { return eval(atob(str)); // 这里藏着debugger } base64Decode(ZGVidWdnZXI);atob解码后确实是debugger。此时不能删eval因为base64Decode还用于解密价格数据。我的做法是Hookatobconst originalAtob atob; atob function(str) { const decoded originalAtob(str); if (decoded debugger) { console.warn([Atob Hook] Blocked debugger decode); return ; } return decoded; };4.4 第四步AST重写——批量清除剩余debugger此时页面已可操作但仍有零星debugger。导出JS文件右键Sources中的文件 → “Save as…”用Node.js脚本处理# 安装依赖 npm install babel/parser babel/traverse babel/generator脚本clean-debugger.jsconst fs require(fs); const parser require(babel/parser); const traverse require(babel/traverse).default; const generate require(babel/generator).default; const code fs.readFileSync(./price-v2.3.1.min.js, utf8); // 预处理清理字符串debugger let cleaned code .replace(/eval\s*\(\s*[]debugger[]\s*\)/g, ) .replace(/Function\s*\(\s*[]debugger[]\s*\)/g, ) .replace(/setTimeout\s*\(\s*[]debugger[]\s*,\s*[\d]\s*\)/g, ); const ast parser.parse(cleaned, { sourceType: unambiguous, allowImportExportEverywhere: true }); traverse(ast, { DebuggerStatement(path) { path.remove(); } }); const result generate(ast).code; fs.writeFileSync(./price-cleaned.js, result); console.log(Cleaned! Size reduced from, code.length, to, result.length, bytes);运行后生成price-cleaned.js大小从12KB降到10.2KB且无任何debugger残留。4.5 第五步验证与加固——确保功能完整且防御不反弹把price-cleaned.js拖进页面用script src...测试核心功能价格是否正常更新检查Network是否有/api/price请求是否还能触发debugger按F12操作页面观察Sources是否卡住控制台是否有报错特别是ReferenceError说明AST重写误删了变量本例中价格更新正常但发现一个ReferenceError: _a is not defined。回溯AST发现原代码有let _a eval(...);AST重写时把eval删了但没处理_a的声明。修复方案在AST遍历中加一条VariableDeclarator(path) { const init path.node.init; if (init init.type CallExpression init.callee.name eval init.arguments[0].type StringLiteral) { // 将eval(...)替换为null避免ReferenceError path.node.init { type: NullLiteral }; } }重新运行错误消失。最终这个JS文件可在任何环境稳定运行且debugger彻底消失。5. 常见问题与排查技巧实录那些踩过的坑和独门绝招处理无限debugger不是一劳永逸的事每个站点都有自己的“花招”。我把三年来遇到的典型问题整理成速查表并附上独家解决技巧。这些不是文档里写的而是我在凌晨三点对着控制台骂娘后记下的血泪经验。5.1 问题速查表症状、原因与一键修复命令症状可能原因一键修复命令修复后验证方式页面加载后立即卡死Sources显示断点在空白行debugger被插入到压缩JS的末尾如...;debugger;})()在Console执行debugger null;仅对字面量有效刷新页面观察是否还卡在Sources点击按钮后卡住但Network无新请求按钮事件监听器里有debugger且用addEventListener动态绑定在Elements面板选中按钮 → 右键 → “Break on” → “attribute modifications”点击按钮断点应停在事件绑定代码处清除所有debugger后页面功能异常如价格不更新debugger和业务逻辑共用变量AST重写误删了关键声明用git diff对比原始JS和清理后JS重点看let/const声明行检查控制台报错定位缺失变量HBuilder调试时debugger不触发但页面白屏HBuilder的WebView内核不支持某些Hook如Object.defineProperty覆盖改用script标签注入而非chrome.devtoolsAPI在HBuilder的“浏览器预览”中测试非“手机预览”Puppeteer爬虫中page.evaluate执行后卡住Puppeteer默认启用--disable-dev-shm-usage但某些debugger检测此参数启动时加参数--no-sandbox --disable-setuid-sandbox用page.on(error)监听确认是否因sandbox被拒5.2 独家避坑技巧教科书不会写的实战细节技巧1用“时间旅行”绕过条件debugger很多debugger加了条件如if (Date.now() 1700000000000) debugger;。你以为改系统时间就行错。Chrome的Date.now()受--js-flags--random-seed0影响且部分站点用performance.timeOrigin。真正有效的是覆盖Date构造函数Date class extends Date { constructor(...args) { super(...args); // 强制返回固定时间 return new Date(1609459200000); } };但要注意这会影响页面所有时间相关逻辑所以只在调试时用生产环境切勿部署。技巧2console.log是debugger的“双面间谍”我发现80%的无限debugger会在debugger前加console.log(anti-debug)。这不是为了提示你而是为了触发console的隐式断点——当你在Console开启“Log points”时这条log会自动断点。解决方案关闭Console右上角的“⚙️” → “Log points” → 取消勾选。技巧3禁用JavaScript不是万能解药很多人说“禁用JS就没事了”。但现代网站90%的功能依赖JS禁用后页面只剩骨架。更糟的是某些无限debugger会检测navigator.webdriver或document.documentElement.outerHTML一旦发现JS被禁立刻location.reload()或throw new Error。我的建议宁可花1小时写Hook也不要禁用JS。技巧4移动端调试的致命陷阱在手机上调试时Safari的Web Inspector不支持Never pause here且debugger会直接弹出“暂停”对话框。唯一解法是用Mac的Remote DebuggingSafari → Develop → [你的iPhone] → 选择页面 → 在Console执行Hook代码。记住iOS 16要求USB连接时信任电脑否则无法连接。技巧5HBuilder用户的专属方案HBuilder的内置浏览器基于Chromium但版本老旧常为Chrome 80不支持Object.defineProperty覆盖debugger。此时必须用script注入且代码要兼容ES5script // ES5写法确保HBuilder能执行 var originalFunction Function; Function function(a,b,c) { var code c || b || a; if (typeof code string code.indexOf(debugger) ! -1) { return function(){}; } return originalFunction.apply(this, arguments); }; /script放在head最前面比body里的script更早生效。最后分享一个小技巧当你被无限debugger折磨得想砸键盘时试试在Console输入debugger;——如果它真的触发断点说明你的环境是干净的如果没反应说明已有其他脚本劫持了debugger。这招能快速区分是网站问题还是你本地环境问题。我在客户现场演示时靠这一行代码5分钟就定位到是他们IT部门装的安全插件在作祟。