企业官网建设流程全解析

这两年我的爬虫项目经历了一个典型的“由繁入简”过程。2026年还在聊工具选型，很多人第一反应是“Scrapy老当益壮”“Playwright又能处理动态页面了”，但实际上真把手头三个数据采集项目放在一起对比之后，会发现一个比工具本身更重要的问题：你到底是在做一次性技术验证，还是在长期维护一条数据管道？我在这轮横评里从Scrapy一路试到Bright Data，最后反而把大部分环节改成了“不写代码”的方案。这篇文章就把完整的选型思考、逐项评测和最终落地配置写出来，给同样卡在工具选择上的朋友一个参考。

先说清楚背景。我今年同时要跑三个项目：一个是垂直电商平台的商品页采集，页面上有动态加载的规格参数，还嵌了两个iframe分别管价格和库存；一个是行业资讯站的存量文章迁移，总规模大概十几万篇，多数是静态页面；还有一个是给研究团队做社交平台公开数据的抽样，对采集节奏和反爬要求比较高。这三个需求放在一起，基本覆盖了从最简单到最麻烦的所有爬虫场景，也正好让我把市面上主流的工具类型都过了一遍。

1. 先交代背景：我做的是什么项目，凭什么敢来横评

1.1 三个真实项目逼出来的选型需求

项目A是垂直电商的商品详情页采集。麻烦点在两部分：第一，商品的规格参数是页面加载后才通过接口动态渲染的，直接用HTTP请求拿不到完整数据；第二，页面上有价格iframe和库存iframe，主文档和两个iframe之间共享cookie但是不共享DOM。想抓全数据，要么处理异步接口，要么处理多文档上下文。我当时用Scrapy做了一层基础抓取，发现静态部分好办，动态部分得再叠加浏览器渲染，架构变得很别扭。

项目B是资讯站的文章迁移。这个站本身没有太强的反爬，但是存量十几万篇文章，分页规则、列表结构在最近半年改了三次。最开始我用Requests加BeautifulSoup写了一个简单脚本，十几万篇大概跑了两个多小时，跑完那一刻我觉得事儿已经结束了。结果第二个月网站改版，脚本直接报废，我花了整整一晚上去排查是哪个CSS选择器失效了。这种持续性维护，比写脚本本身更消耗人。

项目C是社交平台公开数据的抽样采集。平台的反爬策略比较激进，会检测请求频率、浏览器指纹、行为轨迹，稍有异常就返回验证码或者封禁请求。这个项目让我意识到，有些场景不是你写代码能解决的——你需要的是一个成熟的抓取基础设施，而不是自己从零去造轮子。

1.2 我用来横评的五维判断框架

在正式评测工具之前，我给自己定了一套五维评价框架，避免被某个工具的单个亮点带偏。这套框架在后面逐项对比时帮我省了很多决策成本，这里也分享出来：

这个框架看似简单，但实际使用时会发现，大多数争论“哪个工具好用”的人，分歧本质上是五个维度上的权重不同。有人看重免费，有人看重省心，有人看重抓取成功率，这决定了你最终会选到完全不同的工具。

2. 十大工具逐一点评：能打的、凑合的、纯粹来凑数的

2.1 Scrapy：静态抓取的地基，动态页面的一根刺

Scrapy依然是我在所有Python爬虫工具里最欣赏的框架。它的架构非常清楚：Spider定义爬取逻辑，Item Pipeline处理数据链路，Downloader Middleware管理请求生命周期。因为底层基于Twisted异步网络框架，并发处理几乎是开箱即用的。我在项目B的静态页面抓取上，用Scrapy加CrawlSpider，CONCURRENT_REQUESTS设到16，每分钟能稳定抓取1000多个页面，内存占用才200多MB。这个性能底线是绝大多数无代码工具无法比拟的。

但Scrapy的硬伤在于，它默认的HTTP请求不执行JavaScript。遇到动态渲染的内容和iframe嵌套，你得在中间件里塞一个Selenium或者Playwright去做浏览器渲染。我试过在Downloader Middleware里集成渲染，结果整个抓取速度从每分钟1000多个页面掉到每分钟十几个页面。Scrapy引以为傲的并发优势在动态页面场景下荡然无存，而且这种“双重架构”会让整个项目变得极其难维护。

2.2 Playwright：动态页面和iframe的一把好手

搜索热词里“scrapy playwright 动态 iframe”排得很靠前，说明很多人已经碰到了同样的痛点。Playwright是处理动态页面的最佳选择之一，一套API就能同时操作主页面和iframe，不需要像Scrapy那样手工拼接请求。

针对iframe，Playwright提供了frame_locator接口，可以直接在iframe内部选中元素。比如抓价格iframe里的金额：

price = page.frame_locator("#price-frame").locator(".price-value").inner_text()

登录态管理方面，storage_state机制可以把cookie和localStorage序列化保存，下次启动时直接恢复，不需要每次重新走一遍登录流程。我在项目A的调研阶段用Playwright搭了一套原型，功能上完全跑得通。真正让我犹豫的不是抓不到，而是维护成本。目标平台平均每个月调整两三次前端结构，每次调整后，选择器、等待条件、iframe定位逻辑全要跟着改。写代码本身不难，难的是你不知道它哪一天会崩，也不知道崩了之后要从哪里开始查。

2.3 Selenium：老牌王者，但越来越像一个备胎

Selenium在爬虫圈的地位不可否认，WebDriver协议支持几乎所有浏览器，社区里随便搜一个问题都能找到老帖子。通过WebDriverManager库，驱动管理和浏览器版本匹配的问题也基本解决了。

但它的性能瓶颈实在明显。Selenium走的是WebDriver协议，每次操作都要经过JSON Wire Protocol转换，天然比Playwright的CDP协议慢一大截。更关键的是，Selenium在现代反爬对抗中越来越处于下风。很多风控系统能通过navigator.webdriver属性、浏览器指纹特征、网络协议特征等识别自动化浏览器，Selenium在这类对抗里调整余地很小。

我的态度很直接：拿Selenium做UI自动化测试是一把好手，但如果是新开一个爬虫项目，我不会再选它。你如果已经积累了大量Selenium代码，继续用没毛病；如果从零开始，可以直接跳过。

2.4 Requests + BeautifulSoup：适合“一锤子买卖”，撑不起长期管道

Requests加BeautifulSoup是很多人的入门组合，也是我当年入坑爬虫的起点。对一次性抓几百条数据、之后不再重复的小需求，这套组合最省事，20行代码解决问题。

但它的边界同样明显：没有调度器、没有去重、没有重试机制、没有并发管理，所有工程化问题都得自己处理。我用这套组合跑过项目B的前期版本，每次网站改版，我都要花半天甚至一天去定位是哪个CSS选择器失效了。如果需求只是“跑一次就完事”，这套组合没毛病；如果是要长期维护的数据采集，你必须额外搭一个工程外壳，那为什么不直接用Scrapy呢？

2.5 Apify：云端Actor生态解决了托管问题，但定价不友好

Apify是比较特殊的云爬虫平台。它把爬虫封装成“Actor”，你可以理解成一个个部署在云端的迷你爬虫程序。平台上有大量现成的Actor，既能抓Twitter、Instagram等平台，也有把Scrapy项目打包上传的方案。

Apify最大的价值是帮你省掉了基础设施。不用管服务器、IP轮换、调度和部署，控制面板里填参数点运行就能开始，数据存在云存储里，通过API读取，也可以集成到Zapier或Make里实现自动化流转。

不过它不便宜。免费额度很有限，平台积分计费模式下，一个复杂的Actor跑一次可能就要消耗几百积分，高频使用很快会超过自己租一台云服务器的成本。Apify更适合不愿意维护基础设施但预算充足的团队，对个人开发者来说负担偏重。

2.6 Octoparse与ParseHub：无代码桌面的两位代表，容错率是软肋

聊到“不写代码”，Octoparse和ParseHub是绕不开的两个桌面级工具。两者都是通过可视化方式定义抓取规则，导出成Excel、CSV或JSON。

Octoparse的强项是模板丰富，很多常见网站都有预设模板，改改参数就能跑。它内置了基础的IP轮换功能，应付简单的频率限制够用。ParseHub的交互逻辑更像在“教”它怎么点页面，它的定义方式对一些特殊的翻页和加载交互反而更直观。

两家工具的短板也一致：容错率不高。我用Octoparse抓一个带Cloudflare防护的资讯站，网站加防护之前，配置半小时就能跑；加了防护之后，默认设置全部失败。我不得不去配置请求头、延迟、轮换IP这些选项，操作复杂度反而比写代码高得多。无代码工具真正的优势在于“有固定模式时快速上手”，一旦遇到非常规情况，灵活性短板就暴露了。

2.7 Bright Data：从数据基础设施服务商到抓取平台，技术实力最硬

Bright Data在我的评测名单里占据一个特殊位置。它最早以IP数据基础设施起家，在业内做数据采集的人几乎都用过它的住宅IP资源。这几年它明显在往抓取平台方向转型，推出了Web Unlocker、Scraping Browser和面向特定网站的预构建采集器。

Web Unlocker的核心理念很有启发：你提交一个目标URL，它替你完成页面渲染、风控绕过和结果提取，你直接拿数据。它内置了动态指纹管理、验证码处理和IP资源调度等反检测技术。我用它测试过那个带Cloudflare保护的资讯站，抓取成功率比自己在本地折腾高出不少，尤其是在连接稳定性和请求成功率方面，体验确实不一样。

Bright Data的缺点只有一个字：贵。计费方式按返回数据量算而非请求次数，高频高并发的场景下账单很容易让人心跳加速。但换个角度想，如果你面对的站点反爬特别强、自己怎么调都搞不定，花钱买它的成功率往往是综合成本最低的方案。

2.8 Diffbot：AI解析网页的先行者，价格也相当“AI”

Diffbot走了另一条路。它不依赖CSS选择器，而是用视觉分析和自然语言处理理解页面结构。给它一个URL，它返回一个结构化“实体”，可能是商品、文章、人物或事件，字段已经自动分好。

这个思路在某些场景下确实神。项目B那种文章迁移，Diffbot能自动提取标题、作者、发布时间、正文内容，不需要维护任何解析规则，网站改版对它几乎无影响。这是它最大的卖点，也是我用过的工具中唯一真正做到“无损应对改版”的。

但缺点头也很痛：贵，且结果不可完全掌控。AI解析偶尔会把广告文本当正文，或者把作者字段搞混，你需要花额外时间做数据校验。Diffbot适合数据量大、字段结构相对固定、特别不想维护解析规则的项目，本质上是拿钱买稳定性和时间。

2.9 n8n与低代码工作流：爬虫只是流水线里的一个环节

最后一个要提的，是n8n这类低代码工作流工具。严格说它不是传统爬虫工具，但2026年再谈数据采集，需求已经从“抓一次”变成了“持续抓、抓完要清洗、入库、推送通知”的完整数据管道。n8n填补的正是这个空缺。

n8n提供HTTP Request节点抓取JSON数据，HTML Extract节点基于CSS选择器提取内容，还有丰富的数据库、邮箱和IM集成节点，可以把整个流程做成可视化流水线：定时触发、抓取、解析、写入数据库、发送通知，全程不用写一行代码。它的学习曲线远低于完整爬虫项目，对轻量级抓取需求足够用，还能省掉单独开发调度系统的成本。我项目B的增量抓取后来就迁移到了n8n，每天定时跑一次，数据直接落到数据库，维护起来比维护Scrapy代码轻松太多。

2.10 总结一张表看对比

把上面十个工具按我的五维框架整理成表格，方便大家对照：

3. 那段时间把我逼疯的细节：iframe与反爬的拉锯战

3.1 一次完整的排查过程：iframe嵌套和cookie同步，三天才定位到根因

项目A的iframe问题是我这轮工具评测的导火索。最开始我预期用Scrapy就能搞定，因为商品的基本信息是能在HTML源码里找到的。但抓下来的数据里，价格和库存两个字段总是空的。

我花了一天验证是不是选择器写错了。检查了很多次HTML结构，发现那两个字段压根不在主文档源码里，而是由iframe动态加载的。问题变清晰了：价格和库存内容在另外两个文档里，需要单独发请求。

于是我在Scrapy里新写了一个请求，直接抓取iframe的URL。结果还是空的。继续检查才发现，iframe的URL带了一个token，这个token是主页面脚本在执行过程中通过一次异步接口获取的，每次访问都不同。我必须在Spider里先模拟一次异步调用来拿token，然后再拼接iframe的完整地址请求。这套链路走通之后，我又遇到了session不一致的问题——iframe里带着一个独立的cookie，是主页面在用户点击某个按钮时才种下的，如果不带这个cookie去请求，iframe返回的是空页面。

整个过程前后花了三天。最终用大概200行代码解决了，但代码量本身不是重点，让我难受的是每次网站上一次线，token生成逻辑就会变，cookie的种下时机可能也会变。我辛辛苦苦调试出来的逻辑，活不过两个月。你写的是代码，但维护的是一个需要持续盯防的移动靶。

3.2 反爬升级的博弈：写完的那一刻，方案可能就已经过时

项目C让我更深刻地体会到一件事：反爬对抗是动态博弈，是持续的军备竞赛。

社交平台的公开数据接口，最初直接请求就能拿到JSON。后来加了请求频率限制，我加了一个随机延时，问题暂时解决。再后来它开始校验请求头的顺序，我开始伪装浏览器头。然后是TLS指纹识别、验证码、封禁、需要登录后才能看到更多内容……

每次升级，我都要花时间重新应对，短则几小时，长则几天。而且这些改动往往无法预判，你没有办法提前设计一套“一劳永逸”的方案。更要命的是，即使你解决了当前的反爬问题，平台下一次升级随时可能让你的整个脚本再次失效。

对比一下不写代码的工具路线：Web Unlocker这类托管服务把反爬对抗完全包给了服务商。平台升级反爬策略，服务商通常会在几小时到几天内更新自己的方案，你作为使用者几乎无感知。这也是我最终转变思路的契机——我不再关心“怎么应对反爬”，而是把“怎么稳定拿到数据”变成了一个采购问题，而不是研发问题。

3.3 成本核算：写代码 vs 不写代码，账要算清楚

很多人选工具时只看软件价格或者“要不要花钱”，忽略了最贵的成本其实是自己的时间。我按项目A的实际情况做了一次粗略核算：

把人力成本折算进去，自己写代码的方案一年下来并不比付费方案便宜。我之前一直有一种执念，觉得“自己写才是搞技术”，但后来发现，爬虫是一类很特殊的开发任务：它的核心难点不在工程实现，而在持续对抗外部环境变化。把对抗成本外包给专门做这件事的服务商，其实是在用钱换更宝贵的时间。

4. 我最终落地的不写代码方案：工具组合、配置细节与实测结果

4.1 为什么不是“某一个工具”，而是一套组合

经过一个多月的折腾和对比，我没有只选一款工具，而是搭了一套按难度分层的组合方案。原因很简单：没有哪一款工具能同时满足我三个项目的全部需求，但组合起来就能覆盖得很完整。

• 项目B的资讯站文章迁移，难度较低，交给了Octoparse加n8n，前半段负责抓取列表和正文，n8n负责定时触发、数据清洗和入库。
• 项目A的电商商品页，iframe和动态渲染很麻烦，直接上Bright Data的Web Unlocker接口，提交链接拿结果，不再自己维护渲染逻辑。
• 项目C的社交平台抽样，反爬最重，同样用托管服务处理，配合平台API做数据规范化的后处理。

三个项目里，只有少量定制化逻辑，比如字段清洗和时间格式化，我用n8n的节点配置完成，没有写完整的爬虫程序。整套方案最核心的思路是：能用现成服务的绝不自研，能把逻辑下沉到工具的绝不用代码硬撑。

4.2 具体的工具配置与操作步骤

以项目B为例，我给出一个可以直接参考的配置流程。

第一步是Octoparse里的任务配置。新建一个“自定义抓取任务”，把列表页URL粘贴进去，软件会加载页面。我在页面上点击文章标题和摘要字段，Octoparse自动高亮选中，我把它们映射成“标题”“链接”“摘要”三个字段。然后点掉几个跟分页相关的按钮，告诉它“下一页”在哪里，软件就能自动识别分页规则。整个配置过程在界面上完成，大约半小时。

第二步是导出格式配置。在任务设置里，我选择“定时运行”和“每次运行后导出为JSON”，数据存储位置挑了一个共享文件夹，方便n8n读取。定时频率设置为每天凌晨3点，避开目标站点的访问高峰。

第三步是n8n的流程配置。我在n8n里新建一条workflow：

• 用一个Schedule Trigger节点设置每天早上4点触发，比Octoparse晚一小时，等数据生成完。
• 连接Read/Write File节点读取Octoparse导出的JSON文件。
• 加一个Code节点做字段清洗，比如移除正文里的HTML标签、把时间戳转成标准时间格式。
• 最后接到Postgres节点写库。

我只需要拖动节点、填写参数、点击保存。n8n还自带错误重试和通知机制，失败了会发一条消息到团队群，我不用每天起来检查有没有跑挂。

第四步是项目A的Bright Data配置。在控制台创建一个Web Unlocker请求：

请求示例： GET https://api.brightdata.com/request Headers: Authorization: Bearer <你的API密钥> Content-Type: application/json Body: { "url": "https://目标站点/product/12345", "country": "any", "render": true }

返回的JSON里包含渲染后的HTML和结构化数据字段。我把这段请求封装在n8n的HTTP Request节点里，和项目B共用同一条数据管道。这样项目A的抓取维护从原来每月1-2天降到了基本为零——只要站点没有出现特别离谱的结构变化，Web Unlocker会自动适配。

4.3 运行三个月的实测数据

这套方案上线跑了三个月，我记录了几个关键数据：

三个月下来，工具总成本大约多了一千块钱，但省出来的时间至少是20个工作日。这笔账怎么算都划算。更重要的是，我不再处于“随时担心代码失效”的焦虑状态里了。

5. 给后来者的建议：什么时候继续写代码，什么时候果断放弃

5.1 写代码仍然是最优解的场景

我也不是建议所有人都放弃写代码。如果你遇到下面这几种情况，自己写代码依然是最合理的选择：

• 深度定制的工程化需求：需要和现有业务系统深度集成，对并发、调度、数据精度有特殊要求，现成工具包不住。
• 高度专业化的解析：抓的是某个特定协议或者加密接口，需要逆向分析，无代码工具根本做不到。
• 预算极其有限：每月连几百块工具费都拿不出来，只能用时间换钱的时候。
• 学习目的：你想通过爬虫入门Python、熟悉异步编程和前端渲染，那必须自己写一遍。

5.2 不写代码更省心的场景

反过来，如果你的情况符合以下特征，果断转向不写代码的方案：

• 抓取目标是常见网站类型，比如电商商品页、资讯文章页、社交媒体公开页，这类需求已经有非常成熟的模板和服务。
• 目标页面经常改版。任何需要“维护选择器”的方案都是长期债务，让工具服务商替你去还。
• 反爬压力很大，而你又不打算把爬虫当作核心业务。
• 你更在意数据结果，而不是代码过程。

5.3 我踩过的几个坑

最后分享几个踩坑经验，希望能帮后来者少走弯路。

第一个坑是“先选工具再想需求”。我在项目A初期先定了Scrapy，导致后面所有设计都在迁就Scrapy的限制。正确做法是先列需求清单，再倒推工具选型。需求清单包括：目标页面类型、预计数据量、抓取频率、是否需要登录态、是否处理iframe、反爬预期强度、数据如何消费。这七项列完，工具基本就浮出水面了。

第二个坑是忽略数据校验环节。无代码工具也可能会返回脏数据，尤其是网页结构调整或者AI解析误判的时候。建议在数据管道里加一个字段完整性校验节点，比如检查一条记录里标题、链接、正文三个字段是否都非空、格式是否正常，失败记录单独标记出来人工处理。

第三个坑是以为“不写代码”等于“一点不学技术”。实际上你还是要理解DOM结构、HTTP状态码、XPath/CSS选择器这些基础概念，只不过不需要亲手实现调度器、解析器这些工程组件。我在n8n里配置HTML Extract节点的时候，如果不清楚CSS选择器怎么写，一样寸步难行。所以这篇文章说的“不写代码”，准确说是“不写工程化代码”，但要懂得怎么用节点、怎么设计数据流、怎么定位问题。掌握了这套能力，你会发现爬虫这件事终于从一项持续的负担变成了一次性配置就能长期跑通的基础设施。