深入理解技术探索与实践：从爬虫到前端，一个中台人的自白
大家好，我是某上市公司技术中台团队的一名普通码农，入职快两年了。平时除了和 CI/CD 流水线斗智斗勇、给上下游系统“擦屁股”，最大的爱好就是在博客园写点技术碎碎念——当然，更多时候是深夜加班后的情绪宣泄。
上周五晚上十点半，我正对着屏幕发呆，产品经理又甩过来一个需求：“能不能抓一下竞品的前端页面结构？我们想分析下他们的 UI 趋势。” 我心里一万个 MMP，但嘴上还得笑着说：“好的，我评估下可行性。”
于是，就有了这篇关于技术探索与实践的复盘。不是那种高屋建瓴的架构白皮书，而是实打实踩坑、debug、推翻重来后的血泪总结。
为什么这次探索这么“痛”？
事情起因其实挺简单：公司最近在做新一代产品管理后台的体验升级，设计团队疯狂安利《Designing Web Interfaces》这本书（顺带一提，这本书真的不错，建议前端同学人手一本）。书里提到“数据驱动的设计迭代”，那问题来了——我们的数据在哪？
内部埋点数据滞后、用户行为样本不足，而市面上第三方工具又贵又不准。这时候，有人提议：“不如直接爬竞品的公开页面，反向分析他们的组件结构和交互逻辑？”
听起来很美好，对吧？直到我真正动手才发现：这哪是技术探索，简直是“前端+反爬+产品理解”的三重地狱。
技术选型：别被“轮子”忽悠瘸了
一开始我信心满满：不就是个爬虫嘛？Python + requests + BeautifulSoup，十分钟搞定！结果第一版脚本跑起来，直接被 Cloudflare 的 JS 挑战拦在门外——人家首页根本不是静态 HTML，而是用 React 渲染的 SPA。
Error: Detected bot activity. Please enable JavaScript to continue.
——那一刻，我仿佛听见了运维同事在笑。
显然，得上无头浏览器。Puppeteer？Playwright？还是 Selenium？团队之前用过 Puppeteteer，但内存占用高、稳定性差，去年双11压测时还因为 Chromium 崩溃导致整个数据采集 pipeline 断掉，被 SRE 骂了一顿。
这次我决定试试 Playwright。理由很简单：
- 多浏览器支持（Chromium/Firefox/WebKit）
- 自动等待机制更智能
- 对现代前端框架（React/Vue）的兼容性更好
但新问题来了：如何高效提取“结构化”的前端信息，而不是一堆 DOM 字符串？
从 DOM 到产品洞察：别只当搬运工
爬下来只是第一步。真正的挑战在于如何把原始 HTML 转化为对产品有用的信息。
比如，我们想知道竞品用了多少种按钮样式、表单布局是否响应式、有没有使用微前端架构……这些光靠正则匹配肯定不行。
我最后搞了个“前端结构解析器”：
- 用 Playwright 执行页面，等待关键元素加载
- 注入一段自定义 JS，遍历所有组件节点，打上语义标签（如
type: primary-button,layout: two-column-form） - 将结构化的 JSON 数据吐出来，存入 ES 供分析
// 简化版注入脚本示例
function extractUIComponents() {
const components = [];
document.querySelectorAll('[class*="btn"], button').forEach(el => {
components.push({
type: 'button',
text: el.innerText.trim(),
classes: Array.from(el.classList),
position: el.getBoundingClientRect()
});
});
return components;
}
这个过程让我深刻意识到：技术探索不能脱离产品目标。如果只是机械地“爬”，那和外包团队有什么区别？我们要的是可行动的洞察，不是数据垃圾。
架构权衡：性能 vs 准确性 vs 成本
上线前，我和 TL（技术负责人）吵了一架。他坚持要实时爬取，我说：“兄弟，人家网站 QPS 限制 5，你让我每分钟扫 200 页？等着 IP 被封吧。”
最后我们妥协出一个折中方案：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 实时爬取 | 数据新鲜 | 容易被封、资源消耗大 | 高频监控（如价格变动） |
| 定时快照 | 稳定、可缓存 | 延迟高 | 结构分析、UI 趋势 |
| 第三方代理池 | 规避封禁 | 成本高、不可控 | 敏感目标 |
我们选了定时快照 + 本地缓存比对。每天凌晨 3 点跑一次，只抓有变更的页面（通过 ETag 或内容哈希判断），大幅降低请求量。
另外，为了不让中台服务背锅，我还加了个“熔断机制”：连续失败 3 次就自动暂停任务，并发钉钉告警。毕竟，谁也不想半夜被 call 起来修爬虫。
最大的收获：技术是手段，不是目的
折腾两周后，项目终于交付。设计团队拿着我们输出的“竞品组件分布热力图”，开出了三个优化方案，其中一个已经被排进 Q3 产品 roadmap。
但对我个人而言，更大的收获是思维方式的转变。
以前总觉得“中台就是提供稳定 API”，现在明白：中台的价值在于连接业务与技术的缝隙。产品经理说不清需求？那就用代码帮他验证假设。前端抱怨没参考？那就主动构建分析工具。
就像《软件架构模式》里说的：“架构不是画在 PPT 里的框图，而是解决实际约束的决策集合。” 这次爬虫项目，本质上是一次轻量级的领域驱动设计（DDD）实践——我们在用技术语言翻译产品语言。
吐槽 & 反思
当然，过程中也有一堆想吐槽的：
- 产品经理第 N 次改需求：“能不能顺便把他们用户评论也抓了？” —— 亲，那是另一个法律风险区啊！
- 前端同事听说我在分析竞品代码，默默递来一杯咖啡：“记得看他们有没有用微前端，我们正愁要不要上 qiankun……”
- 测试同学跑来问：“这个爬虫算不算自动化测试的一部分？” —— 算，算你赢了。
最后，也是最重要的教训：别为了技术而技术。当初差点沉迷于 Playwright 的高级特性（比如模拟地理位置、设备旋转），后来发现产品根本不需要。砍掉花里胡哨的功能后，系统反而更稳了。
写在最后
技术探索从来不是一蹴而就的“高光时刻”，而是一连串试错、妥协、重构的日常。作为中台人，我们或许不直接面向用户，但每一次对技术边界的试探，都在悄悄支撑着产品的进化。
如果你也在做类似的事情——不管是爬虫、前端监控，还是别的什么“脏活累活”——记住：你不是工具人，你是产品背后的第二双眼睛。
好了，不说了，刚收到消息，产品经理又想分析 TikTok 的 H5 页面……我先去研究下 WebRTC 指纹绕过了 😅
（完）
本文写于 2024 年 6 月某个加班的深夜，咖啡已凉，但代码还在跑。
欢迎交流，但别找我要竞品数据，我怕法务找我喝茶。
评论 0