TypeScript写满三年后，我开始怀念裸奔的JavaScript

三年前，团队引入 TypeScript 时，我举双手赞成。类型系统带来的安全感，像给代码上了保险——重构不怕改崩，协作不用猜接口，编辑器智能提示让开发效率翻倍。但最近半年，我发现自己越来越频繁地怀念起裸奔的 JavaScript：那种随手写个函数就能跑、不用先定义 interface 的畅快。这不是技术倒退，而是一种对开发体验的重新审视。

TypeScript 的收益毋庸置疑，尤其是在大型项目和长期维护中。但它的成本同样真实：类型定义本身成为新的维护负担，尤其是当后端接口频繁变动时，前端需要同步修改类型，否则编译报错。更微妙的是，类型系统会诱导开发者追求“类型正确”而非“逻辑正确”——一个函数只要类型对得上，哪怕内部实现有漏洞，也能通过编译。这种虚假的安全感，在快速迭代的业务中反而可能掩盖问题。

另一个痛点是心智负担。写 TypeScript 时，大脑需要同时处理两套逻辑：运行时逻辑和类型逻辑。对于简单功能，类型定义可能比业务代码还长。比如一个表单提交函数，参数类型、返回值类型、泛型约束加起来十几行，而实际逻辑只有三行。这种比例失衡在小型工具函数中尤为明显。JavaScript 的“裸奔”虽然危险，但至少让开发者专注于问题本身，而不是类型体操。

当然，我并非主张放弃 TypeScript。它的价值在复杂场景下无可替代。但我们需要警惕“类型崇拜”：不是所有项目都需要严格类型，不是所有代码都值得写泛型。近期社区中关于“类型覆盖率”的讨论逐渐升温，一些团队开始尝试渐进式类型策略——核心模块用 TypeScript，边缘脚本用 JavaScript，甚至允许在 TypeScript 文件中使用 any 作为逃生舱。这种务实态度，比一刀切的强制类型更值得推广。

从行业趋势看，TypeScript 的采用率仍在上升，但工具链也在进化。比如基于 JSDoc 的类型检查可以在不写类型注解的情况下获得部分类型安全，一些运行时类型校验库则弥补了编译期类型的不足。这些方案让开发者有了更多选择：既可以享受类型的好处，又不必背负全部负担。

怀念裸奔的 JavaScript，本质上是怀念那种低摩擦的开发节奏。技术选型从来不是非黑即白，TypeScript 和 JavaScript 也不是对立关系。关键在于根据项目阶段、团队规模和业务复杂度动态调整策略。对于追求快速验证的 MVP，JavaScript 的灵活性可能更合适；对于需要长期演进的系统，TypeScript 的约束则是必要之恶。成熟的开发者，应该学会在类型安全与开发效率之间找到平衡点，而不是被工具绑架。