如何定义结构一致的TypeScript响应接口？通用接口方案是否合规？

完全符合TypeScript的规范，而且这是减少代码冗余、提升类型复用性的标准操作，社区里也非常推荐这种做法。下面给你具体的实践方案和扩展建议：

基础实现：复用基础接口 #

首先定义一个通用的基础响应接口，把重复的字段抽出来：

// 推荐用BaseResponse/ApiResponse这类名称，避免和浏览器全局的Response冲突
export interface BaseResponse {
  statusCode: number;
  statusMessage: string;
}

然后让各个业务响应接口继承这个基础接口，既保留语义化名称，又不用重复写字段：

export interface UserFailureResponse extends BaseResponse {}
export interface UserCreateResponse extends BaseResponse {}
export interface AuthCheckResponse extends BaseResponse {}

扩展性优化方案 #

1. 给特定响应新增字段 #

如果后续某个业务响应需要额外字段，直接在对应的子接口里添加即可，不会影响其他响应类型：

// 比如创建用户成功后需要返回用户ID
export interface UserCreateResponse extends BaseResponse {
  userId?: string;
}

2. 泛型版本适配带数据的场景 #

如果你的接口有带业务数据的场景，可以把基础接口改成泛型，适配更多情况：

export interface GenericResponse<T = unknown> extends BaseResponse {
  data?: T;
}

// 使用示例：返回用户列表的响应
type UserListResponse = GenericResponse<Array<{ id: string; name: string }>>;
// 使用示例：仅返回状态的响应（和原结构一致）
type SimpleResponse = GenericResponse;

社区常用实践建议 #

• 避免命名冲突：不要直接用Response作为接口名，因为浏览器全局环境已经有Response类型（对应Fetch API的响应对象），容易引发类型混淆，用BaseResponse或ApiResponse更安全。
• 保持语义化：即使结构相同，也要为不同业务场景单独定义接口（通过继承），这样代码可读性更强，其他开发者能快速对应到具体的业务操作。
• 优先用interface而非type：接口支持继承和声明合并，后续扩展基础响应字段时更灵活；类型别名（type）虽然也能实现，但在类型扩展的场景下不如接口方便。

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