无限 debugger 不是 Python 爬虫的问题，而是浏览器 JS 反调试机制所致；Python 请求不执行 debugger，真正需解决的是浏览器调试时的卡顿，可通过关闭“Pause on debugger statements”、注入脚本屏蔽检测或使用 playwright 规避。
直接说结论：无限 debugger 不是 Python 爬虫本身的问题，而是你用浏览器手动调试时被前端代码干扰；Python 爬虫代码里根本不会执行 debugger，所以不需要在 Python 侧“绕过”它——真正要解决的，是你在分析网页行为、逆向加密逻辑时，如何让浏览器不卡死在断点上。
为什么 Python 爬虫代码里看不到 debugger 却被卡住？
因为你不是在运行 Python，而是在用 Chrome/Firefox 打开目标页面、按 F12 调试。此时执行的是页面里的 JS，它检测到 devtools.isOpen 或窗口尺寸变化等信号，就循环触发 debugger。Python 的 requests 或 playwright 请求本身完全不受影响。
-
debugger是 JS 语句，只在浏览器 JS 引擎里生效，requests.get()拿到的是原始 HTML/JS 字符串，不会执行它 - 如果你用
selenium或playwright启动浏览器，且没禁用 devtools 检测，那页面 JS 一样会触发debugger - 真正需要干预的，是“你人眼观察和调试 JS 的过程”，不是 Python 脚本本身
Chrome 里快速跳过无限 debugger 的实操方法
别折腾插件或代理，先用最稳的原生方式：
- 打开开发者工具（F12）→ 切到 Sources 面板 → 在右上角找到 Pause on exceptions 旁边的 Pause on debugger statements 开关，把它关掉（Firefox 从 2023 年起也支持这个开关）
- 如果已卡在某个
debugger行，鼠标悬停在行号上 → 右键 → 选 Never pause here（不是“Remove breakpoint”，是这个选项） - 遇到用
eval动态生成的debugger（比如eval("debugger")），上述开关可能无效，得靠 Hook：window.debugger = function(){}直接覆盖（在 Console 里执行，刷新前有效）
用 playwright 启动浏览器时规避 JS 反调试
如果你用 playwright 自动化调试，别让它暴露 devtools 特征：
立即学习“Python免费学习笔记（深入）”；
- 启动时加参数屏蔽常见检测信号：
context = browser.new_context(bypass_csp=True, java_script_enabled=True)，但关键在 user-agent 和 viewport - 禁用
debugger相关 API：在页面加载前注入脚本，重写setInterval和setTimeout，过滤含"debugger"的字符串（注意：不能只删字面量，要拦截动态构造） - 更可靠的做法是关闭 devtools 检测逻辑：在
page.add_init_script()里塞一段 JS，把window.outerWidth、window.outerHeight固定成大值，再把__REACT_DEVTOOLS_GLOBAL_HOOK__等全局变量删掉
别在 Python 里硬解混淆后的 debugger 链
看到一堆 eval 套 atob 套 Function 构造器？说明你已经掉进陷阱了。这类反调试往往和真实业务逻辑耦合，强行在 Python 里模拟 JS 执行环境（比如用 execjs）极容易漏掉隐式依赖（window、document、localStorage）。
- 优先用浏览器自动化（
playwright）跑通流程，再把最终请求参数抓出来，用requests复现 - 如果必须静态分析，用 Chrome 的 Overrides 功能把混淆 JS 映射到本地，删掉
debugger后逐行设断点，比在 Python 里拼字符串靠谱得多 - 记住：90% 的“无限
debugger”只是障眼法，核心加密逻辑通常藏在后续 XHR 请求里，盯着debugger看半天，不如切到 Network 面板看发了什么包
真正麻烦的从来不是 debugger 本身，而是它背后那套检测逻辑——比如监听 window.outerWidth 变化、检查 console.log 是否被重写、甚至用 getEventListeners 查 devtools 是否挂载。这些细节一旦漏掉一个，你刚绕过 debugger，下个请求就 403 了。
