Bun canary AOT 启动报 returns is not defined

bun build 已经成功，独立可执行文件一启动却在 /$bunfs/root/ 下抛出 ReferenceError: returns is not defined。源码里没有叫 returns 的变量，只有 JSDoc 的 @returns 时，应检查是否启用了 AOT。

这条具体故障见于 Bun 1.4.4-canary.1+da867c60b 的 CommonJS 输入。普通运行可用，AOT 产物失败；不能据此宣称正式 Bun 1.4.4 或所有独立编译方式都有相同问题。

先回到抛错文件的注释

触发条件包括 CommonJS 文件中的 JSDoc @import，以及后面的 @returns。受影响路径可能让注释内容逸出为实际代码，最终把 returns 当作运行时标识符。依赖链里即使只是邮件样式处理或 HTML 转换，也可能在首次加载解析库时失败。

保存完整 Bun 版本、构建参数和原产物，沿堆栈确认出错文件属于哪个依赖。再比较同一份锁文件、同一入口在普通运行与 AOT 构建后的表现。不要直接在全局定义 returns，那只会遮住第一个被错误生成的标识符。

如果源码确实写了一个没有声明的变量，或堆栈来自手工生成的业务代码，则仍应按正常的 ReferenceError 排查，不能因为报错词相同就判断是注释解析异常。

将 AOT 从构建链中单独隔离

先在独立输出目录去掉 --aot，保留原来的入口、目标平台和其他必需选项。需要单文件分发时，可评估普通的 --compile 路径；例如，下面只展示非 AOT 独立构建的基本形状：

bun build ./cli.ts --compile --outfile ./dist-without-aot/mycli

将示例入口和输出位置换成项目已有的构建约定，不能覆盖唯一可回退的产物。普通运行成功是定位线索，不自动证明非 AOT 独立产物成功；生成后必须在目标运行环境验证启动和真实功能。

不要把删除依赖里所有 @returns 当作常规修复。直接改 node_modules 不易复现，也可能被下一次安装覆盖。若确实需要维护依赖补丁，应有最小修改、补丁文件和锁定版本，并重新核对类型工具及构建输出；它不是给所有 JSDoc 做清洗的理由。

验收要经过实际出错的依赖路径

可执行文件能打印版本号，可能还没有加载导致故障的库。保留会触发原依赖的输入，核对转换结果和退出状态，再检查异常输入是否仍按原约定报错。还应确认分发包里放入的是本次非 AOT 产物，而不是先前失败的缓存文件。

恢复 AOT 前，应在拟采用的版本上覆盖相同的 CommonJS 注释形状和业务入口。除了构建成功，还要确认独立可执行文件真正经过原来出错的依赖路径。