字节跳动聘请迪士尼高管这事儿，本质上是在买一张全球化的门票，但门票本身不解决流量获取的物理边界。我们团队去年接了个海外竞品数据监控的活儿，客户要我们实时抓取 TikTok 在十几个国家的热门榜单和标签趋势，当时第一反应就是用 Selenium 无头浏览器硬上，结果第一天就把对方服务器干出防护墙了。
真正的难点不是绕过反爬，是资源管理。你开一百个无头浏览器实例，内存直接爆掉，AWS 账单能让你心梗。后来我们拆解了整个过程，发现 80% 的页面结构是稳定的，只有 20% 的动态加载内容需要真实渲染。那就别全用无头模式，用 requests 库配合 lxml 解析静态 DOM 树，只对那 20% 的 AJAX 请求单独启动无头浏览器处理。这里有个关键判断逻辑：先发一个 HEAD 请求看响应头里的 Content-Type，如果是 text/html 且没有特定的 XHR 标识符，就直接走静态解析；如果检测到页面引用了特定的 JavaScript 框架文件（比如 React 或 Vue 的生产环境打包文件），再触发无头流程。
但这还不够。无头浏览器实例不能即用即开，那启动时间太长了。我们搞了个池化管理，类似数据库连接池。维护一个“健康”的无头实例队列，每个实例执行完任务后不是关闭，而是清空 Cookies 和 LocalStorage，重置到初始状态放回池里。这里有个坑，Chromium 的无头模式即使清空了缓存，某些指纹特征还是会被网站追踪到，所以我们给每个实例随机化了 Viewport 尺寸、User-Agent 的细微版本号，甚至通过注入 CSS 来轻微修改渲染出的 Canvas 指纹。
流量边界的另一层意思是，你爬得再快，也快不过别人商业 API 的调用限额和地域封锁。字节跳动买迪士尼的人，是为了搞定内容合规和本地化运营，这是另一种“反爬”。我们当时为了模拟不同国家的用户，必须在对应的 AWS 区域部署代理节点，用住宅 IP 池，一个 IP 的生命周期严格控制在 2 小时内，超过就废弃。这成本根本不是技术问题，是资金问题。你技术再牛，没有足够的预算买干净的 IP 资源，一切都是空谈。
现在回头看，2020 年我带着团队陷在这种高并发采集的交付里，每天焦虑的不是技术实现，是成本和稳定性之间的平衡。客户要的是“实时”，但实时意味着更高的资源消耗和更频繁的触发反爬机制。我们设计了一套降级策略：当连续触发 429 状态码（请求过多）时，系统自动切换为“增量模式”，只抓取上次抓取后新增的条目，并且拉长请求间隔。同时，用 Redis 缓存所有成功解析的页面结构模板，下次同类型的页面直接套用模板提取数据，减少不必要的渲染。
迪士尼高管带来的可能是内容策略和品牌合作，但字节跳动全球化的底层，还是无数个像我们这样的团队在解决流量获取的脏活累活。技术可以优化到极致，但永远有新的边界——法律边界、文化边界、资源边界。那时候我身心俱疲，管理着十几号人，每天睁眼就是服务器账单和客户催进度的消息，技术上的兴奋感早就被交付压力磨没了。你优化得再好，客户只觉得这是你应该做的，他不会为你省下的那 30% 的 AWS 费用多付一分钱。这种状态，离崩溃也就不远了。
