Python爬虫实战：抓取广东省租房数据并存入SQLite

1. 做这件事之前先想清楚这几个问题我去年有一阵子想找个合适的住处顺手查了广东省几个城市的租房行情结果发现多数平台要么数据藏在交互式页面上要么只给你看前10页翻到最后也凑不齐一个像样的统计样本。后来我干脆自己写了一个Python脚本把广东省主要城市在公开渠道上展示的租房信息抓下来统一存成结构化数据再做后续筛选和分析。这篇文章不会贴完整源码但会把整个项目的思路、代码要点、坑和优化方案讲透让你看完之后能自己动手做一个抓取某区域租房数据并落库的小工具。在动手之前有几个问题必须想清楚否则后面大概率返工抓什么要抓的是列表页数据标题、价格、户型、面积、城区、发布时间还是详情页数据楼层、朝向、配套、联系人两者复杂度完全不同。存哪里存Excel、CSV还是MySQL/SQLite决定了你的数据清洗和查询效率。如果你后面要按城市筛选、按价格区间统计建议直接入库。抓多少是只抓一轮做快照还是要定时更新、累积历史数据。这会影响反爬策略的强度和你对IP、Cookie、延迟的管理方式。被抓的风险无论抓哪个公开站点都存在访问频率限制、验证码、封IP的可能。脚本要做得温和、可控、可暂停不能像洪水一样打过去。我当时的定位是抓取广东省21个地级市的租房列表信息覆盖每个城市尽量多的页面数据落到SQLite方便后续用SQL做统计分析。这个定位决定了后面所有技术选型和代码结构。2. 目标拆解广东省有哪些城市数据长什么样广东省的城市数量不算少直接说广东各城市的时候至少要明确是珠三角核心城市广州、深圳、佛山、东莞、中山、珠海、惠州、江门、肇庆还是包括粤东西北的全部地级市。我当时选择全部地级市因为租房数据在城市维度上的差异很大——广深的平均租金和云浮、汕尾完全不是一个量级只抓核心城市会少了很多对比乐趣。在抓数据之前建议先把城市列表固定下来写成配置文件方便后续循环抓取广州、深圳、佛山、东莞、中山、珠海、惠州、江门、肇庆汕头、潮州、揭阳、汕尾、梅州、河源、清远、韶关湛江、茂名、阳江、云浮每个城市的租房数据来源通常有两种选择通用的大型信息分类平台覆盖面广但反爬相对严格数据字段可能不全。本地生活平台或中介网站的频道页字段完整但各城市站点结构不一定一致。我当时选了一个相对稳定的公开信息平台作为数据源它不需要登录就能看到列表数据且字段中包含了我要的标题、租金、户型、面积、城区简直是练手好数据。不过我不会在文章里直接点名因为这样的数据源随时可能调整反爬策略今天能用明天不一定能用更重要的是掌握抓取思想而不是背一个固定的URL。每条租房记录的核心字段我建议按这个表格设计后续入库和查询都方便字段名含义示例city城市名称深圳district所在区域南山title房源标题科技园附近电梯两房rent月租金元6800layout户型2室1厅area面积平方米78publish_time发布时间2025-01-12source_url来源页面URLhttps://xxx这里有个很容易踩的细节rent字段在网页上往往带着元/月整租等文字或者会用6800元这种格式直接存字符串会让后续排序很难受。所以抓完第一件事就是清洗把非数字内容剔除统一转成整数或浮点数。area字段也是同理网页上可能是78㎡78平要做归一化。3. 环境准备与工具选型3.1 Python版本和依赖库我的运行环境是Python 3.10操作系统是Windows 11但这个脚本在macOS和Linux上同样能跑只要依赖装好就行。实际用到的库只有三个requests发送HTTP请求拿HTML源码。BeautifulSoup4解析HTML提取字段图书馆里最友好的解析工具。pandas做数据清洗和格式化最后写入SQLite。如果你还没装直接一行命令pip install requests beautifulsoup4 pandas有人会问为什么不用Selenium或Playwright那些工具确实能解决动态渲染问题但代价很大——每个页面都要启动无头浏览器抓1000个页面就相当于打开1000次浏览器速度和内存都顶不住。我的原则是能通过看网络请求解决的就用requests实在有动态渲染、被JS加密的才上浏览器自动化。后来我也确实遇到一个城市分页是异步加载的这个我们放到后面反爬与分页章节专门讲。3.2 给requests设置合理的请求头很多初级爬虫脚本死在第一步服务器返回403。原因是requests默认的User-Agent太显眼了像在告诉对方我是脚本。我们需要伪装成一个正常浏览器的请求头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, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Referer: https://www.xxxxx.com/, } session requests.Session() session.headers.update(HEADERS)用requests.Session而不是直接requests.get有一个实际好处Session会自动管理Cookie如果目标站点在第一次访问时下发了一个Cookie后续请求都会自动带上这样更接近真实用户的浏览行为减少被风控的概率。3.3 测试连接与页面结构我建议拿到目标URL后先不要急着写完整爬虫先在Python交互式环境里跑一下看看返回的状态码和页面内容url https://www.example.com/zufang/guangzhou/ resp session.get(url, timeout10) print(resp.status_code) print(resp.text[:500])如果状态码是200并且有内容再进入下一步。如果报403或跳转验证码页得先解决反爬问题后面章节会展开。请求加timeout参数是我强烈建议的习惯。如果你不设超时网络一卡脚本可能卡在那里不动整轮抓取就停摆了。设成10秒或15秒比较合理。4. 核心解析逻辑从HTML到结构化数据4.1 分析页面上的房源节点拿到一个列表页的HTML后不要直接用正则硬抠容易碎。正确做法是用BeautifulSoup先把页面转成可查询的节点树再找到每条房源信息对应的DOM节点。我一般会先在浏览器里打开目标页面按F12查看元素找到列表容器的class或id。常见的结构是div classhouse-list div classhouse-item div classtitle...房源标题.../div div classprice6800元/月/div div classinfo2室1厅 | 78㎡ | 南山/div /div /div实际站点的class名不会这么规整但思路一致。在BeautifulSoup里实现from bs4 import BeautifulSoup soup BeautifulSoup(resp.text, html.parser) items soup.select(div.house-item) for item in items: title_el item.select_one(.title) price_el item.select_one(.price) info_el item.select_one(.info) ...这里有个经验select_one返回第一个匹配元素select返回所有匹配元素列表。如果结构稍有变动直接print出来看不要靠猜。4.2 解析字段时的三个坑第一个坑是空值。有些房源可能没填面积或者价格显示面议这时候如果直接转int会抛异常。我的处理方式是把字段解析包在一个函数里统一做防御性编程def parse_int(text): import re if not text: return None nums re.findall(r\d, text) return int(nums[0]) if nums else Nonere.findall(r\d, text)会把6800元/月中的6800抠出来。如果text为None或空串返回None后续插入数据库时置为NULL。第二个坑是整租和合租混在一起。如果目标页面上同时有两类房源layout字段解析出来的可能是3室1厅但其实这条数据是合租单间。如果你想做统计分析建议额外加一个字段rent_type从标题或列表标签中提取整租或合租否则统计平均租金时会混入完全不可比的数据。第三个坑是发布时间格式。有些房源显示今天更新有些显示2025-01-12如果用统一的日期解析肯定出错。我的解决方案是先将所有日期格式统一成字符串遇到今天更新就取当天日期遇到X天前就倒推日期。这个逻辑不复杂放到后面清洗阶段处理。4.3 把数据装进pandas DataFrame每次解析完一个页面的items后我会把字段追加到一个全局列表中最后一次性构建DataFrame。这样比一行一行的插入数据库要快几个数量级all_rows [] def parse_page(resp): soup BeautifulSoup(resp.text, html.parser) items soup.select(div.house-item) for item in items: row { city: current_city, district: parse_district(item), title: parse_title(item), rent: parse_int(parse_price(item)), layout: parse_layout(item), area: parse_int(parse_area(item)), publish_time: parse_publish_time(item), source_url: current_url, } all_rows.append(row)把所有页面抓完后import pandas as pd df pd.DataFrame(all_rows) df df.drop_duplicates(subset[title, district, rent])drop_duplicates这一步很重要因为列表页翻页时偶尔会把前一页最后一条数据再次带到下一页不去重的话入库记录会有重复。5. 分页循环抓取控制节奏与边界5.1 翻页URL的规律大部分列表页的翻页有两种方式路径式/zufang/guangzhou/pg2/、/zufang/guangzhou/pg3/规律直观。参数式/zufang/guangzhou/?page2也很常见。我建议先翻到第二页、第三页观察URL的变化规律。如果看到pg2说明是路径式分页如果是page2就是参数式分页。还有一种更麻烦的情况——点击下一页后URL完全不变内容通过AJAX异步加载这种就要去Network面板里找XHR请求一般返回的是JSON数据可能还加密。遇到这种情况我会单独写一个抓取函数来处理。我当时遇到的情况是路径式分页循环逻辑就很简单for page in range(1, 101): page_url fhttps://www.example.com/zufang/{city_url_name}/pg{page}/ resp session.get(page_url, timeout10) if resp.status_code ! 200: print(f第{page}页失败状态码{resp.status_code}) break parse_page(resp) time.sleep(random.uniform(1, 2))5.2 递归终止条件的设置这里有个非常实际的问题你根本不知道这个城市总共有多少页。一种做法是请求首页时看分页栏的最大页码另一种做法是循环请求直到页面为空或请求失败。我推荐第二种原因是最大页码有时候也是动态变化的硬编码容易过期。终止条件用当前页面解析出的房源数为0或者连续几次请求失败empty_pages 0 while True: resp session.get(page_url, timeout10) items parse_page(resp) if not items: empty_pages 1 if empty_pages 3: break else: empty_pages 0 page_url compute_next_page(page_url, page 1)连续3次空页才终止可以避免网络抖动导致的提前结束。5.3 抓取节奏控制不要让自己变成攻击者这一步是本项目最需要克制的地方。很多人写爬虫时只顾着速度一个循环下来毫无延迟结果把目标站点惹毛了IP被封锁还是小事更糟的是对方直接升级验证码策略导致所有数据源一夜之间全废。我采用的策略是每页之间随机暂停1到2秒import time import random time.sleep(random.uniform(1, 2))不要小看这点延迟广东省21个城市、每个城市几十页加起来上千个请求如果不限速半小时之内就可能触发风控。我实测下来的安全节奏是每页1.5秒左右一个城市3-5分钟跑完整体耗时约一小时。这个速度不快但很稳。如果你打算抓取更多页或者更高频度更新建议增加代理IP池和更长的延迟。但对我来说一个晚上的时间成本完全可以接受没必要为此引入太复杂的代理体系。6. 数据清洗与入库从DataFrame到SQLite6.1 SQLite还是MySQL我在这个项目里选择了SQLite原因有三零配置Python自带sqlite3模块不需要装服务。单文件存储方便备份和迁移。数据量级完全够用——就算21个城市各抓100页每页20条总共也就几万条记录SQLite毫无压力。如果你后续要做多人协作或者线上查询可以考虑换成MySQL但核心逻辑不变。学好SQLite对入门者更友好。6.2 建表语句与写入建表时我尽量把所有字段都定义成明确类型避免后续查询时频繁转换CREATE TABLE IF NOT EXISTS house ( id INTEGER PRIMARY KEY AUTOINCREMENT, city TEXT NOT NULL, district TEXT, title TEXT, rent INTEGER, layout TEXT, area INTEGER, publish_time TEXT, source_url TEXT UNIQUE );这里给source_url加了UNIQUE约束可以在数据库层面二次防重复。如果同一条房源被多个页面抓到了INSERT时就会违反唯一约束。配合INSERT OR IGNORE重复数据就会被静默忽略import sqlite3 conn sqlite3.connect(guangdong_rental.db) cursor conn.cursor() df.to_sql(house, conn, if_existsappend, indexFalse) conn.commit() conn.close()但直接用df.to_sql有个问题它不会处理UNIQUE冲突遇到重复会抛异常。所以要更稳妥的话可以逐行插入insert_sql INSERT OR IGNORE INTO house (city, district, title, rent, layout, area, publish_time, source_url) VALUES (?, ?, ?, ?, ?, ?, ?, ?) data_tuples list(df.itertuples(indexFalse, nameNone)) cursor.executemany(insert_sql, data_tuples) conn.commit() conn.close()executemany比逐条execute快很多这也是一个经验点。6.3 清洗阶段的几个细节抓取完成后不要急着入库我先用pandas做一轮清洗df[rent] pd.to_numeric(df[rent], errorscoerce) df[area] pd.to_numeric(df[area], errorscoerce) df df.dropna(subset[rent]) df df[df[rent] 0]pd.to_numeric加errorscoerce的作用是如果某个值转不了数字就变成NaN不会报错。然后再把房租小于等于0的脏数据删掉。这类脏数据非常常见比如租金面议解析失败后变成None或者价格字段混入押一付三这类文字导致抠出非租金数字。对于发布时间我用一个简单函数归一化from datetime import datetime, timedelta def normalize_time(text): today datetime.now().date() if 今天 in text: return str(today) if 昨天 in text: return str(today - timedelta(days1)) if 天前 in text: days int(parse_int(text)) return str(today - timedelta(daysdays)) # 否则尝试匹配2025-01-12 import re match re.search(r\d{4}-\d{2}-\d{2}, text) if match: return match.group(0) return None6.4 数据验证抓完怎么知道靠不靠谱入库后别急着下一个城市先做几个快速统计看数据是否符合常识SELECT city, COUNT(*) AS cnt, AVG(rent) AS avg_rent FROM house GROUP BY city ORDER BY cnt DESC;如果某城市只有两条数据大概率是分页终止条件出了问题或者页面结构不一致导致解析失败。如果某城市的平均租金奇高或奇低要看是不是混入了商铺、厂房或者其他非住宅类房源。我跑第一轮时就发现东莞的数据里混进了一些厂房招租信息后来在字段解析里增加了对标题的过滤才算干净。7. 遇到异步加载页面时怎么办前面提到我实际抓取时遇到一个城市的列表页无法通过普通翻页拿到数据。浏览器Network面板一看原来页面滚动到底部时发起了一个XHR请求返回的是JSON字符串。这种请求的URL通常类似https://www.example.com/api/zufang/list?cityzhongshanpage3返回的JSON格式大致是{ status: 0, data: { list: [ { title: xx花园三房, rent: 2500元/月, area: 89㎡ } ] } }这时候用requests直接请求这个API地址反而比解析HTML更简单。流程是先请求列表页拿到总页数或总数。循环请求API每次换page参数。用json.loads解析再提取data.list。代码示意import json api_url https://www.example.com/api/zufang/list params { city: zhongshan, page: page, } resp session.get(api_url, paramsparams, timeout10) data json.loads(resp.text) items data.get(data, {}).get(list, [])这里要注意的是有些API会校验请求头里的X-Requested-With: XMLHttpRequest或者自定义的Referer。遇到时要先看浏览器发出的完整请求头把它抄过来。所以我一直建议不要一开始就默认所有页面都是静态HTML。正确的流程是先用浏览器开发者工具看Network确认列表是直接渲染还是XHR渲染再决定写哪种解析器。8. 避坑清单与常见故障排查这一节把整个项目过程中容易踩的坑集中列出来按出现频率排序。很多问题不是你代码写得不对而是对目标站点的行为判断失误。8.1 请求被拦截返回验证码页症状状态码200但解析出来的房源数为0或者页面里含请输入验证码字样。原因请求频率太高或UA不被信任。解决办法降低并发、加大随机延迟。换更真实的UA并补全Accept、Referer等请求头。不要一次性把21个城市连续抓完中间加入休息。8.2 数据解析不出来select返回空列表症状items为空或者select_one返回None。原因页面结构可能在不同城市之间有差异。比如广州的列表项class是house-item深圳的却是house-card。解决方法是针对每个城市单独调试不要假设全省统一。我在项目里维护了一个城市到CSS选择器的映射字典city_selector { guangzhou: div.house-item, shenzhen: div.card-item, ... }这样每个城市都能用自己对应的解析规则虽然代码多一些但稳定。8.3 入库后出现大量重复记录原因可能是页面有重复推荐位或者翻页边界导致同一条数据出现多次。解决办法在上面已经提到先drop_duplicates再在数据库层做UNIQUE约束。8.4 中途断点续抓如果你抓了10个城市后脚本挂了或者你想分成多个时段跑需要支持断点续抓。我的做法是把已完成城市记录到一个文本文件finished_cities set() if os.path.exists(finished_cities.txt): with open(finished_cities.txt, r) as f: finished_cities set(f.read().splitlines()) for city in all_cities: if city in finished_cities: continue crawl_city(city) with open(finished_cities.txt, a) as f: f.write(city \n)这个细节在数据量大时很救命避免了一次失败后从头再来的痛苦。9. 抓完数据之后从存储到可视化这才是完整项目数据落到SQLite只是个开始真正有意思的是用这些数据做什么。我当时拿到广东省各城市的租房数据后先做了三类分析9.1 城市间租金对比SELECT city, ROUND(AVG(rent), 0) AS avg_rent FROM house WHERE area BETWEEN 60 AND 100 GROUP BY city ORDER BY avg_rent DESC;限定面积区间是为了减少户型差异对均价的影响。结果基本符合直觉深圳和广州最高珠海和佛山其次粤东粤西城市则低不少。但也有一些意外比如中山某些靠近深中通道的板块租金明显被带起来这种区域性信息在数据里很直观。9.2 户型分布统计SELECT city, layout, COUNT(*) AS cnt FROM house GROUP BY city, layout ORDER BY cnt DESC;从这个结果可以看到不同城市的主力供应户型。广州和深圳的小户型占比明显偏高这和人口结构有关。9.3 简单可视化我用pandas读取SQLite结果再用matplotlib画了一个横向柱状图。这一步很简单就不展开讲库了重要的是数据本身质量要可靠否则图再好看也没有意义。10. 抓取合规与长期可维护性的思考最后说点实际的。做这类项目时我始终给自己设三个底线只抓公开可见的数据不碰需要登录才能看的内容更不绕过验证码。控制访问频率不给目标站点制造压力遵守robots.txt中的抓取约定和站点公开条款。抓下来的数据仅作个人学习与参考不用于商用、不对外批量发布。这三个底线不是大道理而是实用主义。因为你一旦越界轻则IP被封数据断供重则惹上法律麻烦。做技术练手没必要把自己置于风险之中。另外爬虫脚本的长期可维护性也很重要。我过两个月再回来看这个项目发现城市列表变了、页面结构变了脚本大概率跑不通。所以我在代码里留了一个简单的CONFIG区把城市列表、URL模板、选择器都集中放在文件顶部方便下次改。这是一个好习惯——爬虫代码的生命周期短尽量把易变的部分收敛到一处降低维护成本。提示这类自用数据抓取脚本建议单独建虚拟环境固定依赖版本避免两三个依赖升级后脚本彻底不能用。如果你现在正准备做类似的抓取项目我的建议是先手动抓一个城市、确认解析和入库链路完全通了再扩展到全省。别一上来就跑全量不然全省21个城市里只要有三个城市结构和预期不一致你调试的时间会远超写代码的时间。慢就是快。