17370845950

TypeScript 是 JavaScript 的静态类型扩展，所有合法 JS 代码都是合法 TS 代码；tsc 编译后生成纯 JS 并移除类型注解，运行时不依赖 TS，IDE 报红源于语言服务的静态分析而非运行时错误。

TypeScript 不是 JavaScript 的替代品，而是它的静态类型扩展——所有合法的 JavaScript 代码都是合法的 TypeScript 代码，但 TypeScript 在编译时会检查类型、接口、类结构等，提前暴露逻辑错误。

为什么 tsc 编译后 JS 还能运行，但 IDE 却报红？

因为 TypeScript 的类型系统只在开发和编译阶段起作用，tsc 默认把带类型的 TS 文件编译成纯 JS（去掉所有类型注解），运行时完全不依赖 TS。IDE 报红是基于 TS 语言服务的静态分析，不是运行时报错。

• 确保你打开的是 .ts 文件，而不是编译后的 .js 文件
• 检查是否启用了 VS Code 的 TypeScript 插件（默认已启用，但工作区可能禁用）
• tsc --noEmit 可单独做类型检查，不生成 JS，适合 CI 阶段验证
• 如果 no

  

  de_modules 中有类型声明缺失，可安装对应 @types/xxx 包

any 和 unknown 在函数参数中到底该选哪个？

两者都表示“类型未知”，但语义和约束完全不同：any 关闭类型检查，unknown 强制你显式断言或检查后再使用。

function processInput(val: unknown) {
  if (typeof val === 'string') {
    return val.toUpperCase(); // ✅ 安全
  }
  throw new Error('Expected string');
}

function badProcess(val: any) {
  return val.toUpperCase(); // ✅ 通过，但 runtime 可能报错
}

• 团队协作或第三方数据输入（如 API 响应、localStorage.getItem）优先用 unknown
• any 应仅用于临时迁移旧 JS 代码，且需加 TODO 注释限期替换
• unknown 无法直接赋值给其他类型，必须经过类型守卫（typeof、instanceof、自定义谓词函数）

为什么加了 strict: true 后大量 Object is possibly 'null' 报错？

这是 TypeScript 的严格空值检查（strictNullChecks）在起作用——它让 null 和 undefined 不再隐式属于每个类型，必须显式声明可空性。

• 修复方式不是关掉 strict，而是用可选链 ?. 或空值合并 ??
• 函数返回值若可能为空，应写成 string | null 而非 string
• 类属性初始化缺失时，TS 会认为它是 undefined，需用非空断言 !（慎用）或构造器赋值
• DOM 查询如 document.getElementById('x') 返回 HTMLElement | null，不能直接调用 .innerText

TypeScript 的价值不在语法糖，而在把一部分运行时错误提前到编辑器里标出来；但它的约束力完全取决于你是否开启 strict 模式、是否拒绝 any、是否为外部数据写准确的类型定义——这些地方稍一松懈，类型系统就形同虚设。