TypeScript是否存在Hoisting？与JavaScript的Hoisting有何差异？

一、TypeScript 中的 Hoisting 行为及和 JS 的差异 #

首先要明确核心边界：TS 是 JS 的超集编译层，不存在独立于 JS 的运行时，所谓的「提升类行为」分为两类，和 JS 原生 Hoisting 逻辑完全不同：

• 运行时 Hoisting 完全继承自 JS：TS 不会修改 JS 本身的 Hoisting 规则，最终输出的 JS 代码的提升行为和配置的编译目标版本完全一致。比如编译到 ES5 时，function 声明会被提升、let/const 不存在运行时提升；编译到 ES6+ 时，let/const 的暂时性死区规则和原生 JS 完全对齐。
• 编译期的声明可见性是 TS 特有静态逻辑：TS 会在类型检查阶段提前扫描整个作用域内的编译期实体（包括接口、类型别名、枚举、命名空间等），这些实体不会输出到最终的 JS 代码中，它们的「可提前引用」是编译器扫描符号表的结果，而非 JS 引擎执行层面的 Hoisting。

两者核心差异：JS 的 Hoisting 是引擎执行代码时的运行时行为，会直接影响代码执行结果；TS 的编译期可见性是编译工具的静态分析逻辑，仅作用于类型校验和转译环节，不会影响最终运行时的任何行为。

二、示例代码可正常转译的底层逻辑 #

先拆解示例代码结构：

// 第1行：运行时调用
getCarDetails({name: 'Xyz', topSpeed: 300})

// 第3行：运行时函数声明
function getCarDetails(carDetails: CarDetails) {
  console.log(carDetails.name);
  console.log(carDetails.topSpeed);
}

// 第8行：纯编译期接口声明
interface CarDetails {
  name: string;
  topSpeed: number;
}

这个现象和 TS 特有的 Hoisting 无关，是两个独立逻辑叠加的结果：

1. 第1行的函数调用合法，是 JS 原生函数声明 Hoisting 导致的——function 声明的提升是 JS 固有规则，哪怕不写 TS，纯 JS 这么写也能正常执行。
2. 第3行使用后置的 CarDetails 接口不报错，是 TS 编译器的全量扫描逻辑导致的：TS 在做类型检查时，会先遍历整个当前文件的顶层作用域，把所有编译期声明的信息存入符号表，之后再逐行做类型校验。哪怕接口写在文件最底部，编译器也已经提前收集到了它的结构信息，可以关联到前面的类型引用上。

注意：这种后置引用的能力仅适用于同一个编译单元内的顶层编译期实体。如果是跨文件的类型引用，依然需要正确配置 import、types 路径等，不能随意跨文件引用后置声明的类型。
反例验证：如果把示例里的函数声明改成 const getCarDetails = (carDetails: CarDetails) => {}，TS 会直接抛出「变量在赋值前被使用」的错误，完全对齐 JS 的暂时性死区规则——这也能证明 TS 不会对值类型的运行时实体做额外的提升处理。

内容的提问来源于stack exchange，提问作者atish