TypeScript 代码审查：让高级开发人员抓狂的 10 个错误

轻松学习Python，无需理论负担。在浏览器中直接解决带自动检查的实践任务，无需安装任何东西。

引言：为什么你的 TypeScript 代码审查看起来像控制台上的红灯？

你是否曾经提交过一个 pull request，一小时后收到了高级开发人员的 20 条评论，其中一半以“这可以做得更好”开头？很熟悉吧。如果你用 TypeScript 编写代码，但你的代码仍然让同事想从头重写——这篇文章就是为你准备的。

我们在 PythonLib 经常遇到这样的情况：即使开发人员了解 TypeScript 语法，也会犯同样的错误。这些错误不会破坏代码，但会使代码变得不可读、不安全且难以维护。今天，我将向您展示高级开发人员在 TypeScript 代码审查 中常写的 10 条典型意见，以及如何避免它们。准备好重构吧！

1. “Any”——你的敌人，而非朋友

在任何 TypeScript 代码审查中最常见的投诉就是使用 any。似乎写 const data: any = await fetch(...) 比处理类型更简单。但高级开发人员视其为红布。

不好的写法：

function processUser(user: any) {  console.log(user.name.toUpperCase());}

好的写法：

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

为什么这很重要？ 如果你使用 any，TypeScript 就失去了全部意义。你实际上是在禁用类型系统。如果数据来自 API——创建一个接口。如果类型复杂——使用带检查的 unknown。这是 TypeScript 最佳实践 的主要规则之一。

2. 忽略严格模式

许多项目在 tsconfig.json 中关闭严格模式，因为“这样更快”或“类型烦人”。TypeScript 高级开发人员会立即注意到你的代码没有检查 null 和 undefined。

不好的写法 (strict: false)：

function getLength(str: string) {  return str.length; // str 可能为 null，这会导致崩溃}

好的写法 (strict: true)：

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

建议： 在 tsconfig.json 中启用 strict: true。这将迫使你编写更安全的代码。在 TypeScript 代码审查 中，这将是加分项，而非减分项。

3. 类型魔法：过度复杂

有时开发人员试图展示自己有多厉害，编写出连高级开发人员都挠头的类型。例如，在可以用简单接口解决问题的地方，使用带有嵌套泛型的条件类型。

不好的写法（过度设计）：

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

好的写法（简洁）：

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

高级开发人员重视代码可读性。如果你的类型可以用只有三个字段的接口替代——那就这样做。不要不必要地复杂化。

4. 错误的错误处理

在 TypeScript 代码审查 中，一个典型的错误是使用 any 的 try-catch 或空的 catch 块。高级开发人员会立即指出这一点。

不好的写法：

try {  const data = await fetchData();} catch (e) {  console.log('错误');}

好的写法：

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('未知错误', error);  }}

对错误使用 unknown。这会