企业信息采集实战：Python爬虫技术与合规数据获取指南

经常有人在技术群里问：Python爬虫能不能做到无账号无限制地拿企查查的企业信息？我的回答通常是：技术上可以聊，但真正该问的不是能不能，而是该不该、怎么拿才安全。这篇不是教你怎么硬闯风控，而是把企业信息采集这件事从需求拆解到落地完整讲一遍，顺便说说那些爬虫新手最容易踩的坑。适合刚接触爬虫的Python开发者，也适合想系统做企业数据采集、但还没想清楚数据边界的朋友。

尤其是“无账号无限制”这六个字，很多人把它当成爬虫练手的终极目标，但实际做过企业信息采集的人都知道，这句话背后藏着两个大问题：一是目标站点不会让你“无限制”，二是就算技术上能短期突破，法律和平台协议的风险也远高于那点数据收益。所以我先泼一盆冷水：不设防地爬取企查查这类聚合平台，不是一个值得复制的方案。真正有价值的是你理解请求、解析、并发、存储这一整套爬虫基本功，然后把它们用在合法授权的数据源上。

1. 先想清楚：这个需求背后到底要什么

1.1 企业信息采集的真实使用场景

大部分找“爬企查查”的人，要的不是某个网站本身，而是企业维度的结构化数据。常见需求包括销售拓客、风控尽调、竞品监控、市场分析，甚至只是帮朋友查一家公司有没有经营风险。这类需求通常需要这些字段：企业名称、统一社会信用代码、法定代表人、注册资本、成立日期、经营范围、股东信息、主要人员、变更记录、司法风险、经营异常等。

这些字段看起来不多，但真要清洗成一份能用的表格，比想象中复杂得多。比如同一家公司在不同数据源里的名称可能差一个字，注册资本有“万”和“万元”的差异，成立日期有时是纯数字串，有时是“2001-05-16”格式。如果一开始没有把“最终要拿到什么字段、什么格式、怎么更新”想清楚，后面写再多代码都是在给垃圾数据做搬运。

另外还要想清楚数据量级。是要查十家、一千家，还是几百万家？量级不同，技术方案完全不同。十家直接用浏览器手动复制都比写爬虫快，一千家可以考虑脚本抓取，几百万家就需要设计分布式任务队列和增量更新机制。很多人一上来就学分布式爬虫，结果自己的需求只有几百条数据，完全是杀鸡用牛刀。

1.2 为什么“无账号无限制”是一个伪命题

先说结论：对企查查这类平台，无账号无限制本身就是不存在的状态。原因有三层。

第一层是账号体系。企查查的搜索、详情页很多功能要求登录。你以为是“无账号”，实际是平台把所有访客都当成了“未登录的低权限用户”，能看到的字段被大幅裁剪。真正完整的企业关联图谱、风险穿透、受益所有人信息，都在付费会员后面。所以“无账号”不是优势，而是数据缺失的代名词。

第二层是风控体系。这类平台每天要面对大量爬虫和恶意请求，早就部署了多层反爬：IP维度的频率限制、会话维度的行为分析、浏览器指纹、字体反爬、SVG映射、滑块验证码、短信验证码等。所谓“无限制”，只是在你还没有触发风控之前看起来没有限制，一旦请求量超过阈值，等待你的就是验证码、封IP，甚至整个网段被拉黑。

第三层是法律和协议边界。企业信息聚合平台的数据虽然很多来自公开渠道，但平台对数据做了加工、整理、编排，这种劳动成果受到法律保护和平台用户协议的约束。你写爬虫去采集，平台完全有理由依据用户协议主张违约或侵权。更不用说如果采集到的数据里包含个人敏感信息，处理不当可能涉及个人信息保护问题。所以“无账号无限制”这件事，从合规角度看从一开始就不该作为目标。

1.3 合规自检：动手前先过这四关

在写第一行代码之前，我建议按下面这个清单做一次自检。不要觉得这是形式主义，真出问题的时候，这个清单能救你。

我见过太多项目挂在第一关：不看用户协议，不看robots，直接开写。等收到了对方法务函才想起来查条款，那时候已经晚了。爬虫不是不能用，而是要用在“你被允许访问”的数据范围内。比如很多政府公开数据平台、企业自行开放的API、授权第三方数据服务商，都是合法的采集对象。先把数据源选对，后面的技术才有意义。

2. 目标解析与请求构造：学会像浏览器一样说话

2.1 先做一次干净的抓包分析

无论目标是什么网站，第一步永远是打开浏览器开发者工具，观察一次正常访问到底发了哪些请求。用Chrome或Edge的F12都行，关键是别一上来就写Python，而是先在Network面板里看清楚。

一般要关注四类信息。一是请求URL，包括路径和查询参数，搞清楚哪些字段是搜索关键词，哪些是分页参数，哪些是时间戳。二是请求Method，绝大多数页面是GET，但搜索、筛选、翻页有可能是POST，参数会放在Form Data或JSON Body里。三是请求头，重点看User-Agent、Referer、Origin、Cookie，这些是服务器判断请求来源的主要依据。四是响应内容，先看返回的是完整HTML，还是JSON数据，还是只有一段JavaScript渲染逻辑。

抓包的时候不要登录，先把未登录状态下的请求链路摸清楚。通常一次搜索行为会经历首页加载、搜索接口、结果列表、详情页多个步骤。你要找的是真正返回业务数据的那几个接口，而不是被图片、脚本、埋点统计淹没的全部请求。一个简单技巧：在Network面板里用关键字过滤，比如搜索企业名称关键词，或者直接看XHR/Fetch类型的请求，因为现代网站的业务数据大多走异步接口。

2.2 用requests构造基础请求

拿到关键请求之后，就可以用Python试着复现了。下面是一个标准的requests请求模板，没有任何特殊技巧，但足够应对大部分不需要登录的公开页面。

import requests HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0.0.0 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", "Referer": "https://example.com/", } def fetch_html(url): try: resp = requests.get(url, headers=HEADERS, timeout=10) resp.raise_for_status() resp.encoding = resp.apparent_encoding return resp.text except requests.RequestException as e: print(f"请求失败: {e}") return ""

这个模板里有几个细节值得说一下。第一，timeout必须设置，不设置的话，一个卡死的请求可能让你的脚本挂几分钟。第二，resp.encoding = resp.apparent_encoding很关键，很多中文网站的响应头里没写正确编码，不手动设置的话，解析出来的中文全是乱码。第三，raise_for_status()会在HTTP状态码为4xx或5xx时主动抛异常，避免你把错误页面当成正常数据继续解析。

另外，requests默认的User-Agent是python-requests/x.x.x，很多网站看到这个UA直接拒绝。所以自定义UA是基本功，但也不要只改UA就以为万事大吉，服务器还会校验请求头组合、Cookie、访问频率等一堆信号。

2.3 那些容易被忽略的请求头细节

新手最容易忽略的是请求头之间的联动关系。举个例子，一个页面如果直接访问能打开，但带上Referer反而被拒绝，这很可能是服务器做了Referer白名单校验，只允许从首页或搜索页跳转过来的请求。反过来，有些接口强制要求Referer必须带上，不带就返回403。碰到这种情况，不要凭感觉乱填，回到浏览器里看真实请求是怎么带的，照着抄。

Cookie也是一个大坑。很多网站刚打开页面时会种下一个种子Cookie，之后的所有请求都要带着它，否则会被判定为异常访问。这种场景下常见做法是用requests.Session()保持会话，因为Session对象会自动保存和携带Cookie。

session = requests.Session() session.headers.update(HEADERS) session.get("https://example.com/", timeout=10) resp = session.get("https://example.com/search?q=test", timeout=10)

注意，我说的是维护登录态？不，这里说的只是未登录状态下服务器种下的匿名Cookie。真正的会员登录态Cookie，不建议也不应该通过爬虫去复用，那已经超过公开访问的边界了。更稳妥的做法是，只采集未登录状态下就能看到的公开信息。

3. 拿到响应之后：HTML、JSON、混淆文本怎么解析

3.1 先判断响应类型

请求返回之后，别急着找数据，先看响应到底是什么。我一般按下面这个表格快速分类。

判断方法很简单：用resp.headers.get("Content-Type")看是application/json还是text/html，再把响应体前500个字符打印出来看结构。千万别拿到一个HTML就去写解析规则，结果真正的数据是页面里的某个JSON字符串。

3.2 BeautifulSoup + lxml 解析表格

对于服务端渲染的HTML页面，最常用的解析方案是BeautifulSoup加lxml解析器。下面是一个解析企业列表表格的示例，注意我只用了CSS选择器，逻辑清晰，容易维护。

from bs4 import BeautifulSoup def parse_company_table(html): soup = BeautifulSoup(html, "lxml") table = soup.find("table", class_="company-table") if not table: return [] rows = [] for tr in table.select("tbody tr"): cells = [td.get_text(strip=True) for td in tr.find_all("td")] if cells: rows.append(cells) return rows

解析表格的要点有三个。第一，优先选class_或id，实在没有再用位置关系，因为位置关系在小改动下就崩。第二，get_text(strip=True)能去掉首尾空白和换行，避免出现“ 北京 有限公司 ”这种脏数据。第三，不要一上来就处理全部字段，先跑通一个页面，把字段对应关系确认清楚，再批量跑。

有时候页面返回的不是标准HTML表格，而是div一块块拼出来的卡片列表。这时候选择器和上面类似，但更建议提取一个卡片块后再提取子字段，而不是一次性写一个超长选择器。宁可代码多几行，也要保证未来页面微调时能快速定位问题。

3.3 字体反爬和SVG混淆是怎么回事

企业信息站点里，字体反爬和SVG混淆是两种很常见的文本混淆手段。它们的本质，是把页面里的文字转换成浏览器能正常显示、但爬虫不能直接读取的形式。

字体反爬的做法，是自定义一套字体文件，把某些字符的映射关系替换掉。你在网页里看到的“北京”，其实际文本可能已经映射到了另外几个Unicode码位，复制出来是乱码。SVG混淆则更常见，把一段文字拆成坐标位置，再用背景图或CSS定位方式显示文字，HTML里只留下偏移量。

不少教程会教你怎么下载字体文件、解析cmap表、建立字符映射，或者怎么识别SVG坐标还原文字。就技术学习而言，这些思路确实很有意思，也是很好的逆向练手题目。但我必须提醒一句：在线上去破解别人主动设置的混淆机制，和在本地自己造一份样本研究原理，是两种完全不同的性质。前者属于绕避技术保护措施，风险很高。

如果只是想练手，我建议你自己构造一个简单的“自定义字体反爬”样本页面，把字符替换规则写在本地，然后写解析脚本把映射关系还原。这个过程能让你彻底理解原理，又不碰任何不该碰的线上服务。

3.4 遇到验证码和登录墙时怎么办

验证码和登录墙是反爬的最后一道防线，也是合规的分水岭。滑块验证码、点选文字、旋转图片、短信验证码，每一种都在做同一件事：确认操作者是人，并且行为正常。

合规采集遇到验证码，第一反应不是研究怎么绕，而是检查自己的请求频率是不是太快了。我见过很多情况，脚本本来跑得好好的，加了个并发池之后，十分钟内就被验证码拦住了。把并发降到1，每个请求之间加2到3秒延时，很多验证码根本不会出现。

如果降频之后还是被验证码挡着，那就说明目标页面明确不欢迎自动化访问。这时候正确的选择是：停手，换数据源，或者联系对方商务买数据。打码平台、验证码识别工具，技术上确实存在，但一旦用上，你的整个项目就彻底踩进了高风险区域。为了一点公开数据赌上账号和法律责任，不值得。

4. 采集效率：并发设计不是越快越好

4.1 单线程、多线程、异步怎么选

数据量一大，单线程逐条请求确实慢，于是很多人开始研究并发。但并发设计没有标准答案，只有适不适合你的场景。

我的建议是：对绝大多数企业信息采集需求，先不要碰分布式，用单线程加延时把流程跑通，再用线程池把速度提到一个可控范围。等你真的遇到每天上百万请求的规模时，再考虑分布式也不迟。很多人第一步就搞Kafka加Celery，结果数据源连账号权限都没搞定，纯属自嗨。

4.2 一个可控的并发请求示例

下面这个示例用ThreadPoolExecutor和信号量同时限制最大并发数和最小请求间隔。它不是为了跑满带宽，而是为了在“速度”和“安全”之间找一个平衡点。

import time import threading from concurrent.futures import ThreadPoolExecutor, as_completed rate_lock = threading.Lock() last_request_time = 0 MIN_INTERVAL = 1.0 # 每个请求至少间隔1秒 def throttled_fetch(name): global last_request_time with rate_lock: now = time.time() wait = MIN_INTERVAL - (now - last_request_time) if wait > 0: time.sleep(wait) last_request_time = time.time() # 这里替换为你自己的请求函数 result = {"name": name, "status": "ok"} return result company_names = [f"测试公司{i}" for i in range(20)] with ThreadPoolExecutor(max_workers=5) as executor: future_map = {executor.submit(throttled_fetch, name): name for name in company_names} for future in as_completed(future_map): name = future_map[future] try: result = future.result() print(result) except Exception as e: print(f"{name} 处理失败: {e}")

这段代码的核心在throttled_fetch里的锁和延时。锁保证同一时间只有一个线程在决定“下一次请求什么时候发”，从而让整体请求频率均匀。如果没有这个锁，5个线程同时冲出去，前5个请求会挤在同一瞬间，很容易触发服务器限流。

并发数怎么定？没有固定公式，我一般从max_workers=3开始试，观察响应状态码和耗时。如果出现权限类错误或验证码，就降并发、加间隔；如果稳定，再逐步加。这个“逐步试探”的过程，比网上任何推荐配置都可靠。

4.3 限速、重试与优雅退出

并发爬虫一定要有重试机制，但不能无脑重试。我用的重试策略是：连接超时和短暂5xx错误可以重试两到三次；403、418这类风控响应不要重试，因为重试只会让封禁更严重；参数错误或数据不存在也不要重试，再试结果一样。

退避策略方面，最简单的是固定延时重试，比如第一次失败后等3秒，第二次等6秒，第三次直接放弃。也可以用随机延时，在1到3秒之间加一点抖动，让请求节奏更接近人类操作。不要把退避时间写成固定的0.5秒，那反而容易被机器学习模型识别为机器行为。

优雅退出指的是，脚本在收到终止信号时，能把手头正在处理的任务收尾，而不是直接崩溃导致数据写了一半。实现方式很简单：用try/finally包裹资源释放，或者把每个公司名和它的抓取状态存到本地文件，下次启动时跳过已完成的部分。这比任何高级技巧都实用。

4.4 数据去重与存储

企业数据采集到本地，最怕的就是重复入库。同一家公司可能通过不同关键词搜索到两次，也可能在你的脚本重启后被抓了两遍。所以落库阶段一定要有唯一键约束。

SQLite是小项目的最佳选择，单文件、不用部署、Python内置。建表时把统一社会信用代码设为主键或者唯一索引，没有信用代码的中小企业，可以用“企业名称 + 注册地”组合做唯一键。如果你存的是原始HTML，那就把完整的请求URL设为主键，这样天然去重。

CREATE TABLE IF NOT EXISTS company ( credit_code TEXT PRIMARY KEY, name TEXT NOT NULL, legal_person TEXT, reg_capital TEXT, created_date TEXT, raw_json TEXT, updated_at TEXT DEFAULT CURRENT_TIMESTAMP );

插入时用INSERT OR IGNORE或ON CONFLICT DO UPDATE，代码里就不用先查一遍再判断是否插入。这个细节虽然小，但能省掉大量重复逻辑，也让数据更干净。

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

5.1 状态码速查：403、418、999分别意味着什么

爬虫过程中的错误码各不相同，我整理了一份速查表，按经验由高到低排序。

遇到这些状态码，先在代码里统一加一层日志，把URL、状态码、请求头、响应体前200个字符都打出来。很多时候问题一眼就能看出来，比如Referer写错、参数少了page字段、Cookie过期了。没有日志就去猜原因，是排查效率最低的方式。

5.2 动态渲染页面到底要不要上浏览器自动化

有些页面打开全是数据，但requests拿到的HTML里什么都没有，因为数据是JavaScript异步加载的。新手第一反应是上Selenium或者Playwright，打开一个无头浏览器慢慢等渲染。这个方法能用，但代价很大：内存占用高、运行慢、更容易触发风控，因为浏览器自动化特征很明显。

更推荐的顺序是：先用抓包定位真正的异步接口，很多动态页面的数据其实就藏在某个XHR请求里，直接请求那个接口，又快又稳。只有当你发现数据被加密、接口参数带有动态签名时，才考虑浏览器自动化。即便如此，也要记住，浏览器自动化不是用来“绕过”验证码的，而是用来处理“必须执行JS才能获得数据”的页面。如果你没有这个页面的访问授权，用浏览器自动化和用requests，风险是一样的。

5.3 数据校验与增量更新

抓回来的数据必须做校验。最简单的校验方式是抽样人工比对：随机抽5到10条，去网页上核对关键字段。只要有一两条对不上，就要检查解析逻辑，不要继续跑批量任务。

增量更新方面，企业工商信息的变化频率不算高，但也不是一劳永逸。常见策略是：首次全量抓取，之后按天或按周更新新增数据，对已有企业定期做变更检测。变更检测的字段可以只看注册资本、法定代表人和经营状态，没必要每次把全部字段都刷新一遍。

存数据时给每条数据加一个updated_at字段，更新时用ON CONFLICT DO UPDATE覆盖旧数据，同时保留采集日志。这样出了问题，你知道这条数据是什么时候抓的、从哪个URL抓的，能回追溯。

5.4 日志和监控：出问题能追溯

不要高估自己的记忆力，也不要低估数据采集的任务时长。一个脚本可能要跑几小时甚至几天，中间会经历网络波动、目标页面改版、本地磁盘满了等一堆问题。没有日志，你会连问题发生的时间点都找不到。

我习惯在每个关键节点打日志：开始请求、请求成功、解析到多少条、入库多少条、失败多少条。日志格式尽量统一，用print能看，但更好的是写入文件，方便事后搜索。可以用Python自带的logging模块，按天轮转文件，保持日志不会无限膨胀。

另外一个容易被忽略的监控点是入库数量的趋势。如果连续十分钟入库数量为0，多半是解析规则崩了，或者请求全部被拦截。这时候可以加一个最简单的计数器报警：每入库100条打印一次进度，很久没有新进度就人工关注。不用上复杂的监控平台，一个文件日志加时间戳就够小项目用了。

6. 更推荐的路线：API、授权数据源与长期方案

6.1 官方API和开放数据接口

如果目标是稳定、持续地获取企业信息，最靠谱的路线是使用官方API或授权数据服务。各级政府公开数据平台、企业信用信息公示系统、行业协会公开名单，都提供了很多合法可用的企业基础信息。虽然接口的实时性和字段完整度不一定比得上商业聚合平台，但胜在合规，不怕被告，也不怕被封。

商业数据API是另一个选择。市面上有不少正规的企业数据服务商，提供工商、司法、知识产权、招投标等维度的数据接口，按调用量收费。价格可能不便宜，但因为数据经过了合规授权和清洗，省下来的法务成本和开发时间，往往比你自己维护一套爬虫更划算。

我的经验是：如果企业信息采集是你业务的核心链路，就老老实实付费买数据；如果只是偶尔查几十家公司的信息，直接用浏览器手动查都行；只有当你想练爬虫技术本身时，才值得自己写一套，但要选一个你确定有权访问的公开数据源。

6.2 自建企业数据集：从一次性抓取到持续维护

如果你确实需要自己维护一套企业数据，我建议做一个清晰的架构拆分：采集层负责从合法数据源拉取原始数据，解析层负责把HTML或JSON转成结构化字段，存储层负责去重入库，调度层负责定时触发增量更新。

一开始不需要把这四层做得那么重，一个Python脚本加一个SQLite文件就能跑。但表结构要提前想好，字段要尽量标准化，比如注册资本统一存数字和单位两个字段，日期统一存ISO格式。否则等数据量上来再改表结构，那痛苦你不想经历。

增量更新也别想太复杂。每天固定时间跑一次定时任务，查询当天新注册企业的公开信息，再对已有企业做一次变更检测。如果目标数据源不支持按时间范围查询，就从你已存的最大序号或更新时间往后拉几页。保持简单，才有机会长期维护下去。

6.3 什么时候应该放弃自建爬虫

最后说点个人经验。我见过不少项目，自建爬虫的团队把大量时间花在应对反爬、修解析规则、维护代理池上，最后算下来，成本比直接购买数据还高。数据采集只是手段，不是目的。如果你的核心价值在产品、分析或服务上，爬虫能省就省，能用API就用API，能买现成数据就买现成数据。

这是我在踩过多次坑之后的真实体会，分享出来供参考。自建爬虫很适合作为技术学习，它能让你深刻理解HTTP协议、网页解析、并发控制、数据建模这些基本功。但到了生产环境，合规、稳定、可维护才是第一位的。与其强求“无账号无限制”，不如把精力放在把一条合法数据链路做到极致，哪怕慢一点，也是真正能长期跑下去的方案。