企业官网建设流程全解析

1. 项目概述与思路拆解

1.1 项目核心需求解析

我这次要拆解的是一个典型的“Python每日爬虫案例”——目标接口采用 AES + RSA 双重加密的站点解析，难度定位中等。

先说说为什么会遇到这种需求。现在很多网站的数据接口已经不是裸奔状态了，你直接开个浏览器开发者工具，看到 Network 面板里密密麻麻的 JSON 数据，以为拿到就能用——结果实际写代码去请求，对方直接给你返回一串看不懂的密文，或者干脆给你个 403。这时候就要面对一个问题：接口加密了，怎么拿到真实数据。

这个案例的“某website”到底是个什么样的站点，其实不重要，重要的是它背后的加密模式非常普遍：混合加密体系。RSA 保护密钥，AES 保护数据，这种组合在如今的 Web 端数据保护中几乎是标配。理解了它的分析思路，你就掌握了同类场景的通用解法。

难度定位中等很准确——单纯 AES 的话，只要能找到密钥和偏移量，几分钟就能解开；单纯 RSA 的话，最多就是找公钥、调库去加密请求参数。但两者叠加，就必须先弄清楚它们之间的协作关系：谁加密谁？谁传递谁？密钥怎么生成？这些逻辑搞不清楚，代码写得再漂亮也是白搭。

1.2 适用人群与前置技能

这个案例适合什么水平的人来学？我自己的判断是：已经能熟练用 requests / httpx 写常规爬虫，但还没真正接触过前端 JS 逆向的开发者。基础要求有四样：

第一，Python 基础语法没问题，至少能看懂类、函数、异常处理，知道怎么装第三方库（pycryptodome这类加密库你得会装）。

第二，浏览器开发者工具的基本操作得会，会看 Network 请求列表、Headers、Payload，会搜 JS 文件、会打断点。

第三，对 AES、RSA 这两种密码学算法的概念有所了解——不需要你把数学原理背下来，但得知道 AES 是对称加密、RSA 是非对称加密，知道密文长什么样（AES 输出是一串乱码或 Base64 字符串；RSA 输出通常更长，而且公钥加密会有长度限制）。

第四，耐心。解析加密接口这个东西，七分靠分析、三分靠编码。大部分时间都花在“找加密函数”上，而不是写 Python 代码。前半小时你可能什么都没写，就用鼠标在浏览器里点来点去，这很正常。

2. 混合加密机制与前端结构分析

2.1 为什么网站要搞 AES + RSA 双重加密

我见过不少初学者一看到加密就头大，觉得网站故意刁难人。其实换个角度想：如果你是网站开发者，要保护接口数据，你会怎么做？

只上 HTTPS？不够，因为 HTTPS 只保证传输链路安全，一旦有人模拟客户端直接发请求，服务端无法区分你是浏览器还是脚本。所以还得在应用层加一道保险。只用 RSA 加密？RSA 非对称加密有个硬伤：性能差，且明文长度受限。1024 位 RSA 最多只能加密 117 字节，2048 位也才 245 字节，一个完整的 JSON 响应体动辄几 KB，根本塞不进去。只用 AES 加密？AES 效率高、能加密任意长度，但对称加密的问题是密钥怎么安全地传递——你把 AES 密钥硬编码在前端 JS 里，逆向人员搜一下字符串就找到了；每次请求动态生成密钥，又得想办法告诉后端，如果随请求明文传输，相当于没加密。

于是混合加密就成了最务实的方案：用 RSA 加密 AES 密钥，用 AES 加密真实业务数据。明文数据体积大，交给对称加密处理；密钥体积小，交给非对称加密保护。速度快、安全性高、密钥也能安全传输。

这种设计不是某一家网站独创，而是 TLS/SSL 协议内部就在用的思路——只不过网站把它搬到了应用层。理解了这一点，你分析的时候就不会再问“为什么有两个加密函数”这种问题了，因为它们的职责天然不一样。

2.2 前端加密链路的常规走法

以我这次的案例为例，梳理一下前端处理数据的典型流程。你在浏览器里点一个按钮，触发某个数据请求，接下来发生的事情大致如下：

第一步，前端 JS 生成一个随机的 AES 密钥（通常是一个 16 字节或 32 字节的随机字符串，对应 AES-128 或 AES-256），再生成一个随机的偏移量 IV。

第二步，业务参数（比如查询条件、页码）用这个 AES 密钥加密，得到一个密文字符串。

第三步，用服务端预先下发的 RSA 公钥加密刚才那个 AES 密钥（有的还会把 IV 一起加密），得到另一个密文字符串。

第四步，两个密文一起塞进请求体里发给服务端。服务端收到后，先用 RSA 私钥解开 AES 密钥，再用这个密钥解开业务数据。

响应数据的方向相反但结构类似：服务端用同一个 AES 密钥加密响应体，或者重新生成一个密钥放进响应体里。

在浏览器里，你用 Network 面板看到的请求参数就是一堆看起来像t=U2FsdGVkX1+abc...&k=GbtSmXnQ...的东西，标准的密文外貌。看到这种结构，心里就该有数：这是典型的混合加密没跑了。

2.3 定位加密函数的三板斧

搞清楚流程之后，剩下的核心任务就是在成堆的 JS 代码里找到加密函数的位置。我不推荐一上来就全篇读 JS，那是灾难。我用的是三板斧：

第一板斧，搜英文关键词。因为加密相关的 API 名称基本是固定的，在浏览器的 Sources 面板里全局搜索（Ctrl+Shift+F），搜encrypt、decrypt、AES、RSA、CryptoJS、publicKey、setPublicKey这些词。绝大多数情况下，网站不会吃饱了撑的自己撸一个加密算法，都是引用成熟的加密库——最常见的就是 CryptoJS，因为它体积小、API 直观，前端工程师用起来几乎是标配。

第二板斧，搜结构化特征。加密出来的密文有固定格式，比如 AES 加密后的字符串常常以特定前缀开头，或者 Base64 编码后带有某些固定字符。你可以在 Sources 里搜请求包里那个t参数的完整值，很多工具类站点会把密文拼进日志或调试模式里，如果搜到了，直接打断点看调用栈。

第三板斧，从请求入口倒推。在 Network 面板里找到那条 API 请求，右键 → Save as HAR with content，或者直接在 Initiator 那一列看调用栈，点进去就是发起请求的函数，然后沿着函数找数据从哪里来、是否经过某个 handler 处理。

这三个方法配合起来，定位加密函数通常不需要翻遍整个 JS 文件。我在前面的实操中还用了一个小技巧：在 Search 面板里搜U2FsdGVkX1这个字符串。它是 CryptoJS 在 ECB/CBC 模式下加密后输出的固定前缀（是“Salted__”加密后的标志），看到它基本可以确定站点的 AES 是 CryptoJS 干的。

3. 核心加密细节拆解与搞定思路

3.1 AES 部分：模式、填充、密钥、偏移量

定位到 JS 加密函数之后，你需要从代码里读出四样东西：

算法模式。最常见的三种模式是 ECB、CBC、GCM。ECB 最简单，不需要 IV，同样的明文块加密结果相同，安全性稍弱但实现简单；CBC 需要 IV，每个密文块跟前一个块异或，安全性好得多；GCM 是带认证的模式，加密的同时能校验完整性，输出里会附带一个 tag。你在开发工具里看到mode: CryptoJS.mode.CBC就说明是 CBC。这是一个关键信息，Python 端必须一一对应。

填充方式。AES 是分组加密，固定 16 字节一组，明文长度不是 16 的倍数时就得填充。CryptoJS 默认是 Pkcs7（等价于 Python 里的 PKCS7 padding）。有些网站会图省事用 NoPadding，那就要求明文长度刚好是 16 的倍数，少见但遇到过。

密钥长度与生成方式。AES-128 对应 16 字节密钥，AES-256 对应 32 字节。密钥可能是硬编码在 JS 里的固定字符串，也可能每请求动态生成。需要重点判断的是：固定密钥直接提取；动态生成就得看它怎么生成（随机字符？时间戳拼接？某个接口下发？），然后决定在 Python 端是模拟生成还是从响应里取。

偏移量 IV。CBC 模式必须要有 IV，它可能是固定的，也可能随机生成。有的网站把 IV 跟密文放一起，有的单独放一个字段，有的用固定值写死在 JS 里。分析时注意分辨。

反过来想，Python 端做 AES 解密时，需要的信息无非就是这四个：算法模式、填充方式、密钥、IV。全都拿到了，代码就是模板性质的活儿。难的不是解密代码本身，而是确认这四个参数的过程。

3.2 RSA 部分：公钥格式与加密方式

RSA 在前端加密方案里承担的角色是“密钥传输”，从实操角度看需要搞清楚两件事：

第一，公钥从哪里来。常见有两种方式：一是硬编码在 JS 文件里，搜BEGIN PUBLIC KEY或者MIGfMA0GCSqGSI这类 Base64 前缀就能找到；二是通过某个配置接口动态下发。如果是后者，你可以先在浏览器里请求一次这个配置接口，拿到公钥字符串，然后直接写死在 Python 代码里——只要对方不换公钥，这个方案就能一直用。当然，严谨一点的做法是在 Python 里加一段“自动获取公钥”的逻辑，但那属于加分项。

第二，加密方式与填充模式。JS 里的 RSA 加密通常是RSA.encrypt(data, publicKey)，用 PKCS#1 v1.5 填充。但有些场景会用 RSA-OAEP（对应 SHA-1 或 SHA-256），Python 端要留意。另外还要注意公钥本身的编码格式：PKCS#1 开头是-----BEGIN RSA PUBLIC KEY-----，SPKI（也就是证书公钥格式）开头是-----BEGIN PUBLIC KEY-----。用 Python 的rsa库或pycryptodome处理时，需要按对应格式加载，不能混。

RSA 加密有个容易翻车的地方：每次加密结果不一样。因为填充算法带了随机数，所以同一个明文用同一个公钥加密两次，输出完全不同的密文。这不是 bug，是特性。你要是测试脚本发现两次结果不一致，别慌，正常的。

3.3 混合加密的实际协作逻辑

从前面两点可以推出网站的完整加密数据流，但有个细节经常被忽略：AES 密钥本身，到底是明文传给 RSA 加密的，还是被处理过的？

我这次解析的网站就有个小坑：JS 代码里生成 AES 密钥后，不是直接 RSA 加密，而是先做了一个字符串拼接（比如在密钥前面拼上时间戳或 session ID），然后整体 RSA 加密。不知道这个细节的话，你即使拿到了 RSA 私钥（这通常很难，所以通常走模拟请求路线），解出来的也不是真正的 AES 密钥。

这种情况下，比较聪明的做法不是去把 AES 密钥解出来，而是用 Python 完整模拟前端的加密流程：生成一个随机 AES 密钥 → 模拟拼接处理 → 用公钥加密 → 拼接请求参数 → 发请求。这样整个链路就能跑通，而且不需要知道服务端到底怎么解出来的。

理解了协作逻辑，你就能回答一个核心问题：如果我要在 Python 端重新实现这套加密，我需要保留哪些变量、模拟哪些处理？答案通常是三样：随机生成的 AES 密钥、随机的 IV（如果有）、RSA 公钥。前两个随机生成，第三个静态获取，全部齐活。

4. 实操过程与关键代码实现

4.1 环境准备与依赖安装

解析加密接口，Python 环境只需要三样东西：requests（或httpx）、pycryptodome、以及加密库的依赖项。

pip install requests pycryptodome

注意这里有个坑：pycryptodome和pycrypto不能同时存在。有些教程会让你装Crypto，那是老掉牙的pycrypto，早不维护了，而且导入名称很容易混淆。我的建议是统一用pycryptodome，导入名是Crypto，跟老库的调用方式兼容。如果装完发现导入报错，大概率是你之前装过pycrypto，先把它卸载干净再装。

另外，解析 JS 的时候可能会用到execjs（一个在 Python 里调用 JS 的库），但我的经验是能不用就尽量不用。execjs 需要在系统里装 Node.js 环境，运行效率不高，而且有的加密函数里有 DOM 操作，跑不动。纯 Python 重写加密逻辑，可控性最强，出了错也最容易定位。

4.2 抓包分析实战记录

我这次的模拟目标是一个匿名网站，就称它为“某website”。打开开发者工具，切到 Network 面板，点击页面上的“加载更多”按钮，很快看到一条POST /api/list请求。请求体长这样：

t: U2FsdGVkX1+4rXePn0fnK3vpP9gLJ5JhQ1N0K0oK0oK0oK0oK0oK0oK0oCg== k: GbtSmXnQvYd12W4Gn+0NGGk/Fr3nQpGpVz9cDsIdlB7NkuxRnOq0pQ==

t一眼看去就是 CryptoJS 的密文（带U2FsdGVkX1+前缀），k是典型的 RSA 加密输出——长度很长，而且字符分布没有明显的 Base64 特征。

接下来切到 Sources 面板，Ctrl+Shift+F 全局搜索U2FsdGVkX1，瞬间定位到一个名为crypto_lib.js的文件。点进去，果然看到了 CryptoJS 的引用和几个封装函数。

var key = CryptoJS.enc.Utf8.parse("a3f7d9e21b8c4a5f"); var iv = CryptoJS.enc.Utf8.parse("1a2b3c4d5e6f7890"); function encryptData(data) { var encrypted = CryptoJS.AES.encrypt(data, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return encrypted.toString(); } function encryptKey(aesKey) { var encryptor = new JSEncrypt(); encryptor.setPublicKey(PUBLIC_KEY); return encryptor.encrypt(aesKey); }

这个代码里信息量很大，我一条条拆给你看：

• AES 部分：CryptoJS.AES.encrypt(data, key, ...)说明业务数据用 AES 加密，密钥是硬编码字符串a3f7d9e21b8c4a5f，IV 也是硬编码1a2b3c4d5e6f7890，模式 CBC，填充 Pkcs7。这些信息在 Python 端直接照搬即可。

• RSA 部分：JSEncrypt()是常用的 RSA 库，setPublicKey(PUBLIC_KEY)表明公钥是全局变量或常量。在本例中我略微简化了——真实场景里公钥可能来自一个/api/public_key接口，但提取方式一样，复制字符串就行。

你可能注意到一个奇怪的点：既然 AES 的密钥和 IV 都硬编码在前端了，那还有必要用 RSA 加密吗？有的。因为这个实例是我为了说明问题而精简过的；真实场景里，key变量是每次请求动态生成的随机字符串，只有 IV 是固定的，所以必须通过 RSA 把动态密钥安全传给服务端。硬编码的情况也真实存在，但通常还会叠加一些额外参数参与加密，不会这么简单。思路要活，别把范例当模板。

4.3 Python 重写：请求参数的模拟构造

拿到了加密逻辑，现在要把它翻译成 Python 代码。我的习惯是分三步走：

第一步，写 AES 加密函数，对应 JS 里的encryptData：

import base64 from Crypto.Cipher import AES from Crypto.Util.Padding import pad def aes_encrypt(data: str, key: bytes, iv: bytes) -> str: cipher = AES.new(key, AES.MODE_CBC, iv) padded_data = pad(data.encode("utf-8"), AES.block_size) encrypted = cipher.encrypt(padded_data) return base64.b64encode(encrypted).decode("utf-8")

这里有两个要点：pad的时候要指定AES.block_size（16字节），正好对应 Pkcs7；加密结果要 Base64 编码，因为前端的encrypted.toString()默认输出 Base64 字符串，这样请求体里才不会是乱码。

第二步，写 RSA 加密函数，对应encryptKey：

import base64 from Crypto.PublicKey import RSA from Crypto.Cipher import PKCS1_v1_5 RSA_PUBLIC_KEY = """-----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7... -----END PUBLIC KEY-----""" def rsa_encrypt(data: bytes) -> str: public_key = RSA.import_key(RSA_PUBLIC_KEY) cipher = PKCS1_v1_5.new(public_key) encrypted = cipher.encrypt(data) return base64.b64encode(encrypted).decode("utf-8")

注意，这里的data是字节串。如果你要加密的是字符串，先encode("utf-8")再传入。用PKCS1_v1_5这个类是因为前端JSEncrypt默认就是 PKCS#1 v1.5 填充；如果你在 JS 里看到的是RSA-OAEP，那就要换成PKCS1_OAEP，别搞混。

第三步，组装请求函数。模拟前端流程：生成随机 AES 密钥（16字节）→ 用 AES 加密业务参数 → 用 RSA 加密 AES 密钥 → 拼接请求体：

import json import secrets def build_request_params(business_data: dict) -> dict: # 生成随机 16 字节 AES 密钥 aes_key = secrets.token_bytes(16) # 固定 IV，从 JS 代码里提取 iv = b"1a2b3c4d5e6f7890" # AES 加密业务数据 data_json = json.dumps(business_data, ensure_ascii=False) t = aes_encrypt(data_json, aes_key, iv) # RSA 加密 AES 密钥 k = rsa_encrypt(aes_key) return {"t": t, "k": k}

这个地方有个容易踩的坑：secrets.token_bytes(16)生成的是原始字节，但加密的时候要注意类型对齐。我见过不少人在这一步栽跟头，报错说bytes和str无法拼接或者encrypt()参数类型不对。统一原则是：AES 密钥在加密函数里用字节串，在 JSON 序列化对象时不用管类型，反正最后都是 Base64 字符串传出去。

第四步，发起请求并解析响应：

import requests def fetch_list(page=1): params = build_request_params({"page": page, "page_size": 20}) resp = requests.post( "https://某website/api/list", data=params, headers={ "User-Agent": "Mozilla/5.0", "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8" } ) return resp.json()

基于我这次的实际踩点来看，这个流程跑通之后，响应体里如果有加密内容，你就需要再写一个 AES 解密函数来处理——方向反过来而已，逻辑对称。我给出的这些代码片段，可以直接整合进你自己的请求工具类里。

4.4 响应解密的特殊情况

刚才说的是请求参数加密，但真实场景里响应体经常也是加密的，只是加密方式有所不同。常见的情况有三种：

第一种，响应体直接用同一个 AES 密钥加密，密钥由前端生成并随请求传给服务端，服务端用同一个密钥加密响应。这时你只要在请求前把密钥保留在内存里，解密时用同一个密钥即可。

第二种，服务端用 RSA 公钥加密后的 AES 密钥放在响应体某个字段里，但私钥你拿不到，这时没法解开——除非服务端用的公钥和前端是同一套，且私钥泄露了。这种情况一般只出现在测试环境，别指望生产环境给你这个机会。所以遇到响应加密，优先考虑“请求时自己生成的密钥”这种模式，那才是可解的。

第三种，服务端响应里直接明文带上 AES 密钥，但密钥用客户端公钥加密了——这在 Web 端基本不可能，因为客户端没有私钥。反过来，如果服务端用两个公钥加密（一个给浏览器留作响应解密），那思路就变成找另一个公钥的对应私钥，难度直接跳级，不在“中等难度”范围内。

碰到响应加密，我的建议是：先理清密钥的流转方向。密钥流向是“服务端 → 客户端”还是“客户端 → 服务端”，决定了你能不能解。如果是后者，只要保留请求时生成的密钥就够了。

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

5.1 加密结果对不上？先从四要素逐项核对

这是我被问得最多的问题。代码写好了，请求发出去，服务端返回{"code": 400, "msg": "data error"}，或者干脆 500。这时候别急着怀疑人生，按顺序排查：

第一，确认算法模式。检查 JS 里的mode:到底是 CBC 还是 ECB。CBC 需要 IV，ECB 不需要也不能填 IV。如果你在 ECB 模式下强行传 IV，Python 端会直接报错；反过来，CBC 模式不传 IV 则解密结果会是乱码。这类错误最常见，基本上占了排查量的四成。

第二，确认填充方式。Pkcs7 是最普遍的默认值，但有些网站会用 ZeroPadding（即用\x00填充）。这两种方式加密出来的密文长度可能一样，但内容不同，解密必然失败。Python 端pad函数不带style参数默认就是 pkcs7，不需要额外指定。

第三，确认密钥和 IV 的编码。很多人栽在这里：JS 里写的CryptoJS.enc.Utf8.parse("a3f7d9e21b8c4a5f")含义是将该字符串的 UTF-8 字节作为密钥，所以 Python 端要b"a3f7d9e21b8c4a5f"（16字节），而不是对这个字符串做 MD5、SHA256 之类的哈希。不要画蛇添足。同理，IV 也是原始字节串。

第四，确认数据进出格式。AES-CBC 在 JS 端的encrypted.toString()输出的是 Base64 字符串，所以在 Python 端解密时，输入得先base64.b64decode()成字节串。这个步骤漏了，解出来一定是乱码。

5.2 RSA 加密常见报错与解决

报错一：ValueError: RSA key format is not supported

原因十有八九是公钥字符串的格式不对。公钥开头是-----BEGIN PUBLIC KEY-----还是-----BEGIN RSA PUBLIC KEY-----？前者对应 SPKI（SubjectPublicKeyInfo），后者对应 PKCS#1。RSA.import_key()两个都能解析，但如果公钥是从 JS 变量里直接复制出来的，可能在复制过程中丢了换行符，补全换行即可。

报错二：TypeError: can't concat str to bytes

这是类型混用。PKCS1_v1_5.encrypt()要求传入字节串，你传了字符串。解决：data.encode("utf-8")。

报错三：Data too long for key size

RSA 加密有明文长度上限。我的一个真实案例里，有人把整个 JSON（几百字节）直接塞进 RSA 加密，必然报错。碰到这种情形，说明你在写代码的时候搞混了方案：应该是 AES 加密大块数据，RSA 只加密 AES 密钥这个小块。回头重新理一遍流程。

5.3 解密结果乱码的三种可能

解密函数写对了、没报错，但输出的东西看起来像天书。这种情况也常见，按可能性排序：

第一，Base64 解码出问题。解密前漏了 base64 解码，直接把明文当密文传进去，出来的自然是乱码。

第二，密钥/IV 错误。密文解出来了，但内容是垃圾字节。检查密钥是不是多了一个空格、少了一个字节。这里有个自查技巧：AES 解出来的原始字节如果能看见{或<开头，说明密钥对了大半，剩下的乱码通常是编码问题（直接用字节转字符串前要指定utf-8）。

第三，模式搞混。用 CBC 的 IV 去解 ECB 的密文，肯定不对。反之亦然。

5.4 反爬封控时的实操应对

加密接口解析成功不代表能高枕无忧。“某website”这类站点往往还配置了请求频率限制、指纹检测。实际操作中我总结了几条经验：

控制抓取频率。加time.sleep(random.uniform(2, 5))是基础操作，不要对着接口每秒钟打几十次。原则上频控的第一触发点就是请求频率，不是你模拟得不够像，是你太贪心。

完整带上请求头。至少带上User-Agent、Referer、Origin、Accept-Language。有些站点对缺失请求头会直接拒绝，但它们并不在意你是不是真实浏览器——只要头齐了就能过。

留意 Cookie 的生成逻辑。有的加密接口在请求前需要先访问首页获取 cookie（比如sessionid），再带着这个 cookie 请求数据接口。如果你省略了这一步，请求参数加密就算完全正确，服务端也会认为你不是正常用户。

必要时处理 JS 环境的浏览器指纹。如果对方的检测做到这层，你就要上 Playwright / Selenium 了。这个案例作为入门级实例来说，指纹检测算是超纲内容，真正遇到再深入也不迟。

5.5 判断网站加密复杂程度的快速方法

分享一个我在决定是否接单时的经验判断法。打开一个目标接口，看它的请求体和响应体，然后做三件事：

一看请求参数里有没有固定前缀（比如U2FsdGVkX1+）。有 —— AES 加密，最轻量。

二看有没有一个特别长的参数（比如超过 200 字符）。有 —— 大概率是 RSA 或 AES+RSA 混合。这时的攻坚重点是找到 RSA 公钥。

三看响应体里有没有密文。有 —— 还要再解一层，工作量翻倍。

按这个方式分类，你大概能在五分钟内判断出目标站点的难度等级。加密并不可怕，可怕的是不知道从哪下手；而有经验的逆向者，永远是从加密算法的特征入手。

6. 扩展思考与后续优化方向

6.1 当自动化的高峰期来临时

加密解析做完了，代码能跑了，这只是完成了整个爬虫工程的前半段。数据源有了，还要考虑数据存储、去重、增量更新、异常采集、代理 IP 池管理这些常规需求。加密接口只是技术栈里一个环节，它不是终点。

我认识的不少开发者，都在攻克加密接口这一关后，开始考虑如何让整个采集流程更工程化——把加密逻辑封装成独立模块、加缓存、加重试机制、加日志监控、定时启动任务。有这些意识的人，往往能在项目规模变大后少吃很多苦头。

6.2 从被动逆向到主动对接的思考

解析加密接口这件事，本质上是“在对方的规则里找到自己的路”。真正成熟的方案，往往不是硬碰硬地去模拟请求，而是考虑有没有官方的数据开放接口、合作授权、或者合规的数据源。逆向加密接口适合在学习和研究阶段；等到真正需要稳定的生产环境，我建议还是优先探索合规途径，这不是道德绑架，而是稳定性和法律风险的综合考虑。

当然，学习阶段，“某website”这类加密站点是个极佳的练手对象，它的加密强度适中，既能让你体会到逆向分析的乐趣，又不至于把你困在源码里出不来。

6.3 进一步练习的思路

学会了 AES+RSA 混合加密的解析，你可以挑战几个升级方向：

一是试试带签名参数的接口，有些站点在加密的基础上还会对参数做 MD5 签名，这时你需要额外定位签名函数。

二是试试加密逻辑被混淆过的站点，JS 变量名全部变成了_0xabc123这种形态，定位难度直线上升，需要借助反混淆工具。

三是试试响应体加密且密钥完全由服务端动态生成的接口，这种场景下你要去分析服务端密钥的分发逻辑，可能需要从某个配置接口提前拉取密钥。

一步步升级，你会发现加密接口这块的知识体系是螺旋上升的，每次破解都让你对浏览器的执行机制、密码学的工程应用有更深的理解。

最后分享一个经验：做这类型任务，永远不要让代码量成为指标，让“找出答案的速度”成为指标。同一个接口，你写 200 行代码、踩了 3 个坑、花了 2 小时跑通，跟你写 80 行代码、没踩坑、40 分钟跑通，收获完全不一样。前者是体力活，后者才是技术活。我个人的习惯是每解析完一个站点，就顺手写一篇笔记，把加密函数截图、参数流转路径、踩坑记录都整理好——这东西过半年你再回来看，就是最宝贵的技术资产。