题干与适用场景
一个前端工具链团队维护大型 TypeScript 应用，某个分析模块在导入时注册全局监听器并读取环境配置，导致首屏启动变慢。团队想用 TypeScript 5.9 支持的 import defer 延后副作用，但构建产物仍需运行在不支持该语法的旧运行时。请解释模块加载、模块求值、访问触发点和迁移闸门。
TypeScript 5.9 文档说明，import defer 只允许命名空间导入；模块及其依赖会先被加载，但模块代码要到访问命名空间成员时才求值。TypeScript 不会把它降级转换，只有 preserve 或 esnext 模块模式适合直接保留该语法。
面试官考察点
面试官会关注你是否区分加载与求值、静态导入与动态导入，是否能识别全局注册和环境读取等副作用。高质量回答还应覆盖 bundler、旧浏览器、SSR、预加载、测试隔离和回滚策略，而不是只把 import defer 当成更短的懒加载写法。
回答前需要澄清的问题
- 目标运行时和 bundler 是否原生理解
import defer？ - 模块的副作用能否安全延后，还是必须在启动阶段完成？
- 访问哪个导出会触发求值，是否有隐藏的顶层访问？
- SSR、客户端 hydration、预加载和测试是否要求确定的执行顺序？
- 迁移失败时能否切回普通静态导入或动态
import()？
30 秒回答
“我会先把 import defer 定义为延后求值，不把它等同于动态加载。TypeScript 5.9 要求命名空间导入，模块资源仍会加载，第一次访问命名空间成员才执行模块代码；编译器不会为旧运行时自动降级。因此我会先审计顶层副作用和 SSR 顺序，在支持该语法的 bundler 与运行时中做小流量实验，同时保留普通导入或动态 import() 的开关。只有构建、hydration、性能和副作用测试都通过，才扩大范围。”
分步骤深入解答
1. 先固定语义和版本
记录 TypeScript 5.9 版本、目标模块模式和 TC39 提案状态。回答中明确：资源加载与模块求值是两件事；import defer 延后后者，不能承诺网络请求一定延后。把这两个时间点分别打点，避免用首屏网络瀑布图推断代码没有执行。
2. 说明语法边界
只有命名空间导入可以延后求值，不能写默认导入或具名导入。访问命名空间属性时触发模块求值，因此成员读取本身成为可观察的执行边界。
import defer * as analytics from "./analytics.js";
// 模块文件已经被加载，但顶层注册尚未执行。
export function openPanel() {
analytics.start(); // 第一次访问成员时触发求值。
}如果调用点需要 analytics.start 之前就完成全局注册，延后求值会改变行为；此时应该保留普通导入，或把初始化改成显式函数。
3. 与动态 import 对照
动态 import() 通常返回 Promise，并把加载和求值放进异步流程；import defer 保持静态模块关系，资源可提前加载，却延后顶层代码执行。两者在错误传播、预加载、打包切分、SSR 和测试时序上不同，不能互换名称后直接比较首屏指标。
4. 检查副作用和访问图
列出顶层副作用：事件监听器、单例注册、环境变量读取、polyfill、遥测初始化和缓存填充。沿着所有命名空间成员访问点画图，找出 hydration、路由预取或测试 setup 中的隐式访问。若必须控制顺序，把副作用搬入显式 initialize()，让调用方决定时机。
5. 处理构建与运行时兼容
TypeScript 不会把 import defer 降级。为支持旧运行时，应确认 bundler 能转换或拒绝该语法；不能转换时保留普通导入/动态 import() 实现。CI 至少覆盖目标浏览器、Node SSR、开发服务器、生产打包、source map、代码分割和错误边界。
6. 设置上线与回滚闸门
用功能开关选择 deferred、静态和动态三种路径，记录首屏交互延迟、模块求值耗时、重复初始化和 hydration 错误。任何顺序变化、旧运行时语法错误或指标回退都关闭开关并回到稳定导入；不要在提案或工具链仍变化时修改公共包的模块契约。
高质量示范回答
我会先确认 TypeScript 5.9 与目标运行时的支持矩阵，再把导入模块的顶层副作用列成清单。import defer 只支持命名空间导入，模块可以先加载，第一次访问成员才求值，TypeScript 不负责降级；因此网络加载、执行时机和动态 import() 必须分别测量。实验同时覆盖 SSR、hydration、旧浏览器、bundler、测试隔离和重复初始化，并用功能开关保留普通导入回滚。只有语义顺序、构建产物和性能数据稳定后，才扩大迁移。
常见错误
- 把
import defer当成动态import()→ 忽略静态依赖与 Promise 时序 → 分别验证加载、求值和错误传播。 - 使用默认或具名导入 → 违反 TypeScript 5.9 的语法边界 → 只用命名空间导入并在访问点触发。
- 假设 TypeScript 会自动转译 → 旧运行时直接语法失败 → 验证 bundler 转换能力并保留回退路径。
- 忽略顶层副作用 → 监听器、polyfill 或遥测初始化时序改变 → 改成显式初始化或保留普通导入。
- 只看首屏网络请求 → 资源加载提前并不代表代码执行提前 → 分别记录加载与求值时间。
追问及应对
为什么 import defer 只允许命名空间导入？
命名空间对象提供明确的属性访问边界；默认或具名导入会在绑定阶段暴露具体值，无法保持“第一次访问成员才求值”的统一语义。
它和代码分割是同一件事吗？
不是。代码分割决定资源如何拆包和加载，import defer 主要改变模块代码何时求值；资源可能已经被加载或预取。
SSR 应该如何处理？
确认服务端和客户端的求值顺序一致，避免服务端已注册全局状态而客户端尚未注册。必要时在服务端保留静态导入，或把初始化改成显式、可重复调用的函数。
如何测试副作用只执行一次？
在隔离的测试进程中记录模块初始化计数，分别覆盖未访问、首次访问、重复访问、并发访问和测试 teardown，验证单例与监听器不会重复注册。
什么时候不应采用它？
当运行时或 bundler 不支持、模块必须在启动阶段完成副作用、SSR 顺序不可改变，或性能收益无法重复时，继续使用普通导入或动态 import()。