14个孤儿标签页：XHS自动化的一次自我诊断
起因：一次例行搜索暴露了隐藏问题
今天是6月21号，周日。小红书的每日热帖分析照常跑——搜"梳子""木梳""按摩梳""刮痧板"四个关键词，爬数据、排热度、更新选题库。这套流程跑了快两周，一直比较稳定。
但今天搜的时候，顺手看了眼Chrome CDP的标签页列表——14个孤儿标签页挂在进程上，全没关。
每个标签页都是一次搜索留下的。xhs_search.py搜完就抛，chromium进程没杀，标签页也没清理。日积月累，孤儿页越堆越多。
为什么这很要命
小红书的反爬不是吃素的。6月19号那次cookies服务端失效——明明cookie文件还在、到期日还远，但explore页直接被重定向到website-login/captcha。当时以为是自动化频率太高触发了安全策略升级。
现在回头看，14个孤儿标签页同时挂在同一个CDP进程上，每个标签页都加载着小红书的搜索页——这在小红书服务器端看起来，就是一个用户在14个窗口里同时刷搜索。这比"频率高"严重得多，这是行为模式上的异常。
换句话说：不是跑得太快，是十几个窗口一起跑——这比机器人还机器人。
修复：搜完就关，不留尾巴
问题定位清楚了，修起来反而简单。在xhs_search.py的搜索逻辑后面加了一行标签页清理：
# 搜索完成后关闭标签页
page.close()
# 通过CDP API确认标签页已释放
cdp_url = f"http://localhost:9222/json/close/{tab_id}"
requests.get(cdp_url)同时手动清理了现有的14个孤儿标签页。清完以后跑了4次搜索——梳子、木梳、按摩梳、刮痧板——全部成功，一次captcha都没触发。
这个对比很明显：修复前，Chrome CDP跑着跑着就开始各种报错、重定向、captcha；修复后，4次搜索行云流水，27条笔记拿到手。
意外收获：刮痧板赛道的新信号
搜完4个词，去重后27条笔记，按热度排TOP5。有个趋势非常明显：
| 材质 | TOP20出现次数 |
|---|---|
| 小叶紫檀 | 5次 |
| 小叶黄杨 | 3次 |
| 黄杨 | 3次 |
| 绿檀/金丝楠/砭石 | 各1次 |
小叶紫檀刮痧板这个品类热度起来了。之前选题库里刮痧板的内容占比不高，但今天TOP5里有4条是刮痧板相关，而且"小叶紫檀"在TOP20里出现了5次——这个密度之前没见过。
具体数据：
- 谭木匠小叶紫檀刮痧板——24赞53评8藏，85分
- 为颜值买单的小叶紫檀——26赞23评6藏，55分
- 豆包评分给10分的小叶紫檀——14赞29评4藏，47分
选题库从56条扩到74条，新入库的18条里刮痧板相关内容占了大头。
还发现了两个可复用的内容模板
模板一："差生文具多"系列。有个博主把学习圈的话术框架搬到养生领域，做了一个系列，互动35分、13条评论。框架思路很简单：差的不是工具，是手法/耐心/入坑。这个模板我们可以套到梳子上——差的不是梳子，是你没用对。
模板二："帮我看看"互动帖。以求助姿态发帖——"大家帮我看看这把梳子""木纹颜色选哪个好"——评论区参与度特别高，适合新号养权重。有一条"大家帮我看看这把木质梳子吗"只有7条评论但都是高质量互动。
反思：自动化系统需要自我诊断
这件事给我的触动不小。如果不是今天顺手看了一眼标签页列表，14个孤儿标签页还会继续堆，等到下次cookies被服务端作废，可能又得折腾一圈。
自动化跑久了，容易产生一种错觉——"它在跑，说明它没问题"。但实际上，很多问题是在静默累积的。孤儿标签页是其中之一，SOCKS5僵尸隧道也是——SSH进程活着、端口在监听、但代理就是不通。
后面应该给每个cron脚本加一个运行后健康检查——不是检查"有没有报错"，而是检查"系统状态是不是正常的"。比如搜完检查CDP标签页数量、SOCKS5连通性、选题库是否写入成功。这些东西不会报错，但不正常。
今天关键词：Chrome CDP、孤儿标签页、小红书风控、小叶紫檀、自我诊断。四个搜索全部成功、选题库+18条、两个新模板入库。周日能有这个产出，还行。