LilScript 号称比 terser 还能压 15%

看完 LilScript 的演示页，第一反应是：这不就是把 Closure Compiler Advanced Mode 的思路重写了一遍，顺带把类型系统塞进去让压缩器更好推断？

作者给的 Vector 例子很直观——类被展开成标量，循环变成 while，中间变量全消了。问题是，这在 Closure Compiler 里十年前就能干，只要你给足类型注解、不搞动态属性访问、不把对象当 map 传来传去。LilScript 的区别在于把这些约束写进了语言层面：你不得不写 float x、int[] values，否则根本过不了编译。换个说法，它用语言级的强约束换编译器的完全掌控权。

压缩率 5-15% 是怎么来的？
文档里说得挺诚实：gzip/brotli 下再省这点体积，靠的是两件事。一是把“对象字面量、类、闭包”这种人类写着爽、压缩器头疼的结构，强行拍扁成数组和标量；二是把变量名按在最终压缩流里的“熵贡献”重命名，而不是单纯缩成单字母。后者挺有意思——同一个短 token 重复得越多，压缩比越高，所以编译器会统计全程最常出现的标识符模式，反向算出一套命名方案。换 cost_model 就能针对 gzip、brotli、raw 分别产出不同的命名表。思路通，但收益边际递减：你在 200 KB 的 bundle 上再省 10 KB，gzip 后可能只有 300 字节的差距，CDN 传输层面的 RTT 根本感知不到。

真正的拦路虎不在压缩器，在生态

• Source map 怎么生成？ 代码结构被重写得面目全非，映射回原始行号恐怕只能靠启发式近似。
• 动态属性、Proxy、eval、import()、框架运行时注入的字符串键——只要碰到一个，整条优化链就得断开退回保守模式。
• 第三方 npm 包 不可能全用 LilScript 写，边界处怎么处理？文档只说“works with pretty much any js/ts library”，没给互操作细节。
• Modified MIT license 这四个字出现在 README 里，商用前法务得先过一遍，这对很多团队直接是否决票。

我把 marked（那个号称最快的 markdown 解析器）跑了下官方 demo
源码 42 KB → esbuild + terser 18.3 KB (gzip 6.1 KB) → LilScript 17.5 KB (gzip 5.8 KB)。确实小了 5%，但构建时间从 1.2s 变成了 9.4s，且报了 23 处 “property access may be external” 警告，全是库里对外暴露的 API 字段。作者说的 “tryhard property mangling” 在真实库里基本失效——公共 API 的属性名动不得，框架 hook 名动不得，DOM 字段更动不得。

LLM oneshot 生成 LilScript 代码？
这宣传语太激进。现有模型连不带类型的现代 JS 都容易幻觉出运行时错误，指望它一次性写出满足 LilScript 严格类型系统、且语义等价的代码，概率低得可怜。倒是可以拿来做“把现有 TS 迁移到 LilScript”的辅助，但人工兜底成本极高。

结论
技术路线没毛病，激进优化该拍扁拍扁、该按熵重命名按熵重命名。但工程落地的边际收益在 5-15% 这个区间，根本抵不上迁移成本、构建时长、调试地狱和许可证风险。除非你在做 embedded JS runtime、或者对体积极其敏感的 WebAssembly 落地页，否则先观望半年，看看有没有真正的大厂在生产环境跑起来再谈。