Java爬虫实战：电商商品详情与价格采集的完整方案

做Java爬虫的，早晚都会被丢来这么一句需求：帮我抓一批电商商品详情，标题、价格、图片全要。提需求的人往往一脸轻松，好像这就是复制粘贴半天的活。真正动手之后才知道，光是一个价格字段，就能让你从入门到放弃好几回——要么抓到一半全是空值，要么几百条就被封IP，要么睡一觉起来页面改版，解析代码直接全部作废。

这活儿我从零写过好几版，早前给某公司做商品价格监控系统，核心就是采集国内一家主流电商平台（下文统一用J商城代称）的商品详情和价格数据。从请求头模拟、Cookie保鲜、价格接口挖掘，到代理IP池调度、异常降级，能踩的坑基本都踩了一遍。这篇把整个方案掰开揉碎讲清楚，完全用Java生态的落地姿势来写，技术选型、核心实现、反爬应对、问题排查一个不落。

不同基础的人都能从里面拿到东西：只想交个作业Demo的，直接抄核心代码就能跑通；要上生产环境做批量采集的，重点看反爬和稳定性那一节，里面有我在线上环境总结出来的血泪经验。每个关键设计我都会解释背后的原因，让你知道为什么这么做、坑在哪里、还有没有更好的替代方案。

1. 项目起步：先搞清楚你到底要采集什么

很多爬虫项目最后烂尾，不是技术不行，是需求没想清楚就动手了。采集J商城商品数据这件事，同样需要先拆一拆。

1.1 真实业务场景有哪些

我接触过的需求基本可以归成三类，每一类的侧重点不一样。

第一类是价格监控。做比价工具、返利平台、或者电商运营需要盯竞品调价，这类需求核心是价格，而且要高频抓取，比如每隔五分钟刷新一次重点商品的售价和促销价。它关心的是价格波动曲线，对详情页图片、文字描述反而没那么在意。

第二类是商品库建设。做数据分析、选品研究，或者自建一个商品数据库，这类需求要把标题、主图、规格参数、店铺名、评价数、好评率全部结构化落库。量级通常比较大，一次可能上万条SKU，还会持续增量更新。

第三类是单商品快速查询，比如用户输入一个商品链接，立刻返回当前价格和库存状态。这种通常做成一个查询接口，延迟要求高，单次请求要快，反爬策略不能太重，不然用户等不起。

你要做的项目是哪种，决定了整套方案的复杂度。如果只是价格监控，可以跳过大量详情页字段的解析；如果要建商品库，那数据库设计和增量更新策略就得提前想好。

1.2 J商城采集难在哪里

电商平台基本都有成熟的反爬体系，J商城在国内是出了名的难啃。具体难在四个地方。

第一，价格不直接渲染在HTML源码里。早期版本的商品详情页，HTML里根本没有价格，需要额外请求一个价格接口才能拿到，而且接口的返回格式和请求参数时有变化。这意味着你光用Jsoup解析静态HTML还不够，还得去抓动态接口。

第二，反爬维度多。除了最基础的User-Agent校验和Referer校验，还有IP访问频率限制、行为特征分析、验证码机制，热门商品和促销节点（比如大促）会临时加强风控。一旦被识别成爬虫，轻则返回错误页，重则弹滑块验证。

第三，页面结构时有改版。今天这个字段有class="sku-name"，明天可能就换成了别的标识。解析代码和页面耦合度很高，稍微一改就全部抓空。

第四，部分商品信息需要登录态。尤其是精确的促销价、Plus专享价、库存余量，不登录可能只显示一个区间价，或者干脆不返回。这就要求我们维护Cookie登录态。

1.3 整体架构怎么搭

不管需求大小，我都建议按分层思路来设计，养成习惯后后续扩展会轻松很多。整套流程像一条流水线：

• 调度层：负责触发任务，比如定时任务、消息队列、简单的循环线程池。
• 采集层：负责发HTTP请求，带好请求头、Cookie、代理IP，拿回HTML或JSON。
• 解析层：用Jsoup解析HTML提取详情字段，用Jackson解析JSON提取价格等动态数据。
• 清洗层：去重、类型转换、字段补全，比如把"￥1,299.00"清洗成1299.00。
• 存储层：写入MySQL或者文件，支持增量更新。
• 监控告警层：记录任务成功率、失败原因，页面改版时及时报警。

别一上来就把代码全写在同一个main方法里。先分层，后面每一步都能单独测试、单独升级。我自己早期图省事，所有代码堆在一起，结果改一处坏一片，后来老老实实按分层重写，省了无数维护的时间。

2. 技术选型：这套组合拳用得最顺手

Java生态的爬虫，核心就是三块：HTTP客户端、HTML解析器、JSON解析库。选对了，后面能少踩一半坑。

2.1 HTTP客户端选型对比

Java领域常用的HTTP客户端有三个，我做过一个简单对比。

我推荐用OkHttp。核心原因有三个：第一，拦截器机制非常好用，你可以在拦截器里统一加请求头、统计耗时、做重试，代码不用分散在各处；第二，连接池、超时控制、代理配置都很人性化；第三，API设计符合直觉，读起来就像在说话。

2.2 HTML解析与JSON处理

页面解析我们用的Jsoup，这基本是Java解析HTML的事实标准。它支持CSS选择器，比如你想拿商品标题，一行代码就能搞定。注意Jsoup只是解析器，不是HTTP客户端，虽然它内部也有一个connect方法可以做请求，但功能太弱，只能应付简单场景，生产级方案还是让OkHttp负责请求，让Jsoup只负责解析。

JSON解析我选Jackson。Fastjson虽然老牌，但这些年出过多个反序列化漏洞，在要求严格的团队里会比较敏感。Jackson性能不差，而且生态稳健，配合Jsoup用得很顺手。

2.3 依赖清单直接抄

如果你的项目是Maven管理，直接把下面这个依赖清单复制到pom.xml里：

<dependencies> <dependency> <groupId>com.squareup.okhttp3</groupId> <artifactId>okhttp</artifactId> <version>4.12.0</version> </dependency> <dependency> <groupId>org.jsoup</groupId> <artifactId>jsoup</artifactId> <version>1.17.2</version> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.17.1</version> </dependency> <dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId> <version>5.1.0</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>2.0.12</version> </dependency> </dependencies>

HikariCP是数据库连接池，如果你要把结果写进MySQL会用到。SLF4J是日志门面，爬虫项目的日志必须打全，不然出了问题连定位都无从下手。

2.4 数据库怎么选

小规模的Demo或者几百条数据，直接用一个本地文件或者SQLite就够了，轻量无负担。生产级的价格监控项目，我推荐MySQL配合HikariCP，数据量大之后可以按SKUID分表。如果是为了跑数据分析，落ClickHouse这类列式存储效果更好，不过那是后续话题，本文还是以MySQL为主。

3. 核心实现：详情页与价格采集全流程拆解

这是整篇文章的重头戏。我会从一个商品详情页URL开始，一步步把它变成结构化数据，每一步都有代码和设计理由。

3.1 先从URL解析出SKU编号

J商城的商品链接一般长这样：

https://item.jmall.com/1000123456.html

最后那一串数字就是SKU编号，后面所有流程都靠它。解析方式很简单：

public static String parseSkuId(String url) { // 形如 https://item.jmall.com/1000123456.html String[] segments = url.split("/"); String last = segments[segments.length - 1]; return last.replace(".html", ""); }

这里有个细节：有些链接还会带参数，比如?skuId=1000123456&source=...，要注意兼容。实际项目里我会写两个分支，一个从路径取，一个从Query参数取，保证都能解析到。

3.2 OkHttp请求带完整请求头

爬虫请求能不能过第一关，请求头占了六成功劳。裸请求（没有User-Agent的请求）基本直接被拒。我整理了一套亲测稳定的请求头配置：

public static Request buildProductRequest(String skuId, String cookie) { HttpUrl url = HttpUrl.get("https://item.jmall.com/" + skuId + ".html"); return new Request.Builder() .url(url) .header("User-Agent", UserAgentPool.random()) .header("Referer", "https://www.jmall.com/") .header("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8") .header("Accept-Language", "zh-CN,zh;q=0.8,en-US;q=0.5") .header("Accept-Encoding", "gzip, deflate, br") .header("Connection", "keep-alive") .header("Cookie", cookie) .build(); }

Referer为什么重要？因为很多电商服务器会校验请求来源，如果Referer为空或者指向别的网站，会被当成非正常流量。Accept-Language也容易被忽略，但有些风控策略会检查这个头，认为缺少中文化言头的请求不太像真人浏览器。

User-Agent不要用固定的一个。真人的UA五花八门，Windows Chrome、macOS Safari、Android WebView都有。我在UserAgentPool里放了二十多个常见UA字符串，每次请求随机取一个。

3.3 Jsoup解析商品详情字段

拿到详情页HTML之后，用Jsoup解析。这里我不能写死真实的CSS类名（平台改版频繁），只说方法和思路：用浏览器F12审查元素，找到每个字段对应的DOM位置，然后用选择器定位。

常规操作如下：

Document doc = Jsoup.parse(html); // 商品名称 String title = doc.select("div.sku-name").text(); // 商品副标题/卖点 String subTitle = doc.select("div.summary-text").text(); // 图片地址 String mainImage = doc.select("#spec-img").attr("data-origin"); // 店铺名称 String shopName = doc.select("div.shopName").text(); // 品牌 String brand = doc.select("#parameter-brand li").attr("title");

如果你看到某个字段解析出来是空字符串，先别急着改代码，用浏览器打开页面，F12找到那个字段，看看实际的HTML结构是什么。类名是动态生成的话，就别用完整类名做选择器，尽量找id或者稳定的父级元素定位。

3.4 价格数据怎么拿：独立接口策略

这是全文最关键的部分。商品详情页静态HTML里通常不含精确价格，真正价格是页面加载后通过异步接口请求回来的。早期的实现方式是用一个价格专用接口，传入SKU编号数组，返回一个JSON数组，里面有普通价格、促销价、Plus价等字段。

思路是：先通过浏览器F12打开Network面板，刷新商品页，找到返回价格JSON的那个XHR请求，把它的URL和请求参数记下来。然后我们再模拟这个请求。

代码大致如下：

public static BigDecimal fetchPrice(String skuId, String cookie) throws IOException { String priceApi = "https://price-api.jmall.com/prices?type=1&skuIds=J_" + skuId; Request request = new Request.Builder() .url(priceApi) .header("User-Agent", UserAgentPool.random()) .header("Referer", "https://item.jmall.com/" + skuId + ".html") .header("Cookie", cookie) .build(); try (Response response = httpClient.newCall(request).execute()) { String json = response.body().string(); JsonNode root = objectMapper.readTree(json); // 返回数组，取第一个元素里的价格字段 JsonNode first = root.get(0); BigDecimal price = first.get("p").decimalValue(); return price; } }

写这段代码时有几个细节需要记住。

价格接口一定要带Referer，而且Referer要指向对应的商品详情页。平台方会有校验，如果Referer不对，接口可能返回空数据或者错误码。

请求参数里的type=1别乱删。有些平台拿这个参数区分返回字段，删了之后返回的JSON结构可能完全不同，这点我在联调时被坑过，后来老老实实抓包对比才确认。

价格字段会经历类型变化。有时候是数字字符串"1299.00"，有时候是纯数字1299，甚至可能是"-"表示无货。反序列化之前要统一处理，我一般先把节点转成字符串，再判断是不是合法的数字格式。

促销价和普通价要分开存。监控价格的话，普通价变化不大，促销价才会频繁变动。我在数据库里设计了两个字段分别存，做价格波动分析时明显更直观。

3.5 完整采集流程示例

把上面所有环节整合成一个方法，逻辑很清晰：解析SKU、获取页面、解析详情、请求价格、组装对象、落库。我习惯把整个采集过程封装成一个ProductService，对外只暴露一个collect(String url)方法。

public class ProductCollector { private final OkHttpClient httpClient; private final ObjectMapper objectMapper = new ObjectMapper(); public ProductInfo collect(String productUrl) throws Exception { String skuId = parseSkuId(productUrl); String cookie = CookieManager.getValidCookie(); // 第一步：请求详情页 Request pageRequest = buildProductRequest(skuId, cookie); String html; try (Response response = httpClient.newCall(pageRequest).execute()) { if (response.code() != 200) { throw new CollectException("详情页请求失败，HTTP状态码：" + response.code()); } html = response.body().string(); } // 第二步：解析详情 ProductInfo info = parseDetailPage(html); info.setSkuId(skuId); // 第三步：请求价格接口 BigDecimal price = fetchPrice(skuId, cookie); info.setPrice(price); return info; } private ProductInfo parseDetailPage(String html) { Document doc = Jsoup.parse(html); ProductInfo info = new ProductInfo(); info.setTitle(doc.select("div.sku-name").text()); info.setBrand(doc.select("#parameter-brand li").attr("title")); info.setMainImage(doc.select("#spec-img").attr("data-origin")); return info; } }

这套流程跑通之后，一个商品的基础数据和价格就都能拿到了。但距离生产级别还很远，因为平台的反爬策略会在你跑了百八十条之后让你见识什么叫社会的毒打。

4. 反爬应对：稳定运行的关键策略

能抓第一条数据不算本事，能稳定抓一万条数据才是本事。这一节聊的是我在线上环境反复试错后才稳定下来的策略。

4.1 User-Agent轮换与请求头伪装

UA轮换是基础中的基础。我维护了一个固定的UA池，至少二十条，只能在请求前随机取，不要每秒钟换来换去，那样反而显得机械。有条件的还可以让UA和IP形成绑定关系，比如这个IP这次用Chrome UA，下次换一个UA，不要同一个IP在短时间内频繁变UA。

请求头不光要有，关键是要像一个真实的浏览器。我还会带上Accept、Accept-Language、Accept-Encoding、Connection这几个头，顺序不用刻意管，只要存在且合理即可。有些反爬系统会校验请求头缺失情况，缺失过多的请求直接被标记。

4.2 Cookie保鲜：登录态怎么维护

前面提到，J商城部分价格数据需要登录态才能拿到。Cookie从哪里来、过期了怎么办，这是两个核心问题。

获取Cookie有两种方式。第一种是手动方式：用你自己的浏览器登录J商城，F12打开Network面板，随便刷新一个页面，把请求头里的Cookie字符串完整复制出来，配置到代码里。这种方式简单直接，适合自用场景和中小项目。缺点是Cookie有时效，过期之后要手动重新复制。

第二种是自动方式：用代码模拟登录，拿到登录后的Cookie存到Redis或者内存里，定期刷新。登录接口通常有验证码和滑块，模拟难度不小，不是本文重点。我的建议是，第一阶段用手动Cookie把采集跑通，如果确实需要登录态高频使用，再投入精力去做自动登录。

Cookie保鲜有个容易忽略的细节：要监控Cookie的可用性。我写了一个CookieManager，每次请求前判断当前Cookie是否还能用，如果连续多次采集失败且状态码为302或403，就触发刷新流程。不要让一个失效的Cookie白白浪费大量请求。

4.3 代理IP池设计

价格监控项目跑得频繁，单IP很快就会被限制。根本解决办法是引入代理IP池，让不同的请求走不同的IP出口。

代理IP池的基本设计是这样的：从IP资源池里分配一个可用IP，去执行请求，如果请求成功且返回数据正常，这个IP的信用分加一；如果请求失败或被限制，信用分减一，信用分低于阈值的IP暂时移出可用队列。这样池子会自动淘汰不稳定的IP，保留可用率高的。

选择代理IP有两个方向。免费IP池（网上搜集的公开代理）能应急，但不稳定，经常连不上或者极慢，不推荐生产环境用。商业代理IP池是付费的，有按量计费也有按天计费，稳定性好,还有专门针对电商采集的IP库，虽然要花钱，但和人力排查成本相比根本不值一提。我个人建议，量小的项目用免费池凑合，量大的项目直接买商业代理。

用了IP池以后，还要注意一个关联问题：Cookie和IP的搭配。如果同一个Cookie一会儿从北京IP访问，一会儿从上海IP访问，风控系统一眼就能看出来是异常。我维护了一个简单的映射关系，绑定Cookie与固定地域的IP段，避免这个穿帮。

4.4 采集节奏控制：限速与随机延时

真实用户不会一秒刷新十个商品页面，爬虫如果毫无节制，很快就会被封。控制节奏的方法有两个，都很简单但极其有效。

一是固定延时加随机抖动。比如每次请求完成后，随机sleep 1到3秒，平均一秒多一个请求。这个节奏在夜间可以稍微快一点，白天繁忙时段要慢一点。

二是令牌桶限流模式。简单说就是设定一个速率上限，比如每秒最多2个请求，多出来的请求在队列里排队。我用Guava的RateLimiter做过一个简单的限流器，代码如下：

RateLimiter limiter = RateLimiter.create(2.0); // 每秒最多2个请求 // 每次请求前执行 limiter.acquire();

这个限速值要根据你的代理IP数量动态调整。只有5个IP的话，每秒2个请求都嫌多；有50个IP的话，每秒5到10个问题不大。核心原则是：让全体请求速率低于平台判定为异常流量的阈值，同时在多个IP之间分散压力。

4.5 降级与重试机制

网络请求一定会失败，关键是失败之后怎么处理。我设计了一套三级降级策略。

第一级，单个请求失败，立即重试一次，不过这次换一个新的代理IP。很多时候只是上一个IP触发了限流，换个IP就好了。第二级，换个IP还不行，就隔一段时间（比如30秒）再重试，因为可能是对方风控临时加强。第三级，连续多次失败，就放弃当前任务，记录下来，等下一轮调度再处理。

重试的时候需要设置合理的超时时间，请求超过8秒没响应就直接断开，不要无限等下去。OkHttp里用connectTimeout和readTimeout控制，我一般分别设为5秒和10秒，超时后立即走重试分支。

5. 问题排查实录：高频坑位与解决速查表

爬虫开发过程中，你会反复遇到一些类似问题。我把实际项目中高频出现的情况整理成了表格，方便你排查时快速对号入座。

5.1 最容易被封的三种操作习惯

第一个坏习惯是启动即狂抓。线程池开二十个线程，瞬间发出去几百个请求，这种脉冲式访问模式最容易触发风控。我见过一个项目就是因为启动瞬间打爆了对方接口，整个IP段都被拉黑。

第二个坏习惯是不注意采集时间。促销活动期间、整点抢购节点，平台风控力度会临时增强，这时候大规模采集基本就是送人头。我之前做监控系统，会在整点前后自动降速。

第三个坏习惯是不记录响应状态。每次请求返回的HTTP状态码、响应体开头的内容都要打日志，这样出问题才能知道是被重定向了、被限流了、还是直接返回了异常页。没有日志的爬虫项目，排查问题全靠猜，效率极低。

5.2 页面改版后的应急处理

不管前面解析代码写得多好，某天早上醒来，平台一改版，你的Jsoup选择器可能全抓空了。我的处理习惯是这样的。

核心字段解析代码全部集中在一个解析类里，绝对不允许散落在各处。这样改版时只改一个类就行。解析结果为空时，不直接记个空对象完事，而是触发一个告警日志，标注"解析失败，疑似页面结构变更"，避免数据静默变脏。采集端和解析端之间加一层校验，比如解析出来的标题为空、图片为空就视为这条数据解析失败，单独记录，而不是入库。

我至今还保留着定期手工抽查的习惯：随机选几条最新采集的数据，打开页面比对，确认解析逻辑仍然有效。这个习惯帮我躲过好几次页面改版的大坑。

5.3 数据质量问题怎么清理

采集到的数据经常是乱的。价格"1,299.00"带千分位逗号、标题前后有大量空白、图片地址是相对路径。入库之前必须清洗。

我的做法是单独写一个ProductCleaner，定义各种清洗规则。价格字符串统一去掉逗号和货币符号，转成BigDecimal；空白字符全部trim；图片地址如果以//开头，补全为https://。清洗规则要沉淀起来，形成一份可读的文档，以后换人接手也看得懂。

去重问题必须在数据库层面解决。商品表给SKU字段加唯一索引，入库时用INSERT ... ON DUPLICATE KEY UPDATE，这样既能保证不重复，又能顺便更新价格等字段，一举两得。

5.4 并发采集时的线程安全注意点

批量采集不是简单for循环里开线程就完事。有几个线程安全问题很隐蔽。

Cookie、代理IP这些共享资源，不要每个线程都去查数据库取，最好是启动时加载到内存，配上定时刷新机制。我踩过的坑是：多个线程同时发现Cookie失效，一起触发刷新逻辑，导致重复登录，接口被限流。解决方式是刷新操作加锁，只让一个线程执行。

日志要能区分线程。给日志加上线程名称，线上排查时才能定位到是哪个采集线程出了问题。线程池命名用fetch-pool-1、fetch-pool-2这种有意义的名字，不要用默认的pool-1-thread-1。

6. 写在最后：一点个人体会

做了几版商品采集项目之后，我最大的感受是：能稳定跑一个月的爬虫，比能抓一百条数据的爬虫难一个量级。很多人在Demo阶段跑得飞起，到了生产环境就各种翻车，根本原因不是不会写解析代码，而是对反爬、稳定性、数据质量这些非功能性的东西认识不足。

我个人在项目落地时会坚持三个习惯。第一，所有请求必经日志层，响应状态码和耗时全记录，没有日志等于瞎跑。第二，采集代码和解析代码严格分层，页面改版只动解析层。第三，每次大规模采集前先手动发起几个请求验证Cookie和IP可用性，确认一切正常再让任务全面铺开，这个习惯帮我避掉了无数次无效采集和数据污染。

如果你后续想在这个方案上继续扩展，可以考虑的方向有：用消息队列做任务分发、把入库数据接到可视化面板做价格趋势图、加入品牌和关键词维度的自动分类。采集本身只是第一步，数据能用起来才是最终目的。希望这篇文章能帮你少走几段弯路，把时间和精力花在更有价值的地方。