企业官网建设流程全解析

PLFM_RADAR 这个名字，懂行的人一眼就能拆出来：PLFM 是 Platform 的缩写，RADAR 就是雷达。合在一起，就是一套“平台雷达”——盯着多个公开平台持续扫描、把目标数据自动捞回来的系统。跟雷达扫描空域一个道理：你给它一个范围、一组目标，它就不停地转、不停地看，把新增的、变化了的、异常的信号全部捉回来。

我做这套东西的起因特别实际：手上同时维护着好几个资讯源和商品渠道，业务方每天要“全网价格对比”“竞品动态日报”“舆情走势”，靠人工一个个开网页、复制、粘贴、再汇总，一天下来光重复劳动就占掉三四个小时，还容易漏。后来逼急了，干脆把这个活儿做成一个自动化雷达系统，让机器去盯，人只负责看结果。

这套系统适合谁？两类人最对口：一类是每天跟多平台数据打交道的运营和分析师，另一类是刚开始接触爬虫和数据采集的开发者。前者可以把它当成一个现成的采集思路参考，后者则能从中看到一整套“从扫描到落库”的完整链路是怎么搭起来的。

1. 项目定位与整体设计思路

1.1 为什么叫“平台雷达”

雷达的概念其实特别适合描述数据采集这件事。雷达的工作原理是：发射信号、接收回波、从回波里提取目标信息。放到数据场景里，就是：

• 发射信号 = 定时向目标平台发起请求；
• 接收回波 = 拿回 HTML、JSON 或者其他结构化的响应；
• 提取信息 = 从响应里解析出标题、价格、发布时间、作者、热度这些字段。

我一开始没想这么多，纯粹觉得 PLFM_RADAR 这名字够直白，后来做着做着发现，雷达还有另外两个特性特别值得借鉴：一是持续扫描，二是目标筛选。持续扫描意味着你不能只跑一次，得按固定节奏反复跑，才能捕捉到“新增”和“变化”；目标筛选意味着你得先定义清楚“雷达要盯哪片空域”，不然全网数据量太大，跑不完也存不下。

所以这个项目的核心不是“爬得有多快”，而是“盯得有多准”。把有限的计算资源聚焦在少数几个关键平台上，设定好扫描频率、目标路径和字段规则，剩下的交给系统自动执行。

1.2 四大核心模块的拆解

我实际把系统拆成了四个模块，各管一摊。

第一个是调度模块。它决定什么时候去扫哪个平台，相当于是雷达的“转速表”。我用的是定时任务加队列的方式，每个平台对象自带扫描间隔，比如商品类平台 1 小时扫一次，资讯类平台 30 分钟扫一次，热点类平台 10 分钟扫一次。调度模块到点就把任务丢进队列，由工作进程取走执行。

第二个是采集模块。它的职责是真正发起请求并拿到响应。这里要处理的坑最多，包括请求头伪装、频率限制、过期链接、接口参数变化等等。采集模块我做得比较“厚”，集成了统一的重试机制、超时控制和响应状态检查，任何异常都会记进日志，而不是直接崩掉整个任务。

第三个是解析模块。拿到响应之后，得从里面结构化出有用的字段。这一步我用的思路是“配置化解析”：每个平台对应一份解析配置，里面写清楚标题、正文、价格、时间分别用什么选择器或正则提取。这样以后平台结构变了，改配置就行，不用动代码。

第四个是存储与通知模块。解析出来的数据统一写入数据库，同时跟历史数据做对比，如果发现新增或者显著变化（比如价格大幅波动、标题换了两版），就通过消息通知推给相关人员。这个模块让整套系统从“自动采集”升级成“主动预警”。

模块划分的原则就一句话：单一职责、接口清晰。每个模块只干自己的事，模块之间通过数据结构和消息队列沟通，后期想替换任何一个环节都不会牵一发动全身。

1.3 技术选型：为什么用这套组合

技术栈我没追求新潮，全部选稳定成熟的东西：Python 3.10 做主语言，Requests 加 BeautifulSoup 处理绝大多数静态页面，遇到接口型数据源就直接请求 JSON 接口；调度用的 APScheduler，队列用的 Redis，数据库用的 PostgreSQL，通知用的企业微信机器人。

有人可能会问，怎么不用 Scrapy、不用 Playwright？我的考虑是这样的：Scrapy 确实强大，但它的学习成本和框架约束对一个小而美的系统来说有点重；Playwright 适合跑 JavaScript 渲染严重的页面，但资源占用高、并发能力差，我只有少数几个平台需要执行 JS 才能拿到数据，没必要让整套系统都背着浏览器跑。

选择 Requests 加 BeautifulSoup 还有一个现实原因：大多数平台的公开数据其实藏在两个地方，要么是静态 HTML 里直接渲染出来，要么是页面向后端接口请求后返回的 JSON。前者用 BeautifulSoup 抽数据很顺手，后者直接 Requests 拿 JSON 更快。只有在这两种方式都失效的时候，我才会临时引入 Playwright 做兜底。

数据库选 PostgreSQL 而不是 MySQL，主要是看中它对 JSON 字段的支持和数组类型。采集来的半结构化数据可以直接塞进 JSONB 列里，查询和扩展都比较灵活。Redis 的作用是任务队列和简单缓存，比如去重用的指纹集合、最近抓取过的 URL 列表，放 Redis 里做内存判断效率高得多。

这套组合的优点是：上手快、依赖少、单机就能跑起来，不用搞一堆容器编排。缺点是并发能力有限，但我的场景是“盯住少量目标平台”，单机加协程的方式完全够用。如果你的目标是全网大规模采集，那这套思路里的模块划分仍然可以参考，只是执行层需要换成更重的分布式框架。

2. 核心细节解析与采集要点

2.1 平台接入规范与合规边界

开始写代码之前，我强烈建议先把合规这事想清楚。这里不讨论法律条文细节，只说实际操作中我给自己定的几条红线：

第一，只采集对公众开放且允许被索引的数据。需要登录才能看的内容、明确写了禁止抓取声明的内容，一律不碰。第二，控制请求频率，不给目标平台造成压力。我自己定的标准是单平台请求间隔不低于 5 秒，单个出口的并发数不超过 3。第三，尊重平台的反爬机制，对方明确拒绝访问的接口，不去硬闯。

这三条听起来像空话，但实际执行中特别重要。我见过不少团队贪图一时方便，把频率调得很高，结果 IP 被拉黑、接口被封，连正常的业务访问都受了影响，得不偿失。真正稳的采集系统，节奏一定是有节制的。

另一个容易被忽略的点是数据的使用边界。内部做分析、做报表，问题不大；但如果你把采集来的数据打包售卖、或者大量转载到自己的平台上，就很容易踩到版权和竞争的雷区。我的做法是：数据只服务于内部决策，风险极高的平台直接放弃采集，换人工录入。

2.2 页面解析与反爬应对

解析这块，我的经验是优先找接口，次选静态 HTML，最后才考虑浏览器渲染。为什么？因为接口返回的 JSON 结构清晰、字段完整，解析成本最低；静态 HTML 虽然要写选择器，但胜在稳定，只要页面版式不变就能一直用；浏览器渲染虽然能拿到一切，但速度慢、耗资源，而且每个平台都要维护一套浏览器自动化代码，属于高维护成本方案。

实际操作里，我遇到过好几次“页面看着是静态渲染，其实数据是从接口拉回来再填充的”情况。这时候只要打开浏览器的开发者工具，切到 Network 面板，刷新一次页面，看哪些请求返回了完整的业务数据，就能找到真正的数据源。这种做法比我最初“埋头分析 HTML 结构”的效率高太多了。

反爬应对是绕不开的话题。我的原则是“像真人一样访问”，而不是“暴力破解验证码”。具体做法包括：

• 请求头尽量模拟真实浏览器的完整信息，包括 User-Agent、Accept-Language、Referer 等；
• 每次请求之间加随机延时，比如 3 到 8 秒，不要用固定值；
• 定期轮换 User-Agent，不要一个 UA 用到底；
• Cookie 尽量携带真实会话信息，尤其是需要登录后才能看的数据，我会用单独维护的账号带 Cookie 访问。

这套“像个正常人”的访问策略，实测下来比任何花哨的绕过手段都管用。很多平台的反爬系统其实就是看请求特征是否“可疑”，你把节奏放慢、特征做全，它就不会把你当机器人。

2.3 数据去重与更新策略

采集系统最怕的一件事就是数据重复。同一篇文章、同一条商品链接，正常逻辑下只应该入库一次。我最初没做去重，跑了一周之后发现库里有大量重复记录，分析报表全被污染，后来才补上去重机制。

我用的方案是“URL 指纹 + 内容指纹”双层去重。URL 指纹最简单，把请求的 URL 做一次哈希，存到 Redis 集合里，发现已存在的直接跳过。但有些平台会在 URL 参数里带时间戳、随机数之类的信息，导致同一个内容每次 URL 都不一样，这时候就得靠内容指纹兜底：把标题加正文前几百个字符拼接起来算 MD5，存进数据库的唯一索引字段，插入时遇到重复就直接忽略。

更新策略同样重要。不是所有数据都无脑重复入库，我的做法是给每条数据加一个“最后变化时间”字段，入库前先查一下库里有没有同源记录。如果有，就比较关键字段是否发生变化——价格变没变、标题变没变、热度涨没涨——只有变化了才更新，没变化就只更新时间戳。这样数据库里始终保存的是最新状态，又不会无限膨胀历史版本。

如果你需要保留历史轨迹，比如看价格曲线，那就不能只留最新值。我会额外建一张变更记录表，每当检测到关键字段有变化，就把旧值写到变更表里，一行一条。这样既保留了历史，又不会让主表变得臃肿。

3. 实操过程与核心环节实现

3.1 雷达扫描主循环设计

整个系统最核心的是一个主循环，所有平台的扫描任务都从这里开始。我用一段伪代码来描述它的逻辑：

def radar_loop(): while True: tasks = dispatch_new_tasks() for task in tasks: worker_pool.submit(execute_task, task) time.sleep(10)

实际代码里当然不是这么简陋，但核心思路没变：调度器负责生成任务，工作池负责执行任务，中间用 Redis 队列解耦。每个任务对象至少包含平台标识、目标 URL、抓取类型、上次抓取时间这几个字段。

一个值得注意的细节是“任务幂等性”。如果某次抓取因为异常重试了三次，最终结果必须和只成功执行一次完全一致。怎么保证？我在执行器里做了两步：第一步在请求前检查 Redis 里的任务锁，同一个任务同时只允许一个 worker 执行；第二步在写入数据库时依赖唯一索引做兜底，即便锁没兜住，也不会插入重复数据。

还有并发数控制。我的单机系统用了一个简单的信号量：全局限量 8 个并发请求，每个平台再额外限量 3 个并发。这样既保证了整体吞吐，又不会在某个响应慢的平台卡死所有 worker。

3.2 三个实测稳定的采集方案

方案一：JSON 接口直采。适用于平台后端有公开接口、返回 JSON 数据的场景。做法是先用浏览器开发者工具找到接口地址，再构造请求。这里有个坑：很多接口会校验请求头的 Referer 和 X-Requested-With，缺失或者不对就会返回 403。我在请求时会把浏览器里看到的关键请求头都带齐，实测成功率很高。

方案二：静态 HTML 解析。适用于数据直接渲染在 HTML 里的场景。用 BeautifulSoup 先定位内容容器，再写选择器抽取字段。我的建议是选择器写得越具体越好，不要用一大串嵌套关系，否则页面稍微改个 class 名就全崩。尽量用 id 或者稳定属性定位，实在不行再用父子关系兜底。

方案三：渲染兜底。适用于强依赖 JavaScript 渲染数据、接口抓不到或加密复杂的场景。这里我单独做了一个服务，用 Playwright 打开页面、等待必要元素出现、然后取页面渲染后的 HTML。这个方案我只保留了两个平台在用，因为它的资源消耗确实是另两个方案的十倍还多。新增平台时，我会优先看看能不能用前两种方案，能就不用渲染。

3.3 数据落库与定时调度

落库我用的模型挺简单，核心就两张表：一张基础数据表存最新状态，一张变更记录表存历史轨迹。基础数据表的唯一索引是“平台 + 来源 ID”，这样从源头就避免重复。变更记录表则负责在检测到变化时插入一条新记录，记录变化的字段、旧值、新值和时间。

定时调度我用的是 APScheduler 的 CronTrigger 模式。比固定间隔更灵活，可以做到工作日每半小时跑一次，周末改成两小时一次。调度配置我放在一个独立的配置文件里，每个平台一段配置，想加平台就加一段配置，不需要改代码。

调度这块容易忽略的问题是时区和夏令时。我一开始直接用服务器本地时间，结果遇到不同平台的发布时间换算时经常错位。后来统一改成 UTC 时间存储，展示时再按用户时区转换，总算是一劳永逸。

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

4.1 高频踩坑速查表

我把这一年多踩过的坑整理成一张表，方便大家直接对照自查：

这张表里的每一条我都亲手踩过，尤其是 403 和页面结构变化这两个坑，出现的频率最高。建议大家在系统里加一个“采集成功率”指标，每天看一眼，一旦低于 95% 就及时查原因，别等数据断了一周才发现。

4.2 反爬升级后的应对思路

平台的反爬手段是会不断升级的。最常见的升级路径是：先是简单频率检测，然后加 User-Agent 黑白名单，再往后是浏览器指纹检测、行为分析、验证码弹出。应对思路只能跟着它的节奏走，但我有几个经验可以分享。

第一，不要跟它硬刚。一旦发现平台开始弹验证码，我通常的做法是降低该平台的采集频率，甚至主动暂停一周，等风头过了再说。硬刚验证码往往收益很低，还会让你耗尽账号资源。

第二，把“成功率”当作最重要的监控指标。反爬升级的第一表现不是直接封 IP，而是响应里开始频繁出现异常页面、空数据、跳转验证码。把这些异常情况都识别出来，计入失败统计，你就能在数据还没断之前发现问题。

第三，保持采集行为的人性化。这是一个在工程上很难做到、但方向明确的指标：你的请求节奏越接近真实用户，长期被反爬误判的概率就越低。我甚至试过在两次请求之间加入模拟阅读页面的延迟，虽然牺牲了吞吐量，但换来的是超长的稳定运行期，非常值。

4.3 一些小众但好用的经验

最后分享几个不太常被人提到、但我实测下来很有用的细节：

• 给每个平台准备独立的 HTTP 状态码统计。很多框架默认是按模块汇总的，但不同平台的状态码分布差异很大，拆开统计更容易发现单个平台的问题。
• 数据抓下来之后，别急着入库。先丢进一个“待清洗队列”，里面做好类型校验、字段补全、异常值筛查，清洗完再写库。这个小步骤能避免脏数据污染报表。
• 把解析规则做成可热更新。我把每个平台的解析配置放在数据库而不是代码里，改完配置重启服务就能生效。这样平台改版后，我能在十分钟内恢复采集，不用重新部署。
• 做好基础设施的可观测性。给采集任务加上日志追踪 ID，每一次抓取都能串成一条完整链路，“调度到执行到解析到入库”出了问题能快速定位在哪个环节。

这些经验在一般的技术文档里看不到，都是我一次次踩坑、一点点试出来的。很多看起来“没必要”的步骤，关键时刻能省掉你一整天的事故排查时间。

做完 PLFM_RADAR 这套系统之后，我最大的感受是：数据采集这行，真正的门槛不在代码，而在对细节的耐心和敬畏。平台改个版、反爬升个级、时区差一小时，都可能让整套系统静默失败。如果你也在做类似的东西，我的建议是先把稳定性和可观测性做好，再考虑采集规模；跑得稳，远比跑得快重要。我自己就是在一次“数据静默断供一周没人发现”的事故之后才彻底想明白这件事的，那次教训让我把监控指标从头建了一遍。后续我会继续往里加新的平台规则和预警能力，也希望这篇拆解能让你少走几段弯路。