用途：在静态类型语言中设计类型、审查函数签名或编写代码时，应用这套原则让编译器拒绝不可能的状态、不匹配的原语和未处理的变体。倾向从根本上消除错误与特例，而非不断增殖处理器。TypeScript 语法细节另见 typescript-best-practices 技能。
主要能力与主张：一、让非法状态无法表示，变体用和类型（可辨识联合、带载荷枚举、密封类）建模，而非一堆可选字段。如 { completed: boolean; completedAt?: Date } 允许 completed 为 true 却无日期；应把布尔值从 completedAt 派生，或建模为 { kind: 'open' } | { kind: 'done'; at: Date }。若能写注释解释字段组合何时有效，就拆成和类型。二、类型是构造而非限制，从想要的取值自下而上构造类型，而非用检查从宽松类型中雕刻；非空列表是头加尾，合法时间范围是起点加时长。三、品牌化语义原语：UserId 与 OrderId 底层都是字符串但不可互换，各自独立类型（如 TypeScript 品牌交叉类型或其他语言 newtype），创建时验证一次，下游信任类型。四、外部数据在被解析前是无类型的，RPC、JSON、IPC、CLI 参数、配置文件、环境变量、数据库行都需在边界处用解析函数转为类型化模型。五、不要对类型系统说谎，强制转换、不安全强制、断言函数绕过编译器是潜在运行时崩溃；编译器无法证明的事就去证明（验证、收窄、精炼模型）。六、穷尽匹配交给编译器：和类型的匹配在新增变体未处理时必须编译失败，用各语言惯用法，如 TypeScript 的 never 绑定、Rust 的未标注 match、Haskell 的 -Wincomplete-patterns、Kotlin 密封类匹配穷尽。七、从权威模式派生类型，如 protobuf、OpenAPI、GraphQL、数据库迁移、设计令牌文件。八、仅在出现部分性处强化类型，运行时断言、空检查或“不应发生”抛错标记了类型过弱之处，把检查上推进类型后即停止；类型系统只需跟踪每个使用点必须处理的情况，优先全函数。
适用场景与限制：适用于任何静态类型语言中的类型设计与签名评审。资料未提供具体安装命令、代码示例以外的完整实现、收费信息或平台限制。