1. 这不是“爬虫教程”而是一次煤炭行业数据获取的实战复盘金投网——这个名字在能源、大宗商品和金融信息领域并不陌生。它长期提供包括煤炭在内的多种基础工业品价格指数、港口库存、产地报价、铁路运量等结构化数据这些数据被广泛用于市场分析、期货对冲、采购决策和政策研究。但它的公开页面并不直接提供API接口历史数据需手动翻页导出Excel下载功能仅限于近30天且关键字段如“鄂尔多斯5500大卡坑口价”“秦皇岛港5500大卡平仓价”“曹妃甸港库存量”等分散在不同栏目、不同子域名、甚至不同HTML结构中。我第一次接到某能源咨询公司委托时原以为只是写个“requestsBeautifulSoup”的小脚本结果在第三天就卡死在反爬策略上页面返回空表格、AJAX请求带动态时间戳参数、关键价格数据被JavaScript渲染、部分列表页存在滚动加载infinite scroll且无明确分页URL。这不是技术炫技而是真实业务场景下的数据基建问题——你无法用“爬取失败”去向客户解释为什么下周的周报缺了山西主焦煤的环比变动。关键词里虽为空但结合标题与行业常识核心要素非常清晰煤炭价格数据、港口/产地/铁路三类维度、结构化存储、增量更新机制、抗页面结构变更能力。这不是面向程序员的“如何写爬虫”而是面向能源分析师、风控专员、采购经理的“如何稳定拿到可用数据”。我试过用Selenium模拟浏览器结果单日抓取200页耗时47分钟服务器CPU飙到98%根本无法部署为定时任务也试过逆向分析其前端JS发现价格数据由一个叫getPriceData的函数解密后注入DOM该函数依赖页面内嵌的window.__INITIAL_STATE__对象而这个对象每次刷新都变化。最终跑通的方案既没用无头浏览器也没硬啃加密逻辑而是抓住了金投网自身架构的一个“设计惯性”它所有价格数据源最终都指向同一个后端接口/api/v1/price/list该接口虽有签名验证但签名规则固定、时间窗口宽松、且关键参数如commodity_idcoal、regionshanghai完全可枚举。这篇文章就是把这段从“页面失效”到“接口稳提”的完整路径掰开揉碎讲清楚——包括为什么选这个接口、怎么定位它、如何构造合法请求、如何应对字段突然消失、以及最重要的如何让这套逻辑在金投网改版三次后依然有效。2. 为什么放弃“页面解析”转向“接口直取”一次成本-收益的硬核算很多人看到“金投网煤炭数据爬取”第一反应是打开开发者工具切到Network标签页刷新页面找XHR请求。这没错但错在“找完就停”。真正的难点不在“找到”而在“确认这个请求是否可持续”。我花了整整两天时间系统性地对比了三种主流路径的成本与风险结论非常明确页面解析HTML Parsing是短期救急方案接口直取API Direct Call才是生产级选择。下面这张表是我基于连续7天实测记录整理的量化对比维度页面解析BeautifulSoup requests页面解析Selenium ChromeDriver接口直取requests 签名构造单页平均耗时1.2秒不含等待JS渲染8.7秒含启动浏览器、加载JS、等待元素0.35秒纯HTTP请求日均稳定抓取量2核4G服务器6,200页但30%页面因结构微调导致字段缺失1,100页频繁触发Cloudflare人机验证12,800次请求成功率99.6%维护成本月均工时12小时需每日检查HTML class名、table位置、JS变量名是否变更20小时需同步ChromeDriver版本、处理弹窗、截图debug1.5小时仅需监控commodity_id映射表是否新增数据完整性风险高价格数字常被span classprice-up582/span包裹但涨跌箭头图标可能用SVG或字体图标导致文本提取错位中能渲染JS但动态加载的“更多历史”按钮需模拟点击易漏页极低接口返回JSON字段名稳定如current_price、change_rate、unit部署可行性可容器化但需定期人工校验输出难容器化需Xvfb或DockerChrome资源占用高极易容器化支持K8s水平扩缩容这个表格背后是血泪教训。比如第4次金投网改版他们把“秦皇岛港5500大卡平仓价”的HTML结构从div classprice-item改成article>// 伪代码实际JS已混淆但逻辑不变 function loadPriceData() { const params { commodity: coal, region: getCurrentRegion(), // 返回qinhuangdao type: port, timestamp: Date.now() }; const signature generateSignature(params); // 关键 return fetch(/api/v1/price/list?${new URLSearchParams(params)}signature${signature}); }这里的关键洞察是getCurrentRegion()返回的值决定了你抓取的是哪个港口的数据而这个值是由页面URL的path决定的。例如访问https://www.jintou.com/coal/port/qinhuangdao/getCurrentRegion()就返回qinhuangdao访问https://www.jintou.com/coal/origin/shanxi/就返回shanxi。所以你不需要去猜region参数只需要按规则构造URL就能批量生成所有目标区域的请求参数。3.2 第二步提取签名生成逻辑避开JS逆向陷阱上面代码里的generateSignature函数是混淆的重点。它被压缩成一行包含atob、btoa、多次字符串拼接和crypto.subtle.digest。但注意crypto.subtle.digest的输入是一个ArrayBuffer而这个ArrayBuffer的来源是JSON.stringify(params) 一个固定字符串。我用了一个取巧但极有效的方法在浏览器控制台给generateSignature函数下断点当它执行到return digest(...)前手动执行console.log(input:, JSON.stringify(params) fixed_secret_2023)立刻得到签名原文。实测发现这个“fixed_secret_2023”在JS文件里出现过3次且每次都是同一串字符。于是签名算法简化为import hashlib import hmac import json def generate_signature(params: dict) - str: # params 是请求参数字典如 {commodity: coal, region: qinhuangdao, timestamp: 1712345678} # 注意params 必须按字母序排序后拼接这是HMAC的常见要求 sorted_params dict(sorted(params.items())) payload json.dumps(sorted_params, separators(,, :)) fixed_secret_2023 signature hmac.new( keybfixed_secret_2023, msgpayload.encode(utf-8), digestmodhashlib.sha256 ).hexdigest() return signature注意json.dumps的separators(,, :)至关重要。如果保留空格签名就会错。我曾因此调试了6小时直到用curl -v对比浏览器发出的请求头才发现空格差异。3.3 第三步构建参数字典覆盖全品类煤炭数据金投网的煤炭数据不是单一维度而是“品类×区域×类型”的三维矩阵。commodity参数不只是coal还包括coking_coal焦煤、anthracite无烟煤region参数也不是简单城市名而是预定义ID如qinhuangdao秦皇岛、caofeidian曹妃甸、yulin榆林、ordos鄂尔多斯type参数则区分port港口、origin产地、railway铁路。这些ID并不在URL里明文体现而是存放在前端JS的某个配置对象中。我的做法是在控制台执行console.log(window.__REGION_MAP__)直接输出一个巨大的JSON对象里面是{qinhuangdao: 秦皇岛港, yulin: 榆林产地}。我把这个映射表导出为region_map.json作为项目的基础配置文件。同理commodity_map.json和type_map.json也用同样方法获取。这样整个参数空间就变成了可枚举的笛卡尔积# 伪代码生成所有合法请求参数 for commodity in [coal, coking_coal, anthracite]: for region in [qinhuangdao, caofeidian, yulin, ordos, taiyuan]: for type_ in [port, origin, railway]: params { commodity: commodity, region: region, type: type_, timestamp: int(time.time()) } signature generate_signature(params) url fhttps://www.jintou.com/api/v1/price/list?{urlencode(params)}signature{signature} # 发起请求...3.4 第四步设计弹性容错机制应对字段漂移即使接口稳定数据字段也可能“悄悄”变化。比如某次更新change_rate字段名被改为price_change_percent但旧字段并未删除而是同时存在。如果代码里硬编码data[change_rate]就会报KeyError。我的解决方案是建立字段别名映射表并在每次请求后做字段健康检查。在项目根目录创建field_mapping.json{ current_price: [current_price, latest_price, price], change_rate: [change_rate, price_change_percent, change], unit: [unit, price_unit], date: [date, update_time, as_of_date] }Python解析逻辑变为def safe_get_field(data: dict, field: str) - Any: 根据别名映射表安全获取字段值 candidates FIELD_MAPPING.get(field, [field]) for cand in candidates: if cand in data: return data[cand] raise KeyError(fField {field} not found in response, candidates: {candidates}) # 使用示例 try: price safe_get_field(api_response, current_price) change safe_get_field(api_response, change_rate) except KeyError as e: logger.warning(fField mapping failed: {e}) # 记录告警但不中断流程用None或默认值填充 price None change None这套机制让我在后续两次接口字段微调中仅需更新field_mapping.json无需动一行业务代码。4. 从“能跑通”到“可交付”生产环境必须解决的五个细节写一个能抓到数据的脚本和交付一个客户能天天用的系统中间隔着五座山。我服务的某能源集团要求数据每天6:00前入库误差不超过5分钟且任何异常必须短信告警。以下是我在生产环境中打磨出的、必须落地的五个细节每个都源于真实故障。4.1 时间戳精度与服务器时钟同步差3秒就签名失效金投网接口的timestamp参数要求与服务器当前时间偏差≤300秒5分钟但更致命的是它校验的是“请求发起时刻”的时间戳而非“服务器系统时间”。我们最初用int(time.time())但在高并发下从生成时间戳到请求发出可能经历DNS解析、TCP握手、SSL协商耗时超过100ms。当QPS50时约3%的请求因时间戳“过期”被拒。解决方案是在请求发起前的最后一毫秒生成时间戳并用time.time_ns()纳秒级精度校准import time def make_request_with_fresh_ts(url: str, params: dict): # 在真正发送前用纳秒级时间生成timestamp now_ns time.time_ns() # 转换为秒级但确保是整数 params[timestamp] now_ns // 1_000_000_000 # 构造完整URL full_url f{url}?{urlencode(params)}signature{generate_signature(params)} # 发送请求 return requests.get(full_url, timeout10)同时强制服务器使用NTP同步时间sudo timedatectl set-ntp on并每小时检查偏移timedatectl status | grep System clock synchronized。我们曾因一台服务器NTP服务崩溃导致时间慢了4分12秒连续3天数据全量失败。4.2 请求频率控制不是“越快越好”而是“恰到好处”金投网没有明确的QPS限制但实测发现单IP连续请求间隔1.2秒第5次请求开始返回503 Service Unavailable。这不是封禁而是后端负载均衡器的自动熔断。我们最初的策略是“请求后sleep(1.5)”但这样太保守日均只能抓2万次。优化方案是采用令牌桶Token Bucket算法允许短时突发但长期匀速。用Redis实现import redis import time r redis.Redis() def can_proceed(): now int(time.time()) # 每10秒重置一次桶容量10个令牌 key fjintou_rate_limit:{now // 10} count r.incr(key) if count 1: r.expire(key, 10) # 设置过期避免key堆积 return count 10 # 使用 while not can_proceed(): time.sleep(0.1) # 执行请求...这样峰值QPS可达10平均QPS稳定在1完美匹配其后端承受力。4.3 数据去重与幂等写入避免“同一条数据入库三次”金投网的部分接口尤其是铁路运量存在数据延迟发布现象今天抓到的“4月10日运量”明天又抓到一遍。如果直接INSERT INTO会导致数据库重复记录。我们的方案是以“日期区域品类”为联合唯一索引并用INSERT ... ON CONFLICT DO NOTHINGPostgreSQL或REPLACE INTOMySQL。建表语句关键部分-- PostgreSQL 示例 CREATE TABLE coal_price_data ( id SERIAL PRIMARY KEY, date DATE NOT NULL, region VARCHAR(50) NOT NULL, commodity VARCHAR(50) NOT NULL, current_price NUMERIC(10,2), change_rate NUMERIC(5,2), unit VARCHAR(20), created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), UNIQUE (date, region, commodity) -- 核心保证幂等 );这样即使同一条数据被请求10次数据库也只存一份。4.4 异常链路监控不是“报错就停”而是“报错即诊断”最怕的不是报错而是“静默失败”。比如某天接口返回{code:200,data:[]}但程序没检查data长度直接解析结果存了一堆NULL。我们的监控体系分三层应用层用logging记录每次请求的status_code、response_time、data_length并设置阈值告警如data_length0连续3次触发企业微信告警基础设施层用Prometheus采集requests_total{jobjintou}、request_duration_seconds_bucketGrafana看板实时显示成功率曲线业务层每天凌晨跑校验脚本比对“今日抓取数据量”与“昨日同期数据量”波动15%即发邮件。其中业务层校验最有效。有一次我们发现“鄂尔多斯产地价格”数据量突降90%排查发现是金投网把regionordos改成了regioneerduosi而我们的region_map.json没更新。告警邮件里直接附上curl -v https://www.jintou.com/api/v1/price/list?commoditycoalregionordos...的响应运维同事5分钟内就定位了问题。4.5 增量更新与历史回溯不是“只抓今天”而是“随时补昨天”客户常问“上周三的数据丢了能补吗”金投网接口默认只返回最近30天但它的date参数支持指定任意日期只要在数据存在范围内。我们的增量策略是日常任务每天抓取datetoday和dateyesterday确保最新数据补数机制维护一张missing_dates表记录所有失败日期。每晚23:00扫描此表对每个缺失日期发起/api/v1/price/list?date2024-04-05...请求历史归档每月1日自动触发全量回溯抓取过去180天数据用于训练价格预测模型。这个机制让我们在去年一次服务器硬盘故障中仅丢失了2小时数据其余全部通过补数恢复。5. 一次真实的“改版劫难”与我们的应对从恐慌到预案去年10月金投网进行了一次重大前端重构所有URL路径从/coal/port/qinhuangdao/变成/commodity/coal/port/qinhuangdao/CDN JS文件哈希值全部变更window.__REGION_MAP__对象被重命名为window.__GEO_CONFIG__。当天上午9:00我们的监控系统报警所有请求status_code404。团队立刻进入应急状态但整个过程只用了37分钟就恢复原因是我们有一套成熟的“改版应对SOP”。这不是运气而是把每一次小改动都当作“压力测试”来积累经验。5.1 第一阶段快速定位变更点0-10分钟我们不看新页面而是直接比对“旧JS”和“新JS”用curl https://cdn.jintou.com/static/js/price-list.7a2b3c.js old.js保存旧版用curl https://cdn.jintou.com/static/js/price-list.x9y8z7.js new.js保存新版用diff -u old.js new.js | head -n 50查看差异。立刻发现两处关键变化fetch(/api/v1/price/list?...变成了fetch(/api/v2/price/list?...window.__REGION_MAP__变成了window.__GEO_CONFIG__。这10分钟我们确认了接口路径升级、配置对象重命名但签名算法和参数结构未变。5.2 第二阶段最小化修改验证10-25分钟我们不做全量修改而是先改一个点验证是否可行修改Python代码将/api/v1/替换为/api/v2/修改控制台命令console.log(window.__GEO_CONFIG__)确认新对象结构一致用Postman手工构造一个/api/v2/price/list?...请求传入旧签名返回{code:200,data:[...]}。这15分钟我们用最小代价验证了核心逻辑依然有效只是路径和配置名变了。5.3 第三阶段批量更新与回归测试25-37分钟确认主干逻辑OK后执行批量操作全局替换/api/v1/为/api/v2/更新field_mapping.json增加geo_config: [__GEO_CONFIG__, __REGION_MAP__]运行回归测试脚本遍历所有commodity×region×type组合发起100次请求验证成功率99%将新JS里的fixed_secret_2023与旧版比对确认未变更确实没变。37分钟服务恢复正常。这次事件后我们把“JS文件哈希值”和“配置对象名”加入每日巡检清单一旦发现变更立即触发告警而不是等数据丢失。提示永远不要相信“前端不会改”。我们把金投网的每一次小更新如按钮文字从“查看更多”变成“展开详情”都记录在changelog.md里。累计半年发现92%的“页面结构变更”其实不影响接口只有8%需要代码调整。这种习惯让改版从“灾难”变成了“例行维护”。6. 写在最后数据获取的本质是理解业务逻辑的耐心做完这个项目我最大的体会是爬虫工程师的终极竞争力从来不是Python写得多溜而是对业务的理解有多深。金投网为什么要把价格数据拆成港口、产地、铁路三类因为这对应着煤炭流通的三个关键环节生产端产地、运输端铁路、消费端港口。为什么commodity要区分coal和coking_coal因为动力煤和焦煤的定价机制、下游客户、期货合约完全不同。当你理解了这些你就会知道/api/v1/price/list?typerailway返回的“日运量”其单位一定是“万吨”而typeport返回的“平仓价”其unit字段一定是“元/吨”。这种业务直觉让你在字段名突然变成unit_desc时能立刻判断它和unit是同一字段而不是慌乱地去查文档。我见过太多人花三天写了个“完美”的BeautifulSoup脚本却在第四天因为一个class名变更而全线崩溃。而我们这套接口直取方案上线一年半只因两次重大改版做了代码调整其余时间全自动运行日均稳定产出12,000条结构化数据支撑着三家能源企业的日报、周报和模型训练。它不酷炫没有AI不涉及分布式但它像一台老式柴油机——转速不高但扭矩十足从不趴窝。如果你正面临类似需求我的建议只有一条别急着写代码先花半天把金投网所有煤炭相关页面的URL、JS文件、网络请求全部扒下来做成一张关系图。图上的每一个节点都标上它的业务含义。当你能把这张图讲给一个非技术人员听懂时你的代码就已经成功了一半。