TypeScript在正规公司前端已是标配，但面试官要听平衡的答案——不是"TS一定更好"。有思考的候选人会同时指出成本（编译、类型定义、学习曲线）和收益。
基本事实：TS是JS加编译期静态类型。产物是普通JS，运行时行为完全一致——所有价值都在开发工具和提前发现bug上。
具体收益：IDE自动补全真的懂你的API形状、重命名一次改所有引用、null/undefined访问编译期就能发现、函数签名就是自文档。
结构化类型：形状匹配即类型匹配，不看名字。{name: string}的对象满足任何参数类型{name: string}，比Java/C#的名义类型更灵活，特别适合JSON-heavy的JS生态。
TS值得用的场景：3+人团队协作6个月以上的代码；API重的代码（需要跨层映射schema）；给别人用的库。不值得用的场景：一次性脚本、原型、个人玩具项目。
成本：编译步骤、CI时间、无类型库要@types或any、strict模式要纪律维持，any/as转义口用多了会悄悄削弱保护。
TypeScript是加了静态类型系统和编译期检查的JavaScript。编译产物就是普通JS，没有运行时开销、没有语义变化。价值完全在开发工具和提前发现bug上。TS给你三个JS没有的东西。第一，IDE真正懂你的代码——自动补全知道API形状、属性typo实时报错、跨模块跳转定义。第二，重构自信——重命名一个属性，大仓里所有引用都更新，不用"希望grep全找到了"。第三，避免线上bug——尤其是null/undefined访问、参数顺序错、漏传必填字段。TS用结构化类型——值和类型是否匹配看形状不看名字。函数参数类型{name: string, age: number}接受任何字面量对象只要字段对。比Java或C#的名义类型灵活，很契合JS处理JSON的主要场景。真正的问题是什么时候值得用。3人以上团队共写一份代码持续6个月以上，重构和文档价值指数级累积——类型注解就是永不过时的机器校验文档。API重的代码——后端响应→前端状态→UI props之间反复映射，每层有类型能提前抓到shape不一致，JS环境会直接崩。成本侧：编译步骤增加CI时间、无类型的第三方库要@types或any（不写容易传染）、strict模式下要纪律维持，每个any或as都在悄悄削弱保护。一次性脚本、原型、hackday代码，TS的overhead划不来。100K行的团队项目，TS明显值。我的判断规则：如果这代码会被两个工程师在不同时间读，就用TS。
要承认TS有代价——只列优点显得naive。
能讲"结构化类型"是差异化信号，大部分候选人只说"加了类型"。
"团队规模×持续时间"的判断框架好记且显务实。
临场忘了"结构化类型"这个词，即答侠可以实时提示。
不会——编译产物就是普通JS，和手写JS完全一样。所有TS机制都在构建期。
新项目全开。老JS项目渐进迁移时先开strictNullChecks，性价比最高。
真的不知道shape的动态数据时的转义口。当不安全代码处理——加注释解释原因，用前做type guard。