北宋人前阵子在分析某出行平台网页端的时候，我盯着一个叫 wsgsig 的请求参数看了很久。如果你也做过这类平台的接口调试，大概率会在翻请求头或者 params 的时候撞见它——一串长得有点像 Base64、又混着十六进制字符的字符串。第一次见的人很容易把它当成普通的 token 或者 session id，但实际上它是整个请求链路里最关键的一层签名校验。我当时最早排查问题的时候，就是因为忽略了它的生成规则，导致模拟请求一直报参数错误，折腾了两天才找到症结。
这篇文章我不打算堆理论，就围绕 wsgsig 这个网页参数，把它的定位方式、生成逻辑的通用分析思路、以及我在实际调试中踩过的坑，完整梳理一遍。内容适合正在做网页端接口分析、前端加密参数逆向、或者对风控签名机制感兴趣的开发者阅读。我会尽量把分析过程拆成可操作的步骤，让你在自己电脑上也能顺着这套思路把问题跑通。
1. 先搞清楚 wsgsig 是什么，以及它为什么重要
1.1 从一次失败的模拟请求说起
当时我在本地用脚本模拟某出行平台的网页端行为，目标是拉取一个基础的列表数据接口。肉眼观察浏览器的请求，发现 query string 里除了常规的 page、city、keyword 之外，还有一个长字符串，参数名就叫 wsgsig。我一开始想当然地认为它只是某种固定的令牌，于是把它复制粘贴到脚本里，结果请求直接返回 403。更让人恼火的是，同样的参数复制到浏览器的另一个 Tab 里重放，居然也会失效。
这个现象本身就说明了一个关键问题：wsgsig 不是一个静态值，它和请求的其它参数、时间、甚至运行环境有强绑定关系。从名字猜测，sig 是 signature（签名）的缩写，wgs 大概率是某个业务模块的代号前缀。这种命名方式在很多互联网大厂的前端工程里都很常见——每个业务线用自己的缩写打头，后面跟功能后缀，比如 xxxsig、xxxtoken、xxxid。
1.2 这类签名参数解决的问题
理解了命名，就要理解它存在的目的。在网页端，后端接口并不能天然相信来自浏览器的每一次请求。如果完全不加防护，任何人都可以构造请求轻松拉走全量数据，甚至通过批量刷接口来影响业务。于是前端工程师会在请求发出前，利用一段 JavaScript 代码把请求参数、时间戳、设备标识等信息进行拼接和加密，生成一个签名串。这个签名串随着请求一起发送到后端，后端用同样的算法和密钥重新计算一遍，比对结果是否一致。如果不一致，直接判定为非法请求并拒绝服务。
wsgsig 扮演的就是这个“签名”角色。它的存在，意味着任何想正常调用该平台接口的程序，都不能绕过前端 JS 直接裸调接口，必须先把生成签名的那段逻辑完整复现出来。这既是风控的一部分，也是技术分析的突破口。
1.3 分析 wsgsig 前的准备工作
不管你是出于学习目的还是工作需要，在开始分析之前都要把环境准备好。我建议至少准备以下几样东西：
- 一台装了最新版 Chrome 或 Edge 的电脑，最好控制变量，不要开太多无关插件，否则会在分析调用栈时增加噪音。
- Chrome DevTools 要熟练使用，特别是 Sources 面板的断点调试、Call Stack 查看、Scope 变量监视。
- 一个轻量级的本地抓包工具，比如 Fiddler 或 Charles，也可以直接用 Chrome 自带的 Network 面板，但有些场景下需要修改请求做重放验证，抓包工具会更方便。
- 如果涉及 JS 代码阅读和格式化，可以用 webpack 工程里常见的 sourcemap 还原，或者直接用 Beautify 插件把压缩代码格式化。
准备工作不需要太复杂，核心就一句话：你需要在浏览器里观察到请求的完整生命周期，并且能控制它执行到一半停下来，看看到底是谁、用什么东西、生成了这个 w