支付宝总部从杭州搬到上海，这新闻让我盯着电脑屏幕愣了几秒钟。不是感慨大厂战略，是突然意识到，我他妈连自己的“总部”都快没了——这个堆满服务器和泡面箱的出租屋。团队扩张到八个人之后，我每天的工作就是给甲方爸爸写日报、安抚闹情绪的程序员、以及计算下个月发完工资还剩几个钢镚。物理上的位移？我连下楼取个外卖的时间都觉得奢侈。
重度交付泥潭，这词儿太贴切了。我们接了个本地生活类的数据监测项目，要求每天凌晨三点抓取五个平台的商家活动信息，清洗、去重、生成分析报告，早上八点前邮件发送。最开始用 Python 脚本加 crontab 硬扛，但平台一改 DOM 结构就全崩，半夜报警电话能把我从床上炸起来。更可怕的是，团队里负责这块的哥们儿提了离职，理由是“天天熬夜调爬虫，快猝死了”。那一刻我懂了，我赚的不是钱，是医药费预付款。
自救是从把“流程”拆成“零件”开始的。不能再靠人肉盯了。我翻出以前玩过的 Node-RED，但觉得太玩具，后来盯上了 n8n，那时候它还叫“n8n.io”，没现在这么火。核心思路很简单：用它的可视化界面把一个个孤立的 Python 脚本像积木一样连起来。抓取是一个脚本，用 requests-html 处理动态加载，设好异常重试和代理池切换；数据清洗是另一个脚本，主要用 pandas 做格式规整和关键词提取；最后的报告生成，用 Jinja2 模板把数据灌进去变成 HTML。
连接这些“积木”才是关键。n8n 的 HTTP Request 节点可以触发 Python 脚本（跑在 Docker 容器里），脚本处理完把结果吐到指定的 webhook URL，n8n 再抓取这个结果传递给下一个节点。比如，抓取节点成功后，会把 JSON 数据 POST 到清洗脚本的接口，清洗完再触发报告生成。整个流程的开关、错误报警（集成 Telegram Bot）、甚至简单的条件判断（比如某平台数据为空就跳过后续步骤），全在 n8n 的画布上拖拽完成。这相当于我把原本需要人工干预的“if-else”和“重试”逻辑，做成了可视化的故障隔离带。
然后就是 Docker 这个资源吞噬兽。早期我直接一个容器跑一个 Python 脚本，内存蹭蹭就上去了，服务器那点钱根本扛不住。调优心得就两条：第一，合并同类项。把多个轻量级、依赖库相似的脚本塞进同一个容器，用 supervisor 管理多个进程，而不是一个脚本一个容器。比如，清洗和报告生成都用 pandas 和 Jinja2，那就放一起。第二，限制资源上限。在 docker-compose.yml 里给每个服务严格设置 `mem_limit: 512m` 和 `cpus: ‘0.5’`，并且把 Python 的垃圾回收机制调得更激进一些。这逼着我去优化代码，减少内存中的大数据对象残留，本质上是在跟服务器的账单搏斗。
闭环最后一步是自动发布。报告生成后，n8n 会调用一个脚本，把 HTML 文件通过模拟登录的方式上传到客户用的某个老旧 CMS 后台。这里最恶心的就是验证码和 session 维持，我用 PIL 加一些简单的二值化处理对付简单的图片验证码，复杂的就暂时绕不过，得准备个手动介入的“后门”节点。整个流程跑通那天，我看着 n8n 画布上那些自动流转的线条，没有兴奋，只有一种深不见底的疲惫——我花了三个星期，搭建了一个能替代半个程序员工作的系统，而省下来的这点人力成本，可能转眼又得填到其他项目的坑里去。
大厂搬总部是战略，是新闻。我这种小个体搞的“自动化搬迁”，是把脑力劳动从一个焦头烂额的自己，迁移到一堆冰冷但可靠的容器和流程线上。机会？也许有吧。至少下次再有程序员跟我说干不动了，我能指着屏幕说：“看，我在造你的替身，所以你最好别真的累死。”
