【开源自荐】jsunpack：把几乎不可读的前端产物，变成可以理解的代码
一、前言：为什么会有 jsunpack
做前端久了，我经常会遇到这样一个场景：
“这个效果是怎么做出来的？”
“这个页面到底用了什么框架、什么技术栈？”
“能不能只看产物，大概判断它的实现方式？”
现实是——
你能拿到的，往往只有浏览器里加载的那一堆 JS 产物。
而这些代码：
- 已被多轮打包、压缩、Tree Shaking
- 变量名被彻底抹掉
- 字符串被混淆、拆分、加密
- 框架代码与业务逻辑混在一起
即使你很懂前端，打开之后也常常是👇
“这不是代码，这是噪音。”
我自己在技术调研、效果学习、逆向分析中反复遇到这个问题。
市面上也试过不少工具，但结论很一致：
- 只能格式化
- 或只处理某一类混淆
- 对真实项目（多 chunk、多入口、框架混杂）基本无效
没有一个工具，是围绕「让人真正读懂前端产物」来设计的。
这就是 jsunpack.tech 出现的背景。
二、jsunpack.tech 在做什么
jsunpack.tech 做的不是“还原源码”，
而是 把前端构建产物，变成「可以被人理解和分析的代码」。
它的核心目标只有一个：
让你看懂：
- 用了什么技术栈
- 项目大概怎么组织
- 关键逻辑在哪
- 核心效果是如何实现的
核心能力概览
👉 在线地址：www.jsunpack.tech/
👉 前端开源：github.com/zhongguagua…
1️⃣ 前端产物结构化解析
上传或粘贴打包后的 JS 产物后，平台会自动：
- 拆分模块结构
- 识别入口与核心模块
- 还原更合理的目录与文件关系
📷 （被混淆的源码）
📷 （结构视图截图）
2️⃣ 自动识别技术栈 & 第三方依赖
我们会从产物中分析并标注：
- 使用的框架（React / Vue / PixiJS / Three.js 等）
- 第三方库及其职责
- 推断对应的
package.json依赖结构
📷 （依赖识别截图）
这一步对技术选型分析、学习陌生项目非常有帮助。
3️⃣ 针对混淆代码的可读性还原
不是简单 prettier，而是：
- 变量语义恢复（在可推断范围内）
- 控制流整理
- 字符串与表达式展开
- 去除无意义的混淆噪音
目标不是“像源码”，
而是 “像一个人能顺着读下去的代码” 。
三、一个真实示例：拆解一个 H5 游戏
我在之前的文章和视频中演示过这个案例👇
新西兰旅游局的一个 H5 找物小游戏
ispy.heihei.resn.co/
这是一个交互非常完整的项目：
- 地图拖拽 / 缩放
- 倒计时
- 关卡与积分系统
- 动画与资源加载
直接看产物几乎无法下手。
通过 jsunpack.tech 解析后，可以很清晰地看到：
GameApplication：Pixi 应用初始化LoaderScreen：资源加载CountdownScene：倒计时逻辑HiddenObjectGame：核心玩法
📷 （模块结构截图）
虽然因为打包丢失了部分环境与构建配置，
项目无法直接运行，
但用于：
- 学习实现方式
- 判断技术方案
- 拆解核心逻辑
已经完全足够。
四、技术边界与使用原则
这里必须说清楚几件事：
- ❌ 不提供破解、绕过授权相关能力
- ❌ 不以 100% 还原源码为目标
- ✅ 仅支持 合法合规的技术研究与学习场景
这是一个客观事实：
多轮打包与混淆之后，
部分语义信息本身就是不可逆的。
jsunpack.tech 当前阶段解决的是：
“能不能被人理解”
而不是：
“能不能一键拿去跑”
五、目前进展 & 使用情况
截至目前：
-
已服务 3000+ 开发者
-
完成 10000+ 次解析
-
使用场景主要集中在：
- 技术调研
- 架构分析
- 方案学习
- 线上问题排查
六、后续计划
接下来我会持续推进：
- 更复杂真实项目的解析稳定性
- 更多打包 / 混淆场景支持
- 逐步整理并公开核心实现思路
- 在掘金持续分享 JS 反编译实战与踩坑经验
写在最后
jsunpack.tech 并不是一个“宏大叙事”的项目，
它来源于一个非常具体、也非常真实的问题：
“我只是想看懂这个前端产物。”
如果你也曾因为看不懂 JS 产物而卡在：
- 技术决策之前
- 实现方案选择上
- 学习陌生框架时
那它也许真的能帮到你。
