CHAPTER 01 · 起步

生态全景地图

TS 生态之所以让人眼花缭乱，是因为 Java 里一个 JDK 包办的事情，在这里被拆成了五六个可替换的工具。拆开看每一层，其实都能在你熟悉的世界里找到对应物。

开场：一个项目，七八个命令

答案方向：把 TS 源码变成“用户能用的应用”，要经过一条流水线：管理依赖 → 检查类型 → 去掉类型 → 打包优化 → 在某个运行时上执行 → 发布到某个平台。在 Java 世界，JDK + Maven 把其中大部分合在一起；在 TS 世界，每一步都有独立的、可替换的工具。上面每个命令，就是流水线上的一个工位。

先用你熟悉的世界做对照

下表把 TS 生态的每一层映射到 Java / Go / Python。这张表是整章的“锚点”，后面每一节都是在展开其中一行。

有两行在你熟悉的世界里没有真正的对应物，也正是新人最容易糊涂的地方：“类型检查与转译分离”和“打包”。我们先讲它们。

流水线：从 .ts 文件到运行中的应用

核心原理：类型检查和转译是两件事 原理

在 Java 里，类型错误意味着编译失败，没有 .class 文件，程序根本跑不起来。TS 不一样。TypeScript 的设计目标之一是：类型只存在于编写阶段，运行时完全不存在。这叫类型擦除（type erasure）。转译器要做的事情简单到近乎机械：把类型标注删掉，剩下的就是合法的 JavaScript。

正因为“删类型”不需要理解类型，esbuild、SWC 这类用 Go / Rust 写的转译器才能快到每秒处理几十万行代码。从 Node.js 23.6 起，Node 可以直接运行 .ts 文件（内置的类型剥离，type stripping），Node 26 更把它作为稳定的默认行为。但请注意：Node 只是删掉类型，它不做类型检查。

2026 年 7 月发布的 TypeScript 7 把编译器用 Go 重写为原生程序，大型项目类型检查快了约 10 倍。它改变的是速度，不是语言：你写的代码、类型规则都一样。对你的实际影响是：类型检查便宜了，没理由再跳过它。

为什么前端需要“打包” 知道

Go 把程序编译成一个二进制，服务器从本地磁盘加载，文件多大、分几个文件都无所谓。浏览器不一样：代码要通过网络下载到每个用户的设备上。一个项目可能有几千个模块文件（你的代码加上 node_modules 里的依赖），逐个下载会慢到无法接受。打包器（bundler）要解决的就是这个问题：

• 合并：把几千个模块合成少量文件，减少请求数。
• 摇树（tree shaking）：只保留真正被用到的代码，删掉没用到的导出。
• 代码分割（code splitting）：按页面或路由拆分，首屏只下载首屏需要的代码。
• 压缩（minify）：去空格、缩短变量名，减小体积。
• 处理非 JS 资源：CSS、图片、字体，给文件名加内容哈希以便长期缓存。

2026 年你最常遇到的两个名字：Vite（Vite 8 起内部统一使用 Rust 写的 Rolldown 打包器；TanStack Start、React Router、Astro、SvelteKit 等都基于它）和 Turbopack（Next.js 的默认打包器）。它们属于“知道”档：你几乎不需要手动配置，出问题时也通常是明确的构建报错。

运行时：JS 代码实际在哪里执行

JavaScript 引擎（如 V8）只负责执行语言本身：变量、函数、对象。“读文件”“发网络请求”“操作页面”这些能力，是宿主环境提供的。不同的宿主环境，就是不同的运行时（runtime）。

一个让这些运行时能共享代码的关键事实：它们都在向Web 标准 API靠拢——fetch、Request、Response、URL、ReadableStream、crypto.subtle。如果你的服务器代码只用这些标准 API，它就能在 Node、Bun、Deno 和 Cloudflare 上原样运行。这就是 Hono 这类框架“一份代码到处部署”的原理。

包管理：package.json 和 node_modules

每个 JS/TS 项目的根目录有一个 package.json，相当于 pom.xml 或 go.mod：

• scripts：项目的“命令菜单”。pnpm dev 就是运行 vite dev。读一个陌生项目时，先看这里。
• dependencies vs devDependencies：运行时需要的依赖 vs 只在开发和构建时需要的工具。
• ^19.2.0：语义化版本（semver）范围，“兼容 19.2.0 的任何 19.x 版本”。实际装了哪个版本，由锁文件（lockfile）决定，例如 pnpm-lock.yaml。锁文件必须提交到 Git。
• "type": "module"：声明使用现代的 ES 模块（import/export），第 03 章会解释它和旧的 CommonJS（require）的区别。

用哪个包管理器？推荐 pnpm：它把所有包存在一个全局的内容寻址仓库里、通过链接复用，磁盘占用小、安装快；而且它的依赖结构是“严格”的——你没在 package.json 里声明的包，代码里就 import 不到，避免了“在我机器上能跑”的幽灵依赖。npm 是 Node 自带的默认选择；bun 速度很快，适合已经在用 Bun 运行时的项目。

框架分层：谁管界面，谁管路由，谁管数据

“框架”这个词在 TS 生态里指代的东西差异很大。按职责分三层来看就清楚了：

和 Java 世界最大的不同在于：一个元框架项目同时是前端和后端。Next.js 应用里既有 React 组件，又有处理 HTTP 请求、读写数据库的服务端代码，它们在同一个仓库、同一种语言、甚至可以互相 import 类型。这带来巨大的便利（端到端类型安全，第 08 章），也带来新的风险（服务器代码被误打包进浏览器，第 07 章）。

2026 年的三条主流路线

下面三种组合覆盖了绝大多数新项目。它们的共同部分远大于差异：TypeScript + React + Tailwind + Zod + Drizzle + Vitest 在三条路线里都适用。差异主要在元框架和“运行在哪”。

版本快照（2026 年 9 月）

这张表会过时，但它能帮你判断 Agent 给出的代码是否“太旧”（模型的训练数据有截止时间，经常写出上一代 API）。

自检