自动化实践 / 浏览器脚本
我把自动浏览 linux.do 帖子
的脚本做成了一套可恢复的自动化流程
这不是一个“纯粹为了点开网页”的小脚本，而是一套围绕
登录态复用、去重、跨分类补量、随机停留和中断恢复
设计出来的浏览器自动化流程。它最终要解决的问题很实际：
打开帖子、停留几秒、避免重复、数量可以持续往上补。
先说结论
这套脚本真正重要的地方，不是 Selenium 会不会点页面，而是它有没有能力在
跑到一半暂停之后继续接着跑，且尽量不重复打开楼层链接、分类页和旧帖子。
为什么我会写这个脚本
这件事最早的目标其实很简单：我已经在 Chrome 里登录了 linux.do，然后希望自动打开分类页里的帖子，每篇像人类一样浏览几秒，关掉，回到列表，再继续下一个。
但这个目标一旦开始做，就很快会遇到几个现实问题：
-
- 已经打开过的帖子不能重复点，否则很浪费时间。
-
- 如果一个分类页的新帖子看完了，就应该自动切到别的分类。
-
- 脚本不能只靠内存记状态，否则一中断就要重来。
-
- 有些链接是同一主题的不同楼层，比如 /1、/7，如果不归一化，会被误认为不同帖子。
-
1. 不是抓数据，而是模拟“浏览动作”
脚本不会去解析帖子正文，也不是做传统爬虫。它做的是浏览器层面的动作序列：
打开分类页、收集主贴链接、用新标签页打开、滚动几次、停留若干秒、关闭标签页、返回列表页。
重点：
目标是“看起来像人在浏览”，不是“尽快扫完链接”。
2. 浏览数量可以不断往后补
最初目标从 50 个开始，后面逐步增加到 1000、2000、3000。脚本设计成
带历史状态恢复
的形式，就是为了以后可以把目标继续往上推，而不是每次都从头开始。
重点：
脚本不是“一次性任务”，而是可续跑任务。
这套脚本是怎么组织起来的
核心文件是 linuxdo_browse_resume.py。从代码结构上看，它主要分成四层：
-
- 全局配置：目标总量、Chrome 用户目录、日志文件列表、分类 URL 列表。
-
- 状态层：从历史日志中恢复已经浏览过的标题和 URL。
-
- 采集层：在分类页中收集主贴链接，滚动到底部后不断补充。
-
- 执行层：逐个打开帖子、滚动、停留、关闭，并把新记录写回日志。
-
TARGET_TOTAL = 3000
PROFILE_DIR = Path(r"C:\Users\xiaozhu\AppData\Local\Temp\scoped_dir8300_1643392292")
CATEGORY_URLS = [
"https://linux.do/c/develop/4",
"https://linux.do/c/domestic/98",
"https://linux.do/c/resource/14",
...
]
第一个关键逻辑：复用已经登录的 Chrome
这一步非常关键。如果每次脚本启动都从“打开浏览器并重新登录网站”开始，整体复杂度会立刻增加很多，而且很容易被登录态、验证码、站点策略卡住。
所以脚本直接复用了一个固定的 Chrome 用户目录。这样 Selenium 拉起 Chrome 时，会继承这份用户数据，包含 cookie、登录态和浏览器环境信息。
这样做的好处：
-
- 不需要自动处理登录表单。
-
- 浏览流程更像真实用户。
-
- 脚本关注点可以集中在“浏览逻辑”本身。
-
第二个关键逻辑：历史日志驱动的恢复执行
如果只靠 Python 进程内存来记录“已经看过哪些帖子”，那脚本一旦中断，状态就没了。所以这里用了一个很朴素但很稳的方法：
每打开一篇帖子，就往日志里写一行。
下次启动时，不是从零开始，而是先扫描旧日志，把以前出现过的标题和 URL 全部读回来，重新构造 `seen_titles` 和 `seen_urls`。
def load_seen() -> tuple[set[str], set[str]]:
seen_titles: set[str] = set()
seen_urls: set[str] = set()
pattern = re.compile(r"open(?:_new)?\s+\d+/\d+\s+(.*?)(?:\s+\|\s+(https?://\S+))?$")
...
return seen_titles, seen_urls
第三个关键逻辑：URL 标准化去重
这是后面专门补上的增强点。原因很直接：linux.do 的同一个主题，有时会出现
/1、
/7
这类楼层后缀，或者带查询串和 hash。如果直接拿原始 URL 去重，脚本就会把它们误认为不同链接。
所以脚本新增了一个 `normalize_topic_url()`，把同一主题的不同楼层链接统一折叠成标准形式，例如：
归一化前：
https://linux.do/t/topic/2001328/7?u=test#reply
归一化后：
https://linux.do/t/topic/2001328
第四个关键逻辑：跨分类补量
如果只盯着一个分类页，新的帖子很快就会不够看。这个脚本的做法是预先准备多个分类入口，当某个分类没有新增主题时，就继续切到下一个分类。
这会让脚本更像“沿着不同板块持续扫新内容”，而不是在某一个列表页里死循环。
目前轮转的分类包括：
develop、domestic、resource、wiki、job、reading、news、feeds、welfare、gossip、square、feedback 等。
第五个关键逻辑：让浏览动作更像人
这里没有简单粗暴地“打开页面然后 sleep 5 秒”。而是拆成了一串更自然的动作：先开新标签、停一下、往下滚、再停一下、继续滚、再回看上半部分，然后关闭标签。
driver.execute_script("window.open(arguments[0], '_blank');", href)
driver.switch_to.window(driver.window_handles[-1])
time.sleep(random.uniform(1.6, 2.1))
driver.execute_script('window.scrollTo({top: 280, behavior: "smooth"});')
time.sleep(random.uniform(1.4, 1.8))
driver.execute_script('window.scrollTo({top: 760, behavior: "smooth"});')
time.sleep(random.uniform(1.4, 1.8))
driver.execute_script('window.scrollTo({top: 180, behavior: "smooth"});')
time.sleep(random.uniform(1.1, 1.5))
driver.close()
意义在于：
停留时长虽然仍然是程序控制，但行为节奏不再那么机械。
实际运行时，日志长什么样
日志除了用于恢复状态，本身也能看出脚本的执行节奏。下面这几行很有代表性：
[2026-04-20 17:56:32] resume_start seen_titles=2005 seen_urls=1989 target=3000
[2026-04-20 17:56:38] category https://linux.do/c/develop/4 | 最新开发调优话题 - LINUX DO
[2026-04-20 17:54:56] collected=283 pending_new=282 cumulative_seen=2000
[2026-04-20 17:54:56] open_new 1/282 GPT上下文压缩（compaction）一直失败 | https://linux.do/t/topic/2012658
尤其是 `seen_urls=1989` 这类数字，能直观看出去重增强是否生效。
这套脚本的本质
它不是一个复杂算法项目，但它是一个很典型的
自动化系统稳定性问题：
既要跑得动，也要停得住；既要能继续，也要尽量不重复。
一旦你开始把这类脚本当成“长期运行的流程”而不是“一次性的录制动作”，设计重点就会自然转移到状态、恢复、去重和执行稳定性上。
写在最后
这篇文章并不只是介绍一个脚本，也是在记录一种很典型的自动化思路：先把动作跑通，再把状态补上，再把恢复和去重做扎实，最后才谈规模和稳定性。
后面如果继续往下做，这套脚本还可以再加强，比如更细的 URL 标准化、更严格的分类统计、远程调试端口接管当前浏览器，甚至把运行结果自动整理成日报。到那一步，它就不再只是“自动点帖子”，而是一套完整的浏览行为自动化系统了。
