在我的笔记本电脑上可以运行：为什么爬虫在生产环境中崩溃（以及到底是什么导致的故障）

I’m happy to help translate the article, but I don’t have the full text of the post. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the article text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and technical terms.

本地可获得的（意外优势）

• 住宅宽带 ISP IP
• 类人请求量
• 新鲜的浏览器指纹
• “正常”的地理位置

部署时会有什么变化

生产环境通常包括：

• 数据中心 IP
• 高并发
• 重复的请求模式
• 固定地区
• 长时间运行的进程

对于现代网站来说，这类流量不再像用户行为——它更像是系统行为。

常见生产环境

• 云虚拟机
• 容器
• 无服务器函数

这些几乎总是使用数据中心 IP 范围。

核心问题

许多站点会对数据中心流量进行速率限制或降级。
有些站点并未直接阻止，而是降低响应质量，返回 HTTP 200 但内容不完整或被篡改。这就是为什么“no errors” ≠ “correct data”。

本地 vs. 生产 请求模式

反机器人系统监控你如何发起请求，而不仅仅是请求什么。你的系统越稳定，看起来就越不像人类。

Regional Effects

许多开发者认为“抓取公开页面——位置无关紧要”。实际上：

• 价格因地区而异
• SERP（搜索结果页面）因 IP 而异
• 社交和电商平台本地化力度大
• 某些内容受地区限制，却没有明显错误

如果生产环境只在单一地区运行，你的数据将变得 有偏差、不完整且不具代表性——这对 SEO 监控、市场调研和机器学习训练数据都是严重问题。

静默失败

最危险的失败不会抛出异常。相反，你会看到：

• 空列表
• 结果更少
• 内容顺序被打乱
• 缺失的字段

你的管道仍然继续运行，呈现出扭曲的现实。这些失败可能会在数周内不被注意到。

流量真实感：缺失的环节

此时，许多团队意识到问题不在于 Scrapy、Playwright 或 requests；而在于 流量真实感。

住宅代理

通过 ISP 分配的消费者 IP 路由请求可以帮助：

• 避免立即被数据中心过滤
• 访问符合地区的内容
• 减少静默降级
• 使生产流量看起来像真实用户

像 Rapidproxy 这样的工具并非作为“增长黑客”使用，而是作为基础设施——类似于添加重试、退避或可观测性。

重要注意事项

• 代理无法修复损坏的选择器。
• 它们无法绕过激进的机器人挑战。
• 它们也不能为不良请求模式开脱。

它们能够修复的方面：

• 本地与生产环境之间的基础设施层面不匹配
• 不现实的 IP 声誉
• 区域盲点
• 早期阶段的限流

它们缩小了“在我的笔记本上可用”与“在真实环境中可用”之间的差距。

构建稳定的爬虫

一个稳定的爬虫通常结合以下要素：

• 合理的并发
• 会话一致性
• 可观测的封锁率
• 区域感知的访问
• 真实的 IP 流量

一旦团队加入这些要素，失败率会下降——虽然不是降到零，但会降到一个 可预测且可诊断 的水平。可预测性是生产系统最需要的。

要点

大多数爬虫并不是因为写得糟糕而失效；它们失效是因为 生产流量与真实用户完全不同，而且网络已经学会了察觉这一点。

如果你的爬虫在本地能够正常工作，但在生产环境中失败，先不要急于重写。首先问自己：

“真实用户会这样行为吗？”

如果答案是 否，那么你的基础设施同样需要得到与代码同等的关注。