泛型过多会引发TypeScript性能问题吗？自定义Express请求类型可行吗？

我听说使用过多泛型会导致「编译极慢」。我想在代码中创建一个供所有控制器使用的Express新Request类型，并在200+路由中应用该类型。请问这是最佳实践吗？是否会引发性能或其他问题？

我的类型定义：

import { Request } from 'express';

export interface ExpressRequest<TOUTPUT = any, TPARAMS = any, TBODY = any, TQUERYPARAMS = any>
  extends Request<TPARAMS, any, TBODY, TQUERYPARAMS> {
  output?: TOUTPUT;
}

以下是我在Express路由中使用该类型的示例代码：

import express, { NextFunction, Request, Response } from 'express';
import * as core from 'express-serve-static-core';
const app = express();
const port = 3000;
app.use(express.json());

export interface ExpressRequest<TOUTPUT = any, TPARAMS = core.ParamsDictionary, TBODY = any, TQUERYPARAMS = any>
  extends Request<TPARAMS, any, TBODY, TQUERYPARAMS> {
  output?: TOUTPUT;
}

export type Message = {
  message: string;
};

export type User = {
  name: string;
  age: number;
};

app.get('/message/:message', (req: ExpressRequest<Message, Message>, res: Response, next: NextFunction) => {
  const message = req.params.message;
  req.output = { message };
  console.log({ message });
  next();
});

app.post('/createUser', (req: ExpressRequest<User, any, User>, res: Response, next: NextFunction) => {
  const user: User = req.body;
  req.output = user;
  console.log({ user });
  console.log('User has been created !');
  next();
});

// Middlewares
app.use((req: ExpressRequest, res: Response, next: NextFunction) => {
  res.json(req.output);
});

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`);
});

1. 是否属于最佳实践？ #

这个方案本身合理，但并非绝对的最佳实践，具体价值取决于团队场景：

• 优势：统一扩展Express的Request类型，给req.output加上明确的类型约束，避免any类型滥用，在200+路由的项目中能提升代码可读性与类型安全性，减少重复的类型定义工作。
• 可优化点：当前泛型参数顺序（TOUTPUT排在首位）和Express原生Request的泛型顺序（Params, ResBody, ReqBody, ReqQuery）不一致，团队成员需要额外记忆参数顺序，容易传错类型。建议将TOUTPUT放到参数列表末尾，或者对齐原生顺序，降低认知成本。

2. 会不会引发编译性能问题？ #

泛型确实会增加TypeScript的编译计算量，但200+路由的规模几乎不会导致「编译极慢」：

• TypeScript对泛型的优化已经很成熟，只有当泛型嵌套层级极深、依赖大量复杂类型推导时，才会出现明显的编译延迟。你这种简单扩展原生Request的泛型属于轻量级类型操作，编译时间的增加可以忽略不计。
• 如果后续真遇到编译变慢的情况，可通过tsconfig.json的skipLibCheck、incremental等选项优化，或者将公共类型定义抽离到单独文件，避免重复解析。

3. 其他需要注意的问题？ #

• 类型一致性问题：示例中重复定义了ExpressRequest（一处在单独文件，一处在路由文件），会导致类型不一致。建议将ExpressRequest抽离到专门的类型文件（比如types/express.d.ts）中全局引入，避免重复定义。
• 中间件类型兼容：在中间件中使用无泛型参数的ExpressRequest时，req.output会被推断为any。如果想在中间件中也获得类型提示，可以给中间件的泛型传参，或者通过类型守卫缩小类型范围。
• 避免过度泛型化：如果大部分路由不需要用到所有泛型参数，没必要强制传参——利用你设置的any默认值，只在需要类型约束的路由里明确传入对应类型即可，减少冗余。

总结 #

这个方案完全可行，适合你的200+路由场景，只要注意统一类型定义、对齐泛型参数顺序，就不会有严重的性能或维护问题。

内容的提问来源于stack exchange，提问作者TheSmartMonkey