企业官网建设流程全解析

简介：一份集Python爬虫与JS逆向于一体的学习案例合集，覆盖网易易盾、极验滑块、加速乐、雪球网、QQ音乐、1688等20余个主流网站的反爬破解与数据采集实战，既适合系统入门JS逆向，也适合作为毕业设计选题参考。压缩包共70个文件，以30个Python脚本和30个JavaScript文件为核心，配合JSON配置、Markdown说明、依赖清单等辅助材料，整体仅827KB，目录按案例分模块组织，便于快速定位。目前已有721人浏览学习。除常规请求加密参数还原外，资源还覆盖微信小程序反编译、RPC解密实现、多种滑块验证码处理等进阶主题，每个案例均保留核心脚本与配套代码，可帮助读者理解从抓包分析、断点调试到逆向落地的完整链路，是一套轻量而实用的爬虫逆向学习素材。 干爬虫这行五年多，最常被问的一句话是：某某网站的数据你能不能爬？翻译成技术语言，这句话的实际意思是：这个站点的反爬体系你搞得定吗？今天要分享的这套东西，是我在一次跨平台数据采集项目里沉淀下来的Python爬虫代码集合，包含 whggzy、qiming、mohurd、endata、1688、cinfo、qq-m 这七个站点，基本覆盖了从入门到进阶会遇到的反爬层级。如果你正在学爬虫、准备接触JS逆向，或者想找一个能直接参考的多站点实战项目，这篇应该对你有用。

这个集合不是临时拼凑的脚本，而是我按真实业务场景做的工程化方案。每个站点从抓包、定位加密参数、还原算法，到最终的Python落地，都有完整的处理链路。接下来我会把整体设计思路、不同站点的反爬类型、典型逆向过程以及踩过的坑，一五一十讲清楚。

1. 项目整体思路与网站分类

1.1 为什么攒这样一个多站点集合

我接手的项目需要从多个平台持续抓取公开数据，一开始是来一个站写一套脚本，代码越堆越多，维护成本越来越高。后来我做了个决定：理清公共逻辑，把请求调度、代理切换、日志、数据存储这些通用模块单独抽出来，每个站点只专注做两件事——分析反爬、写解析逻辑。

这个决策的核心原因是：爬虫代码里真正容易崩的部分，从来不是解析那条XPath或JSON路径，而是反爬机制的破解。所以我很早就定了一条规矩：每个站点的加解密逻辑必须独立成模块，和主流程解耦。这样即使某个站点改版，也只需要替换对应的逆向模块，不会牵连整个系统。

这套代码集合还有一个好处：新站点接入时，先对比已有站点的反爬级别，如果只是加个Header、换个签名方式，直接复用现有方案改参数就行，不用从零开始分析。

1.2 七个站点怎么分类

我按反爬的复杂度把七个站点分成了三个梯队。第一梯队是基础校验型，代表是cinfo和mohurd；第二梯队是签名与Token型，代表是whggzy、qiming和endata；第三梯队是复杂逆向与风控型，代表是1688和qq-m。这个分层不是随便拍的，而是根据我实际踩坑的经验总结出来的。

下面的表格可以直观看出每个站点的特点和破局重点：

一旦把站点分好类，后续的破解思路就很清晰了：基础校验型优先维持会话，签名Token型重点做参数还原，复杂逆向型则需要花大力气在JS代码分析上。

2. 核心反爬机制分析与破解思路

2.1 基础校验型站点：先别急着上逆向

cinfo和mohurd这两个站点，反爬强度在我处理过的网站里算入门级别，主要校验请求头是否规范、Cookie是否有效，偶尔检查一下Referer和访问频率。很多人一上来就开JS逆向，最后发现根本没加密函数可逆，纯属浪费时间。

正确的做法是用requests.Session保持会话，把浏览器控制台里拷贝出来的完整请求头原样写进代码，带上Cookie建立一次稳定的会话，然后正常请求就行。mohurd的接口对请求频率比较敏感，我实测每秒钟超过2次请求就会触发限流，所以我在代码里强制加随机延时，每次请求间隔0.5到1.5秒，配合代理IP轮换，基本不会出问题。

处理这类站点的经验是：先用最简单的方案验证数据能不能拿到，拿不到再逐级加码，不要一上来就做最复杂的准备。爬虫工程最忌讳的，就是过度设计。

2.2 签名与Token型：抓住时间戳和MD5

whggzy、qiming和endata这类站点，核心反爬集中在接口参数上。它们的请求里通常会带几个看似毫无规律的字段，比如nonce、timestamp、sign。拆开看，大部分都遵循同一个模板：把固定密钥、时间戳、业务参数按一定顺序拼接，再做一次哈希运算。

处理这类问题的第一步永远是抓包，看明文，不要急着打断点。我会在DevTools的Network面板里找到目标接口，观察请求参数里哪些是固定值、哪些是动态值，然后把动态参数名放到Sources面板里全局搜索（快捷键Ctrl+Shift+F），快速定位到生成它的JS代码。绝大多数情况下，发现的过程比想象中简单，它就是把几个字符串拼起来做哈希，看懂之后用Python的hashlib就能直接复现。

qiming这类企业信息网站还多了一个花样：字体反爬。页面上的数字看起来正常，但爬下来全是乱码，因为网站把数字渲染成了自定义字体。处理方案是把CSS里@font-face指向的woff文件下载下来，用Python的fontTools库解析字体映射表，把字形和真实数字一一对应起来。

2.3 复杂逆向与风控型：1688和qq-m才是重头戏

1688和qq-m是我在这个集合里花时间最多的两个站点。1688作为电商平台，搜索接口和详情页接口都有完整的签名体系，参数里data、sign、jssdk版本号环环相扣。qq-m这边更狠，不仅签名复杂，对请求头顺序、Cookie完整性、TLS指纹都很敏感，单纯用requests很难稳定跑通。

针对这类反爬，我的处理思路分两步。第一步用playwright驱动真实浏览器访问目标页面，把接口响应直接拦截下来，这样能快速验证业务可行性和数据结构。第二步，等确认数据有价值之后，再花时间分析具体签名算法，用Python或Node复刻。

这里有个很关键的判断标准：如果只是短期拉数据，playwright方案完全够用；如果要长期跑，一定要做纯代码逆向，否则每次浏览器升级都要跟着维护一次。我曾经为了图省事直接用playwright挂机跑了一个月，后来才发现每天消耗的CPU和内存资源远超预期，换成纯Python实现的签名方案以后，资源占用直接降了七成。

3. 实战：典型网站的JS逆向完整过程

3.1 whggzy：从抓包到还原Token生成算法

whggzy是我在这个集合里第一个搞定逆向的站点，它的Token生成逻辑非常适合当入门案例来讲。

第一步，打开网站列表页，按F12进入DevTools，切到Network面板，刷新页面，过滤出返回JSON数据的XHR请求。第二步，在请求Headers里看到一个X-Token参数，值是一长串类似Base64编码的字符串。第三步，在Sources面板里按Ctrl+Shift+F全局搜索X-Token，定位到赋值语句。

定位后的代码逻辑其实很简单：token等于时间戳加一个固定clientKey，拼起来做Base64编码。用Python实现如下：

import base64 import time def generate_token(client_key: str) -> str: timestamp = str(int(time.time() * 1000)) raw = f"{timestamp}|{client_key}" return base64.b64encode(raw.encode("utf-8")).decode("utf-8")

这段代码看起来简单，但套路是通用的。以后再遇到X-Token、X-Sign、Authorization这类参数，先全局搜参数名，看看它是由哪几个固定值拼接成的，大部分问题就能解决一半。我见过太多人一上来就钻进调试器里逐行分析，结果转了半天才发现加密逻辑不过十几行代码。

3.2 1688：sign签名如何一步步定位

1688的签名逆向过程比whggzy繁琐得多。它的搜索接口URL里会带一个sign参数，这个参数由前端JS动态生成。我的定位方法是：

第一步，打开商品搜索页，在Network里过滤XHR，找到名为asyncSearch的接口。第二步，全局搜索sign，会在多个JS文件里搜到一堆结果，这时候要优先看app.js这类业务代码，别在第三方依赖库里浪费时间。第三步，在疑似生成sign的代码处打断点，刷新页面进入debugger，然后看Call Stack调用栈，逐层点击栈帧找到真正执行加密逻辑的函数。

经过分析发现，1688的sign是基于jssdk内部一套完整的签名机制，会拼接url、业务参数、时间戳、密钥，再通过特定哈希算法计算。定位到核心函数后，我把这段JS单独抽取出来，放到本地Node环境运行，通过加console.log的方式观察不同输入对应的输出，最终在Python里用hashlib还原了整个签名流程。

这类型站点的逆向千万别指望一次成功，通常要反复对比浏览器生成的签名和自己的算法生成的值，一旦发现不一致，就回到JS代码里补细节。我大概花了三个晚上才完全跑通1688的签名逻辑，这也是为什么我强调要把过程记录下来——每次重头分析一遍，成本太高了。

3.3 补环境与JsRPC的取舍

有些网站的加密算法特别依赖浏览器环境，会检测window、navigator、document这些对象，缺一个就报错。这时候有两种解决方案。第一种是补环境，用jsdom或者自己写一个假的window对象，把浏览器环境模拟出来，让JS以为自己还在浏览器里运行。第二种是JsRPC，把浏览器本身当成远程执行环境，通过WebSocket或HTTP从外部调用浏览器里的加密函数。

以我自己的经验来说，如果是临时任务、数据量不大，JsRPC绝对是最快的方案，启动一个无头浏览器，在页面里注入WebSocket客户端，外部Python脚本请求加密函数，几行代码就能打通。但如果要长期维护，我强烈建议走补环境路线，前期把环境补齐，后面维护会很省心。

目前很多站点的反爬也在更新换代，已经出现了检测Playwright和Puppeteer特征的方案。遇到这种情况，我的应对思路是尽量把核心逻辑回归到纯Python实现，减少对浏览器模拟的依赖，这样站方升级检测技术时，我只需要调整算法实现，不用改整个架构。

4. 常见问题与排查技巧实录

4.1 高频报错与解决速查表

这七个站点跑下来，我整理了出现频率最高的几类问题和对应的解决办法，直接看表：

这里重点说两个容易忽略的坑。第一个是execjs的Node环境版本问题，系统里如果装了两个Node版本，Python调用的可能是旧版，导致某些ES6语法直接报错。第二个是代理IP的复用问题，某个IP一旦在1688或qq-m上触发滑块，短期内复用大概率还会触发，所以我在代理池里做了冷却机制，触发风控的IP直接拉黑24小时。

4.2 数据更新与日常维护方案

爬虫写完不是结束，真正的考验是日常维护。网站改版频率完全不可控，可能今天还能用的签名方式，第二天就失效了。我的应对方案是每个站点都内置一个轻量级健康检查脚本，每天定时请求核心接口，校验返回状态和关键字段，一旦出现异常立刻告警，这样能在业务方发现问题之前就提前修复。

在逆向代码的归档上，我会把每个站点对应的JS文件、参数说明文档、生成时间标注放在同一个目录下。这样过几个月之后回看，还能迅速理解当时的思路，不用重新逆向一遍。比如whggzy的token生成原理，1688的sign拼接顺序，我都写成了详细的markdown笔记，对后续维护效率提升非常明显。

另外想提一句，现在大模型对JS逆向的帮助越来越大了。把一段被混淆的加密函数扔给支持代码理解的大模型，让它解释逻辑或者直接翻译成Python，通常能节省不少时间。但要注意，模型给出的结果只能当参考，最终的算法校验还是要靠对比真实请求的输入输出来确认，我遇到过几次模型翻译得逻辑通畅但细节参数对不上导致签名结果有偏差的情况。

回到这套集合本身，我最大的收获其实是沉淀了一套方法论：基础校验型站点维持会话优先，签名Token型站点优先全局搜参数名，复杂加密型站点先验证业务可行性再投入时间做完整逆向。这套方法论让新站点的接入时间从最早的三四天，压缩到现在的半天一天。如果把爬虫当成一门手艺，那这套多站点的JS逆向集合，就是我最常拿出来打磨的工具箱。

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