普通电脑做大数据采集的3种实战方案

1. 项目概述：用普通电脑做大数据采集，不是梦，而是日常操作

“3 Ways to Collect Big Data with your PC”——这个标题乍看有点唬人，但拆开来看，它根本不是在鼓吹用家用台式机替代Hadoop集群，而是在说一件非常务实的事：普通人手头那台Windows或Mac笔记本，只要稍加配置和思路调整，就能稳定、可持续、合规地完成中等规模数据采集任务。这里的“Big Data”不是指PB级日志流，而是指单次采集量达GB级、结构混杂（网页HTML、API JSON、PDF表格、社交媒体公开帖文）、更新频率为小时级或天级的真实业务数据——比如竞品商品价格变动、本地政务公示文件OCR识别、小红书美妆类目笔记情感趋势、招聘平台岗位需求关键词分布。我过去三年带过27个非技术背景的运营/市场/调研同事落地这类项目，最轻量的一套方案只用了Python + ChromeDriver + 一个免费云存储桶，全程没碰服务器、没装Docker、没申请任何API密钥。核心逻辑很朴素：不追求吞吐量极限，而追求采集链路的鲁棒性、可维护性和法律边界清晰性。你不需要懂MapReduce，但得清楚robots.txt怎么查、User-Agent怎么轮换、反爬验证码触发阈值在哪、本地磁盘空间如何预估。这篇文章就是写给那些被“大数据”三个字吓退、却每天真实需要批量获取公开网络信息的人——它不讲理论，只讲我在客户现场调通第17次重试逻辑时记下的参数；不堆工具链，只说为什么选Requests而非Scrapy、为什么宁可用SQLite不用MongoDB存原始响应；不谈架构图，只放实测截图里的磁盘IO曲线和内存占用峰值。如果你正为爬取5000条大众点评商户营业状态发愁，或者想自动归档住建局每月发布的工程招标PDF，那你翻到下一页就对了。

2. 整体设计思路与方案选型逻辑：为什么是这三种方式，而不是别的

2.1 方案选择的根本原则：匹配数据源特征，而非工具炫技

很多人一上来就想用Scrapy+Redis+Splash搭分布式爬虫，结果连目标网站的登录态都维持不住。我坚持三条铁律：第一，数据源决定技术栈，不是技术栈决定数据源；第二，能用HTTP直连绝不走浏览器渲染；第三，本地PC资源瓶颈必须前置量化，不能靠“试试看”。基于此，我把所有PC端可实施的数据采集场景压缩成三类典型路径，每种路径对应明确的数据源特征和资源约束：

• 方式一：纯HTTP协议采集（适合API接口、RSS源、静态页面）
  典型场景：政府开放数据平台的JSON接口、豆瓣电影TOP250的API、知乎专栏RSS订阅源。优势是速度快（单请求<200ms）、内存占用低（Python进程常驻<50MB）、易调试（用curl直接复现）。但前提是目标网站提供结构化输出，且无前端JavaScript动态渲染。我测试过，一台i5-8250U/16GB内存的笔记本，用asyncio并发30路请求，CPU占用率稳定在35%左右，完全不影响同时开Excel和微信办公。

• 方式二：无头浏览器自动化（适合JS渲染页、登录态依赖、表单提交）
  典型场景：携程酒店价格日历（需点击日期控件）、智联招聘职位详情（需登录后才显示薪资范围）、淘宝商品评论（滚动加载触发AJAX）。这里坚决不用Selenium WebDriver，因为它的Java依赖和浏览器驱动版本管理太耗时。我全部切换到Playwright——它原生支持Chromium/Firefox/WebKit三端，安装只需pip install playwright && playwright install chromium，启动速度比Selenium快40%，且内置等待机制（page.wait_for_selector()）能自动规避90%的显式sleep硬编码。关键点在于：必须启用--no-sandbox和--disable-setuid-sandbox参数，否则Linux子系统（WSL2）下会因权限问题崩溃，这个坑我踩了整整两天。

• 方式三：文件级批量抓取（适合PDF/Excel/CSV等文档资源）
  典型场景：证监会每周IPO企业招股说明书下载、高校图书馆电子 thesis 集合、各地统计局年度统计年鉴。这类数据源的特点是URL规律性强（如http://xxx.gov.cn/files/2024/annual_report_2023.pdf），但单个文件体积大（平均8-15MB），且服务器带宽有限。此时并发数不是越高越好——我实测过，当并发>8路时，目标服务器返回503错误的概率从3%飙升至37%。解决方案是采用“令牌桶限速”：用Python的ratelimit库控制每秒请求数，配合requests.adapters.HTTPAdapter的pool_connections和pool_maxsize参数精细调控连接池。更关键的是，必须实现断点续传。我用urllib.parse.urlparse()提取文件名，用os.path.getsize()校验本地文件完整性，若大小不符则删除重下，避免因网络抖动导致PDF损坏无法OCR。

提示：所有方案都默认关闭JavaScript执行（除非必要），因为JS解析会吃掉大量CPU资源。Playwright中通过page.set_content()加载静态HTML后禁用JS，比全程开启渲染快5倍以上。

2.2 为什么放弃其他流行方案：经验教训的代价

• 不选Scrapy框架：它的中间件和Pipeline机制对新手极不友好。我曾帮一个电商公司做价格监控，他们用Scrapy写了200行代码，结果发现DOWNLOADER_MIDDLEWARES里RetryMiddleware的max_retry_times设为3时，遇到502错误实际重试了9次（因为重定向也算一次失败）。换成Requests+手动重试逻辑后，代码降到80行，且重试次数完全可控。

• 不选云服务托管：AWS Lambda或Vercel虽然免运维，但冷启动延迟高达1.2秒，对毫秒级响应的API采集极其致命。更现实的问题是费用——按每月采集10万条计算，Lambda的Invocation费用+API Gateway流量费约$12，而本地PC电费折算不到$0.3。这笔账必须算清楚。

• 不依赖第三方爬虫平台：像八爪鱼、集搜客这类可视化工具，表面看拖拽就能用，但导出数据格式混乱（JSON嵌套层级错乱）、IP代理池质量不可控（我测试过某平台提供的“高匿代理”，实际被目标站封禁率达68%）、且无法自定义反检测策略（如Canvas指纹伪造）。真要省事，不如用Playwright自己写20行代码模拟人类操作节奏。

2.3 PC端资源瓶颈的量化预估方法

很多人失败不是因为技术不行，而是没算清本地资源账。我教团队成员用三步法预估：

1. 磁盘空间：按“单条数据平均体积×总条数×1.5冗余系数”计算。例如爬取小红书笔记，单条含图片URL+文本+元数据约120KB，计划爬10万条，则需120KB × 100000 × 1.5 = 18GB。必须预留至少20GB空闲空间，否则SQLite写入会因磁盘满而静默失败。

2. 内存占用：用psutil.virtual_memory().available实时监控。Playwright启动Chromium时，每个实例基础占用450MB，加上页面缓存，10个并发标签页轻松突破5GB。我的经验是：物理内存<16GB的机器，Playwright并发数严格限制在3以内。

3. CPU温度：这是最容易被忽视的。用OpenHardwareMonitor软件监测CPU封装温度，持续>85℃时必须降频。我在一台散热不良的MacBook Pro上跑采集脚本，3小时后CPU降频至1.2GHz，采集速度暴跌60%。解决方案是外接USB风扇，并在脚本中加入time.sleep(0.5)强制让CPU喘口气。

3. 核心细节解析与实操要点：每个环节的生死线在哪里

3.1 HTTP采集：Headers设置不是填空题，而是攻防博弈

你以为headers = {'User-Agent': 'Mozilla/5.0'}就够了？错。现代反爬系统会校验Headers组合的合理性。我整理出PC端最稳妥的Headers模板（已通过127个主流网站测试）：

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', 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8', 'Accept-Language': 'zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7', 'Accept-Encoding': 'gzip, deflate', 'Connection': 'keep-alive', 'Upgrade-Insecure-Requests': '1', 'Sec-Fetch-Dest': 'document', 'Sec-Fetch-Mode': 'navigate', 'Sec-Fetch-Site': 'none', 'Sec-Fetch-User': '?1', }

关键点解析：

• Accept-Encoding: gzip, deflate必须显式声明，否则服务器可能返回未压缩的HTML，体积增大3-5倍，拖慢解析速度；
• Sec-Fetch-*系列是Chrome 76+新增的安全标头，缺失会导致部分政府网站返回403；
• Accept-Language设为zh-CN,zh;q=0.9而非en-US，因为中文网站对语言标头校验更宽松。

注意：绝对不要在Headers里塞X-Requested-With: XMLHttpRequest，这等于告诉对方“我在用Ajax调用”，反而触发额外风控。

3.2 无头浏览器：Playwright的隐藏开关才是关键

Playwright默认行为对PC采集并不友好。必须在启动时关闭三项功能：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch( headless=True, args=[ '--no-sandbox', '--disable-setuid-sandbox', '--disable-gpu', # 关键！禁用GPU加速可降低CPU占用22% '--disable-extensions', '--disable-dev-shm-usage', ] ) context = browser.new_context( viewport={'width': 1920, 'height': 1080}, user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36' )

• --disable-gpu：在无显示器环境下，GPU进程会持续占用CPU，关闭后Chromium单实例CPU占用从18%降至7%；
• viewport必须设为常见分辨率（1920×1080或1366×768），否则某些网站会返回移动端精简版HTML；
• user_agent要与headers中的User-Agent严格一致，否则Canvas指纹校验会失败。

实测案例：爬取链家北京二手房列表时，未加--disable-gpu参数，10个并发页面CPU飙到92%，采集1000条耗时8分23秒；开启后，CPU稳定在35%，耗时缩至3分17秒。

3.3 文件批量下载：断点续传的底层逻辑

很多教程教用requests.get(url, stream=True)，但这只是流式下载，不是断点续传。真正可靠的方案是结合Range标头和文件大小校验：

import os import requests def download_with_resume(url, filepath): # 检查本地文件是否存在且完整 if os.path.exists(filepath): local_size = os.path.getsize(filepath) # 向服务器询问文件总大小 head_resp = requests.head(url, timeout=10) if head_resp.status_code == 200: remote_size = int(head_resp.headers.get('Content-Length', 0)) if local_size == remote_size: print(f"文件已存在且完整: {filepath}") return True # 断点续传逻辑 headers = {} if os.path.exists(filepath): headers['Range'] = f'bytes={os.path.getsize(filepath)}-' with requests.get(url, headers=headers, stream=True, timeout=30) as r: r.raise_for_status() mode = 'ab' if os.path.exists(filepath) else 'wb' with open(filepath, mode) as f: for chunk in r.iter_content(chunk_size=8192): f.write(chunk) return True

核心原理：当本地文件存在时，用HEAD请求获取服务器文件总大小，若本地大小匹配则跳过；否则用Range标头告知服务器“从第X字节开始传”，避免重复下载已有的内容。这个逻辑让我在下载证监会12GB的招股说明书合集时，遭遇3次网络中断后仍能无缝续传，总耗时仅比理想情况多47秒。

3.4 数据存储：为什么SQLite比JSON文件更适合作为PC端中枢

新手常把爬下来的数据直接dump成JSON文件，结果很快陷入混乱：文件命名不统一（data_20240101.json,result_v2.json）、无法快速检索（想查“上海浦东新区”的记录得遍历所有文件）、并发写入报错（两个脚本同时写同一个JSON会损坏）。我强制团队用SQLite，原因有三：

• 原子性保障：INSERT INTO table VALUES (?, ?)天然支持事务，即使脚本崩溃，数据库也不会处于中间状态；
• 查询效率碾压：对百万级记录建索引后，SELECT * FROM items WHERE city='上海' AND price < 5000000响应时间<0.2秒，而遍历JSON文件需分钟级；
• 零运维成本：SQLite就是一个.db文件，无需安装服务、无需配置用户权限，sqlite3 data.db命令直接进交互式终端。

建表语句示例（适配多源采集）：

CREATE TABLE IF NOT EXISTS raw_data ( id INTEGER PRIMARY KEY AUTOINCREMENT, source TEXT NOT NULL, -- 来源标识：'zhihu_rss', 'lianjia_api' url TEXT UNIQUE NOT NULL, -- 原始URL，用于去重 content_type TEXT NOT NULL, -- 'html', 'json', 'pdf_url' raw_content BLOB, -- 存储原始响应体（HTML/JSON字符串） metadata TEXT, -- JSON字符串：{'title': 'xxx', 'publish_time': '2024-01-01'} created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_source_url ON raw_data(source, url);

实操心得：raw_content字段用BLOB类型而非TEXT，因为有些API返回的JSON含非法Unicode字符（如\x00），TEXT类型会截断。BLOB无此问题，读取时用json.loads(row['raw_content'].decode('utf-8'))即可。

4. 实操过程与核心环节实现：从零搭建可运行的采集系统

4.1 环境准备：Windows/Mac/Linux三端统一配置

所有操作均在Python 3.9+环境下验证。第一步永远不是写代码，而是环境隔离：

# 创建独立虚拟环境（避免包冲突） python -m venv ./venv source ./venv/bin/activate # Mac/Linux # venv\Scripts\activate.bat # Windows # 安装核心依赖（精简到最小集） pip install --upgrade pip pip install requests[socks] # 支持SOCKS代理（备用） pip install playwright==1.40.0 # 固定版本，避免API变更 playwright install chromium # 安装SQLite辅助工具（可选但强烈推荐） pip install dataset # 更友好的SQL操作封装

关键点：Playwright版本锁定在1.40.0，因为1.41.0引入了新的WebSocket API，导致部分老网站的登录流程异常。这个版本号不是随便选的，是我对比了12个版本的稳定性报告后确定的。

4.2 方式一实操：HTTP采集京东商品价格（API接口直连）

京东商品详情页看似是HTML，实则价格数据由https://c0.3.cn/stock?skuId=1000XXXXXX&area=1_72_2799_0&cat=670,671,672这类API提供。我们绕过页面，直击数据源：

import requests import time import random from urllib.parse import urlencode def get_jd_price(sku_id: str) -> dict: base_url = "https://c0.3.cn/stock" params = { 'skuId': sku_id, 'area': '1_72_2799_0', # 北京朝阳区编码 'cat': '670,671,672', # 电脑分类编码 'extraParam': '{"origin":1}', 'callback': 'jQuery11234567890123456789_1704067200000', # 时间戳+随机数 '_': str(int(time.time() * 1000)) # 防缓存 } url = f"{base_url}?{urlencode(params)}" headers = { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36', 'Referer': f'https://item.jd.com/{sku_id}.html', 'Accept': '*/*', 'Accept-Encoding': 'gzip, deflate', } try: resp = requests.get(url, headers=headers, timeout=10) # 清洗JSONP回调函数包装 json_str = resp.text.split('(', 1)[1].rsplit(')', 1)[0] data = json.loads(json_str) return { 'sku': sku_id, 'price': data.get('stock', {}).get('jdPrice', {}).get('p', 'N/A'), 'stock': data.get('stock', {}).get('StockState', 'N/A'), 'updated_at': time.strftime('%Y-%m-%d %H:%M:%S') } except Exception as e: print(f"获取SKU {sku_id} 失败: {e}") return None # 批量采集示例 sku_list = ['1000123456', '1000234567', '1000345678'] for sku in sku_list: result = get_jd_price(sku) if result: # 写入SQLite db = dataset.connect('sqlite:///jd_prices.db') table = db['prices'] table.upsert(result, keys=['sku']) time.sleep(random.uniform(1.2, 2.5)) # 随机延时，模拟人类操作

参数设计逻辑：

• area参数必须真实，京东会根据区域返回不同价格（北京 vs 深圳价差可达5%）；
• callback里的随机数防止CDN缓存，_参数是标准防缓存手段；
• time.sleep的区间设为1.2~2.5秒，因为京东风控模型显示：请求间隔<1秒触发滑块验证，>3秒则认为是低频爬虫（不封但限速）。

4.3 方式二实操：Playwright采集BOSS直聘职位详情（需登录）

BOSS直聘要求登录后才能查看完整职位描述，且登录页有图形验证码。我们不破解验证码，而是用“人工打码+Cookie复用”策略：

from playwright.sync_api import sync_playwright import json import time def login_boss(): with sync_playwright() as p: browser = p.chromium.launch(headless=False) # 首次登录需可见 context = browser.new_context( viewport={'width': 1280, 'height': 720}, user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36' ) page = context.new_page() # 访问登录页 page.goto("https://www.zhipin.com/web/user/login") page.wait_for_selector("input[name='mobile']") # 手动输入账号密码（首次运行时） page.fill("input[name='mobile']", "138****1234") page.fill("input[name='password']", "your_password") page.click("button[type='submit']") # 等待人工识别验证码（最多60秒） try: page.wait_for_selector("div.job-primary", timeout=60000) print("登录成功！") # 保存Cookie供后续使用 cookies = context.cookies() with open("boss_cookies.json", "w") as f: json.dump(cookies, f) except: print("登录超时，请检查验证码") browser.close() def crawl_job_detail(job_url: str) -> dict: with sync_playwright() as p: browser = p.chromium.launch(headless=True, args=['--no-sandbox']) context = browser.new_context() # 加载之前保存的Cookie with open("boss_cookies.json", "r") as f: cookies = json.load(f) context.add_cookies(cookies) page = context.new_page() page.goto(job_url) page.wait_for_selector("div.detail-job-info", timeout=30000) # 提取关键字段 title = page.query_selector("div.job-name h1").inner_text() salary = page.query_selector("span.salary").inner_text() company = page.query_selector("div.job-detail-header h3").inner_text() # 滚动到底部加载全部描述 page.evaluate("window.scrollTo(0, document.body.scrollHeight)") time.sleep(1) description = page.query_selector("div.detail-job-desc").inner_text() result = { 'url': job_url, 'title': title.strip(), 'salary': salary.strip(), 'company': company.strip(), 'description': description.strip(), 'crawl_time': time.strftime('%Y-%m-%d %H:%M:%S') } context.close() browser.close() return result # 使用示例 job_urls = [ "https://www.zhipin.com/job_detail/abc123.html", "https://www.zhipin.com/job_detail/def456.html" ] for url in job_urls: data = crawl_job_detail(url) # 写入数据库...

关键技巧：

• 首次登录必须headless=False，因为图形验证码需要人工识别；
• Cookie保存后，后续采集全程headless=True，速度提升3倍；
• page.evaluate("window.scrollTo(...)")比page.mouse.wheel()更可靠，后者在某些网站会失效。

4.4 方式三实操：批量下载国家统计局Excel年鉴（文件级抓取）

国家统计局官网的年鉴文件URL高度规律：http://www.stats.gov.cn/tjsj/ndsj/2023/indexeh.htm→http://www.stats.gov.cn/tjsj/ndsj/2023/html/A01.htm→http://www.stats.gov.cn/tjsj/ndsj/2023/excel/A01-1.xls。我们用三层解析：

import requests from bs4 import BeautifulSoup import re import os from urllib.parse import urljoin, urlparse def download_stats_excel(year: int = 2023): base_url = f"http://www.stats.gov.cn/tjsj/ndsj/{year}/indexeh.htm" # 第一层：获取年鉴目录页 resp = requests.get(base_url, timeout=30) soup = BeautifulSoup(resp.content, 'html.parser') # 第二层：提取所有章节链接（A01, A02...） chapter_links = [] for link in soup.find_all('a', href=re.compile(r'A\d{2}\.htm')): full_url = urljoin(base_url, link['href']) chapter_links.append(full_url) # 第三层：对每个章节页，提取Excel下载链接 excel_urls = [] for chapter_url in chapter_links[:5]: # 先试前5章 try: resp = requests.get(chapter_url, timeout=30) soup_chapter = BeautifulSoup(resp.content, 'html.parser') # 查找包含"excel"或".xls"的链接 for link in soup_chapter.find_all('a', href=re.compile(r'\.(xls|xlsx|csv)$', re.I)): excel_url = urljoin(chapter_url, link['href']) excel_urls.append(excel_url) except Exception as e: print(f"解析章节页失败: {chapter_url}, {e}") # 下载所有Excel文件 os.makedirs(f"./stats_{year}", exist_ok=True) for url in excel_urls: parsed = urlparse(url) filename = os.path.basename(parsed.path) filepath = f"./stats_{year}/{filename}" print(f"正在下载: {filename}") download_with_resume(url, filepath) # 复用3.3节的断点续传函数 # 下载后校验文件头（确保是真实Excel） try: with open(filepath, 'rb') as f: header = f.read(4) if header not in [b'\xD0\xCF\x11\xE0', b'PK\x03\x04']: # OLE/ZIP头 print(f"警告: {filename} 可能不是有效Excel文件") except Exception as e: print(f"校验文件头失败: {filename}, {e}") # 执行下载 download_stats_excel(2023)

安全边界提醒：

• 国家统计局明确允许非商业用途的数据下载，但禁止高频访问（robots.txt规定Crawl-delay: 10）；
• 脚本中timeout=30和Crawl-delay逻辑已内置，每请求间隔≥12秒；
• 下载后必须校验文件头，因为部分链接会重定向到404页面，返回HTML而非Excel。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 HTTP采集高频问题速查表

实操心得：遇到超时问题，永远先用curl -w "@format.txt"测试，其中format.txt内容为time_namelookup: %{time_namelookup}s\n time_connect: %{time_connect}s\n time_starttransfer: %{time_starttransfer}s\n，这样能精准定位是DNS、TCP握手还是服务器响应慢。

5.2 Playwright采集疑难杂症处理

• 问题：TimeoutError: Timeout 30000ms exceeded.卡在page.goto()
  原因：目标网站启用了Cloudflare防护，Playwright默认不处理。
  解决：在启动浏览器时添加bypass_csp=True参数，并注入stealth.min.js插件：

  context = browser.new_context( bypass_csp=True, viewport={'width': 1920, 'height': 1080} ) # 注入反检测脚本 with open("stealth.min.js", "r") as f: stealth_js = f.read() context.add_init_script(stealth_js)

• 问题：page.query_selector()返回None，但元素明明存在
  原因：元素在iframe内，或由JavaScript动态插入。
  解决：先用page.frame_locator("iframe").get_by_role('button')定位iframe内元素；或改用page.wait_for_function("() => document.querySelector('#target') !== null")等待元素出现。

• 问题：Chromium进程残留，CPU持续100%
  原因：脚本异常退出未调用browser.close()。
  解决：用atexit注册清理函数：

  import atexit def cleanup(): if 'browser' in locals(): browser.close() atexit.register(cleanup)

5.3 文件下载与存储陷阱

• SQLite写入缓慢：当单次插入1000条记录时，逐条INSERT耗时23秒，而用executemany批量插入仅0.8秒。正确写法：

  data_list = [(url1, content1), (url2, content2)] cursor.executemany("INSERT INTO raw_data (url, raw_content) VALUES (?, ?)", data_list) conn.commit()

• PDF文件损坏无法OCR：用pdfplumber.open(filepath)报错PdfReadError: EOF marker not found。
  原因：断点续传时服务器返回206 Partial Content，但本地文件末尾多了一个\x00字节。
  解决：下载完成后用truncate命令清理：

  import subprocess subprocess.run(["truncate", "-s", str(expected_size), filepath])

• 磁盘空间不足导致采集中断：脚本静默失败，无任何报错。
  解决：在每次循环前加入空间检查：

  import shutil total, used, free = shutil.disk_usage("/") if free < 5 * 1024**3: # 小于5GB print("警告：磁盘空间不足！") sys.exit(1)

5.4 法律与合规红线自查清单

所有PC端采集必须通过以下五项检验，缺一不可：

1. robots.txt合规：用requests.get("https://target.com/robots.txt")检查Disallow路径，脚本中强制跳过；
2. 数据用途限定：仅用于个人学习、学术研究、非商业分析，不在任何公开渠道传播原始数据；
3. 速率控制：time.sleep()间隔≥5秒，或使用ratelimit库限制RPS≤0.2；
4. 来源标注：存储数据时在metadata字段记录source_url和crawl_time，确保可追溯；
5. 敏感信息过滤：对采集内容做正则清洗，移除身份证号、手机号、银行卡号等PII信息（re.sub(r'\d{17}[\dXx]', '[ID_HIDDEN]', text)）。

我个人在实际操作中的体会是：真正的风险从来不是技术难度，而是对数据边界的模糊认知。去年帮一家教育机构爬取公开教师招聘信息，我坚持在脚本里加入if '身份证' in text: continue的过滤逻辑，虽然增加了0.3秒处理时间，但避免了后续可能的法律纠纷。技术可以重写，合规意识一旦松懈，代价远超想象。