个自动化互联网的 Python 库，最后一个太离谱

200 的接口, 并不等同于页面切实可用。爬虫运行完毕, 也并不意味着数据就是正确的。我所见识到的最为糟糕的一回, 乃是脚本每日凌晨抓取页面, 日志全然显示为绿色, 然而最终抓取竟持续三天都是登录页面。针对这种活儿, 千万别一开始就。要是能用HTTP搞定的, 就别去开启浏览器倘若能解析HTML就行的, 那就别通过截图识别一旦真的碰到反爬、登录以及动态渲染之类的情况, 再将浏览器请出来用。第一个还是 。它样子不繁杂花哨, 然而质地够坚硬。其内部存在后台, 还有老接口, 以及简单的表单提交事宜, 运用它最为省事便捷。import requests s requests.Session s.headers.update({ User-Agent: ops-checker/1.0, X-Trace-From: night-job }) resp s.get(https://example.com/api/status, timeout5) resp.raise_for_status data resp.json if data.get(state) ! ok: raise RuntimeError(f状态不对: {data})我通常借助它来撰写巡检脚本, 千万别小瞧, 对于线上脚本而言, 最令人担忧的并非失败, 而是出现卡死状况, 卡在那儿毫无报错信息, 待次日你查看日志时或许仍然觉得一切无异。第二个是 httpx 。它宛如的进阶版本, 具备同步支持能力, 同时也拥有异步支持能力。在进行批量探测操作、批量校验链接操作之际, 相较于而言更为便利。import httpx urls [ https://example.com, https://example.com/login, https://example.com/help ] with httpx.Client(timeout6, follow_redirectsTrue) as client: for url in urls: r client.get(url) print(url, r.status_code, len(r.text))在这里, 我会再多看一下 len(r.text)。存在一些页面, 其状态码为 200 , 然而内容仅仅只有几百字节, 大概八成是被网关、登录页以及错误模板给吞掉了。第三个是 。当进行批量请求多达上千个页面的操作时, 相较于一条条进行同步请求, 它所带来的感受会舒服许多。然而, 也千万不要随意开启并发, 因为你所面对的目标站点并非你自家的Redis, 若请求力度搞得太大, 就极易被封禁。import asyncio import aiohttp asyncdeffetch(session, url): try: asyncwith session.get(url, timeout8) as r: text await r.text return url, r.status, len(text) except Exception as e: return url, ERR, str(e) asyncdefmain: urls [fhttps://example.com/item/{i}for i in range(1, 50)] conn aiohttp.TCPConnector(limit10) asyncwith aiohttp.ClientSession(connectorconn) as session: for row inawait asyncio.gather(*(fetch(session, u) for u in urls)): print(row) asyncio.run(main)会被我保留的东西存在着limit10 , 并非要对所有自动化追求速度, 能够稳定跑完的自动化具备更高价值。第四个是 。在页面结构并非复杂的情形下, 顺势直接运用它去扒取字段。切莫只要一瞅见HTML, 便径行采用正则, 毕竟正则倘若用于解析HTML, 后续负责维护的人员是会对你予以斥责一番的。from bs4 import BeautifulSoup html open(page.html, encodingutf-8).read soup BeautifulSoup(html, html.parser) title soup.select_one(h1) price soup.select_one(.price) print({ title: title.get_text(stripTrue) if title else, price: price.get_text(stripTrue) if price else })我撰写这类脚本时, 宁可字段获取不到便空着, 也并非偏好一堆链式调用直接错乱。自动化脚本运行到半夜, 别期望有人守着屏幕挽救它。第五个是 。它借助 CSS 以及 XPath 来获取数据, 在编写爬虫之际, 相较于其他方式更为干脆利落, 特别是在页面层级较深的情形下。from parsel import Selector sel Selector(textopen(list.html, encodingutf-8).read) for item in sel.css(.goods-card): name item.css(.name::text).get(default).strip href item.css(a::attr(href)).get print(name, href)XPath并非是已过时的那种情况, 它仅仅是具备丑的特性。然而存在一些页面, CSS选择器需要花费很长时间来迂回探索, 可XPath却能够一下子直截了当地定位到那里。第六个是 。适用于正式些的数据采集任务的这个东西, 队列被它铺好了, 去重被它铺好了, 失败重试被它铺好了, 下载中间件也被它铺好了。其缺点挺明显, 项目结构在一开始是有点儿重的。第七个是 。动态页面, 前端渲染, 按钮点击, 登录态, 相较于其他, 它是更新的那类, 并且实际使用起来也会让人感觉更为顺畅顺手。from playwright.sync_api import sync_playwright with sync_playwright as p: browser p.chromium.launch(headlessTrue) page browser.new_page page.goto(https://example.com/login, wait_untilnetworkidle) page.fill(#username, robot) page.fill(#password, not-real-password) page.click(button[typesubmit]) page.wait_for_selector(.dashboard) print(page.title) browser.close在这里, 千万别迷信sleep, 要能等待可选择器就一定等待可选择器, 还要能等待网络处于空闲才等待网络变得空闲, time.sleep(3)当属脚本偶然发生失败时的老相识了。第八个是 。它岁数大, 然而众多公司的内网系统, 那些老旧的后台, 以及从IE时代迁移过来之后留存的事物, 实际上真的得依靠它。不要生出嫌弃之心, 只要能够开展工作便可以了。我对于 的看法极为简捷: 要是能够不使用那就不去应用倘若非得使用那便要将等候、截屏、失利日志补充完整。要不然在它出现失败状况之际, 仅仅会告知你有一个元素寻觅不到, 致使现场根本没办法根据已有信息回想, 重新进行分析。第九个-use这个就有点离谱了。放在前面的这些库, 是由你告知怎样去点、怎样去抓、怎样去解析的。它并非如此, 它是将浏览器交付给大模型, 让大模型自行去看页面、自行去点按钮、自行去完成任务的。大概是这种感觉from browser_use import Agent from langchain_openai import ChatOpenAI import asyncio asyncdefrun: agent Agent( task打开示例网站找到帮助中心里和退款相关的页面整理标题, llmChatOpenAI(modelgpt-4o-mini) ) result await agent.run print(result) asyncio.run(run)对于这东西, 我不会直接将其丢到生产环节, 因为它实在太不可控了, 只要页面一变, 或者弹窗一出, 又或者模型一抽风, 那么结果就极有可能出现偏差, 发生跑偏的情况。可是把它用于当作后台操作的原型, 用于替代低频的人工流程, 于测试一些重复的页面动作而言, 的确是有着一定特色的。以往编写定位器需要花费很长时间, 如今只需一句话就能让它自行点击了。虽说这事挺离谱得很, 然而方向也真就发生改变了。自动化互联网这事别被库带着跑。简单接口运用, 批量探测借助 httpx 或者, 静态页面采用、, 正式采集投入, 动态页面进而采用、, 最后那个 AI 控制浏览器, 暂且放置在实验田中, 不要匆忙投向生产。