这招是被逼出来的。Rembg Pro 的网页端升级了，整个抠图流程被封装在一个复杂的单页应用里，DOM 树乱得像被猫抓过的毛线团，传统的 XPath 和 CSS 选择器彻底失效。我盯着开发者工具里那些动态生成的、毫无规律的 div 和 canvas，知道老路走不通了。不是技术升级，是生存所迫。
以前那种靠解析 HTML 结构、模拟点击的爬虫路子，在这类重度依赖前端渲染和 Canvas 绘制的应用面前，就是石器时代的棍棒。你连“按钮”这个元素都定位不到，它可能就是画布上的一堆像素。焦虑感一下子就上来了，感觉手里吃饭的家伙正在生锈。不能这么等着被淘汰。
思路必须换。既然“结构”抓不到，那就抓“结果”。直接放弃与网页内部逻辑的缠斗，转向最终呈现的视觉层。我的方案是“多模态视觉抓取”：用无头浏览器（Puppeteer）完整加载页面并截图，然后对截图进行 OCR 识别定位交互元素（比如“上传”按钮的区域坐标），再用计算机视觉库（OpenCV）去匹配和定位画布上特定状态（比如“抠图完成”的预览图出现）。最后，不是去点击“下载”按钮——那个按钮可能根本不存在于 DOM——而是直接通过浏览器调试协议，拦截网络请求，捕获最终生成图片文件的资源链接。
这本质上是在模拟一个“视力”和“理解力”都受限的用户操作。技术栈完全变了，从 requests + BeautifulSoup 的轻量组合，变成了 Puppeteer + Tesseract.js + OpenCV 的臃肿但强力的全家桶。每一个环节都可能出问题：截图分辨率影响 OCR 精度；页面加载时机导致截图过早；网络拦截可能漏掉加密的请求。调试一次完整的流程，本地机器风扇狂转，时间以小时计。
所以必须上云端算力。本地跑一次成本太高（时间成本和硬件损耗），我需要一个可以快速启动、执行任务、然后立即销毁的环境。选了 Google Cloud 的 Compute Engine 预定义虚拟机，搭配一个轻量级的调度脚本。核心心得就两条：第一，镜像要预制好所有环境依赖，包括那些麻烦的 CV 库和字体包，启动时间就是金钱；第二，必须给每个任务设置严格的超时和资源占用监控，一旦检测到任务卡死或内存泄漏，立刻强制终止实例，避免产生计划外的费用。云服务的账单陷阱，比代码的 Bug 更可怕。
深夜，脚本提交了，云端实例启动。我这边盯着日志流，看着一行行状态输出。那种感觉很奇怪，不是放松，而是一种高度集中的亢奋。你知道机器在千里之外替你拼命，每一个环节都像齿轮一样咬合转动，而你能做的只有等待和监视。这种失控中的掌控感，是独属于技术人的兴奋剂。当日志最后跳出“结果文件已存储至 OSS，链接为……”时，那种瞬间的释然和成就感，比什么都提神。但紧接着脑子里算的就是：这次任务实例跑了 47 分钟，存储费用多少，下次哪个环节还能优化压缩到 30 分钟以内。焦虑永无止境，只是换了个战场。
