用途
本规则用于 TypeScript 实现与类型审查阶段，统一类型安全与错误处理方式，适用于后端实现、数据流处理及测试代码。
主要能力
数据流类型安全
采用分层模式：输入层（unknown）→ 类型守卫 → 业务层（类型已保证）→ 输出层（序列化）。后端典型场景包括：
- API 通信：始终以 unknown 接收响应，用类型守卫校验
- 表单输入：外部输入视为 unknown，校验后确定类型
- 遗留系统集成：逐步断言，如 window as unknown as LegacyWindow
- 测试代码：为 mock 定义类型，使用 Partial<T> 与 vi.fn<[Args], Return>()
编码约定
- 类使用判断：推荐用函数与接口实现，以提升可测试性与函数组合灵活性；允许使用类的场景为框架要求（NestJS Controller/Service、TypeORM Entity 等）、自定义错误类、状态与业务逻辑紧密耦合（如 ShoppingCart、Session、StateMachine）。判断标准是「该数据是否具有行为」。
- 函数设计：参数最多 0-2 个，3 个及以上使用对象参数。
- 依赖注入：将外部依赖作为参数注入，保证可测试性与模块化。
- 异步处理：始终使用 async/await，始终用 try-catch 处理，显式定义返回值类型（如 Promise<Result>）。
- 格式规则：省略分号（遵循 Biome 设置）；类型用 PascalCase，变量与函数用 camelCase；导入使用绝对路径（src/）。
错误处理
绝对规则：禁止抑制错误，所有错误必须有日志输出与适当处理；遵循快速失败原则，防止在无效状态下继续处理。禁止无条件回退（如 catch 中直接 return defaultValue 隐藏错误），应记录日志并重新抛出。可用 Result<T, E> 联合类型显式表达错误可能性。自定义错误示例：
export class AppError extends Error { constructor(message: string, public readonly code: string, public readonly statusCode = 500) { super(message) this.name = this.constructor.name } }
按用途细分：ValidationError(400)、BusinessRuleError(400)、DatabaseError(500)、ExternalServiceError(502)。后端分层处理：API 层转换为 HTTP 响应并记录日志（排除敏感信息）；Service 层检测业务规则违规，按原样传播 AppError；Repository 层将技术错误转换为领域错误。
日志与敏感信息
日志中绝不可包含敏感信息（password、token、apiKey、secret、creditCard）。异步错误处理必须设置全局处理器：unhandledRejection、uncaughtException；所有 async/await 配合 try-catch，始终记录并重新抛出错误。
性能优化
大数据集使用流式处理；显式释放无用对象以防内存泄漏。
适用场景
- 实现或评审 TypeScript 后端代码
- 设计数据类型流与校验边界
- 统一错误处理与日志规范
- 编写类型安全的测试 mock
限制
资料未说明该规则支持的 TypeScript 版本、具体工具链集成方式、与特定框架的兼容范围及安装方式，暂未提供。