企业官网建设流程全解析

做爬虫这几年，我接过不少需求：查竞品价格、抓商品评论、收集行业名录……每次都是先写Python脚本，再处理IP封禁和页面改版，一套下来累得够呛。所以第一次看到maxun这个开源项目时，我第一反应是：总算有个能替我“跑腿”的东西了。

maxun是一个开源的、无需写代码的网页数据抓取工具，官方管它叫“爬虫机器人”。它的核心玩法很有意思：你在浏览器里像正常上网一样操作一遍网页，它把你点击、输入、滚动、选中数据这些动作全部录下来，然后自动生成一个可以重复执行的抓取流程。你把这个流程保存成一个“机器人”，之后每次运行，它都会自动打开目标网页、执行你录过的操作、提取你指定的字段，最后把结果放到控制台，或者导出成文件。

这篇文章适合两类人看。一类是运营、产品、市场这些业务侧的同学，不想写代码但需要定时采集公开网页数据；另一类是开发同学，想快速给团队搭一套自托管的抓取工具，又不想每次需求都从头写脚本。我按“它是什么—架构怎么设计—怎么部署—怎么上手—踩过哪些坑—值不值得用”这个顺序，把这套东西完完整整讲一遍。

1. maxun定位梳理：先搞清楚它到底解决什么问题

1.1 从“手工复制粘贴”到“录制式抓取”

先说个最简单的场景。很多运营同学每天早上需要打开几个行业网站，把新增的供求信息、价格更新、竞品动态一条条复制到Excel表格里。这件事本身不复杂，但很耗时间，还容易漏。python爬虫确实能解放这部分人力，但让业务同学维护一套Python脚本，也不现实。maxun切入的就是这个中间地带：它不需要写代码，用“录屏+圈选”的方式就能把人工操作变成自动化流程。

你只需要在maxun的录制器里，把平时做的事做一遍：打开网页、输入关键词、点击搜索、滚动翻页、选中结果标题和价格，然后点保存。整个过程类似Excel里的“宏录制”——你操作一次，系统记下流程，之后让机器人按这个流程反复执行。这对完全不懂编程的人来说，几乎是零学习成本。

1.2 和传统爬虫方案相比，优势在哪

我做了个对比表，覆盖我落地项目时最常比较的三个维度：上手门槛、部署成本、长期维护。

maxun最明显的短板是它不适合搞百万级分布式抓取。它的定位是“轻量、够用、能自助”，解决的是业务侧最常见的那种需求：定时采集公开数据、量不大、要稳定。你要真想抓全网的公开数据，那还是老老实实上scrapy或自研分布式采集系统，这不是一个赛道的东西。

1.3 这些需求才是它的主战场

结合我用过的实际情况，maxun最典型的使用场景有这么几类：

• 电商价格监控：盯竞品商品的价格变化，每天记录一次，用于后续调价策略或周报。
• 公开名录/黄页整理：从行业信息网站抓企业名称、联系方式、地区等公开字段。
• 招聘信息汇总：抓取职位列表、薪资区间，做简单的行业薪酬分析。
• 资讯归档：定时抓取新闻或公告标题、链接，存下来做内容盘点。
• 上游供应链行情：原料价格、汇率牌价这类公开数据，定期落库。

这些需求有个共同点：数据都在公开页面上，不需要破解什么登录墙，量级也就是几百到几千条，但要求“每天定时跑、稳定不挂”。maxun正好踩在这个需求点上，这也是它在开源社区里火起来的原因。

2. 架构拆解：一个爬虫机器人任务是怎么跑通的

2.1 前端控制台：所有操作的入口

maxun的前端是一个基于React（Next.js）的单页应用，部署后默认跑在5173端口。你在浏览器里打开它，就能看到控制台：登录注册、创建机器人、管理运行记录、查看提取结果、配置定时调度，全部都在这里完成。它和后端之间走的是REST API，所以前端本身不碰数据库，也不碰抓取逻辑，纯粹是“操作台”。

2.2 后端服务：管账号、管配置、管调度

后端是NestJS写的Node.js服务，默认跑在8080端口。它主要负责四件事：

第一，用户认证和权限管理；第二，机器人配置的存取，包括你录制的每一步操作（step）和每个提取字段（extraction）；第三，调度管理，定时任务靠它触发；第四，任务转发，把用户手点“运行”或定时触发的任务投递到消息队列里，等worker来消费。

后端本身不开启浏览器，也不执行抓取动作，所以它的CPU和内存压力很小。这也解释了为什么单独拆一个后端服务出来——把“管任务”和“干活”分开，资源占用大头留给worker。

2.3 worker执行器：真正打开浏览器干活的人

worker是整套系统里最核心的“劳动力”。它监听Redis队列，拿到一个待执行任务后，就启动Puppeteer，拉起一个Chromium实例，然后按照录制时的步骤一步步回放：打开URL、等待元素出现、点击、输入、滚动、提取数据，最后把结果往回传。

这个组件的设计要点是“无状态”。它不保存任何用户状态，只负责执行任务。这意味着想加快抓取速度，直接多起几个worker实例就行，后端和前端都不用动。这也是我推荐用Docker部署的原因之一——docker compose里把worker的replicas调大，扩容非常方便。

2.4 存储与队列：数据落在哪

maxun的存储分两块。关系型数据库（不同版本可能用PostgreSQL或MariaDB，具体以你拉的镜像为准）负责存三类东西：用户账号、机器人配置（操作步骤和字段定义）、运行结果。Redis负责做任务队列，后端把任务push进去，worker从里面pop出来执行。

这里有个容易踩的坑：运行结果是存在数据库里的，如果机器人每天都跑，数据会持续累积。量小的时候无所谓，跑几个月后你会发现数据库体积明显变大。建议定期导出结果后清理历史运行记录，给数据库留出余地。

2.5 一次完整任务的数据流

帮你在脑子里过一遍全流程，理解了这个后面排查问题会顺很多：

1. 用户在控制台点“运行”，或者到了定时任务设定的时间。
2. 后端创建一条运行记录，把任务投递到Redis队列。
3. worker从队列取出任务，启动Chromium实例。
4. worker按录制步骤逐条执行，期间做元素等待、交互、字段提取。
5. worker把提取结果回传给后端，后端写入数据库。
6. 控制台刷新，显示运行状态和结果详情，用户可以导出。

之所以把流程拆这么清楚，是因为“定时任务不执行”或者“跑出来是空的”这类问题，基本都是这一步或那一步断了。排查的时候先看队列里有没有任务堆积，再看worker日志有没有报错，基本就能定位。这个思路放到任何爬虫系统里都通用。

3. 部署实操：手把手把maxun跑起来

3.1 部署前的资源准备

先说服务器。maxun本身是Node.js服务，CPU要求不高，但内存要注意。原因在于抓取时每个Chromium实例大概要占300到500MB内存，如果机器人同时跑三四个任务，占用就奔着2G去了。我建议最低配2核4G，再低的话worker很容易被系统杀掉，表现为“任务一直pending但不执行”。

操作系统用主流的Ubuntu 22.04或Debian就行。前提是装好Docker，版本要求20.10以上，以及Docker Compose v2。你可以用下面的命令确认：

docker --version docker compose version

如果还没装，可以参考Docker官方文档，在Ubuntu上通过apt安装docker-ce和docker-compose-plugin。

3.2 克隆代码并一键启动

maxun官方提供了完整的docker-compose编排，部署过程比我想象中还要省事。核心就三条命令：

git clone https://github.com/getmaxun/maxun.git cd maxun docker compose up -d

第一次执行时Docker会自动构建镜像，视网络情况可能要等几分钟。构建完成后，整个编排会拉起这几个容器：前端（frontend）、后端（backend）、worker、数据库（db）、队列（queue）。具体服务名以你clone到的docker-compose.yml里定义为准，版本不同可能略有差异，但大结构是一致的。

3.3 验证服务状态

启动后，用以下命令看容器状态：

docker compose ps

正常情况下所有服务都应该是Up状态。然后打开浏览器访问http://你的服务器IP:5173，能看到maxun的控制台首页就说明前端起来了。后端接口在http://你的服务器IP:8080，页面会返回一个健康检查相关的响应。

这一步如果发现容器反复重启，先看日志：

docker compose logs -f backend docker compose logs -f worker

最常见的启动失败原因是端口被占用，或者数据库/队列的连接配置没对上。检查一下有没有其他进程占着5173和8080，以及.env文件里的环境变量是否和docker-compose里的一致。

3.4 初始化账号与安全基线

部署之后第一件事是注册一个管理员账号。maxun没有强制初始密码，直接打开页面注册第一个用户，这个用户会成为系统里的第一个账号。这里提醒两点：一是如果服务器暴露在公网，建议注册后立刻改掉默认端口，或者用Nginx做反向代理，把5173和8080都藏在域名后面并启用HTTPS；二是数据库和Redis尽量不要暴露到外网，Docker网络内部互通就够了。

3.5 生产环境建议：内存限制与数据备份

自托管服务最怕半夜悄无声息挂掉。我自己的做法是给worker加上内存限制，避免它把整台服务器拖垮：

# docker-compose.yml 中worker服务的部分 worker: mem_limit: 1500m

数据库备份也一样，我用一个定时任务每天凌晨dump一次PostgreSQL或MariaDB的数据。对备份文件保留最近7天就够，这是“最少必要备份”的思路。

3.6 非Docker方式跑开发环境

如果你想在本地改代码或者调试，可以不走Docker，直接起三个进程：后端、前端、worker。这种模式需要自己安装Node.js、PostgreSQL、Redis，并分别配置数据库连接和队列连接的环境变量。本地开发流程我在跑Puppeteer相关项目时踩过不少坑，建议尽量用Docker跑依赖（数据库和Redis），只在宿主机起前端和后端，免得本地环境一团乱麻。

4. 上手实操：录一个“竞品价格监控机器人”

4.1 新建机器人：从起始URL开始

部署好后端到前端，登录控制台，点击右上角的“新建机器人”，输入你想抓取页面的起始URL。这一步相当于告诉机器人“从哪开始干活”。我建议起始页选一个稳定的列表页或搜索页，而不是直接选一个详情页，因为列表页往往能提取多条数据，效率更高。

4.2 录制操作：把人工流程变成步骤

进入录制器后，会打开一个可交互的预览浏览器。你在这个预览窗口里做的每一步操作，都会被实时记录到左侧的步骤列表里。常用的动作有：点击、输入文本、滚动、等待一段时间。

这里有一个我吃了不少亏的经验：录制时不要用“绝对坐标点击”，而是尽量点击稳定的元素，比如按钮的文案、图片的alt属性。因为页面滚动后坐标会变，而元素本身的位置是相对稳定的。比如搜索按钮，最好通过按钮上的文字“搜索”来定位，而不是记它在屏幕第几行第几列。

录制过程中尽量保持操作简单。一个机器人只做一件事，比如“搜索关键词并提取第一页结果”。不要试图在一个机器人里把搜索、翻页、点详情、回退全部录完，步骤越多，回放失败的概率越高。

4.3 圈选字段：告诉机器人你要什么数据

操作录完以后，最关键的一步是定义提取字段。在预览浏览器里，你可以把鼠标移到页面元素上，选中要提取的内容，然后给它起一个字段名。比如：标题、价格、链接、图片地址。

对于列表型页面，比如搜索结果，maxun支持循环提取多个条目。你可以选中第一条记录的“标题”，它会智能地把同类元素都识别出来，这样一次运行就能抓取整个列表的数据。字段名建议用英文或拼音，导出CSV时列名更干净，后续做数据分析也方便。

4.4 运行与调度：单次跑通再上定时

保存机器人之后，先不要急着配置定时任务。我的习惯是先在控制台点“运行”按钮，手动触发一次，等结果出来了检查字段是否对得上。尤其是价格这种数字字段，经常会有“¥ 1,299.00”这种带货币符号和千分位逗号的格式，要确认提取后的数据是否清洗到位。

确认单次运行没问题后，再配置调度。maxun支持用cron表达式设置运行时间，比如每天早上9点跑一次：

0 9 * * *

如果你的服务器时区不是UTC，记得先确认cron的时区设置，否则可能出现“明明定的早上9点，结果下午4点才跑”的尴尬情况。

4.5 数据导出与对接

运行结果可以在控制台查看，也可以一键导出为CSV或JSON。如果你有自己的数据系统，还可以通过Webhook把结果推送到自己的接口，实现自动化对接。我在实际项目里就是让maxun每天早上抓完数据，通过Webhook推到我们的内部数据库，再触发下游的报表计算，整个过程不用人盯。

5. 常见问题与排查技巧实录

5.1 录制时元素点不中或选不中

这是入手maxun时被问得最多的一个问题。大部分原因是目标页面用了动态加载，或者元素被弹窗、浮层遮挡。解决办法是：在录制时给“点击”前面加一个“等待”步骤，让页面充分渲染后再操作；如果遇到iframe嵌套的页面，先检查录制器是否支持切换到指定iframe；实在不行就换一种交互方式，比如用键盘快捷键而非点击。记住一个原则：宁可多等两秒，也不要盲目点击。

5.2 运行结果为空

机器人录好了，运行也提示成功，但结果数据是空的。这种情况大概率是页面结构变了，或者录制时字段圈选的是绝对定位，页面任何轻微改版都会导致选择器失效。排查步骤是：打开录制器重新进入页面，看看目标元素还存在不存在。如果还在，多半是字段选择器偏了，重新圈选一次并保存；如果元素本身没了，那就得换一个稳定的页面或换一种提取方式。

5.3 worker内存被系统杀掉

现象是任务创建后一直卡在pending状态，docker compose ps看到worker容器是重启状态或退出了。打开worker日志，几乎都是OutOfMemory。我前面提过，给worker设置mem_limit是防护手段，更根治的办法是控制同时运行的任务数，不要在同一个时间点让所有机器人一起跑。把定时任务分散到不同分钟，远比把worker堆内存靠谱。还有，一个任务里如果翻页几十次，浏览器内存会持续上涨，这类重活建议拆成多个轻量机器人。

5.4 定时任务不触发或时区不对

cron表达式本身没毛病，但就是不触发，先看worker是否在线。定时调度靠后端把任务塞进队列，worker消费，如果worker挂了，任务会一直堆积在队列里。另外注意时区：如果maxun的调度按UTC处理，你在配置界面填写的“每天9点”可能和你本地时间差8个小时。我的做法是统一以服务器时间为准，cron表达式里手动换算好再填。

5.5 目标站点加了基础反爬策略

这是个绕不开的话题。对公开数据做低频、合规的采集，一般来说问题不大。但如果目标网站出现验证码、行为检测之类的机制，普通录制机器人确实会吃力。我的建议是：从合规和数据伦理角度考虑，优先抓取允许爬取的网站，遵守目标站的robots.txt规则；采集频率拉低，比如一天一次，不给对方服务器增加压力；可以在录制里加入随机等待步骤，模拟真实用户的操作节奏。即使这样仍然被限，就别硬刚了，换个数据渠道或联系对方开放API才是正路。

5.6 运行记录越积越多，数据库膨胀

maxun每次运行都会保存结果，巡检发现跑得久的实例数据库能达到好几GB。处理和上面提到的一样：定期清理历史运行记录，或者用脚本把结果导出后删除旧的运行数据。数据库瘦身不仅能节省磁盘，还能让控制台响应更快。

6. 用了一段时间后的体验与建议

说实话，maxun给我的整体感受是“性能够用，门槛够低”。它把一个传统上需要写代码才能做的事，压缩成“录一遍、跑定时、看结果”，这种体验对业务同学非常友好。我在一个真实项目里用它跑了两个多月，每天早上自动抓一批公开的价格数据，稳定率在九成以上，偶尔出现的空跑基本都发生在目标站点改版之后，重新录制一次就能恢复。

给准备入手的你几个建议。第一，先跑通一个最简单的小场景，再逐步加复杂逻辑，别一上来就录一个30步骤的超级机器人。第二，机器人命名和字段命名养成规范习惯，导出数据的时候你就知道这有多重要。第三，目标页面一旦确认稳定，尽量不要频繁改动录制步骤，每一次手改都可能引入新的不确定性。第四，部署了就要关注服务器资源，尤其是内存和磁盘，建议给Docker和数据库配置简单的监控告警。

还有一个我个人的小习惯：录制完成后，先用“试运行”模式连续验证两三次，确认手动跑、定时跑结果一致，再放心交给定时任务。这样能省掉很多半夜被“数据是空的”这种消息吵醒的麻烦。抓取公开数据是一件长期重复的事，把每一步都做扎实了，后面才能睡得安稳。