前段时间，我要做一轮热点款式搜图。目标并不复杂：围绕几个关键词去网页里找近期内容，挑出真正展示款式的笔记，再把图片下载下来，按类别整理好。真正开始以后，我才发现，最慢的部分并不是搜索，而是每搜一个词就重新启动一次浏览器。
当时的初始方案是 7 个关键词分别起浏览器。单个关键词大约要 1–2 分钟，浏览器还不一定处在同样的登录状态。有的实例可以打开搜索页，有的实例却要重新登录；如果刚好在批量任务中间遇到登录问题，后面的采集就会变成反复确认会话、重新打开页面和重新等待加载。
我一开始把它看成“关键词太多”的问题，后来发现真正的瓶颈是资源管理。**批量网页采集最应该复用的，不是某个搜索词，而是已经建立好的登录会话和浏览器连接。**只要每个词都重新付一次启动成本，关键词数量一增加，等待时间和出错机会就一起增加。
先判断已有会话能不能用
我先检查了后台已经启动的实例。匿名实例确实没有登录，但这不等于所有浏览器都没有登录。另一个已经运行的常驻实例仍然保留着有效会话，可以继续访问目标网站。这个差别很重要：如果只看到当前实例未登录，就直接得出“必须重新登录”的结论，实际上是在把已有资源当成不存在。
这里最容易误判的是，把“当前入口的状态”当成“整个环境的状态”。浏览器实例之间的会话并不一定共享，一个标签页打不开个人内容，也不能证明另一个已经登录的实例同样打不开。判断之前，我会先问两个问题：有没有已经登录的实例？它能不能打开目标页面并读到有效结果？
如果不先做这一步，后面会出现两类浪费。一类是重复输入登录信息，既慢，又增加触发验证的机会；另一类是任务已经有可用的会话，却因为一开始选错入口而重新搭建整套环境。对于需要连续搜索的任务来说，启动和登录不是一次性的准备动作，而是应该被当成可以长期持有的连接资源。
我选择复用已有登录实例，是因为它同时满足了稳定性和效率两个条件：会话已经验证过，页面也能继续工作。这样做不是为了绕过网站的登录规则，而是避免在同一个授权范围内重复创建没有必要的登录流程。
1 个标签页跑完所有关键词
确认会话可用之后，我没有继续给每个关键词分配 1 个浏览器，而是固定 1 个标签页，按顺序切换搜索词。这个动作看起来很小，实际上改变了任务的结构：浏览器负责维持页面环境，搜索词只是输入给这个环境的不同参数。
这一轮一共处理了 10 个关键词，大约 2 分钟得到 308 条结果。这个结果让我看清，原来慢的不是网页本身，而是重复启动、重复建立连接和重复等待。把常驻实例保留下来以后，每个关键词只需要完成导航、读取和回收结果，不再承担一整套浏览器初始化成本。
当然，单标签复用并不等于不做状态检查。每次切换关键词时，仍然要确认页面已经完成跳转，读到的内容属于当前关键词，而不是上一次搜索的残留。如果页面加载失败，就记录失败的关键词并重新读取，而不是继续把错误页面当成有效结果。
**单标签复用的核心不是“少开几个窗口”，而是让页面状态只有 1 个明确的主人。**状态越分散，越难知道某条结果来自哪个会话、哪个关键词和哪个时间点。固定标签以后，问题虽然仍可能发生，但定位范围明显小了。
先收集结构化结果，再处理图片
搜索结果回来后，我没有一边看到图片一边立即下载。页面里已经有列表数据和详情数据，先把标题、链接、发布时间、互动信息以及图片地址收集起来，后面再统一处理。这一步把“发现内容”和“搬运文件”拆开了。
为什么要拆？因为搜索结果里有不少看起来相关、实际并不适合入选的内容。候选先去掉价格、明星、砍价和营销类内容，再逐篇读取详情，确认它确实是在展示款式，而不是借款式做宣传。原本以为筛 32 篇就够了，逐篇打开后实际读到了 36 篇，最终再根据时间和内容质量做取舍。
这时，结构化数据比肉眼翻页面更可靠。页面上的展示顺序会变化，图片也可能延迟加载，但标题、链接、发布时间和图片地址能够先被统一保存。它们组成了一份候选清单，让后续去重、筛选和下载都有明确依据。
如果不做这一层中间整理，最容易出现的结果就是把同一篇内容下载多次，把营销内容混进款式素材，或者因为图片已经开始下载而舍不得淘汰不合适的候选。下载一旦提前发生，筛选就会被沉没成本牵着走。
去重和时间过滤要放在下载前
10 个关键词得到的 308 条结果并不等于 308 篇独立内容。相同的笔记可能被多个关键词命中，标题相近的内容也可能指向同一个来源。因此，我先按内容链接和标题做汇总去重，再看它是否真的值得进入详情阶段。
详情读取完成后，又增加了时间过滤。大部分入选内容要求发布时间在 2026 年 6 月以后，另外保留了 1 篇更早但确实具有代表性的内容。过滤完成后，31 篇进入下载，原图数量也从候选阶段的 233 张收敛到最终素材范围。
我判断“先筛后下”是必要的，因为图片下载通常比读取几行文本更消耗带宽和存储。如果边搜边把全部图片搬回来，最后仍然要人工删除，机器和人的时间都花在了不会使用的素材上。更糟的是，当下载和页面采集同时进行时，带宽抖动还会反过来影响搜索稳定性。
**批量任务的并发应该留给最后一段，而不是从第一步就铺开。**搜索阶段优先保证会话稳定，整理阶段优先保证数据清楚，只有入选结果确定以后，才适合并发下载。
图片下载也要有可追踪的出口
入选范围确定以后，图片才进入并发下载。这里还有一个细节：不能只保存图片文件，还要同步生成索引。图片按类别、日期、标题和作者组织，索引记录原始内容与本地文件之间的对应关系。这样，未来查看素材时不必重新打开网页猜它来自哪里。
下载时直接使用页面提供的图片源地址，减少通过浏览器逐张打开和另存的步骤。但这并不意味着可以忽略校验。下载完成后要确认文件数量、目录归属和索引是否一致；如果页面宣称有多张原图，本地却少了其中一部分，就不能把“任务结束”当作“素材完整”。
这件事表面上是在提高搜图速度，其实是在建立一条可回溯的采集链。关键词对应哪些候选，候选为什么被淘汰，最终图片来自哪篇内容，都应该留下一点能继续判断的记录。否则下一次只是重新搜得更快，却仍然要从头理解上一轮发生了什么。
把浏览器当成长连接资源
回头看，错误捷径很明显：每个关键词都新开浏览器，遇到登录提示就重复登录，同时把看到的所有图片都下载下来。这个方案在关键词很少时可能也能完成，但它把 3 个不同问题混在了一起：会话建立、内容采集和文件搬运。任何一环变慢，其他环节都会跟着等待。
现在我会把流程拆成 4 段。先复用并验证已有登录会话；再固定单标签顺序搜索，收集列表和详情中的结构化数据；接着按链接、内容类型、发布时间和互动表现去重筛选；最后只对入选结果并发下载，并生成索引。
这个方法可以迁移到很多需要批量浏览的工作里。只要网站允许在已有授权会话中继续访问，就不必把每个查询都当成一次全新的浏览器任务。但会话也不是永久有效的，遇到失效、跳转异常或页面内容不属于当前查询时，应该停下来重新验证，而不是盲目加并发。
这件事让我重新意识到，工具效率不只来自更快的请求。真正难的不是把 10 个词同时发出去，而是知道哪个状态应该被保留，哪个结果应该先被淘汰，哪个资源只有到了最后才值得并发使用。一个批量流程成熟的标志，不是它能一次搜完很多内容，而是它能把会话、判断和文件之间的关系留下来。
下次我会怎么做
下次再遇到批量网页采集，我会先查已有浏览器实例和登录状态，不会默认从匿名入口重新开始。确认可用会话后，我会固定 1 个标签页，先小范围测试页面是否返回当前关键词的结果，再按顺序跑完整批关键词。
我会把列表读取、详情读取、去重筛选和图片下载明确分开。候选阶段只保存必要的结构化信息，先去掉明显不相关的内容，再按发布时间和互动表现决定是否进入详情和下载。真正值得复用的不是“开多少个浏览器”的数字，而是“先复用会话，再集中判断，最后并发搬运”的顺序。
如果会话失效，我会把它当成明确的阶段失败，先恢复会话，再继续未完成的关键词；如果下载数量和索引对不上，就回到文件校验，而不是直接交付。这样做可能让某一次任务多停几分钟，却能避免把启动成本、登录风险和无效下载重复支付很多遍。
我更愿意把浏览器看成长连接资源，而不是一次性工具。连接建立以后，真正重要的工作才刚开始：让每个搜索词共享稳定环境，让每条结果经过统一判断，让最终文件可以被下一次工作直接接手。这个顺序一旦固定下来，批量搜图就不再是不断开窗口，而是一条有边界、有筛选、有记录的采集流程。