Playwright 本身不直接检测死链或404，但可通过 page.route 拦截请求并结合 response 事件检查状态码；需在 page.goto() 前注册 route，用 response.status 判断非2xx/3xx响应，过滤无效URL以避免噪音。
Playwright 本身不直接检测死链或 404，但你可以用它捕获所有网络请求并筛选出状态码为 404（或非 2xx/3xx）的响应——这是最可靠、最贴近真实浏览器行为的做法。
如何用 page.route 拦截并检查每个请求的状态码
Playwright 的 page.route 允许你拦截页面发起的所有请求（包括 fetch、XMLHttpRequest、图片、CSS、iframe 等），并在响应返回后读取状态码。关键在于：必须在页面加载前注册路由监听器，且需启用 handle 或至少调用 route.continue_()，否则请求会被阻断。
- 务必在
page.goto()之前调用page.route()，否则会漏掉导航初始请求 - 使用
route.response()获取响应对象，再读response.status()；注意它可能为None（如请求被取消、超时、CORS 阻止） - 只对需要检查的资源类型做判断（比如跳过
data:、about:blank、内联样式等），避免噪音 - 示例片段：
failed_links = []
page.route("**/*", lambda route: route.continue_())
page.on("response", lambda response: (
failed_links.append({
"url": response.url,
"status": response.status
}) if response.status >= 400 and response.status < 600 else None
))
为什么不能只靠 page.goto() 的返回值判断 404
page.goto() 默认只校验主文档响应，即使服务器返回 404 HTML 页面（常见于 SPA 路由 fallback），只要 HTML 成功加载，它就认为成功。而真正失效的是页面内部的 API 请求、图片链接、CSS 引用等——这些都得靠 page.on("response") 或 page.route 捕获。
-
page.goto(url, wait_until="networkidle")不保证子资源成功，仅等待网络静默 - 某些 404 响应仍返回 200 状态码（如 Nginx 自定义 404 页面），此时需结合响应体内容或 URL 模式识别，不能只信 status
- 重定向链中中间跳转（301/302）不算失败，但最终目标返回 404 就算——
response.url是最终地址，可直接用于比对
如何处理 JavaScript 动态生成的链接（如 fetch 或 location.href）
Playwright 默认能捕获所有浏览器发出的请求，无论来源是 HTML、JS 还是用户交互。但前提是：JS 必须实际执行。如果你用 page.goto(url, wait_until="domcontentloaded")，可能 JS 还没跑完，部分请求就漏了。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 改用
wait_until="networkidle"或加显式等待（如page.wait_for_timeout(2000)），确保异步请求已发出 - 对单页应用（SPA），首次
goto后可能还需触发路由跳转（如点击菜单），再等待一次 networkidle - 如果链接藏在事件监听器里（如点击后才构造 URL），得模拟点击并等待后续请求，不能只依赖初始加载
- 避免用
page.content()解析 a 标签来“预扫描”——这会漏掉 JS 生成、延迟加载、条件渲染的链接
性能与稳定性注意事项
全量监听所有请求（"**/*"）在复杂页面下会产生大量事件，容易拖慢执行、甚至内存溢出。生产环境扫描需有节制。
- 过滤域名：用
page.route("https://example.com/**", ...)限定范围，避免监控 CDN 或第三方统计 - 忽略静态资源类型：在
page.on("response")回调里跳过response.request.resource_type in ["image", "font", "stylesheet"]（除非你真要查图片 404） - 设置超时和重试：对失败请求，Playwright 不自动重试；如需确认是否偶发失败，得自己封装逻辑（例如记录后二次
request.get()） - 注意 headless 模式下某些请求可能被浏览器策略屏蔽（如跨域 iframe），日志里显示
net::ERR_FAILED，这类无法拿到 status，只能归为“未知失败”
真正难的不是抓到 404，而是区分哪些该报、哪些可忽略——比如监控接口返回 404 是正常业务逻辑，而产品图床链接 404 就得立刻告警。规则得按业务定，工具只负责把原始信号给你备齐。
