TypeScript 是 JavaScript 的静态类型扩展，所有合法 JS 代码都是合法 TS 代码；tsc 编译后生成纯 JS 并移除类型注解，运行时不依赖 TS，IDE 报红源于语言服务的静态分析而非运行时错误。
为什么 tsc 编译后 JS 还能运行，但 IDE 却报红？
因为 TypeScript 的类型系统只在开发和编译阶段起作用，tsc 默认把带类型的 TS 文件编译成纯 JS（去掉所有类型注解），运行时完全不依赖 TS。IDE 报红是基于 TS 语言服务的静态分析，不是运行时报错。
- 确保你打开的是
.ts文件，而不是编译后的.js文件 - 检查是否启用了 VS Code 的 TypeScript 插件（默认已启用，但工作区可能禁用）
-
tsc --noEmit可单独做类型检查，不生成 JS，适合 CI 阶段验证 - 如果
node_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
strict 模式、是否拒绝 any、是否为外部数据写准确的类型定义——这些地方稍一松懈，类型系统就形同虚设。 
