NextJS+TypeScript项目中类型声明文件的合理存储方式咨询

1. 把所有类型塞到global.d.ts可行吗？ #

可行，但只适合极小的练习项目。如果项目后续扩展，所有类型堆在一个全局文件里会导致：

• 类型查找难度飙升，维护成本直线上升
• 全局命名冲突风险加大，比如不同业务模块的User类型容易重名
• 团队协作时，新人很难快速定位到对应类型的定义位置

2. 会影响项目性能吗？ #

• 运行时性能完全不受影响：TypeScript类型定义在编译阶段会被完全移除，最终输出的JS代码里不会有任何类型相关内容。
• 编译时性能可能受影响：如果global.d.ts里堆积了成百上千个类型，TypeScript编译器在做类型检查时的扫描和分析时间会变长，但练习项目的规模基本感知不到这种差异。

3. TypeScript项目（含Next.js）存储类型定义的正确方式 #

（1）模块就近定义类型

对于和特定组件/业务逻辑强绑定的类型，直接放在对应的模块文件里，或者同目录下的单独类型文件：

• 比如写一个用户列表组件UserList.tsx，可以在组件文件内直接定义：

interface UserItem {
  id: string;
  name: string;
  email: string;
}

const UserList = ({ users }: { users: UserItem[] }) => {
  // 组件逻辑
};

• 或者拆分到同目录的UserList.types.ts里，然后在组件中导入：

// UserList.types.ts
export interface UserItem {
  id: string;
  name: string;
  email: string;
}

// UserList.tsx
import { UserItem } from './UserList.types';

这种方式的好处是类型和使用场景强关联，维护起来一目了然。

（2）集中管理共享通用类型

对于多个模块都会用到的通用类型（比如API返回结构、全局工具类型、通用枚举），可以在项目根目录下创建src/types目录，按功能分类存放：

• src/types/api.ts：存放所有API接口的请求/响应类型
• src/types/common.ts：存放通用工具类型（比如Nullable<T>、PromiseResult<T>）
• src/types/enums.ts：存放全局通用枚举（比如UserRole、OrderStatus）

示例：

// src/types/api.ts
export interface ApiResponse<T> {
  code: number;
  message: string;
  data: T;
}

export interface GetUserResponse {
  id: string;
  name: string;
  avatar: string;
}

（3）谨慎使用global.d.ts

global.d.ts只适合存放真正需要全局生效的类型，比如：

• 扩展TypeScript内置类型（比如给Window对象添加自定义属性）

// global.d.ts
interface Window {
  __NEXT_DATA__: any;
  customAnalytics: () => void;
}

• 全局通用的类型别名（但尽量少用，优先通过导入方式共享）

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