IndexedDB在TypeScript中需结合运行时校验与编译期建模实现类型安全：定义实体接口、泛型封装对象仓库、类型守卫索引查询，并规避异步类型陷阱。
在HTML5的IndexedDB中直接使用TypeScript无法自动获得类型安全，因为IDBObjectStore、IDBRequest等原生API返回的是泛型擦除后的any或IDBValidKey类型。要真正实现数据库对象仓库（Object Store）的类型约束，需结合运行时结构校验与编译期类型建模，而非仅靠接口声明。
定义与IDBObjectStore对齐的泛型类型模型
为每个对象仓库创建对应的实体接口，并用泛型封装其主键与索引字段：
- 用
interface User { id: number; name: string; email?: string }描述数据结构 - 通过
type UserStore = IDBObjectStore<user></user>显式绑定主键路径（注意：此仅为类型提示，不改变运行时行为） - 对多索引场景，可扩展为
type UserStore = IDBObjectStore<user></user>，辅助类型推导add()、get()等方法的参数类型
封装带类型检查的事务操作类
原生IDBTransaction不携带数据类型信息。可编写一个泛型包装类，在调用objectStore(name)时强制返回对应类型的store实例：
- 构造函数接收
db: IDBDatabase和类型映射表storeMap: Record<string new> T></string> -
getStore<T>(name: string): IDBObjectStore<T>内部校验name是否在映射表中，否则编译报错 - 重写
add(value: T)等方法，调用前用assertIsUser(value)做运行时字段存在性/类型检查（如number主键非undefined）
利用IDBKeyRange与索引联合推导查询结果类型
当按索引查询时，返回值类型应与索引字段类型一致。例如用户邮箱索引emailIndex为unique，调用index.get('a@b.com')应返回User | undefined而非IDBValidKey：
立即学习“前端免费学习笔记（深入）”；
- 为每个索引定义类型守卫函数
isUserByEmail(key: IDBValidKey): key is string - 在封装的
findUserByEmail(email: string)方法中，先用IDBKeyRange.only(email)构造范围，再用index.openCursor(range)并映射结果为User[] - 配合tsconfig.json中启用
"strict": true和"noImplicitAny": true，阻止未标注类型的store访问
避免常见类型陷阱
IndexedDB的异步特性与TypeScript类型系统存在天然错位，需主动规避几类问题：
- 不要给
IDBRequest.result直接赋类型断言——它可能为undefined（如get未命中）或错误值，应统一用request.onsuccess = () => { const data = request.result as T | undefined; }并做空值判断 - 版本升级时新增字段，旧数据缺失该字段会导致运行时undefined，建议在
upgradeneeded中用Object.assign({}, defaultValues, storedData)补全 - 避免在
onerror中忽略event.target?.error的类型——它可能是DOMException或IDBDatabaseException，应单独处理不同code（如"VersionError"、"ConstraintError"）
