如何技术探索与实践？一个阿里P7前端工程师的实战复盘
大家好，我是成都某大厂的前端 P7，经历过好几轮双11大促的“洗礼”——说白了就是每年这个时候头发掉得特别快。平时重度依赖 ChatGPT/Claude 写代码（别笑，我司很多同事都这样），对云原生、K8s 这些基础设施也略懂一二。最近在做一次内部分享时被问到：“你是怎么持续做技术探索和落地的？” 我一愣，心想：这不就是每天都在干的事儿吗？
但转念一想，确实值得系统总结一下。尤其现在行情卷得飞起，不少朋友私下问我：“怎么才能把项目经验写进简历里又不显得注水？”、“搞点爬虫/自动化是不是更容易出亮点？” 所以今天这篇就聊聊我在日常工作中如何“边踩坑边造轮子”，顺便带点真实案例、性能优化和跨角色协作的血泪教训。
起因：产品经理的一句“能不能加个数据看板？”
这事发生在去年 Q3。我们团队负责一个面向商家的数据产品，原本只是展示订单、流量等基础指标。结果某天 PM 在站会上轻飘飘地说：“老板想看看竞品价格走势，要不咱们搞个自动抓取+可视化看板？”
我当场心里一万个草泥马奔腾而过——这不就是爬虫需求嘛！而且还是动态渲染的电商页面，反爬机制肯定贼强。更要命的是，这个需求要赶在双11前上线，留给我们的开发时间只有两周。
更离谱的是，PM 补了一句：“这个功能如果效果好，可以作为亮点写进你们的晋升材料。”（潜台词：搞砸了你今年就别想升 P8 了）
行吧，干就完了。
技术选型：不是所有轮子都值得重造
首先明确目标：稳定、低资源消耗、可运维、能集成到现有产品体系中。这不是个人练手项目，而是要上生产的。
我第一反应是用 Puppeteer + Headless Chrome。但立刻被自己否了——双11期间服务器资源吃紧，每个容器实例都要精打细算。Puppeteer 启动一个浏览器进程动辄几百 MB 内存，还容易 OOM，运维同学看到这种方案怕是要把我拉黑。
于是转向 Playwright ——微软出品，多浏览器支持，资源占用比 Puppeteer 略优。但测试发现，在 K8s 集群里跑无头浏览器仍然不稳定，尤其在高并发抓取时频繁 crash。
最后我们决定：静态页面用 Axios + Cheerio，动态内容才上 Playwright，并且严格限制并发数和超时时间。同时把爬虫服务独立部署为一个微服务，通过 Kubernetes Job 触发，避免影响主应用。
# k8s job 示例：每日凌晨2点执行一次爬取
apiVersion: batch/v1
kind: Job
metadata:
name: price-crawler-daily
spec:
template:
spec:
containers:
- name: crawler
image: registry.aliyun.com/myapp/crawler:v1.2
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "1000m"
env:
- name: TARGET_URLS
valueFrom:
configMapKeyRef:
name: crawler-config
key: urls
restartPolicy: OnFailure
这套架构跑下来，单次爬取内存峰值控制在 800MB 以内，CPU 占用平稳，运维同学终于没再半夜打电话骂我。
性能优化：从 45 秒到 3 秒的逆袭
初期版本上线后，测试同学反馈：“看板加载巨慢，用户都跑了！” 打开 DevTools 一看，好家伙，首屏数据请求耗时 45 秒！
问题出在哪？原来前端直接调用爬虫服务的 API，而爬虫服务每次都要实时抓取 + 解析 + 返回。这显然不可持续。
优化策略三板斧：
- 预计算 + 缓存：爬虫任务改为夜间离线执行，结果存入 Redis（TTL 24h）。前端只读缓存，不再触发实时爬取。
- 分页 + 懒加载：原本一次性返回 30 天数据，改成按周分页，用户滚动时再加载。
- 前端骨架屏 + 渐进式渲染：先展示结构，数据回来后再填充，提升感知性能。
优化后，首屏加载时间压到 3 秒内，Lighthouse 性能评分从 42 提升到 89。最关键的是，用户体验不再像在等泡面熟。
| 优化阶段 | 首屏时间 | Lighthouse 性能分 | 用户跳出率 |
|---|---|---|---|
| 初版 | 45s | 42 | 68% |
| 优化后 | 2.8s | 89 | 21% |
简历怎么写？别只写“用了什么技术”
很多同学写简历喜欢堆砌关键词：“使用 Vue3 + TypeScript + Playwright 实现爬虫系统”。HR 看了只会觉得你在背技术栈。
真正有含金量的写法是突出“综合能力”和“业务价值”。比如我后来在简历里这么写：
主导竞品价格监控系统的端到端落地，融合爬虫、云原生调度与前端性能优化，实现日均 10w+ 页面抓取，数据延迟 <1h。通过离线预计算 + 缓存策略，将前端看板首屏加载时间从 45s 降至 3s，支撑双11期间 500+ 商家使用，成为产品核心差异化功能之一。
你看，这里包含了：
- 技术广度（爬虫 + K8s + 前端）
- 性能指标（具体数字）
- 业务影响（支撑多少商家、成为核心功能）
这才是面试官想看的“综合”能力，而不是“我会写爬虫”。
跨团队协作：别让运维和测试背锅
技术探索最怕闭门造车。这次项目里，我主动拉了运维和测试同学 early join。
- 和运维对齐：容器资源配置、日志格式、告警规则（比如连续 3 次爬取失败就钉钉告警）
- 和测试共建：Mock 数据方案、异常场景覆盖（比如目标网站改版导致选择器失效）
结果上线当天一切顺利。反观隔壁组有个类似项目，前端自己搞了个定时脚本跑在开发机上，结果双11当天机器宕机，数据断更，被老板点名批评。
记住：在大厂，稳定性 > 创新性。你可以炫技，但不能让线上系统冒烟。
血泪教训：别为了“技术亮点”硬上
其实最初我想用 Server-Sent Events (SSE) 实现实时价格推送，显得更“高级”。但评估后发现：
- 商家并不需要秒级更新，小时级足够
- SSE 会增加连接数压力，K8s Ingress 配置复杂
- 增加维护成本，但 ROI 极低
最后果断砍掉，回归简单可靠的轮询 + 缓存。技术探索不是为了炫技，而是解决问题。
上周五晚上我还在加班调一个诡异的内存泄漏，Claude 帮我定位到是 Cheerio 未正确释放 DOM 树。当时真的想砸电脑，但搞定那一刻，成就感爆棚——这种“痛并快乐着”的感觉，大概就是工程师的宿命吧。
总结：技术探索 = 问题驱动 × 工程思维 × 业务敏感度
回过头看，这次爬虫项目的成功，不是因为我多懂反爬策略，而是因为：
- 从产品需求出发，而不是从技术兴趣出发
- 考虑全链路成本：开发、部署、监控、维护
- 用数据说话：性能指标、用户行为、业务结果
- 敢于妥协：在理想架构和现实约束之间找平衡
技术探索从来不是一个人的战斗。它需要你理解产品逻辑、尊重运维边界、配合测试节奏，甚至要会“向上管理”——比如说服老板接受“T+1 数据”而不是“实时”。
所以，别再问“怎么写出好看的简历”了。先把事情做成，把数据跑出来，把问题解决掉。简历自然就有料了。
最后送大家一句我在阿里学到的话：“技术是手段，不是目的。”
共勉。
（完）
作者：阿里前端 P7，坐标成都，正在用 Claude 写下一篇文章。
如果你觉得有用，欢迎点赞/转发，但别抄简历哈 😉
评论 0