「被封」通常不是一件事
脚本昨天还好好的，今天开始返回空白、报错，或者干脆卡住。第一反应通常是换 IP、降频率、改请求头——网上一搜全是这些。
但这些招数处理的是症状。「被封」这个词底下至少有四种完全不同的情况，处理方式互不相干，不分清就动手，多半是白花时间。
四种情况，先分清
一、单纯的频率限制
短时间请求太多，平台暂时拒绝你。特征是过一段时间自己就好了，而且换个网络环境立刻能访问。
这是四种里最轻的，也是唯一「降低频率慢慢跑」真的管用的一种。如果你的需求本来就不赶时间，把并发降下来、把周期拉长，通常就过去了。
二、页面结构变了
这一种最危险，因为它经常不报错。
目标站改版之后，你的选择器还在跑，请求也是 200，但取到的字段是空的。脚本不会告诉你有问题，数据照样往表里写——等你发现的时候，可能已经积累了几周的空数据，而且分不清哪天开始的。
判断方法不是看有没有报错，是看关键字段的空值率。正常运行时某个字段的填充率是稳定的，突然从九成掉到两成，那不是数据源变了，是你的解析规则失效了。
建议每次跑完记录各字段的空值率并和上一次对比。这一步比任何异常告警都灵，而且成本几乎为零。
三、内容本来就在登录墙后
你之前能取到，可能是因为平台当时对未登录访问更宽松。平台收紧之后，那部分内容不再对匿名访问开放。
这种情况换 IP、改请求头、降频率都没有意义，因为限制不在你这边。Instagram、LinkedIn、Facebook 这几个平台的未登录可见范围在过去几年一直在收窄，这是产品决策不是技术对抗。
碰到这一种，该做的是重新看需求：这个信息有没有别的公开来源能替代。三条可行的路和一条明确不该走的，写在受限平台的数据怎么办。
四、你的采集行为被识别为自动化
平台判断这些请求不是人发出来的，于是要求验证或直接拒绝。
到这一步要先停下来问一个问题，而不是继续想办法：这件事到底该不该继续做下去。
我们不做的那部分
站上写死的边界在这里同样适用，说清楚免得浪费彼此时间：
- 不绕过验证码、验证机制或访问控制
- 不用客户提供的账号登录采集，即使账号是你主动给的
- 不承接以规避平台风控为目的的需求
所以如果你的问题是「怎么绕过去」，我们帮不上忙。我们能帮的是判断这个需求能不能换一种方式满足——多数情况下能，只是得先承认原来那条路走不通。
被封是不是该换方式的信号
不一定。判断标准不是「被封了没有」，是这件事要不要长期重复做。
继续自己做是对的：一次性需求、目标站结构简单、你撞上的是第一种情况（限流）。降低频率慢慢跑完就结束了，找人反而更慢。
该重新考虑的：这个采集要按周期长期跑，而你每个月都得花时间修它。第二种情况（结构变化）会反复发生，因为目标站不会为你的脚本保持稳定。
关键在于维护成本不会消失，只会在你和别人之间转移。一次性需求没有这笔成本，所以适合自己做；一旦变成周期性的，这笔账要重算。三条路各自适合什么，写在自己写、买现成工具，还是找服务商。
一个容易被忽略的成本
自己维护采集脚本，真正花掉的不是修的那两小时，是发现问题的延迟。
结构变了、数据悄悄变空，你可能一周后才注意到。这一周的数据要么作废，要么更糟——已经被拿去做了判断。等到发现时，重跑历史数据往往已经来不及，因为页面上的内容已经变了。
这也是我们默认在交付里带完整率统计的原因：不是为了好看，是为了让这种问题在第一次交付时就暴露出来，而不是三个月后。周期性项目还要提前定哪些事，写在周期性数据更新要提前确认什么。
先做的三件事
如果你现在正卡在这上面，按顺序做这三步：
- 换个网络环境手动打开那个页面。 能正常看到内容，说明是限流或自动化识别；看不到或要求登录，说明是登录墙，方向完全不同。
- 查关键字段的空值率。 请求成功但字段空了，那是结构变化不是被封，两者的修法没有关系。
- 问自己这件事还要做多少次。 一次，就慢慢跑完；每周一次，那要算的是长期维护账。
三步走完再决定投入。如果结论是这个需求本身走不通，那要改的是需求不是脚本——把目标网址发过来，评估阶段就能给出这个判断，不收费。