企业官网建设流程全解析

Maxun这种"录制式"爬虫工具，我关注它其实是被逼出来的。之前团队里接的数据采集需求，很多来自业务同学——他们不会写Python，但天天需要从公开网页里抓表格、监控价格、定时拉取行业信息。每次写Scrapy脚本，选择器一换正则就得改半天，等脚本写完了，页面又改版了。后来我试了试Maxun，发现它能直接在浏览器里录一遍鼠标操作，自动生成爬虫任务，浏览器上点击"抓取这个字段"就行，这才发现爬虫这事原来可以不用写代码。这篇文章系统梳理一下Maxun爬虫机器人的核心玩法、自托管部署过程和实战里踩过的坑，适合想搭一套内部数据采集平台、又不想每个需求都写脚本的开发者或运维同学参考。

1. 为什么我会盯上Maxun这个开源爬虫工具

在聊部署细节之前，得先弄清楚Maxun在整个爬虫工具链里的位置。它不是一个普通的爬虫框架，而是一套完整的"网页数据提取平台"。核心玩法是：通过浏览器扩展录制操作，生成一个可重复运行的Robot（爬虫机器人），之后在服务端定时执行或手动触发，最后把抓下来的数据导出成表格或通过API取走。

1.1 从写脚本到录浏览器：爬虫门槛的转变

传统爬虫流程是这样的：分析网页结构、写选择器、写反爬对抗、处理分页、设置重试、再写数据入库。这套流程对工程师来说很熟练，但对大多数需要数据的人来说，门槛高得离谱。

Maxun直接把"采集逻辑"这件事变成了"录一遍自己的操作"。你要做什么，就打开网页录什么——点击字段、输入关键词、翻页，然后在界面上标注"提取这个文本""提取这个链接"。它把这些动作自动转成可复用的机器人编排，后台再用无头浏览器去实际执行录制时的路径。

我个人觉得它的设计思路很像RPA，但它不是面向业务流程自动化的，而是专攻"网页数据提取"这一个动作。它的优势在于：

• 不用维护选择器代码，录制阶段自动记录元素的定位策略
• 把采集任务变成可视化编排，业务人员也能看懂
• 支持自托管，数据不出自己的服务器，不用像在线采集器那样把目标页面发给第三方平台

1.2 Maxun与常见采集方案的本质区别

我把Maxun和另外两条路线做个对比，大家就能理解什么场景下该选它。

从这个表能看出，Maxun本质上是在"工程师成本和业务效率"之间找了个折中点。对于那种数据量不大、采集源不稳定、又需要快速交付的需求——比如竞品价格监控、行业新闻聚合、公开目录抓取——它的性价比很高。要真碰上强反爬的站点、需要复杂加密参数计算的场景，我依然会回去写脚本，这点后面再展开。

2. 部署前的准备：机器选型、Docker环境与端口规划

自托管是Maxun的一个关键卖点。部署方式也不复杂，官方主推Docker Compose。但在真正执行之前，有几个前置决策值得花时间想清楚，否则后面改来改去很耽误事。

2.1 部署架构与资源需求怎么估算

先看架构。Maxun的部署包含三个核心角色：

• 主服务：负责存储机器人配置、运行记录、对外提供控制台和API
• 数据库：用PostgreSQL保存所有采集配置和历史运行数据
• 抓取执行器：在录制和运行时拉起无头浏览器，真正去访问目标网页

我用Docker跑的时候，最直观的感受是内存占用大头其实在无头浏览器身上。每执行一个Robot任务，执行器会拉起一个Chromium实例；如果并行度开得高，内存会线性上涨。

基于我的实际使用经验，资源估算可以参考这个区间：

• 单机部署、平时跑2-3个并发任务：4核8G足够
• 要跑8-10个并发任务，同时还要处理较大页面：建议8核16G起步
• 磁盘：主要增长来自PostgreSQL的历史运行记录和截图日志，按周清理的话，100G能跑很久

我自己在4核8G的机器上部署过，跑两个定时任务每天约十几次运行，整体负载稳定在30%左右，没有出现明显的资源瓶颈。

2.2 为什么用Docker而不是直接跑源码

项目本身是Node.js技术栈，理论上可以clone源码后npm install && npm run start直接启动。但我不建议自己维护这套源码运行方式。原因是：

1. 版本升级不方便。Docker Compose方式升级时只需要拉新镜像，源码跑还得处理依赖冲突
2. 隔离性强。抓取任务本身就带有不确定性，访问的目标网页可能携带恶意脚本，容器隔离能降低对宿主机的影响
3. 环境变量配置集中。数据库连接、初始化信息全在compose文件里，部署一次之后就再也不用动

所以我的建议是：不管你是临时体验还是准备长线使用，都直接走Docker Compose路线，这也是官方推荐方式。

部署前还有一件事要确认：服务器端口是否可用。默认情况下Maxun主服务跑在8080端口，我一般还会预留80或443做反向代理。如果你打算用域名访问，提前把DNS解析、HTTPS证书准备好，后面会省很多麻烦。

3. 用docker compose把Maxun跑起来

环境准备就绪之后，部署过程本身并不长。我按照实际操作顺序拆解一下。

3.1 准备compose文件与关键环境变量

首先登录到服务器，在合适的位置建一个目录，比如/opt/maxun，然后创建docker-compose.yml。以下是我基于官方模板调整后的精简版本：

version: "3.8" services: maxun: image: getmaxun/maxun:latest container_name: maxun restart: always ports: - "8080:8080" environment: - NODE_ENV=production - POSTGRES_HOST=db - POSTGRES_PORT=5432 - POSTGRES_USER=maxun - POSTGRES_PASSWORD=change_this_password - POSTGRES_DB=maxun depends_on: db: condition: service_healthy volumes: - maxun_storage:/app/storage db: image: postgres:15-alpine container_name: maxun_db restart: always environment: - POSTGRES_USER=maxun - POSTGRES_PASSWORD=change_this_password - POSTGRES_DB=maxun volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U maxun -d maxun"] interval: 10s timeout: 5s retries: 5 volumes: maxun_storage: pgdata:

几个关键点说一下：

第一，POSTGRES_PASSWORD是隐藏的安全隐患。很多人图省事用默认密码，直接把数据库暴露在局域网里，又开了5432端口映射，这就非常危险了。建议用强密码，并且不要把PostgreSQL的5432端口映射到宿主机，只让内部网络访问。

第二，maxun_storage这个卷非常重要。它用来保存运行日志、录制的截图和临时文件。生产环境上，我习惯把它额外备份一份到宿主机目录，方便排查问题。

第三，关于image标签。我一开始贪婪地用latest，图省事。后来发现，如果跑了一段时间后手动执行docker compose pull，新镜像可能带来破坏性变更。我的建议是：初次部署用latest没关系，等验证落地后，把镜像tag固定到你验证过的具体版本号，升级前先在测试环境跑一轮。

3.2 启动、初始化与访问验证

文件准备好后，依次执行：

docker compose up -d

然后看日志：

docker compose logs -f maxun

首次启动会有初始化过程，包括建表、生成默认配置。等日志里出现服务监听成功的提示后，打开http://服务器IP:8080访问控制台。

首次访问会让你创建管理员账号。注意：初始化账号只有一次机会，如果中间断网、刷新导致流程中断，需要进数据库手动清理初始化标记，否则会卡在注册页面。所以这一步最好在稳定的网络环境下操作，别用手机热点硬撑。

初始化完成后，控制台主界面就是机器人列表。到了这一步，部署就算告一段落了。下一步才是真正让人兴奋的部分——配置你的第一个爬虫机器人。

4. 部署完成后第一次配置爬虫机器人

Maxun的工作模式是"浏览器录制+云端执行"。录制发生在你自己的浏览器上，执行则在部署Maxun的服务器侧。理解这个分离逻辑很重要，它会直接影响你的排错思路。

4.1 安装扩展、连接自托管实例

要开始录制，首先需要在本机浏览器安装官方配套的Chrome扩展。安装后，扩展设置里有一个"连接服务器地址"的选项，把自托管实例的地址填进去，扩展就能和控制台联动。

这里有个细节注意一下：如果Maxun部署在内网IP，而你的浏览器在另一个网段，录制时要把两边网络打通。更常见的情况是给Maxun配一个自己域名的子域名，使用HTTPS访问，这样浏览器扩展和云端执行都更稳定。

连接完成后，点击扩展图标，选择"录制新机器人"，这时会新开一个浏览器窗口——这个窗口就是"你替机器人演示操作"的舞台。

4.2 录制一个真实采集任务：以商品列表为例

我用一个典型场景演示：抓取某个公开商品列表页的标题、价格和详情链接。

第一步，打开目标列表页，点击页面上的"下一页"。这个时候可以看到扩展生成了一条"点击翻页"的操作记录。

第二步，用鼠标框选第一个商品的标题文字，在弹出的菜单中选择"提取文本"。Maxun会为这个字段自动命名，在右侧面板里改成一个好认的名字，比如product_title。

第三步，同样选中价格，选择"提取文本"，命名为price。

第四步，右键点击商品标题/图片区域，选择"提取链接"，命名为detail_url。

第五步，关键一步——告诉机器人"这些提取动作作用于列表里的所有商品"。在右侧操作列表里，把product_title这一组提取步骤的父级设置为"重复元素"。实际操作中，Maxun会自动识别循环区域，你只需要确认它框选的范围是否覆盖了所有商品卡片。

第六步，保存并命名机器人，比如叫商品列表采集器。

录制过程中有几个习惯性动作会直接影响采集质量：

• 录制时别用滚轮快速滚动页面，要留出元素加载稳定的时间
• 如果页面有弹窗遮挡，先关闭弹窗再开始录制，否则执行时会反复卡在弹窗上
• 需要采集"下一页"链接时，确认选择器定位的是那个稳定的翻页按钮，而不是文字"下一页"本身——有些网站的文字周围会带隐藏的空节点，容易抓错

录制完成后，回到控制台，找到这个机器人，点击"运行"，系统就会在服务器侧的无头浏览器里重放你的操作。运行完成后，打开运行记录，就可以看到提取出来的数据表。这整个过程，一句话总结就是：你录的不是点击路径，而是采集的思路。

5. 部署后最容易踩的坑：任务卡死、字段错位与容器资源

使用一段时间之后，我发现Maxun虽好，但坑也不少。这里把这些坑记录下来，帮大家提前规避。

5.1 录制阶段的选择器陷阱：元素定位脆弱性

第一个让我头疼的问题，是选择器的"脆"。录制时Maxun记录的是元素的定位特征——包括ID、类名、文本、位置关系等。如果目标网站上线了新的CSS版本，某些类名变了，机器人就可能找不到元素。

举个例子。我录制的列表页里，原本用"价格div的class"做定位。后来对方把class从price-tag改成了prc-tag，整个任务一夜之间全部提取不到价格字段，运行记录里的价格列全是空的。

排查方式是从运行日志找到"元素未找到"的告警，然后重新打开页面查看当前元素的真实属性，再修改机器人的选择器策略。Maxun里可以给字段设置多个候选定位方式，相当于给自己买了个保险。我的做法是，对关键字段至少配置"文本定位+类名定位"双重方案。

另外一个常见问题是懒加载页面的滚动。有些列表页必须滚动到底部才会加载下一批数据。录制时如果只是点了"下一页"，执行时可能因为没触发滚动而导致数据缺失。解决方法是：录制过程中先执行一次"滚动到底部"的操作，再记录"下一页"点击，顺序不能反。

5.2 运行阶段的超时和错位：排查链路记录

跑得多了你会发现，任务偶尔会超时。目标网站的响应变慢，或者无头浏览器渲染卡住，都会导致运行任务一直挂起。

第一次遇到时，我在控制台反复点击"停止"，但任务始终显示运行中。后来我直接进服务器查看进程，才发现是执行器的浏览器进程僵死。处理方案分两步：

第一步，命令行手动清理僵死进程：

docker compose stop maxun docker compose start maxun

第二步，优化执行策略：给机器人设置运行超时时间，建议在3-5分钟。这样即便页面卡死，任务也会自动标记失败并终止浏览器进程，避免占用资源。如果你同时跑多个任务，还可以调低并发数，让每个任务都能拿到充足资源。

字段错位问题则更隐蔽。有一段时间我抓的数据表经常出现"价格列里混入标题"的情况。排查后发现原因是：页面部分商品有促销标签，导致价格元素的位置多了一个兄弟节点，Maxun的循环映射时把索引对齐搞错了。

我的解决方法是：把"提取价格"改成通过元素文本前缀去过滤——只提取以"￥"开头的文本节点。在Maxun的字段配置里可以对提取结果加"过滤器"规则，这个功能在应对样式不一致的页面时特别有用。

5.3 容器被杀的排查思路与资源兜底

如果你在服务器上同时部署了其他服务，非常容易遇到一个问题：内存耗尽后容器被操作系统杀掉。表现是Maxun控制台打不开，docker ps里看不到maxun容器，或者容器状态一直显示Restarting。

排查链路如下：

# 查看容器退出原因 docker inspect maxun | grep -A 10 '"State"' # 查看系统内存压力 dmesg | tail -50 | grep -i oom

如果看到OOMKilled字样，那就是内存不够导致的被动重启。针对这个情况，我的兜底方案是：

• 在compose文件里给maxun服务设置mem_limit: 4g，限制内存上限，防止它把宿主机吃垮
• 给关键定时任务错开运行时间，不要所有机器人都在整点启动
• 保留最近30天的运行记录，定期清理更早的日志，减少数据库体积

这套组合拳打下来，容器被杀的频率大幅降低。说到底，Maxun的无头浏览器是个内存大户，你得给它留出足够的空间，也要给它划好边界。

6. 进阶玩法与运维调优：定时调度、数据导出与备份恢复

部署稳定、基础采集跑通之后，Maxun的价值其实更多体现在"无人值守"和"系统集成"这两个方向上。

6.1 定时任务与数据导出：把采集变成常态化监控

对大多数实际需求来说，手动点"运行"肯定不够。我用的最多的是定时调度功能。比如监控某个竞品价格，我就把机器人设置为每天凌晨2点和下午2点各执行一次。选择时区的时候注意要选对，默认时区跑出来的时间和预期总会差8小时——这个坑我踩过一次。

定时调度配置好后，数据怎么取走是关键问题。Maxun支持把运行结果导出为CSV、JSON、Excel格式。实际使用中，CSV文件在服务器上生成后，我直接用脚本通过API拉取或者挂到内部文件系统里做后续处理。

导出CSV时有一个经典小坑：用Excel打开会出现中文乱码。解决办法是在导出设置里给CSV添加BOM头，或者在导入Excel时手动指定UTF-8编码。如果数据后续要进数仓，我更推荐直接导出JSON，字段结构清晰，也不会被表格软件乱改格式。

6.2 数据备份、版本升级与日常检查清单

自托管服务的最大责任是数据自己管。Maxun里最重要的数据是PostgreSQL里的用户、机器人配置和运行历史。如果服务器磁盘挂了，这些数据没备份就等于整个项目白干。

我的备份策略很简单：每周做一次数据库全量备份，通过docker exec进容器执行pg_dump，把备份文件传到独立存储位置。

docker exec maxun_db pg_dump -U maxun maxun > maxun_backup_$(date +%Y%m%d).sql

恢复的流程同样直接：

cat maxun_backup_20250101.sql | docker exec -i maxun_db psql -U maxun -d maxun

版本升级方面，我的做法是：先在测试环境用新镜像跑一天，确认录制、执行、导出这些核心链路正常，再在正式环境执行以下步骤：

docker compose pull docker compose up -d

升级前务必再备份一次数据库。有一次我图省事直接拉最新镜像，结果新版本对数据库结构做了变更，回滚时费了不少劲。从今往后我养成一个习惯：升级可以快，但备份必须先行。

日常巡检我一般看三个维度：

• docker compose ps确认所有容器正常
• 检查最近一次定时任务是否成功
• 观察磁盘使用率，尤其是PostgreSQL数据卷有没有异常膨胀

这三项花不了两分钟，但能把绝大多数隐患提前熄灭。

7. 实际使用一段时间后的个人体会

最后聊点这个工具的适用边界。Maxun是个好工具，但它不是万能的。我用了几个月之后，对它适合什么、不适合什么，心里基本有数了。

它最适合的场景，是那些"业务人员有明确采集需求、但技术团队不想为临时需求反复写脚本"的中小型团队。一个运营同学自己录一个机器人，跑起来第二天数据就到手了，这种效率提升是非常直观的。同时，因为数据全程在自己的服务器里流转，对于在意数据合规的内部数据采集需求，自托管也让审计和管控变得容易很多。

而它不太擅长的方向也很明显：一是需要复杂JavaScript计算、加密参数处理的站点，这种还是得回到真实浏览器自动化或手写协议层代码；二是数据量特别大、要求高并发抓取的场景，Maxun的定位决定了它在并发规模上不如专门设计的分布式爬虫架构。简单说，它是"够用且好用"的工具，不是"极致性能"的引擎。

如果你也打算部署一套试试，我的建议是从最简单的单页列表采集开始，跑通录制-运行-导出整个链路，再逐步加定时、加循环、加复杂字段处理。部署本身不是难题，难的是把采集逻辑设计得稳定、可维护。这一点，无论用什么工具，都是共通的。