团队中的 TypeScript：代码风格、约定，杜绝混乱

为什么“能跑”不等于团队协作？

想象一下：你打开别人的 PR，里面到处是 any，变量名是 a、b、c，代码格式就像猫在键盘上乱踩出来的。熟悉吗？一个人写这样的代码还能忍。但在团队里，这就是通往冲突、bug 和代码审查不眠之夜的捷径。

今天我们来聊聊如何让 TypeScript 在团队中不仅仅是一个工具，而是一个可靠的基础。我们将讨论 代码风格 和 约定，它们能拯救你的神经并加速开发。不枯燥，有生动的例子。

1. 严格类型化：你的第一个朋友

TypeScript 的核心就是类型。但很多团队把它用成了“轻量版 TypeScript”，懒得思考的地方就留个 any。这扼杀了所有的魔力。第一条约定：禁止使用 any。

糟糕的写法：

function fetchData(url: string): any {    // ...}

好的写法：

interface ApiResponse {    id: number;    name: string;    isActive: boolean;}

function fetchData(url: string): Promise<ApiResponse> {    // ...}

当每个开发者都明确描述返回值和参数时，代码就变成了自文档化的。你不再需要猜测：“这个 data 是字符串还是对象？”。类型自己会说话。

2. ESLint + Prettier：无需讨论的配置

如果你的团队还没有统一的 linter 和 formatter，请停下来，立刻配置它们。ESLint 能捕获逻辑错误和代码风格违规，而 Prettier 能让代码格式统一。

TypeScript 的 ESLint 基本配置：

{  "parser": "@typescript-eslint/parser",  "plugins": ["@typescript-eslint"],  "extends": [    "eslint:recommended",    "plugin:@typescript-eslint/recommended",    "prettier" // 必须放在最后  ],  "rules": {    "@typescript-eslint/no-explicit-any": "error",    "@typescript-eslint/explicit-function-return-type": "warn",    "no-console": "warn"  }}

添加 Prettier 并设置简单规则：使用制表符代替空格（或反之，但要统一），单引号，末尾加分号。然后在 IDE 中开启 formatOnSave。这能避免无休止的缩进争论。

3. 命名：说同一种语言

命名约定就像交通规则。没有它们，就是一片混乱。TypeScript 中常用的约定有：

• 变量、函数、方法使用 camelCase：getUserData()、userName
• 类、接口、类型使用 PascalCase：UserProfile、ApiResponse
• 编译时已知的常量使用 UPPER_SNAKE_CASE：MAX_RETRY_COUNT、DEFAULT_TIMEOUT
• 接口的 I 前缀 存在争议，但很多团队仍在使用：IUser。请在项目初期决定好。

糟糕命名的例子：

const data = { n: 'Alex', a: 30 }; // n 和 a 是什么？

好的命名：

const userProfile = { name: 'Alex', age: 30 };

4. 项目结构：不要把一切都塞进一个文件

当项目膨胀时，缺乏结构是最大的敌人。提前约定好文件夹结构。以下是 TypeScript 项目的一个流行方案：

• src/ — 源代码
• src/components/ — UI 组件（如果是 React）
• src/utils/ — 工具函数
• src/types/ — 全局类型和接口
• src/services/ — API 调用
• src/hooks/ — 自定义 Hooks（如果是 React）
\