简介：针对携程酒店数据的Java爬虫项目，面向需要采集酒店房价、房型等公开信息的开发者和数据分析人员，也适合作为Java网络编程、Jsoup/HttpClient等爬虫技术的实战练手。压缩包共34个文件，核心为23个Java源码文件，对应Eclipse工程结构，src目录存放可运行代码，libs附带4个jar依赖包，另有properties、classpath等配置文件以及txt说明文档，全套约1.59MB；通过配置参数可灵活调整爬取类型。目前已有666人学习下载。通过这套工程，读者可以快速理解爬虫抓取、解析、存储的基本流程，掌握携程反爬应对思路，并可将采集结果对接酒店管理系统或用于后续数据分析。项目结构完整，导入Eclipse后即可对照调试，适合有一定Java基础、希望落地爬虫项目的学习者。

1. 爬某旅行平台的酒店数据，CTripSpider 到底在爬什么

标题里的 CTripSpider.zip 看起来像一份网上下载的爬虫工程，但落到实际开发，它解决的核心问题是：把某旅行平台上某个城市、某个日期区间的酒店数据批量抓下来，整理成结构化表格。常见输出字段包括酒店ID、酒店名、星级、评分、点评数、最低含税价、商圈、经纬度、房型与价格。对于做酒店比价、竞品分析、出行产品运营的人来说，这份数据意味着不用再人工挨个查房价，可以批量看到市场真实供给和价格分布。

适合两类人：一类是想研究某旅行平台页面结构、练熟 Scrapy 的爬虫学习者；另一类是需要酒店价格数据做分析的从业者。需要先说清楚的是：爬虫不是目的，数据才是。整个工程值不值得投入，看三件事——项目能不能快速搭起来，数据解析能不能稳定，跑起来之后会不会失控。后面每一章都按这个顺序展开。

2. 起步：用 Scrapy 搭出最小跑通的酒店搜索请求

2.1 为什么这一行用 Scrapy 而不是 requests 一把梭

技术选型是爬虫项目里最容易翻车的一步。很多人拿到需求后的第一反应是先写个 requests 循环：遍历城市、组合日期、发请求、用 BeautifulSoup 解析、存 CSV。这种方式在做十几个页面时完全够用，但换成某旅行平台这种动态页面后，问题会迅速放大。

第一是并发。requests 写循环默认是串行，要提速就得自己开线程池或协程，而酒店爬虫一跑就是几万条请求，线程池里的连接管理和超时处理都得自己写。第二是去重。某旅行平台的酒店列表页和详情页之间存在重复入口，同一个酒店可能从列表页、搜索结果、推荐模块被请求好多次，没有全局去重，等于拿有效请求量去换重复下载。第三是重试和日志。网络抖动、接口临时 500、被风控返回 403，这些在长跑中几乎是必然事件，requests 方案没有内置的自动重试，也没有爬取统计，出了问题只能从日志文件里翻。

Scrapy 恰好把这些问题都收到框架里。它的调度器负责任务排队，去重指纹自动生成，下载中间件里可以挂超时、重试、随机延迟，Item Pipeline 统一处理数据清洗和入库；更重要的是 Scrapy 的统计收集器会记录每个状态码的数量，跑完一批数据后，你一眼就能看到有多少请求成功、多少被拦截。对酒店数据爬虫这种中长周期任务，这些能力比语法简单重要得多。

用一个表格对比会更直观：

我一般不会建议新手为了“轻量”绕过 Scrapy，因为酒店数据爬虫的后续扩展几乎必然要加断点续爬、加定时任务、加增量更新，这些在 Scrapy 里都是配置项，在纯 requests 里就变成一个个自己写的模块，维护成本是递增的。当然，如果只是抓一两个页面做演示，requests 没有问题；只要目标是“能自己跑一个月”，直接选 Scrapy 更值得。

2.2 初始化项目与 settings 里的四组关键参数

确认选型后，先建工程。命令很简单：

scrapy startproject ctrip_spider cd ctrip_spider scrapy genspider hotel_list hotels.example.com

生成之后先不用急着写解析逻辑，第一步是改settings.py。这个文件是整个爬虫的“黑匣子”，很多人在这一步吃过亏：默认设置直接跑，结果请求量一大就被风控。

下面是某旅行平台酒店爬虫场景下我常用的一份最小配置：

# settings.py BOT_NAME = "ctrip_spider" # 并发与延迟：某旅行平台对并发敏感，先保守后放开 CONCURRENT_REQUESTS = 4 CONCURRENT_REQUESTS_PER_DOMAIN = 2 DOWNLOAD_DELAY = 2.5 RANDOMIZE_DOWNLOAD_DELAY = True # 重试：只在明确网络错误时重试，不要对 403 无限重试 RETRY_ENABLED = True RETRY_TIMES = 3 RETRY_HTTP_CODES = [500, 502, 503, 504, 522, 524, 408] # User-Agent 必须换掉 Scrapy 默认值 USER_AGENT = ( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/120.0 Safari/537.36" ) COOKIES_ENABLED = True # 关闭 Robots 协议限制前，先确认你的抓取行为符合目标站点的访问规则 ROBOTSTXT_OBEY = False

这里最关键的是三组参数。DOWNLOAD_DELAY是每次请求之间的基础间隔，单位秒；RANDOMIZE_DOWNLOAD_DELAY会让实际延迟变成 0.5 倍到 1.5 倍的一个随机值，避免请求间隔呈现出机器般的规律性。CONCURRENT_REQUESTS_PER_DOMAIN控制同时发往同一个域名的并发数，对某旅行平台这种对访问频率敏感的站点，我一般先给 2，确认没触发风控再往上加。

RETRY_HTTP_CODES很多人会漏掉。默认情况下 Scrapy 对 403 这类状态码不会重试，但如果你把 403 加进重试列表，就可能出现越重试越被封的局面。我的习惯是只重试明确的服务器错误码，比如 500、502、503、504，碰到 403 说明当前环境已经被风控盯上，应该降速而不是硬冲。USER_AGENT也是必改项，Scrapy 默认的 UA 在很多反爬系统里是“秒识别”的，换成完整浏览器 UA 后，配合Referer构成最小可信头。

2.3 写第一个能请求到列表页的最小 Spider

工程建好后，写一个只负责“把列表页请求回来、确认页面状态”的 Spider。不要一上来就写解析，很多问题出在“页面根本没抓到”却被误判成“解析写错了”。

# spiders/hotel_list.py import scrapy class HotelListSpider(scrapy.Spider): name = "hotel_list" def __init__(self, city_id="2", check_in="2024-05-01", check_out="2024-05-02", *args, **kwargs): super().__init__(*args, **kwargs) self.city_id = city_id self.check_in = check_in self.check_out = check_out def start_requests(self): # 示例域名，实际运行时替换为某旅行平台搜索页地址 url = ( "https://hotels.example.com/hotel/list" f"?cityId={self.city_id}" f"&checkIn={self.check_in}" f"&checkOut={self.check_out}" ) yield scrapy.Request( url, headers={ "User-Agent": ( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/120.0 Safari/537.36" ), "Referer": "https://hotels.example.com/", }, callback=self.parse, errback=self.on_error, ) def parse(self, response): # 第一版只确认页面状态，先不做字段解析 self.logger.info(f"status: {response.status}, length: {len(response.text)}") # 判断是否被引导到验证码页 if "captcha" in response.text.lower(): self.logger.warning("captcha page detected, stop spider") return def on_error(self, failure): self.logger.error(f"request failed: {failure.request.url}")

这段代码里有几个值得注意的点。city_id通过命令行参数传入，因为某旅行平台不同城市对应不同的城市ID，把城市做成参数之后，一个 Spider 可以跑多个城市，不用复制代码。URL 里的checkIn和checkOut也是必带参数，某旅行平台酒店的列表和房价都跟入住日期强相关，不带日期参数返回的数据可能是不完整的。

on_error是很多新手会忘掉的回调。Scrapy 里网络层异常不会走parse，而是走errback，如果只在parse里打印日志，超时和连接失败就像石头丢进水里没声音。加上这个回调后，跑一轮就能看到失败请求的 URL 和异常类型，后续排查会省很多时间。

跑一下看看结果：

scrapy crawl hotel_list -a city_id=2 -a check_in=2024-05-01 -a check_out=2024-05-02

如果控制台输出status: 200, length: 省略，说明请求链路已经通了。这一步先停在这里，下一步再谈数据解析。

3. 从列表页到结构化字段：JSON 接口提取与详情页解析

3.1 别解析 HTML：找到列表页背后的 JSON 接口

某旅行平台的酒店列表页是典型的异步渲染页面。浏览器地址栏能打开完整列表，但用爬虫拿到同一 URL 的 HTML 后，可能只能看到页面的空壳框架，酒店数据不在里面。很多人在这一步卡住，误以为是自己请求头写错了，其实真正的问题是想错了数据源。

常见的做法是打开浏览器开发者工具，切到 Network 面板，过滤 XHR 请求类型，再切换一次酒店城市和日期，观察哪个接口返回了酒店数组。某旅行平台列表页背后的数据接口通常返回一段 JSON，常见的字段结构类似：

{ "hotelList": [ { "hotelId": 1234567, "name": "示例酒店", "star": "5", "score": 4.7, "commentCount": 2381, "minPrice": 489, "address": "示例路88号", "businessZone": "市中心" } ], "totalCount": 320 }

注意里面是minPrice这种直接可用的数值，而不是“¥489起”这种带货币符号的展示文案。JSON 接口拿到的就是数据类型，省去了清洗的麻烦。

拿到接口 URL 之后，把请求从 HTML 列表页换成这个接口：

class HotelListSpider(scrapy.Spider): name = "hotel_list" def start_requests(self): api_url = ( "https://hotels.example.com/api/hotel/list" f"?cityId={self.city_id}" f"&page=1" f"&checkIn={self.check_in}" f"&checkOut={self.check_out}" ) yield scrapy.Request( api_url, headers=self._build_headers(), callback=self.parse_list, ) def parse_list(self, response): data = response.json() hotels = data.get("hotelList", []) total_count = data.get("totalCount", 0) self.logger.info(f"page 1 got {len(hotels)} hotels, total {total_count}") for hotel in hotels: yield { "hotel_id": hotel["hotelId"], "name": hotel.get("name"), "star": hotel.get("star"), "score": hotel.get("score"), "comment_count": hotel.get("commentCount"), "min_price": hotel.get("minPrice"), "address": hotel.get("address"), "business_zone": hotel.get("businessZone"), }

response.json()是 Scrapy 2.4 之后内置的方法，如果响应内容不是合法 JSON 会抛异常。碰到接口返回 HTML 的情况，先用self.logger.error(response.text[:200])打一段响应头，大概率能看出来是登录态失效被重定向到了别的页面。这里我把列表和详情拆成两个 Spider，列表落库后再由详情 Spider 从数据库读hotel_id逐个补齐字段，这样两端能独立重跑，也更容易定位是列表抓取的问题还是详情解析的问题。

如果你更喜欢单 Spider 方案，也可以在parse_list里直接yield scrapy.Request(url, callback=self.parse_detail, meta={"hotel_id": hotel_id})，Scrapy 调度器会把列表页和详情页请求排队处理。代价是这个 Spider 会同时承担两种解析逻辑，日后期望越高，拆开维护越舒服。

3.2 详情页字段：用 script 里的初始化数据而不是正则抠页面

列表接口能拿到的字段已经不少，但酒店开业时间、装修时间、酒店简介、经纬度、附近地标这类信息，往往只在详情页出现。正常思路是请求详情页，然后从 HTML 里提取。但要避免用正则去硬抠页面上的展示文本，某旅行平台的详情页里同一个字段可能在多个地方重复出现，正则会带来大量误匹配。

某旅行平台的详情页里有一段初始化的脚本变量，里面其实是一个大 JSON。把这一段提取出来再解析，命中率和稳定性远高于抠 HTML 标签。

# spiders/hotel_detail.py import json import re import scrapy class HotelDetailSpider(scrapy.Spider): name = "hotel_detail" def start_requests(self): # 从列表落库结果里读 hotel_id，逐个请求详情页 with open("hotel_ids.txt") as f: for line in f: hotel_id = line.strip() if not hotel_id: continue url = ( "https://hotels.example.com/hotel/" f"{hotel_id}.html" ) yield scrapy.Request( url, meta={"hotel_id": hotel_id}, ) def parse(self, response): # 找到页面里的初始化状态脚本，变量名以实际页面为准 m = re.search( r"window\.__INITIAL_STATE__\s*=\s*(\{.*?\})\s*;?\s*$", response.text, re.DOTALL, ) if not m: self.logger.warning(f"no state found in {response.url}") return try: state = json.loads(m.group(1)) except json.JSONDecodeError: self.logger.warning("state json decode failed") return hotel = state.get("hotelDetail", {}) yield { "hotel_id": response.meta.get("hotel_id"), "open_year": hotel.get("openYear"), "renovate_year": hotel.get("renovateYear"), "lng": hotel.get("lng"), "lat": hotel.get("lat"), "intro": hotel.get("intro", "")[:200], }

正则里的.*?配合re.DOTALL，是处理这种“script 里的 JSON 跨行”场景的标准写法。有些页面里脚本变量后面还会跟分号或空行，所以正则末尾做了兼容。这里有一个常见误区：有人会把$符号也写进正则当作结束符，但如果你抓到的页面里 JSON 后面还跟着其他脚本，用\s*$反而可能匹配不到，需要把正则改得更宽松一点，比如只匹配到第一个</script>之前。

把初始化数据解析完，还需要再做一个兜底：如果 script 内容解析失败，再退回去用 XPath 提取页面上的酒店名和地址，而不是直接放弃。我的兜底策略很简单：接口字段优先，script 数据其次，HTML 标签最后，三层都失败才丢。这样页面小改版时，爬虫最多丢一些非关键字段，不至于整体崩掉。

3.3 清洗与标准化：价格、评分和空值处理

解析不是终点。从某旅行平台拿到的字段经常是“半成品”，比如价格字段可能是“¥489起”或者“489元起”，评分可能是“4.7/5分”，星级可能是“五钻”而不是“5”。这些展示型文本不能直接入库，否则后续做价格对比时排序是错的。

在 Item Pipeline 里加一个清洗函数，把这层逻辑独立出来：

# pipelines/clean.py import re def clean_price(raw): if raw is None: return None text = str(raw) # 去掉货币符号、汉字和空格，只保留数字 digits = re.sub(r"[^\d.]", "", text) if not digits: return None return float(digits) def clean_score(raw): if raw is None: return None text = str(raw).replace("分", "").strip() m = re.search(r"\d+(\.\d+)?", text) return float(m.group()) if m else None class CleanPipeline: def process_item(self, item, spider): if "min_price" in item: item["min_price"] = clean_price(item["min_price"]) if "score" in item: item["score"] = clean_score(item["score"]) # 空字符串统一转成 None，便于数据库存 NULL for key in list(item.keys()): if item[key] == "": item[key] = None return item

clean_price里的正则会把“¥489起”里的数字提取出来返回 489.0。写成[^\d.]而不是\D，是为了保留小数点，因为价格字段可能出现 489.5 这种值。clean_score则是先把“分”字去掉，再从字符串里找第一个小数。两个函数的共同点是都做了 None 兜底，原始值缺失时不会在清洗阶段抛异常。

这一步做完，字段才算是能进数据库的干净数据。后面章节里讲的数据入库，都是基于这套清洗管道。

4. 踩坑指南：某旅行平台爬虫的高频翻车现场与修复方法

即使代码逻辑完全正确，某旅行平台也有一万种方式让爬虫挂掉。这一章我按“现象 → 原因 → 解决”的顺序，整理几个跑某旅行平台数据时踩过的高频坑，每一个都是实际会遇到的情况。

4.1 跑着跑着 403：请求量和频率怎么控制

现象：白天抓前 500 到 800 条数据一切正常，再往后请求开始连续返回 403，页面打不开；停个十几分钟后又能恢复。这是典型的访问频率触达阈值。

原因：某旅行平台对单 IP 的访问频率有监控，短时间内的请求密度一旦冲到阈值，后续请求就会被风控直接拦截。403 和验证码还不一样，验证码至少给你一个绕过的机会，403 是直接拒绝。

解决：把下载延迟调大，把并发调小。我的常用配置是DOWNLOAD_DELAY = 2.5到3.5，CONCURRENT_REQUESTS_PER_DOMAIN = 2，同时开启AUTOTHROTTLE_ENABLED让 Scrapy 根据响应速度自动调节请求频率。另外需要避开高峰时段，某旅行平台白天流量大，风控也比较敏感；晚上 22 点之后抓同一批城市，触发概率会低很多。

还有一个血泪经验：一旦出现连续 403，不要继续重试，让爬虫停 10 到 15 分钟再继续。Scrapy 的重试机制只对偶发错误有好处，面对持续封禁时，重试只会让封禁时间更长。

4.2 页面能打开，抓回来却是空壳

现象：请求返回 200，HTML 长度正常，但解析出来的酒店列表是空的，或者只有页面框架没有数据。

原因：某旅行平台的酒店列表是异步加载的，HTML 里只有首屏框架，真正的酒店数据由后续 XHR 请求返回；另一种可能是 Cookie 过期，接口返回了空对象而不是报错。

解决：不要跟 HTML 较劲，直接抓数据接口。用浏览器开发者工具看 XHR 列表，找到返回酒店数组的那个请求，把它的完整 URL、请求头和入参复制到 Spider 里。如果是 Cookie 失效导致的空数据，重新打开浏览器登录一次，把新的 Cookie 贴进请求头，同时确认COOKIES_ENABLED = True不会让 Scrapy 用旧 Cookie 覆盖新值。

这里我一般会在parse开头加一个“标志位检测”：先看在响应文本里能不能找到酒店数量或者某个固定元素，找不到就直接告警，而不是继续往下解析。这样空壳页面会在入口处被拦截，不会带着空列表跑完整个流程。

4.3 二次运行时重复数据暴涨：入库前先建唯一键

现象：第一次跑完数据一切正常，第二次跑同样的城市和日期后，数据库里的记录翻倍，同一个酒店的记录出现两三条。

原因：Scrapy 的去重只在同一进程内有效，每次重启进程都会清空去重指纹；如果代码里又没有对最终落地做唯一性约束，数据就会重复写入。

解决：建表时把hotel_id设成唯一键，入库采用“存在则更新，不存在则插入”的写法。下面是我常用的表结构和写入 SQL：

CREATE TABLE hotel_info ( hotel_id INT PRIMARY KEY, name VARCHAR(128), star VARCHAR(16), score DECIMAL(3,1), comment_count INT, min_price DECIMAL(10,2), address VARCHAR(255), business_zone VARCHAR(64), updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

# pipelines/mysql.py INSERT_SQL = """ INSERT INTO hotel_info (hotel_id, name, star, score, comment_count, min_price, address, business_zone) VALUES (%s, %s, %s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE name = VALUES(name), score = VALUES(score), min_price = VALUES(min_price), updated_at = CURRENT_TIMESTAMP """

ON DUPLICATE KEY UPDATE在 MySQL 里是标准的幂等写法，重复执行不会产生新行，只会刷新价格和更新时间。如果用的是 SQLite，可以换成INSERT OR REPLACE INTO。唯一键的存在会在最后一道关口挡住重复数据，哪怕前面爬虫逻辑有 bug，数据库也不会被污染。

4.4 夜间任务静默失败：零数据却不报错

现象：定时任务每天凌晨跑，一周后查看数据库，发现某几天该城市的数据是空的，但任务中心显示“执行成功”。

原因：夜间页面升级、接口参数变动、验证码策略调整，这些都不会让爬虫直接崩溃，而是让解析逻辑拿不到数据。没有报错，是因为代码里没有做“零数据检测”。

解决：在 Spider 里监听spider_closed信号，读取 Scrapy 的爬取统计，如果item_scraped_count为 0，立即发告警。简单实现如下：

# spiders/hotel_list.py import scrapy from scrapy import signals class HotelListSpider(scrapy.Spider): name = "hotel_list" @classmethod def from_crawler(cls, crawler, *args, **kwargs): spider = super().from_crawler(crawler, *args, **kwargs) crawler.signals.connect( spider.spider_closed, signal=signals.spider_closed, ) return spider def spider_closed(self, spider): stats = self.crawler.stats.get_stats() scraped = stats.get("item_scraped_count", 0) if scraped == 0: self.logger.error("zero items scraped, check page structure")

这个告警不需要很复杂，哪怕只是在日志里打一条 ERROR，也比静默失败好得多。如果你想在凌晨发现问题就收到通知，可以在告警分支里调用企业微信群机器人或者邮件接口，把零数据的城市和日期发出来，第二天早上直接处理。

4.5 不要把 403 加进重试列表

现象：爬虫跑着跑着开始大量重试，日志里全是 403，任务迟迟不结束，数据库里一条新数据都没有。

原因：有人为了让爬虫“更顽强”，把 403 和 429 写进了RETRY_HTTP_CODES。结果 403 是持续状态，不是瞬时错误，重试一次被拒一次，还把请求频率顶得更高。

解决：RETRY_HTTP_CODES只保留 5xx 和超时类错误。遇到 403 时先把速度降下来，等封禁过了再继续；遇到 429 时可以配合Retry-After响应头，但 403 没有这个头，重试没有意义。我还会在中间件里单独记录 403 出现的次数，连续 10 次就直接暂停爬虫，保留现场日志，等人工处理。

这几个坑本质上都指向同一件事：先看状态码，再看请求头，最后才怀疑解析代码。顺序错了，排查成本会翻好几倍。

5. 让 CTripSpider 自己跑一个月：调度、增量更新和校验

跑通一次之后，真正的价值在长期运行。给 CTripSpider 挂一个定时任务，让它在后半夜自动抓取当天数据：

# 每天凌晨 2 点抓列表，凌晨 4 点抓详情 0 2 * * * cd /path/to/ctrip_spider && \ scrapy crawl hotel_list -a city_id=2 \ -a check_in=$(date +%Y-%m-%d) \ >> /var/log/ctrip_spider_list.log 2>&1 0 4 * * * cd /path/to/ctrip_spider && \ scrapy crawl hotel_detail \ >> /var/log/ctrip_spider_detail.log 2>&1

把抓取时间放在凌晨不是随意的。某旅行平台晚上的价格缓存更稳定，白天频繁变价导致的字段抖动会少很多；同时凌晨的用户访问量低，反爬风控相对宽松。但后半夜也容易触发页面升级，所以定时任务一定要配上一道校验：跑完后检查当天落库的hotel_id数量是否和昨天的量级接近，差太多就要警惕页面结构变化。

增量的思路要提前设计。我的做法是列表数据全量抓，详情数据增量抓：详情 Spider 启动前先查一遍库里已经有详情的hotel_id，把这些 ID 从待抓列表里去掉。这样一个月下来，每天新增的详情请求会越来越少，真正消耗请求量的是全量列表接口，用来及时发现新上线酒店和价格变化。

最后用来验证数据质量的办法很朴素：抽三个酒店，打开某旅行平台页面人工对比名称、评分和含税价；再跑一条 SQL 看价格区间分布，如果某一天所有价格数据都比前一天高一截或低一截，大概率是解析管道里混入了展示层文本。我吃过这个亏：某天的价格字段全部带上了“会员专享”几个字，清洗正则没匹配上，整批数据入库后无法参与统计，最后只能重跑那一天。从那以后，我固定会在每天任务结束后抽查一次价格字段的极值和均值，用数值波动反推解析是否正常。

酒店爬虫做扎实之后，下一个值得投入的方向是价格历史表。把每天抓到的min_price按hotel_id和时间维度存下来，一个月后就能画出价格趋势，再配合节假日的入住日期参数做低价日历。这套数据比单次快照值钱得多，也是 CTripSpider 从“跑通”走向“有用”的关键一步。希望这套落地路径帮到你，至少让你少踩几个我踩过的坑。

本文还有配套的精品资源，点击获取