Python爬虫实战：构建CSDN技术趋势分析雷达

当一个技术方向突然从社区里冒出来、到处都在讨论的时候，你通常已经错过了最佳的学习窗口。我一直在想能不能有个东西，可以像雷达一样持续扫描技术社区里的讨论热度，提前嗅到趋势的变化。这个"Python爬虫实战：构建技术趋势分析雷达 (CSDN 版)"的练手项目，就是冲着这个需求去的——用 Python 把 CSDN 上公开的技术文章爬下来，配上 SQLAlchemy 做数据落库，最后通过关键词热度计算画出一张多维度的雷达图，直观展示当下哪些技术方向正在升温。

这篇文章面向的是有一定 Python 基础、想走通"爬虫—存储—分析—可视化"全链路的人。哪怕你之前只在教程里看过 requests 和 BeautifulSoup，跟着这套方案也能把整套流程跑起来。我会把踩过的坑、设计取舍的思考、还有每个关键环节为什么要这么做的理由，全部摊开来讲。

1. 项目设计与整体思路拆解

1.1 这个"雷达"到底要解决什么问题

技术趋势这件事，最大的难点不是"不知道有哪些技术"，而是"不知道哪些技术在变热"。你打开 CSDN 首页看到的内容，本质上是编辑推荐和热门排序的结果，它反映的是"已经火起来的东西"，而不是"正在变热的东西"。真正的趋势信号藏在更细的维度里：某个技术关键词在文章标题里出现的频率曲线、在特定时间窗口内的增幅、相关文章的发布时间密度。

传统做法是人工隔三差五去搜索框里翻一翻，看看哪些话题多了。但人工有两个天然的短板：第一是覆盖维度有限，你只会关注自己熟悉的方向，很容易漏掉跨界信号；第二是记忆不可靠，上周 "WebRTC" 搜出来 50 篇文章，这周搜出来 80 篇，你很难准确记得这个基线的变化。这个项目就是把这两件事交给程序：定时抓取、定量统计、可视化对比。

"雷达"这个名字不是随便起的。雷达的核心特征是扫描、回波、显示——我们对技术社区做的事情完全一样：扫列表页拿文章回波（标题、时间、分类），汇总之后在雷达图上显示各个技术方向的"信号强度"。这也是为什么最终的展示环节选择了雷达图而不是折线图，因为雷达图天生适合做多维度横向对比，一眼就能看出哪个方向的信号突出。

1.2 为什么选 CSDN 作为数据源

选 CSDN 有几个很现实的原因。首先，它是中文技术社区里文章量最大、覆盖面最广的平台之一，Python、Java、前端、算法、硬件、嵌入式这些方向都有大量内容，拿来分析技术热度的代表性足够。其次，CSDN 的文章列表页和搜索页结构相对稳定，URL 参数规则清晰，对新手来说是一个很好的爬虫练手目标，不会像某些平台那样疯狂上混淆和风控，让你在第一步就被劝退。

但这不代表不用讲礼貌。我在实际开发里始终遵守三条底线：严格遵守 robots.txt 的约束，只抓公开可访问的页面；请求频率控制在人类手动浏览的节奏附近，默认加上 3 到 5 秒的延时；只采集非个人隐私的公开文章信息，不碰任何需要登录权限的数据。爬虫本身是中立的技术工具，使用边界在于你能不能克制。这个项目里的所有代码都按这个标准来写，也建议你照着这个原则来跑。

1.3 技术选型背后的考量

整个链路我选了四件套：requests 负责 HTTP 请求，BeautifulSoup 负责解析 HTML，SQLAlchemy 负责数据落库，matplotlib 负责画雷达图。每个选择都有明确理由。

requests 没什么好说的，Python 生态里最成熟的 HTTP 库，上手快，调试直观。BeautifulSoup 有人觉得它比 Scrapy 轻量得太多，但这恰恰是它适合这个项目的原因——我们的采集规模是"每天几百篇文章"，不是"每小时几百万页面"，杀鸡不用牛刀。SQLAlchemy 是我在这个项目里最坚持的一个选型，后面我会专门用一节讲它。matplotlib 的雷达图绘制虽然代码要手写几行坐标变换，但可控性强，不用额外装几十兆的前端依赖。

做这个选型时有一个核心判断：这个项目的复杂度和性能瓶颈都不在"爬得多快"，而在"数据怎么组织、指标怎么算、图怎么画明白"。所以每一层的选型都优先考虑开发效率和可读性，而不是极限性能。对于一个分析型项目来说，这个取舍方向是划算的。

2. 环境准备与核心依赖部署

2.1 Python 环境搭建

虽然现在很多教程默认你已经装好了 Python，但我还是想多说一句，因为我在帮同事排查问题时发现，大量爬虫报错最终都指向环境问题。推荐直接去 Python 官网下载 3.9 或 3.10 版本，安装时务必勾选 "Add Python to PATH" 这个选项。这一步不勾，后面在命令行里敲 python 就会提示找不到命令，那种挫败感会直接消磨掉你动手的兴致。

装完以后我建议做一件事：验证 pip 可用。在终端里执行python -m pip --version，如果正常输出版本号，说明基础环境就绪。然后创建虚拟环境。虚拟环境的作用是为这个项目单独隔离一套依赖库，不污染你系统里的其他 Python 项目。我给这个项目建了个专门的目录，命令行操作如下：

mkdir tech_radar && cd tech_radar python -m venv venv # Windows 下激活 venv\Scripts\activate # macOS/Linux 下激活 source venv/bin/activate

激活后终端前面会出现(venv)字样，这时候装的所有库都只存在这个环境的 site-packages 里。我见过太多人图省事直接全局安装，最后版本冲突起来欲哭无泪。单独建环境这个习惯，值得从第一个爬虫项目就养成。

2.2 依赖库安装与版本说明

激活虚拟环境后，直接通过 pip 安装本次项目需要的东西。我用一份 requirements.txt 来管理，这样换机器、换环境时一条命令就能复现整条依赖链：

pip install requests beautifulsoup4 sqlalchemy pandas matplotlib lxml

这里我特别把 lxml 也装上了，因为 BeautifulSoup 默认的 html.parser 在解析 CSDN 这种结构复杂、标签嵌套深的页面时，速度和容错性都不太好。lxml 是一个 C 语言实现的解析器，性能更强，对残缺 HTML 的容忍度也更高。实测同一个列表页，lxml 的解析速度大概是默认解析器的 3 到 4 倍，在需要连续抓取几十个页面时差距体感明显。

如果安装过程中遇到网络慢或者超时，可以换国内镜像源：

pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests beautifulsoup4 sqlalchemy pandas matplotlib lxml

装完之后建议用pip list检查一遍，确认关键库都进来了。特别留意 pandas，它在这个项目里承担数据清洗和聚合的工作，如果版本装的是 2.0 以上，一些 API 行为和旧版有差异，后面分析环节的代码我按新版写法来给。

2.3 SQLAlchemy 存储方案解析

为什么我强烈推荐在这个项目里用 SQLAlchemy 而不是直接写 SQL？因为爬虫项目的数据结构是"不稳定"的。CSDN 的文章字段今天叫articleTitle，明天可能就改了；你今天只存标题、作者、时间，明天想加一个阅读数字段。如果直接用裸 SQL，每次改动都要同步修改建表语句和所有插入语句，改错一个字段名排查半天。

SQLAlchemy 的 ORM 模型把数据库表映射成 Python 类，字段变更就是改类属性，表结构通过迁移工具同步，代码里到处写的是Article(title=..., url=...)这种直观的对象操作，不是一堆字符串拼接的 INSERT INTO。这个抽象带来的心智负担降低，在数据字段经常变化的爬虫项目里尤其值钱。

另一个原因是 SQLAlchemy 帮你解决了数据库切换的问题。项目开发阶段用 SQLite 零配置起步，一个文件就搞定；将来数据量大了，想改成 MySQL 或者 PostgreSQL，只需要改一行连接字符串。这种平滑迁移能力，是直接写 SQLite API 拿不到的。下面建一个连接引擎是这么写的：

from sqlalchemy import create_engine engine = create_engine('sqlite:///tech_radar.db', echo=False)

关键就在create_engine这个函数。它接收一个数据库 URL，SQLite 的 URL 格式是sqlite:///相对路径，换成 MySQL 就是mysql+pymysql://用户名:密码@主机/库名。爬虫项目的数据层用 ORM 真的能省下大量后期维护精力。

3. 采集层实现：CSDN 列表与详情页爬取

3.1 页面结构分析与 URL 规律

开始写爬虫之前，一定要先花时间手工打开页面、按 F12 看结构。这一步省不了，因为它直接决定你后面解析代码怎么写。CSDN 的博客列表页 URL 规律很清晰，类似https://blog.csdn.net/社区名/article/list/页码，右侧热门文章区域也有固定的 DOM 结构。

我用浏览器开发者工具抓了几个关键节点的特征：每篇文章卡片都是一个article标签，标题在h4里的a标签，链接的href属性指向详情页地址，时间信息在time标签里，分类标签在span内的a标签。这些 class 命名虽然看起来很长，但相对稳定。为了减少对页面结构的耦合，我更推荐走 CSDN 的搜索接口来拿数据。

CSDN 的搜索接口是一个 get 请求，URL 大致是https://so.csdn.net/api/v3/search?q=关键词&t=blog&p=页码，返回的是 JSON 格式。用接口的好处是根本不用解析 HTML，直接拿到结构化字段，速度和稳定性都高出一截。但接口单次返回的条数有限，需要翻页来累积数据量。两种方式我都实测过，一般推荐用搜索接口做数据收集，用列表页解析做页面结构练手。

3.2 请求头设置与 Session 管理

直接裸奔的 requests 请求很容易被服务端拒绝，因为默认的 User-Agent 是python-requests/x.x.x，一眼就能识别出来。我习惯在请求前构造一个完整的 headers 字典，把自己伪装成一个真实浏览器：

import requests headers = { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ' '(KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36', 'Referer': 'https://so.csdn.net/', 'Accept-Language': 'zh-CN,zh;q=0.9,en;q=0.8', } session = requests.Session() session.headers.update(headers)

为什么要用 Session 而不是每个请求单独用 requests.get？因为 Session 会自动维持 Cookie，并且复用底层的 TCP 连接。我们这种分析型爬虫需要连续请求几十甚至上百个页面，如果每次重新建连，光是 TCP 三次握手的时间就白白浪费不少。实测用 Session 之后，同样一批页面的请求总耗时能缩短 30% 到 40%。

请求响应拿到手之后，我做的第一件事不是解析，而是检查状态码和编码。CSDN 页面是 UTF-8 编码，一般不会乱码，但保险起见可以通过response.encoding = 'utf-8'强制指定。如果返回的状态码是 403，先别急着写重试逻辑，多半是请求头伪装不够或者频率太快，稍后我会专门讲反爬应对。

3.3 数据解析与提取逻辑

用接口路径的话，响应是一个 JSON，直接用response.json()就能转成字典。但如果是列表页 HTML，那就轮到 BeautifulSoup 上场了。我写了一个解析函数，专门从文章卡片中提取标题、链接、发布时间和摘要：

from bs4 import BeautifulSoup def parse_article_list(html: str) -> list[dict]: soup = BeautifulSoup(html, 'lxml') articles = [] for item in soup.select('article'): title_node = item.select_one('h4 a') if not title_node: continue title = title_node.get_text(strip=True) url = title_node.get('href') time_node = item.select_one('.date') publish_time = time_node.get_text(strip=True) if time_node else '' articles.append({ 'title': title, 'url': url, 'publish_time': publish_time, }) return articles

这里有几个经验点值得说。第一，get_text(strip=True)能自动去掉标题首尾的空白和换行，但不会处理中间多余的空格，标题清洗的细活我放在数据清洗环节做。第二，select方法支持 CSS 选择器，比find_all写得简洁，定位层级也更清晰。第三，每个字段都要做空值兼容，页面结构小调整时你不想因为某个节点没匹配到就让整个程序崩溃。

解析完每页数据后，我会把这个页面塞进一个待处理队列，在队列里做去重和落库。这样做的好处是把"请求"和"解析"解耦——就算某个页面解析报错，也不影响下一个页面的抓取流程。

3.4 反爬应对与请求频率控制

CSDN 的反爬不算强，但也不是完全不设防。我碰到过的主要有几种情况：短时间请求太密集返回 403 或弹验证码、缺少 Referer 被拦、以及触发频控后必须等待一段时间才能恢复。

应对方案其实很朴素。第一是限速，我直接用time.sleep(random.uniform(2, 5))在每两次请求之间做随机延时，模拟人手动翻页的节奏。这个随机区间很关键，固定间隔反而更容易被识别为机器行为。第二是把 Referer 和 User-Agent 都配齐，让请求看起来是来自正常的浏览器访问链路。第三是设置整体超时时间，用requests.get(url, timeout=10)防止某个页面挂住导致程序卡死。

有一次我连着抓了 200 多页，中间没有做任何延时，结果被限流了整整十分钟。之后我把延时改成随机 2 到 4 秒，同一个脚本一口气跑 500 页也没再触发过风控。这个教训告诉我，爬虫的稳健性远比你抓取的速度重要。再强的反爬手段，都不如一个知道"克制"的爬虫活得久。

4. 数据持久化：SQLAlchemy 建模与清洗入库

4.1 ORM 模型设计

数据落库之前第一步是设计表结构。我建了一张名为 articles 的表，字段包含自增主键、文章标题、文章 URL、发布时间、抓取时间、关键词标签。为了保证数据质量，我还加了几个约束：URL 设为唯一索引，避免重复入库；抓取时间有默认值，这样即使漏传也不会写入空值。

下面是用 SQLAlchemy 的声明式基类来定义模型的写法：

from datetime import datetime from sqlalchemy import Column, Integer, String, DateTime, UniqueConstraint from sqlalchemy.ext.declarative import declarative_base Base = declarative_base() class Article(Base): __tablename__ = 'articles' id = Column(Integer, primary_key=True, autoincrement=True) title = Column(String(512), nullable=False) url = Column(String(1024), nullable=False, unique=True) publish_time = Column(String(64), nullable=True) keyword = Column(String(128), nullable=False, index=True) fetched_at = Column(DateTime, default=datetime.now) __table_args__ = ( UniqueConstraint('url', name='uq_article_url'), ) def __repr__(self): return f'<Article(id={self.id}, title={self.title[:20]})>'

declarative_base()生成的是一个所有模型类的父类，SQLAlchemy 会通过这个基类自动把 Python 类和数据库表映射起来。UniqueConstraint在数据库层面锁死 URL 重复的可能性，这比在代码里先查再插要可靠得多。fetched_at字段用default=datetime.now，注意这个默认值是函数本身，每次插入时都会取当前时间，而不是模型定义时的时间，这个细节很重要，写错了会得到一批完全相同的时间戳。

4.2 建表与会话管理

模型定义好了，接下来要建表和创建会话。SQLAlchemy 的规矩是，所有数据库操作都要在一个 Session 里进行。Session 相当于数据库连接的"工作台"，你在上面执行各种增删改查操作，最后统一 commit。手动管理 Session 容易踩"连接泄漏"的坑，所以我习惯用上下文管理器的方式：

from sqlalchemy.orm import sessionmaker SessionLocal = sessionmaker(bind=engine) def save_articles(article_list: list[dict]): with SessionLocal() as session: for item in article_list: existing = session.query(Article).filter_by(url=item['url']).first() if existing: continue article = Article(**item) session.add(article) session.commit()

这里为什么要先查询再决定是否插入？虽然 URL 在数据库层面有唯一约束，但直接盲目插入然后在异常里处理重复，会让代码逻辑变得混乱。先查再插虽然多一次查询开销，但在我们的数据量级上完全无所谓，换来的是逻辑清晰和错误直观。

with SessionLocal() as session这种用法会自动管理事务边界，正常退出时如果没有显式 commit，会回滚未提交的更改，防止脏数据写进数据库。这是 SQLAlchemy 2.x 推荐的写法，也是我给所有新手朋友强推的会话写法。

4.3 数据清洗的必要性

爬虫拿到的原始数据，说实话挺脏的。标题里可能混着 HTML 实体、全角空格、emoji 字符；发布时间字段在不同页面里格式不统一，有的是2024-05-12，有的是05-12 14:23；还有明明是被推荐到列表页的同一篇文章，在多个关键词的搜索结果里重复出现。

清洗我分三步处理。第一步是文本规范化，用正则把 HTML 实体（比如&）还原成字符，把所有空白字符统一成普通空格。第二步是时间标准化，把不同的时间格式统一成YYYY-MM-DD的字符串，只保留日期信息，因为趋势分析的最小粒度是"天"。第三步是标题关键词校验，把标题里非技术性的杂质词（比如"置顶""推荐""转载"这类前缀）剔除掉，避免它们混入后续的词频统计干扰信号。

如果你用过 pandas，这些清洗工作其实可以做得更优雅。把清洗后的数据装进 DataFrame，用drop_duplicates搭配subset=['url']做去重，用str.replace做文本替换，效率比逐条处理高得多。但考虑到项目主链路里数据量不大，我选择直接用 Python 原生的字符串处理，少一个重依赖，代码也更好理解。

5. 趋势分析与雷达图可视化

5.1 关键词热度计算模型

数据入库只是第一步，真正让"雷达"转起来的是热度计算这个环节。我的思路是选定一组技术方向关键词，然后对每篇文章的标题做包含匹配，统计每个关键词在特定时间窗口内出现的文章数量。但单纯的计数有个问题：一个技术方向可能长期都有人写，看不出"变热"还是"变冷"。所以要在计数基础上加一个增长率权重。

具体计算办法是：以过去 7 天为一个窗口，统计每个关键词在这个窗口内的新增文章数；再往前推 14 天，统计上一个窗口的新增文章数。用这两个数字计算环比增长率，然后把"当前热度值"和"增长率"两个维度结合起来，映射到雷达图的坐标轴上。这就是为什么雷达图的每个维度能同时反映体量和趋势——既有"现在有多少"的信息，又有"增长有多快"的信息。

计算核心代码大致是这样：

from datetime import datetime, timedelta def calculate_hotness(session, keyword: str, days: int = 7) -> float: since = datetime.now() - timedelta(days=days) count = session.query(Article).filter( Article.title.contains(keyword), Article.fetched_at >= since ).count() return count def trend_score(session, keyword: str) -> float: now_count = calculate_hotness(session, keyword, days=7) prev_count = calculate_hotness(session, keyword, days=14) - now_count if prev_count == 0: growth = 0.0 else: growth = (now_count - prev_count) / prev_count return now_count + growth * 10

trend_score的设计思路是让基数热度占主导，增长率作为加权修正。比如一个关键词 7 天有 100 篇文章，另一个关键词只有 10 篇但增长率是 200%，如果不加权重，后者在雷达图上会被前者的体量完全淹没，加增长率修正后，它才有机会凸显出来。这个加权系数 10 是我反复试出来比较顺眼的一个值，你可以根据自己的数据分布调节。

5.2 多维度雷达图的绘制

雷达图在 matplotlib 里没有现成的直接 API，但可以通过极坐标投影实现。原理是把每个维度均匀分布在圆周上，每个维度的数值映射为半径长度，最后把各点连成一个封闭多边形。选用的维度我定为八个常用技术方向：Python、爬虫、人工智能、大数据、前端、后端、算法、数据库。

用 matplotlib 绘制雷达图的关键代码是这样：

import matplotlib.pyplot as plt import numpy as np labels = ['Python', '爬虫', '人工智能', '大数据', '前端', '后端', '算法', '数据库'] values = [trend_score(session, kw) for kw in labels] angles = np.linspace(0, 2 * np.pi, len(labels), endpoint=False).tolist() values += values[:1] angles += angles[:1] fig, ax = plt.subplots(figsize=(8, 8), subplot_kw={'polar': True}) ax.fill(angles, values, color='steelblue', alpha=0.25) ax.plot(angles, values, color='steelblue', linewidth=2) ax.set_xticks(angles[:-1]) ax.set_xticklabels(labels) plt.show()

这里面有几个坑要提前说。第一，np.linspace生成的角度默认从 0 开始，但第一个点和最后一个点如果不闭合，画出来的多边形会少一条边，所以要把第一个点的值复制到末尾。第二，subplot_kw={'polar': True}是让 matplotlib 使用极坐标系的正确方式，写成projection='polar'效果相同。第三，填充色的透明度 alpha 建议控制在 0.2 到 0.3 之间，太实会盖住网格线，太虚又看不出面积差异。

雷达图的面积对比是最直观的信息。如果某个方向的图形明显凸出一块，说明该方向近期文章产出高、增长强，值得关注；如果整体图形很瘪，说明这组关键词在社区里整体热度不高，可能是领域冷门，也可能是你的采样关键词需要更新。

5.3 分析结果的应用场景

这个雷达图跑起来之后，玩法其实可以很多。你可以把同一份代码跑在不同时间点，把雷达图截图存档，月底做一次对比，就能看到哪些方向在持续走强。你还可以把关键词列表换成自己的技术栈词汇，比如从 Kafka、Flink、ClickHouse 这些具体技术名词入手，做一个针对性的团队技术选型参考。

我自己的用法是每周跑一次，把雷达图存到一个专门目录里，配合一个言简意赅的周记文件。三个月下来，回头看这些图基本能复盘出社区讨论热点的完整迁移轨迹。这个价值是任何别人写好的"热榜"都给不了的，因为统计口径和维度完全由你自己定义，你可以只关注你关心的领域。对做技术规划或写博客选题的人来说，这种"定制化的趋势雷达"比通用热榜有意义得多。

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

6.1 高频问题速查表

我把实操中遇到的高频问题整理成了一个表格，每个问题都附上我的排查思路和解决方案，方便你遇到同样情况时快速对照。

最容易被忽略的是第二个问题。很多人以为加了延时就没问题了，但延时只在当前进程内有效，如果你上一次运行脚本留下的频率记录还没被刷新，重启脚本照样被限流。碰到这种情况，最稳妥的做法是真的停下来等一会儿，而不是反复试探。

6.2 排查思路的三个步骤

面对任何一个爬虫问题，我有一套固定排查流程：先确认请求层，再确认解析层，最后确认存储层。这个顺序不能乱。

请求层的问题表现为状态码异常、响应内容为空、超时。排查方法是在脚本里把response.status_code和response.text[:200]打印出来，一眼就能看出是访问被拒绝还是返回内容不符合预期。解析层的问题表现为能请求成功但提取不到数据，这时打开一个 HTML 样例文件，手工比对 CSS 选择器和页面结构是否一致。存储层的问题表现为插入报错或者数据量对不上，直接打开数据库文件看原始数据。

这套思路看起来简单，但能解决九成以上的问题。它本质上是在帮你隔离变量——先确认你拿到了什么，再看你解析出了什么，最后看存进去的是什么。沿着这条链路找问题，永远不会出现"不知道从哪里排查"的茫然感。

6.3 我踩过的几个值得一说的坑

第一个坑是 SQLAlchemy 会话没用上下文管理器。早期版本里我直接session = SessionLocal()，用完没有 close，跑了几个小时后连接数飙升到数据库直接拒绝新连接。后来全部改成with SessionLocal() as session的写法，这个问题彻底消失。教训就是：数据库连接不是自动关闭的，用上下文管理器是最简单的兜底方案。

第二个坑是盲目把请求间隔设置成固定 1 秒。表面上看很礼貌，但实际上固定节奏是最容易被识别为机器的行为特征之一。改成随机 2 到 5 秒之后，不仅没被限流，整体采集速度也没有明显下降。因为大多数时间其实耗在网络 I/O 上，多等几秒对总耗时影响不大，但对风控系统来说完全是两种行为画像。

第三个坑是机器人协议的问题。我一开始抓列表页没看 robots.txt，结果某天发现自己的爬虫在抓一些不在目标范围内的页面。后来加了一个简单的 robots.txt 解析判断，把这些不该碰的路径全部排除掉。这不仅是合规问题，也保证了我们的爬虫只聚焦在真正需要的数据上，反而提升了数据纯度。

7. 从一个练手项目到持续性分析工具

这个项目跑通之后，我就把它从一次性脚本改造成了可以持续运行的常驻分析工具。改造的重点有三个：把关键参数抽到配置文件里、加入日志记录、用定时任务驱动。配置文件里放的是关键词列表、请求延时区间、数据库路径这些可以随时调整的变量，避免每次想换个监控维度都要去翻代码改字符串。

日志记录这块我直接把 Python 自带的 logging 库用上了，每完成一个关键词的抓取就记一条 INFO 日志，每遇到一次请求失败就记一条 WARNING。这样即使脚本挂在半夜也没关系，第二天看日志就能定位出错环节。日志是爬虫项目的隐形基础设施，别等出了问题才想起来补。

定时驱动我用的方案是操作系统的计划任务：Linux 下用 cron，Windows 下用任务计划程序，最简单的做法是让脚本每天凌晨 2 点运行一次。这个时间点的选择也有讲究，凌晨的访问量低，对我们的请求更友好，抓下来的数据第二天一早就能看到分析结果。

根据我个人这段时间实际跑下来的体会，这个雷达最有价值的地方不在于那张图本身，而在于它逼着你养成了"定期回看数据"的习惯。以前我是凭感觉判断哪个技术方向值得关注，现在是看数据说话，虽然样本量不算大，但至少有一个属于你自己的客观参考系。这个项目后续要扩展的话，我建议你可以把数据源从 CSDN 扩展到其他技术社区，或者把时间窗口缩短、增加更多关键词维度，让雷达的"分辨率"更高一些——技术趋势这件事，越早看清，越能从容应对。