简介基于Python的链家二手房信息爬取与数据库存储设计源码是一套集网页数据抓取、图片自动下载与数据库持久化于一体的实战项目。项目以链家二手房列表页为切入点自动解析房源标题、价格、地理位置及房屋详情等核心字段并将整理后的数据按预定格式导入MySQL等数据库而抓取的房源图片则同步保存到本地。资源包共含33个文件包括30张爬取所得的jpg图片、1个Python主脚本、1个SQL表结构脚本和1份安装运行说明压缩包约816KB结构紧凑。该项目已累计有174人学习下载适合正在学习爬虫、数据库设计或对房产数据采集有需求的开发者与研究者。通过参考源码及文档可快速复现整套采集流程并为后续的二手房市场数据分析、备份管理提供有力支撑。1. 链家二手房爬虫与数据库存储先看清这个项目的真实边界如果你搜过“链家爬虫源码”大概率会看到一堆跑不通的旧代码。这个标题真正想解决的问题不是“把网页抓下来”而是从房源列表页一路到 MySQL 表里的完整链路解析字段、清洗文本、设计表结构、处理重复数据和反爬。项目的复杂度不高但坑集中在数据标准不统一和请求频率控制上——链家的列表页是服务端渲染的requests 直接拿 HTML 就能用不需要 Selenium这是先决条件。适合有 Python 基础、想完整走一遍“爬虫 数据库存储”全流程的从业者也适合做二手房价数据分析的人拿来当数据管道的地基。下面按我实际做过的方案拆开讲。2. 选型与最小骨架requests 加 BeautifulSoup 为什么够用2.1 链家列表页是服务端渲染先确认这一点再动手判断一个站点能不能用 requests 硬抓不要凭经验猜打开浏览器开发者工具看 Network 面板。链家二手房列表页https://xx.lianjia.com/ershoufang/返回的 HTML 里直接带有房源标题、单价、总价、小区名、户型、面积、朝向等完整字段不需要等待异步接口返回。这意味着 requests.get 拿到的响应文本就是最终结果解析成本最低。我见过有人一上来就上 Selenium 模拟浏览器结果被资源加载拖慢还更容易触发风控。正确顺序是先用 curl 或 requests 打印响应状态码和前 500 字确认页面结构是服务端渲染再开始写解析。链家部分字段做过字体反爬比如有的页面房源标题里的数字会用自定义字体混淆但列表页的核心字段——总价、单价、面积——目前是明文可以放心用 CSS 选择器提取。另一个需要确认的点是编码。响应头里 charset 是 utf-8但偶尔会因为压缩传输产生乱码。requests 的 Response.apparent_encoding 可以兜底不过更稳定的做法是在请求头里显式声明 Accept-Encoding: gzip, deflate让 requests 自动解压避免拿到压缩流后解析出错。2.2 从列表页到结构化字典最小可用代码骨架下面这段是抓取单页列表并解析出房源核心字段的最小实现字段覆盖了后续数据库设计的大多数列。import requests from bs4 import BeautifulSoup 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-Language: zh-CN,zh;q0.9, Referer: https://www.lianjia.com/, } def fetch_page(url: str) - str | None: 抓取列表页 HTML失败返回 None。 try: resp requests.get(url, headersHEADERS, timeout10) if resp.status_code 200: return resp.text if resp.status_code 403: print(f[警告] {url} 被拒绝可能触发了频率限制) return None except requests.RequestException as exc: print(f[错误] 请求 {url} 异常: {exc}) return None def parse_detail_page(html: str) - list[dict]: 从列表页 HTML 中抽取房源字典列表。 soup BeautifulSoup(html, html.parser) items [] for li in soup.select(ul.sellListContent li.clear): title_tag li.select_one(.title a) if title_tag is None: continue title title_tag.get_text(stripTrue) link title_tag.get(href, ) # 位置信息: 小区 / 商圈 / 行政区用 split 拆更稳 position li.select_one(.positionInfo) if position: pos_text position.get_text(separator|, stripTrue) parts [p for p in pos_text.split(|) if p] else: parts [] # 房屋信息: 户型 / 面积 / 朝向 / 装修 / 楼层 house_info li.select_one(.houseInfo) if house_info: house_text house_info.get_text(separator|, stripTrue) h_parts [p for p in house_text.split(|) if p] else: h_parts [] # 总价与单价 total_price li.select_one(.totalPrice) unit_price li.select_one(.unitPrice) items.append({ title: title, link: link, district: parts[0] if len(parts) 0 else , area_name: parts[1] if len(parts) 1 else , total_price: total_price.get_text(stripTrue) if total_price else , unit_price: unit_price.get_text(stripTrue) if unit_price else , house_info: house_info.get_text(|, stripTrue) if house_info else , h_parts: h_parts, }) return items这段代码里有几个位置值得说明。第一User-Agent用的是 Chrome 的完整 UA 字符串而不是简写的python-requests后者在服务器端很容易被识别为爬虫。第二positionInfo用|做分隔符再拆是因为链家在这个容器里把“行政区 / 商圈 / 小区”用斜杠分隔直接get_text()会得到一长串难处理的文本先按标签分段再拆成功率更高。第三totalPrice和unitPrice取到的字符串带“万”和“元/平”单位入库前必须在清洗阶段转成浮点数这件事放到数据库设计一章一起处理。fetch_page里的超时设为 10 秒链家正常响应通常在 300-800 毫秒超过 10 秒大概率是网络异常或被限流没必要继续等。如果返回 403说明 IP 已被临时限制这时应该停止抓取而不是加重试频率等 5-10 分钟再继续。这个判断逻辑直接影响后面调度器的设计。2.3 分页游标看懂链家列表页的翻页规则链家二手房列表页的 URL 长这样/ershoufang/pg2/。第一页没有pg段第二页开始用pg{n}/标识页码。这个规律意味着可以用一个简单的计数器拼接 URL不需要解析下一页的链接。def build_page_url(city_domain: str, page_num: int) - str: 生成列表页 URL。城市域名形如 https://bj.lianjia.com。 if page_num 1: return f{city_domain}/ershoufang/ return f{city_domain}/ershoufang/pg{page_num}/ def crawl_pages(city_domain: str, max_pages: int): 顺序爬取前 max_pages 页遇到 403 直接中断。 all_items [] for page in range(1, max_pages 1): url build_page_url(city_domain, page) html fetch_page(url) if html is None: break items parse_detail_page(html) if not items: print(f[停止] 第 {page} 页无数据可能是页数越界或反爬介入) break all_items.extend(items) print(f[完成] 第 {page} 页累计 {len(all_items)} 条) return all_itemsmax_pages的上限要看目标城市的房源总量。北京链家二手挂牌量通常在 4 万套左右每页 30 条全量也就 1300 多页但你大概率不需要抓全量。按区域筛选 URL比如/ershoufang/chaoyang/pg2/可以只抓某个商圈更适合做定向分析。这里的关键参数是max_pages和请求间隔——fetch_page里目前没有 sleep生产环境必须加否则第 30 页左右就会触发验证码这部分在避坑章细说。3. 数据库存储设计字段怎么拆、表怎么建才不用返工3.1 从房源详情反推字段清单先建模再建表很多爬虫项目死在第一步抓下来是乱糟糟的字典往数据库里灌的时候发现要么字段不够要么格式冲突。正确做法是拿到一条完整房源记录后先人工把字段列出来再设计表结构。链家二手房列表页能提供的字段包括标题、链接、行政区、商圈、小区名、户型、面积、朝向、装修情况、楼层、总价、单价以及houseInfo里混装的其他描述。详情页还能补充挂牌时间、房本年限、电梯、学区等但那是二级爬虫的事。对于第一版我建议把表设计成两个部分核心字段单列成列不确定的杂项全部塞进extra_json。理由很直接——链家的展示字段会变今天多了个“车位配比”明天改了“供暖方式”如果每个都加列迁移成本太高存成 JSON 文本查询时用 JSON 函数解析对第一版完全够用。核心表设计如下CREATE TABLE IF NOT EXISTS lianjia_house ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, house_code VARCHAR(64) NOT NULL COMMENT 房源唯一编码, 取自链接尾部, title VARCHAR(255) NOT NULL, city VARCHAR(32) NOT NULL DEFAULT 未知, district VARCHAR(32) NOT NULL DEFAULT , bizcircle VARCHAR(32) NOT NULL DEFAULT , community_name VARCHAR(128) NOT NULL DEFAULT , layout VARCHAR(64) NOT NULL DEFAULT COMMENT 户型, 如 2室1厅1卫, area_sqm DECIMAL(8, 2) NOT NULL DEFAULT 0.00 DEFAULT 0 COMMENT 建筑面积, 单位平米, orientation VARCHAR(32) NOT NULL DEFAULT COMMENT 朝向, decoration VARCHAR(16) NOT NULL DEFAULT COMMENT 装修: 精装/简装/毛坯, floor_desc VARCHAR(64) NOT NULL DEFAULT COMMENT 楼层描述原文, total_price_wan DECIMAL(10, 2) NOT NULL DEFAULT 0.00 COMMENT 总价, 单位万, unit_price_yuan DECIMAL(10, 0) NOT NULL DEFAULT 0 COMMENT 单价, 单位元/平米, link VARCHAR(255) NOT NULL DEFAULT , extra_json TEXT COMMENT 其余字段的JSON快照, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_house_code (house_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT链家二手房房源表;几个字段设计上的取舍说明。house_code是从详情链接尾部提取的房源编号比如https://bj.lianjia.com/ershoufang/101234567890.html里的数字串它是天然的业务主键比自增 id 更适合做去重。total_price_wan用 DECIMAL(10,2) 而不是 INT是因为链家显示“589万”清洗后是 589.00但有的房源可能有小数点比如“289.5万”unit_price_yuan用 DECIMAL(10,0) 是因为单价显示为整数“38914元/平”直接保留整数即可。area_sqm保留两位小数链家面积有时显示为“89.6㎡”浮点误差用 DECIMAL 避免。extra_json这个设计在改动频繁的爬虫项目里是后悔药。链家列表页的houseInfo字段有时带装修、有时带入户年份与其为每个可能出现的字段建列不如以 JSON 形式原样存一份需要哪个字段再单独解析。这不影响后续做分析——MySQL 8.0 的JSON_EXTRACT函数可以直接查询。3.2 清洗规则单位、空白、脏文本一次处理完网页抓下来的字符串不可能直接入库。我一般写一个独立的clean_house_record函数把解析出的原始字典清洗成符合表结构的字段。import re import json def clean_price(price_text: str) - float | None: 把 589万 或 289.5万 转成浮点数, 失败返回 None。 if not price_text: return None # 只保留数字和小数点, 兼容 589万 与 总价589万 等变体 match re.search(r(\d(?:\.\d)?), price_text.replace(,, )) return float(match.group(1)) if match else None def clean_unit_price(unit_text: str) - int | None: 把 38914元/平 转成整数。 if not unit_text: return None match re.search(r(\d(?:\.\d)?), unit_text.replace(,, )) return int(float(match.group(1))) if match else None def clean_area(area_text: str) - float | None: 把 89.6㎡ 转成浮点数。 if not area_text: return None match re.search(r(\d(?:\.\d)?), area_text.replace(,, )) return float(match.group(1)) if match else None def extract_house_code(link: str) - str: 从详情页链接中提取房源编号, 用作去重键。 match re.search(r/ershoufang/(\d)\.html, link) return match.group(1) if match else link def clean_house_record(raw: dict, city: str) - dict: 把解析字典转换成插入数据库的干净记录。 h raw.get(h_parts, []) # h_parts 典型形如: [2室1厅1卫, 89.6㎡, 南 北, 精装, 中楼层/共28层] layout h[0] if len(h) 0 else area clean_area(h[1]) if len(h) 1 else None orientation h[2].replace( , /) if len(h) 2 else decoration h[3] if len(h) 3 else floor_desc h[4] if len(h) 4 else return { house_code: extract_house_code(raw.get(link, )), title: raw.get(title, ), city: city, district: raw.get(district, ), bizcircle: raw.get(area_name, ), community_name: raw.get(community_name, ), layout: layout, area_sqm: area or 0.00, orientation: orientation, decoration: decoration, floor_desc: floor_desc, total_price_wan: clean_price(raw.get(total_price, )) or 0.00, unit_price_yuan: clean_unit_price(raw.get(unit_price, )) or 0, link: raw.get(link, ), extra_json: json.dumps({house_info_raw: raw.get(house_info, )}, ensure_asciiFalse), }清洗函数里最值得留意的是正则写法。(\d(?:\.\d)?)匹配整数或带小数的数字replace(,, )处理链家偶尔展示的千分位分隔符比如“38,914元/平”这种格式。把清洗逻辑独立成函数而不是在解析时顺手做是为了后续接入详情页爬虫时能复用——详情页返回的字段更多但清洗规则是一致的。3.3 批量插入与去重INSERT IGNORE 还是 ON DUPLICATE KEY UPDATE数据入库的阶段最常犯的错是一条一条 insert。链家一个城市全量几万条逐条插入要几十分钟批量插入只要几秒。但批量插入必须处理主键冲突这里有个选型问题第一次全量抓取时用INSERT IGNORE最简单重复的house_code直接丢弃后续增量更新时应该用ON DUPLICATE KEY UPDATE更新价格等易变字段。import pymysql def batch_insert(records: list[dict], use_upsert: bool False) - int: 批量写入房源表, use_upsert 控制是否更新已有记录。 if not records: return 0 config { host: 127.0.0.1, port: 3306, user: root, password: your_password, database: house_db, charset: utf8mb4, } conn pymysql.connect(**config) try: with conn.cursor() as cursor: keys [ house_code, title, city, district, bizcircle, community_name, layout, area_sqm, orientation, decoration, floor_desc, total_price_wan, unit_price_yuan, link, extra_json, ] placeholders , .join([%s] * len(keys)) sql fINSERT INTO lianjia_house ({, .join(keys)}) VALUES ({placeholders}) if use_upsert: sql ON DUPLICATE KEY UPDATE total_price_wanVALUES(total_price_wan), \ unit_price_yuanVALUES(unit_price_yuan), update_timeNOW() values [ [r.get(k, ) for k in keys] for r in records ] affected cursor.executemany(sql, values) conn.commit() return affected finally: conn.close()参数说明executemany预处理后批量执行相比逐条execute能快一个数量级。use_upsert参数控制增量场景的行为——全量抓取传 False用 INSERT IGNORE 的语义跳过重复每日增量传 True已存在的房源只更新总价和单价其余静态字段如户型、朝向不变。注意这里没有把ON DUPLICATE KEY UPDATE写成INSERT IGNORE是因为二手房的价格是动态变化的今天挂牌 589 万下周可能调成 579 万忽略掉这 10 万的价差数据分析结果就是错的。4. 链家爬取避坑指南编码、脏文本、反爬的 5 条实战记录4.1 编码乱码控制台正常但文件里是锟斤拷现象用resp.text打印 HTML 正常写入 CSV 后用 Excel 打开全是乱码或者 MySQL 里存的中文变成“???”。原因链家响应头没有显式指定 charsetrequests 默认按 ISO-8859-1 解码导致中文全部变成乱码。有些人的代码在 print 时恰好被终端转码“掩盖”了问题写入文件时才暴露。解决在请求返回后强制指定编码。链家页面实际是 UTF-8所以resp.encoding utf-8要在拿到响应后立刻设置再取resp.text。另外 MySQL 连接参数必须带charsetutf8mb4建表语句也要带DEFAULT CHARSETutf8mb4否则存入的 emoji 字符比如户型里的特殊符号会被截断。4.2 字段缺项导致解析越界现象parse_detail_page偶尔报IndexError: list index out of range或者几条房源的小区名、商圈是空的。原因链家列表页存在少量广告位和失效房源。广告位的li标签没有.houseInfo或.positionInfo元素解析函数按固定下标取parts[0]时就越界。另外链家对部分房源隐藏了商圈信息只显示到行政区级别。解决解析时先判断元素是否存在再取下标。我在parse_detail_page里用if len(parts) 0做保护就是为了处理这种结构性缺项。更保险的做法是在clean_house_record里对空字符串给默认值不让脏数据在插入时才崩溃。入库后也可以跑一个 SQL 查空值比例确认是普遍现象还是个别记录异常。4.3 请求过快触发验证码403 后页面变成滑块现象连续跑 30-40 页后fetch_page返回 403换浏览器看同一 URL 出现滑块验证需要人工拖动才能继续。原因链家对短时间高频请求有 IP 维度限流。requests 的默认行为是每次请求之间间隔极短只要连续访问十几页很容易触发风控。这不是封 IP而是临时限制几小时后自动解除。解决在每页请求之间加随机 sleep。我一般用time.sleep(random.uniform(1.5, 3.5))既避免规律性间隔被识别又能把单页请求频率控制在阈值以下。另一个有效手段是轮换User-Agent准备一个列表随机取用减少指纹一致性。注意不要用代理池——链家对代理 IP 的容忍度更低尤其是数据中心 IP命中即封。这个方案稳但跑全量几万条需要 1-2 小时可接受。4.4 房源价格单位不统一有的“万”有的“元/平”现象入库后total_price_wan有值但取出来分析时发现部分记录价格少了一位数unit_price_yuan也出现个位数的异常值。原因链家在列表页对总价和单价使用了不同的展示格式——总价固定是“589万”单价“38914元/平”看起来统一。但个别房源比如车位或商业性质会显示成“总价45万元”或“单价1.2万元/平”正则(\d(?:\.\d)?)能抓到数字但“万元”和“元”差了 10000 倍不做单位换算就会出错。解决清洗函数里增加单位判断。clean_price检测文本是否含“万”有则直接取数如果有“亿”先乘 10000 再存单价部分如果不含“元/平”按文本是否含“万”做二次换算。这个判断不能省链家二手房里确实会出现总价上亿的豪宅页面。4.5 增量更新把下架房源留在库里现象今天抓 500 条明天再抓昨天 480 条还在但库里没标记哪些已经下架统计挂牌量时数字虚高。原因二手房是增量变化的商品房子卖掉或下架后列表页就不再展示但数据库里旧记录还在。如果只做插入和更新没有“失效检测”表里的数据会随时间推移包含大量已下架房源均价分析也就不准。解决每次全量抓取后把本次出现的house_code集合与数据库已有集合做对比找出“上次有、这次无”的记录给它们打is_active0标记。这比删除好——保留历史快照分析时可以按is_active过滤当前在售房源。MySQL 更新时用UPDATE lianjia_house SET is_active0 WHERE city%s AND house_code NOT IN (...)注意 IN 列表长度有限制超过 1000 项要分批处理。5. 增量更新与限速调度让爬虫按天跑而不是跑一次就废5.1 按页游标和已抓集合控制增量范围全量爬虫写出来不难难的是让它每天自动跑增量。链家二手房列表页的排序不是完全稳定的——同一套房源可能因为调价在列表里换位置所以“只看第一页”的增量策略会漏数据。我采用的做法是每天抓取每个目标区域的前 10 页约 300 条用house_code集合做去重。这个量级对城市级分析足够因为真正剧烈变动的房源调价、新上架、下架基本都出现在排序靠前的位置。def daily_incremental(domain: str, regions: list[str], page_limit: int 10): 按区域跑增量任务, regions 形如 [chaoyang, dongcheng]。 all_records [] for region in regions: for page in range(1, page_limit 1): url build_region_page_url(domain, region, page) html fetch_page(url) if html is None: break items parse_detail_page(html) if not items: break cleaned [clean_house_record(item, citydomain.split(.)[0]) for item in items] all_records.extend(cleaned) sleep_after_request() # 直接入库, 已存在的房源走 ON DUPLICATE KEY UPDATE batch_insert(all_records, use_upsertTrue) # 标记本次未出现的房源为失效 mark_inactive_records(domain, all_records)build_region_page_url和全局列表页不同区域页 URL 是https://{city}.lianjia.com/ershoufang/{region}/pg{n}/第一页没有pg段这里不再重复贴代码。增量场景下use_upsertTrue的关键作用是修正价格波动——昨天这个房 589 万今天调成 579 万ON DUPLICATE KEY UPDATE 能让库里的价格跟随真实挂牌变动。mark_inactive_records的参数校验也很重要如果当天任务失败或者抓到的记录数异常少就不该做失效标记否则会误伤大量正常房源。5.2 限速、UA 轮换与失败重试的工程参数增量任务挂在定时器上每跑一次都伴随反爬风险。我常用的调度策略是每次请求后随机休眠 1.5-3.5 秒重试策略用指数退避——第一次失败等 5 秒重试第二次 10 秒第三次直接放弃该页并记录日志。这里有个容易被忽视的细节重试前的等待不能固定固定间隔比随机间隔更容易被判为机器行为。import time import random UA_POOL [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36, Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/121.0, ] def get_headers() - dict: return { User-Agent: random.choice(UA_POOL), Accept-Language: zh-CN,zh;q0.9, } def sleep_after_request() - None: time.sleep(random.uniform(1.5, 3.5)) def fetch_page_with_retry(url: str, max_retries: int 3) - str | None: 带指数退避的页面抓取, 返回 None 表示彻底失败。 for attempt in range(max_retries): resp requests.get(url, headersget_headers(), timeout10) if resp.status_code 200: return resp.text if resp.status_code in (401, 403): wait (2 ** attempt) * 5 print(f[限流] {url} 返回 {resp.status_code}, {wait}s 后重试) time.sleep(wait) continue time.sleep(2) return None这段代码里UA 池每次随机取用避免同一个 UA 长时间高频出现限流的重试等待是2 ** attempt * 5即 5 秒、10 秒、20 秒三次失败后放弃该页继续下一页。600 页的增量任务按每页 sleep 2.5 秒算大约 25 分钟跑完刚好在限流阈值可控范围内。日常观察如果连续 5 页都返回 403应该主动停止整个任务而不是单页重试——说明 IP 已经进入冷却期再跑只会加重限制。5.3 调度与日志定时任务不能只有成功路径增量爬虫跑在服务器上挂了没有任何输出就等于白跑。我建议至少做三件事写结构化日志到文件、把任务结果写入一张crawl_log表、失败时输出告警信息。日志字段最少包含任务开始时间、抓取页数、新增条数、更新条数、失败页码列表。import logging logging.basicConfig( filenamecrawl.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, ) def log_crawl_result(task_name: str, page_count: int, total: int): logging.info(f任务{task_name} 页数{page_count} 记录数{total})日志文件会告诉你限流发生的规律如果正好在第 40 页左右开始 403说明当前页数阈值是上限要把每次任务的页数限制从 100 降到 60而不是盲目加 UA。Cron 定时任务用0 3 * * *这类凌晨时段跑增量避开白天用户访问高峰风控阈值会放宽不少。6. 跑完一版之后验证数据质量并做最小可用分析6.1 入库后先查这四条 SQL别急着分析数据入库只是开始多数人栽在“分析结果异常但不知道是爬虫问题还是业务问题”。我每次跑完增量第一件事是跑几个校验查询。缺失率要在 1% 以下单价离群值用 3-sigma 找出来看一眼同house_code重复记录数必须为 0价格字段出现 0 或负数说明清洗环节有漏。-- 1. 检查字段缺失率 SELECT COUNT(*) AS total_rows, SUM(area_sqm 0) AS zero_area, SUM(total_price_wan 0) AS zero_price, SUM(community_name ) AS empty_community FROM lianjia_house WHERE city bj; -- 2. 检查重复 house_code SELECT house_code, COUNT(*) AS cnt FROM lianjia_house GROUP BY house_code HAVING cnt 1; -- 3. 检查单价离群值: 偏离均值 3 个标准差 SELECT district, area_sqm, total_price_wan, unit_price_yuan FROM lianjia_house WHERE unit_price_yuan ( SELECT AVG(unit_price_yuan) 3 * STDDEV(unit_price_yuan) FROM lianjia_house ) LIMIT 20;这些查询跑完基本能定位清洗逻辑的问题。比如说zero_area比例突然从 0% 涨到 5%大概率是链家改版了houseInfo的 DOM 结构h_parts[1]不再是面积字段。这时候优先检查页面结构而不是清洗函数——链家改版时旧解析规则会集体失效这是爬虫项目的常态。6.2 把存储数据接一个简单的挂牌均价分析数据落库且验证通过后可以直接用 SQL 算分区间的挂牌均价。这个结果比第三方房价平台更新更快也更能反映真实挂牌趋势。SELECT district, COUNT(*) AS listing_count, ROUND(AVG(total_price_wan), 2) AS avg_total_price, ROUND(AVG(unit_price_yuan), 0) AS avg_unit_price, ROUND(AVG(area_sqm), 1) AS avg_area FROM lianjia_house WHERE city bj AND is_active 1 GROUP BY district ORDER BY avg_unit_price DESC;is_active 1这个过滤条件很关键它保证统计的是当前挂牌房源而不是历史累积。把这张表导出成 CSV再接 Python 的 pandas 或者直接套可视化模板就能生成区域挂牌价热力图。这套管道跑通后每周手动触发一次增量任务数据就在持续更新——不需要重写爬虫只是调参和换区域。我个人的习惯是每三个月复查一次解析规则和表结构因为链家的页面结构平均半年会有一次调整。全文抓住一个原则解析和存储解耦清洗独立成函数表设计留 JSON 扩展位这样页面改版时只动一个模块数据层不用跟着返工。希望这套方案能帮你在二手房数据方向少走几条弯路。本文还有配套的精品资源点击获取