为什么会有 jsunpack.tech

这件事最早其实并不是为了做一个产品。

几年前，一个做前端的朋友找到我，问了一个看起来很简单的问题： “这个页面效果能不能实现？”

他负责的项目里，需要实现一个基于 three.js 的复杂交互动画页面， 目标网站的效果已经在那里，但团队里没有人能完整看懂它是如何实现的。

我们面对的是一堆已经不可读的代码

在缺少相关知识，且拿不到任何源码和构建配置的情况下， 我们只能从浏览器里实际加载的前端产物入手，尝试拆解它的实现方式。

结果很现实：所有代码都已经被打包、压缩，甚至经过了多轮混淆。 变量名被替换成无意义的字符，字符串被加密，控制流被刻意打散。

当时尝试过不少现成工具，但大多数只能做到格式化成功， 实际上依然无法阅读和理解。

很多时间并不是花在理解业务逻辑上， 而是消耗在一件很基础、却又绕不开的事情上： 把代码变得“像人写的”。

市面方案解决不了的问题

后来我系统性地尝试过市面上几乎所有相关工具，结论非常一致：

• 有的只能做代码格式化
• 有的只针对单一混淆点（例如字符串）
• 有的脚本能跑，但结果不可复用
• 对真实项目（多入口、多 chunk、框架代码混杂）几乎无效

没有一个工具，是围绕「如何让人真正读懂前端产物」来设计的。

从自用脚本，到一套流程

没有合适的解决方案，只能自己动手。

通过将 AST 规则体系与大语言模型的Agent流程混排能力结合， 形成了一套混合驱动的代码分析流程。

一开始只是为了把某一个项目跑通， 后来发现这套流程在不同项目中反复都能用得上。

后来在不同项目里反复遇到同样的问题， 我才慢慢确认，这并不是一次偶然的情况。 而是很多开发者、小团队、技术负责人都会遇到的共性问题。

jsunpack.tech 在做什么

jsunpack.tech 目前主要做的一件事是： 把几乎不可读的前端构建产物，转换成一个 结构清晰、逻辑可分析、便于理解的版本。

我们目前并不以 100% 还原原始源码为目标。 这是一个客观存在的技术边界： 在多轮打包和混淆之后，部分语义信息本身已经不可逆地丢失。

但这并不是一个“终点”。

当前阶段，我们优先解决的是「能不能被人理解」； 而更长期的研究方向，是逐步探索：

是否有可能，让还原后的代码不仅可读， 而且在一定条件下具备可运行性。

这仍然处在研究和探索阶段，涉及模块边界重建、 运行时依赖补全、构建环境推断、框架与业务解耦等问题。 它并不是一个短期内可以实现的能力， 这也是我们持续在投入精力研究的方向。

目前被用在什么场景

自上线以来，平台已经服务了超过 3000 名用户， 完成了 10000+ 次 深度解包与分析。

很多用户并不是为了“直接复用代码”， 而是用于技术选型、方案分析、实现学习或问题排查。

技术边界与使用原则

我们只支持合法、合规的使用场景， 包括技术研究、架构学习、安全分析与问题定位。

不提供任何绕过授权、破解商业保护相关的能力，

接下来会做的事情

• 提升复杂真实项目的整体还原稳定性
• 支持更多打包与混淆场景
• 逐步整理并公开可复用的技术实践经验

写在最后

jsunpack.tech 并不是一个宏大的叙事项目， 它只是来源于一个非常具体、也非常真实的问题。

如果你曾经因为看不懂前端产物而卡在技术决策之前， 或只是想搞清楚某个效果到底是如何实现的， 那它或许真的能帮到你。