Bun 1.4.0 旧 canary 热缓存后报 Missing 'default' export

脚本第一次能导入 SVG，原样运行第二次却报下面的错误，关闭运行时转译缓存后又恢复，可以检查入口缓存命中后的加载器选择：

SyntaxError: Missing 'default' export in module '/path/to/asset.svg'.

这里有一个明确的旧预览版故障：Bun 1.4.0-canary.1+cc40d7810 在 macOS arm64 上，入口文件达到缓存门槛后，热缓存路径会把后续未知扩展名当成 TSX 处理。正式版 Bun 1.4.0 的源码已经包含相应修正，不能把这个旧 canary 的表现写成所有 1.4 版本都存在的问题。

冷启动成功，热缓存命中失败

Bun 的文件加载器可以把未按源码处理的资源导入为文件路径。上述故障中，SVG 并没有突然丢失一个 JavaScript 导出；运行时在第二次执行时选错了加载器。

受影响路径有两个条件：入口文件足够大，能进入运行时转译缓存；下一次执行确实恢复了该缓存。该版本缓存入口的最小体积是 4 KiB，因此很短的示例可能无法触发。调试构建还可能主动丢弃恢复项，不能把“连续运行了两次”直接当成已经验证热缓存命中。

可以从实际错误文件、入口大小及启动环境判断是否符合这些条件。保持脚本、资源与锁文件不变，仅对一次受控启动关闭运行时转译缓存：

BUN_RUNTIME_TRANSPILER_CACHE_PATH=0 bun ./run.ts

这里的 run.ts 换成原入口，命令适用于 POSIX shell。它会执行该入口，先确认入口没有不可重复的业务写入；不能拿生产迁移脚本反复试。若应用由其他启动器运行，应把环境设置交给那个启动器，不能另换一条绕过原配置的命令来比较。

关闭缓存能区分一条路径，但不证明所有缺少 default 导出的报错都来自缓存。真正的 ESM 没有 default 导出、扩展名被项目加载插件接管，以及构建工具要求显式资源导入语法，都要按各自契约处理。

漏掉的是入口已加载状态

受影响实现只在正常输出转译结果的路径上标记入口已经加载。从缓存提前返回时没有更新这个状态，后续模块仍被误认成入口尚未加载阶段，未知扩展名便走向 TSX 回退路径。

同一个遗漏还会影响 require.extensions 自定义处理器：冷缓存使用自定义加载器，热缓存却可能落到默认处理。这是入口状态恢复不完整，不是要求把 SVG 改写成有 default 导出的 JS 文件。

已核对的正式 Bun 1.4.0 将状态更新放在这些提前返回路径之前，也包含未知扩展名的冷热缓存回归用例。仍使用旧 canary 的项目，应通过原来的运行时管理方式切换到包含修正的正式版本；其他受影响预览快照应核对具体提交，不能凭同一个 canary 版本前缀推断。

验收要覆盖真正的第二次运行

在可重复执行的受控入口中，保留原来的资源导入方式，分别检查冷缓存与真实热缓存下的退出状态、资源路径和依赖功能。用了自定义扩展名处理器的工程，也要确认处理器两次都被调用。

临时关闭缓存会增加重复转译工作，完成比较后应恢复原启动配置。无需清空所有 Bun 包缓存、删锁文件或重装整套依赖；它们会改变比较条件，也不能代替修正入口状态。