协程泄露表现为内存持续上涨、CPU空转、日志出现“Task was destroyed but it is pending!”；根源是Playwright异步API（如new_page、goto、close等）未被await或create_task调度，导致悬空协程滞留事件循环。
协程泄露的典型现象和定位方式
运行后发现内存持续上涨、CPU空转但任务不结束，或者日志里反复出现 Task was destroyed but it is pending! —— 这基本就是协程泄露了。Playwright 的 page.goto()、page.wait_for_selector() 等方法返回的是协程对象，如果没被 await 或没被 asyncio.create_task() 显式调度，它就只是个“悬空协程”，Python 不会自动执行或回收它。
更隐蔽的情况是：你写了 asyncio.gather(*coro_list)，但 coro_list 里混入了未 await 的 context.new_page() 协程（比如忘了加 await），结果 gather 报错 TypeError: an iterable of awaitables is required，而你只盯着报错，没意识到那些漏掉的协程已经悄悄卡在事件循环里了。
必须显式 await 的三个关键节点
Playwright 异步 API 中，以下三处不 await 就等于埋雷：
-
browser.new_context()和context.new_page()必须加await，它们不是同步构造器，而是协程工厂 -
page.goto()、page.click()、page.wait_for_timeout()等所有带page.前缀的操作，都是协程，不能只调用不 await -
browser.close()和context.close()同样要 await；只调用不 await，会导致浏览器进程残留、socket 未释放
常见错误写法：pages = [context.new_page() for _ in range(5)] → 这生成的是 5 个未执行的协程对象，不是 5 个 page 实例。正确写法是：pages = [await context.new_page() for _ in range(5)] 或用 asyncio.gather 批量 await。
用 async with + asyncio.shield 防止中断导致泄露
网络抖动或人为 Ctrl+C 时，协程可能在中间状态被取消，比如 page.goto() 已发请求但还没收到响应，此时若直接退出，page 实例不会自动 close，底层 socket 和渲染进程就卡住了。
推荐结构：
- 用
async with async_playwright() as p:确保 playwright 全局资源可回收 - 对关键页面操作套一层
asyncio.shield()，防止被外部取消打断，例如：await asyncio.shield(page.goto(url, wait_until="networkidle")) - 所有
page实例必须在try/finally或async with块中管理关闭，不要依赖 GC
别指望 Python 3.12 的新特性（比如改进的 __aexit__ 推导）能帮你兜底——Playwright 的 page 对象不实现异步上下文协议，async with page 会直接报错。
检查协程是否真的执行完毕的实操技巧
开发阶段加一行调试代码，能快速暴露悬空协程：
import asyncio
print("Pending tasks:", [t.get_coro().__name__ for t in asyncio.all_tasks() if not t.done()])
如果输出里有 goto、wait_for_selector、new_page 这类名字，说明对应协程没被 await 或没被 task 包裹。
另一个轻量级验证方式：在脚本末尾加 await asyncio.sleep(0.1)，再看是否还有 pending task。如果有，说明存在未完成的协程链，得顺着调用栈往上查哪一层漏了 await。
最常被忽略的是：在异常分支里忘了 await page.close()，或者用 return 提前退出函数却没清理已创建的 page。这类逻辑漏洞，在并发量一大就立刻暴露。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
