为复杂嵌套对象与数组状态写严格接口，核心是分层建模、显式约束、避免any，借助递归类型和交叉类型应对深度结构；关键在于可推导、可复用、可维护，而非堆砌点号路径。
为复杂的嵌套对象与数组状态写严格接口，核心是分层建模、显式约束、避免 any，并借助递归类型和交叉类型应对深度结构。关键不在“写全”，而在“可推导、可复用、可维护”。
用接口逐层拆解嵌套结构
不要在一个大接口里堆满点号路径；而是按业务语义分层定义小接口，再组合引用。例如用户带地址、订单带商品列表的场景：
-
先定义原子级接口：如
User、Address、Product -
再组合成复合结构：如
OrderItem包含product: Product和quantity: number -
顶层状态接口明确层级关系：如
AppState中currentUser: User | null，orders: OrderItem[]
这样既利于 IDE 补全，也方便单元测试时单独 mock 某一层。
处理动态嵌套（如树形、评论流）用递归类型
当结构深度不确定（比如文件目录、多级评论），用自引用接口保证类型穿透到底层：
立即学习“前端免费学习笔记（深入）”；
- 定义
type TreeNode = { id: string; name: string; children?: TreeNode[] } - 或更严谨地用接口：
interface Comment { id: string; content: string; replies?: Comment[] }
TypeScript 编译器会在 50 层内完整展开推导，访问 comment.replies[0]?.replies[1]?.id 时能准确提示类型，不会报 any 或 undefined 错误。
数组与联合类型要标注具体元素类型
避免只写 items: any[] 或 items: object[] —— 这等于放弃类型保护：
- 用
items: Product[]明确每个元素是Product实例 - 若数组元素类型不统一（如混合表单项），用联合类型：
fields: (TextInputField | NumberInputField | DateField)[] - 配合
as const固定字面量数组类型，例如权限列表：permissions: readonly ['read', 'write', 'delete']
在 Pinia store 和组件 props 中落地接口
接口定义完，必须在运行时上下文中生效才真正起作用：
-
Pinia state：用泛型传入接口，
state: (): UserState => ({ ... })，确保this.users[0].email有完整类型提示 -
组件 Props：在
<script setup lang="ts">中，defineProps<{ config: AppConfig }>()，而非Object as PropType<AppConfig>（后者仅用于遗留兼容） -
可选字段加 ?，只读字段加 readonly：如
theme?: 'light' | 'dark'、readonly createdAt: Date，让调用方清楚哪些能改、哪些不能改
