经常有人在技术群里问Python爬虫能不能做到无账号无限制地拿企查查的企业信息我的回答通常是技术上可以聊但真正该问的不是能不能而是该不该、怎么拿才安全。这篇不是教你怎么硬闯风控而是把企业信息采集这件事从需求拆解到落地完整讲一遍顺便说说那些爬虫新手最容易踩的坑。适合刚接触爬虫的Python开发者也适合想系统做企业数据采集、但还没想清楚数据边界的朋友。尤其是“无账号无限制”这六个字很多人把它当成爬虫练手的终极目标但实际做过企业信息采集的人都知道这句话背后藏着两个大问题一是目标站点不会让你“无限制”二是就算技术上能短期突破法律和平台协议的风险也远高于那点数据收益。所以我先泼一盆冷水不设防地爬取企查查这类聚合平台不是一个值得复制的方案。真正有价值的是你理解请求、解析、并发、存储这一整套爬虫基本功然后把它们用在合法授权的数据源上。1. 先想清楚这个需求背后到底要什么1.1 企业信息采集的真实使用场景大部分找“爬企查查”的人要的不是某个网站本身而是企业维度的结构化数据。常见需求包括销售拓客、风控尽调、竞品监控、市场分析甚至只是帮朋友查一家公司有没有经营风险。这类需求通常需要这些字段企业名称、统一社会信用代码、法定代表人、注册资本、成立日期、经营范围、股东信息、主要人员、变更记录、司法风险、经营异常等。这些字段看起来不多但真要清洗成一份能用的表格比想象中复杂得多。比如同一家公司在不同数据源里的名称可能差一个字注册资本有“万”和“万元”的差异成立日期有时是纯数字串有时是“2001-05-16”格式。如果一开始没有把“最终要拿到什么字段、什么格式、怎么更新”想清楚后面写再多代码都是在给垃圾数据做搬运。另外还要想清楚数据量级。是要查十家、一千家还是几百万家量级不同技术方案完全不同。十家直接用浏览器手动复制都比写爬虫快一千家可以考虑脚本抓取几百万家就需要设计分布式任务队列和增量更新机制。很多人一上来就学分布式爬虫结果自己的需求只有几百条数据完全是杀鸡用牛刀。1.2 为什么“无账号无限制”是一个伪命题先说结论对企查查这类平台无账号无限制本身就是不存在的状态。原因有三层。第一层是账号体系。企查查的搜索、详情页很多功能要求登录。你以为是“无账号”实际是平台把所有访客都当成了“未登录的低权限用户”能看到的字段被大幅裁剪。真正完整的企业关联图谱、风险穿透、受益所有人信息都在付费会员后面。所以“无账号”不是优势而是数据缺失的代名词。第二层是风控体系。这类平台每天要面对大量爬虫和恶意请求早就部署了多层反爬IP维度的频率限制、会话维度的行为分析、浏览器指纹、字体反爬、SVG映射、滑块验证码、短信验证码等。所谓“无限制”只是在你还没有触发风控之前看起来没有限制一旦请求量超过阈值等待你的就是验证码、封IP甚至整个网段被拉黑。第三层是法律和协议边界。企业信息聚合平台的数据虽然很多来自公开渠道但平台对数据做了加工、整理、编排这种劳动成果受到法律保护和平台用户协议的约束。你写爬虫去采集平台完全有理由依据用户协议主张违约或侵权。更不用说如果采集到的数据里包含个人敏感信息处理不当可能涉及个人信息保护问题。所以“无账号无限制”这件事从合规角度看从一开始就不该作为目标。1.3 合规自检动手前先过这四关在写第一行代码之前我建议按下面这个清单做一次自检。不要觉得这是形式主义真出问题的时候这个清单能救你。检查项具体问题判断标准平台协议目标站点的服务条款是否明确禁止爬虫/抓取禁止就换授权渠道或者联系官方获得书面许可Robots协议目标站点robots.txt是否允许访问目标路径不允许就停手不要心存侥幸请求频率你的抓取频率是否可能影响网站正常服务会就主动降速单线程延时是底线策略数据用途数据是否会涉及个人信息、商业秘密或用于竞争性用途有风险就放弃或者改用官方数据服务我见过太多项目挂在第一关不看用户协议不看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/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Referer: https://example.com/, } def fetch_html(url): try: resp requests.get(url, headersHEADERS, timeout10) 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/, timeout10) resp session.get(https://example.com/search?qtest, timeout10)注意我说的是维护登录态不这里说的只是未登录状态下服务器种下的匿名Cookie。真正的会员登录态Cookie不建议也不应该通过爬虫去复用那已经超过公开访问的边界了。更稳妥的做法是只采集未登录状态下就能看到的公开信息。3. 拿到响应之后HTML、JSON、混淆文本怎么解析3.1 先判断响应类型请求返回之后别急着找数据先看响应到底是什么。我一般按下面这个表格快速分类。响应特征数据类型解析方式大段JSON键名规范API接口json.loads()或resp.json()完整HTML含表格和列表服务端渲染页面BeautifulSoup lxmlHTML壳子数据在script变量里首屏直出的JS数据正则或JSON提取后处理大量加密JS、字体文件、动态样式反爬混淆页面先评估合规再决定是否继续判断方法很简单用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(stripTrue) for td in tr.find_all(td)] if cells: rows.append(cells) return rows解析表格的要点有三个。第一优先选class_或id实在没有再用位置关系因为位置关系在小改动下就崩。第二get_text(stripTrue)能去掉首尾空白和换行避免出现“ 北京 有限公司 ”这种脏数据。第三不要一上来就处理全部字段先跑通一个页面把字段对应关系确认清楚再批量跑。有时候页面返回的不是标准HTML表格而是div一块块拼出来的卡片列表。这时候选择器和上面类似但更建议提取一个卡片块后再提取子字段而不是一次性写一个超长选择器。宁可代码多几行也要保证未来页面微调时能快速定位问题。3.3 字体反爬和SVG混淆是怎么回事企业信息站点里字体反爬和SVG混淆是两种很常见的文本混淆手段。它们的本质是把页面里的文字转换成浏览器能正常显示、但爬虫不能直接读取的形式。字体反爬的做法是自定义一套字体文件把某些字符的映射关系替换掉。你在网页里看到的“北京”其实际文本可能已经映射到了另外几个Unicode码位复制出来是乱码。SVG混淆则更常见把一段文字拆成坐标位置再用背景图或CSS定位方式显示文字HTML里只留下偏移量。不少教程会教你怎么下载字体文件、解析cmap表、建立字符映射或者怎么识别SVG坐标还原文字。就技术学习而言这些思路确实很有意思也是很好的逆向练手题目。但我必须提醒一句在线上去破解别人主动设置的混淆机制和在本地自己造一份样本研究原理是两种完全不同的性质。前者属于绕避技术保护措施风险很高。如果只是想练手我建议你自己构造一个简单的“自定义字体反爬”样本页面把字符替换规则写在本地然后写解析脚本把映射关系还原。这个过程能让你彻底理解原理又不碰任何不该碰的线上服务。3.4 遇到验证码和登录墙时怎么办验证码和登录墙是反爬的最后一道防线也是合规的分水岭。滑块验证码、点选文字、旋转图片、短信验证码每一种都在做同一件事确认操作者是人并且行为正常。合规采集遇到验证码第一反应不是研究怎么绕而是检查自己的请求频率是不是太快了。我见过很多情况脚本本来跑得好好的加了个并发池之后十分钟内就被验证码拦住了。把并发降到1每个请求之间加2到3秒延时很多验证码根本不会出现。如果降频之后还是被验证码挡着那就说明目标页面明确不欢迎自动化访问。这时候正确的选择是停手换数据源或者联系对方商务买数据。打码平台、验证码识别工具技术上确实存在但一旦用上你的整个项目就彻底踩进了高风险区域。为了一点公开数据赌上账号和法律责任不值得。4. 采集效率并发设计不是越快越好4.1 单线程、多线程、异步怎么选数据量一大单线程逐条请求确实慢于是很多人开始研究并发。但并发设计没有标准答案只有适不适合你的场景。方案适合场景优点缺点单线程 延时数据量小、目标风控严稳定、不易触发风控慢多线程请求以阻塞式IO为主代码简单和requests配合好线程上下文切换开销协程请求量大、目标允许较高频访问资源占用低、吞吐量高需要aiohttp调试更复杂分布式超大数据量、需要横向扩容可扩展、容错强运维成本高不适合小项目我的建议是对绝大多数企业信息采集需求先不要碰分布式用单线程加延时把流程跑通再用线程池把速度提到一个可控范围。等你真的遇到每天上百万请求的规模时再考虑分布式也不迟。很多人第一步就搞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_workers5) 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_workers3开始试观察响应状态码和耗时。如果出现权限类错误或验证码就降并发、加间隔如果稳定再逐步加。这个“逐步试探”的过程比网上任何推荐配置都可靠。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分别意味着什么爬虫过程中的错误码各不相同我整理了一份速查表按经验由高到低排序。状态码常见含义排查方向403服务器拒绝请求可能是UA、IP或权限问题先检查请求头是否完整再降低请求频率418服务器识别为机器请求Im a teapot基本可以确定是反爬触发停手降速429请求过于频繁增加请求间隔做退避等待999部分平台自定义的“访问被拒绝”大概率是风控封禁建议停止当前目标502/503服务器临时不可用或过载等几秒后重试一次连续出现就放弃404页面不存在检查URL参数、分页逻辑是否写错遇到这些状态码先在代码里统一加一层日志把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协议、网页解析、并发控制、数据建模这些基本功。但到了生产环境合规、稳定、可维护才是第一位的。与其强求“无账号无限制”不如把精力放在把一条合法数据链路做到极致哪怕慢一点也是真正能长期跑下去的方案。