1. 企业级开发全景

在进入具体语法与工程实践之前，需要先建立一张“全景地图”：JavaScript 与 TypeScript 在企业级软件工程中究竟处于什么位置，团队在技术选型时依据什么做判断，以及现代前端/全栈项目常见的架构模式有哪些。只有把这三件事想清楚，后续的模块化、类型系统、构建工具、测试与部署才有稳定的落点。

一、定位：从脚本语言到工程级技术栈

JavaScript 最初是浏览器里的脚本语言，用于表单校验和简单交互。随着 Node.js 出现、ECMAScript 标准持续演进（ES2015 之后的模块、类、Promise、async/await、可选链等），以及 npm 生态的爆发，JavaScript 已经成为可以覆盖浏览器、服务端、桌面端（Electron）、移动端（React Native）和边缘函数的通用语言。它的核心优势是运行时无处不在、生态庞大、上手门槛低；代价则是动态类型在大型协作中容易产生隐性错误。

TypeScript 不是一门替代 JavaScript 的新语言，而是 JavaScript 的超集：所有合法 JS 都是合法 TS，TS 在此基础上增加了静态类型系统、接口、泛型、枚举、装饰器等能力，并通过编译器（tsc）或构建工具（如 esbuild、SWC、Vite）在构建期做类型检查，最终产出标准 JavaScript。它解决的不是“运行速度”，而是可维护性、可读性与协作效率：类型即文档，类型即契约，重构时编译器会替你找出所有受影响的调用点。

在企业级语境下，二者的关系可以概括为：JavaScript 是运行时与生态底座，TypeScript 是工程约束层。团队规模越大、生命周期越长、跨端复用越多，TypeScript 的收益越明显；反之，一次性脚本、极小工具页，纯 JS 可能更轻。

二、技术选型：用可判断的维度替代“感觉”

选型不应停留在“TS 更高级”或“JS 更简单”的层面，而应落到具体维度上做权衡。下面这张图把选型时最值得先看清的几组关系放在一起：语言层、运行时层、框架层与工程层，它们共同决定了一个项目的技术底座。

把这张图落到具体判断上，可以形成几条可操作的选型原则：

• 团队规模与协作强度：3 人以下、短期项目，纯 JS 加 JSDoc 类型注释可能足够；5 人以上、持续迭代超过半年，TypeScript 的收益通常远大于学习成本。
• 项目生命周期：一次性活动页、内部小工具，优先交付速度；核心业务系统、需要长期维护的 B 端产品，优先可维护性。
• 跨端复用程度：如果同一套领域模型要在 Web、Node 服务端、移动端之间共享，TypeScript 的类型定义可以直接作为跨端契约，减少重复沟通。
• 生态与人才供给：React/Vue 生态中 TS 支持已经非常成熟，类型声明包（@types/*）覆盖率高；选型时要确认关键依赖是否有可用的类型定义。
• 构建与运行约束：TS 需要编译步骤，但现代工具链（Vite + esbuild/SWC）已把类型检查与转译分离，开发时转译极快，类型检查放到 CI 或编辑器中进行。

三、典型架构模式：从“页面”到“可演进系统”

企业级项目很少是单一页面，而是由多个关注点交织而成。常见的架构模式可以按“分层”和“数据流”两个视角来理解。

分层架构是最基础的一种：表现层（UI 组件、路由、状态展示）、领域层（业务规则、用例、实体）、数据访问层（API 客户端、缓存、持久化）。TypeScript 在这里的价值是给每一层定义清晰的输入输出类型，例如领域层的 Order、User 接口，数据访问层的 ApiResponse<T> 泛型，表现层只消费这些类型，不直接拼接原始 JSON。

单向数据流是前端框架中广泛采用的模式：状态集中存放，视图根据状态渲染，用户操作触发 action，action 经过 reducer 或 store 更新状态，再驱动视图更新。React 的 Redux/Zustand、Vue 的 Pinia 都属于这一思路。它的好处是数据流向可追踪，配合 TypeScript 可以为 action 和 state 定义联合类型，让非法状态在编译期就被排除。

模块化与微前端则解决“大系统如何拆分”的问题。按业务域拆成独立模块，每个模块有自己的路由、状态和构建产物，通过约定接口通信。TypeScript 的 interface 和 type 可以作为模块间的契约文件，避免运行时才发现字段不匹配。

下面用一个简化的数据流示意，说明一次“用户下单”请求在分层架构中如何流动，以及 TypeScript 类型在哪些位置发挥作用。

// 领域层：定义核心类型（跨层共享）
interface OrderItem {
  skuId: string;
  quantity: number;
  unitPrice: number;
}

interface Order {
  id: string;
  userId: string;
  items: OrderItem[];
  totalAmount: number;
  status: 'pending' | 'paid' | 'shipped' | 'closed';
}

// 数据访问层：泛型响应包装
interface ApiResponse<T> {
  code: number;
  message: string;
  data: T;
}

async function createOrder(payload: {
  userId: string;
  items: OrderItem[];
}): Promise<ApiResponse<Order>> {
  const res = await fetch('/api/orders', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });
  return res.json() as Promise<ApiResponse<Order>>;
}

// 表现层：只消费类型，不关心底层细节
const result = await createOrder({
  userId: 'u_1001',
  items: [{ skuId: 'sku_88', quantity: 2, unitPrice: 39.9 }],
});

if (result.code === 0) {
  console.log('订单创建成功，状态：', result.data.status);
} else {
  console.warn('创建失败：', result.message);
}

这段示例中，Order 的 status 使用字面量联合类型，任何拼写错误或非法状态值都会在编译期报错；ApiResponse<T> 让不同接口的响应结构保持一致；createOrder 的参数类型约束了调用方必须传入 userId 和 items。这些约束在纯 JavaScript 中只能靠文档和运行时校验，而在 TypeScript 中由编译器自动完成。

四、把全景落到项目起点