HTML5中索引名与字段路径需解耦：索引名应语义化（如"byUserEmail"），字段路径（如"profile.contact.email"）保持稳定；通过前缀（by/has/range）和版本策略（v2）规范命名，避免嵌入环境或版本信息。
在HTML5中并不存在“索引名称”与“字段路径解耦”的原生概念——这其实是数据库、NoSQL（如Firestore）、前端状态管理（如Redux Toolkit Query）或某些富客户端框架（如Angular、React + Apollo）中的设计术语。如果你在HTML5上下文中听到这类说法，大概率是指：在使用 IndexedDB 构建结构化客户端存储时，对对象存储（objectStore）的索引（index）进行命名，以及该索引所基于的对象属性路径（keyPath）之间的关系处理。
索引名应表达业务语义，而非字段路径
索引名不是字段名的镜像。例如，一个用户对象有 { profile: { contact: { email: "a@b.com" } } }，其字段路径是 "profile.contact.email"，但索引名不宜直接叫 "profile.contact.email"（难读、易出错、耦合过重）。更合理的命名是 "byUserEmail" 或 "emailLookup"——它说明“这个索引用来按邮箱查用户”，不暴露内部结构。
- ✅ 推荐：
"byUserName"、"activeUsersIndex"、"postsByAuthorId" - ❌ 避免：
"name"（太泛）、"data.user.name"（含实现细节）、"idx_001"（无意义）
字段路径（keyPath）保持稳定，索引名可随需求演进
字段路径由数据模型决定，一旦写入大量数据后变更成本高；而索引名只影响代码可读性和维护性。当业务逻辑变化（比如从“按邮箱查”扩展为“按邮箱或手机号查”），你可以新增索引 "byContactIdentifier"，而无需改动原有 "profile.contact.email" 的 keyPath。二者解耦后，重构和灰度上线更安全。
- 定义索引时显式传入字段路径：
objectStore.createIndex("byUserEmail", "profile.contact.email", { unique: true }) - 查询时只依赖索引名：
index.get("test@example.com")，完全不出现字段路径 - 后续若调整数据结构（如把
email提到顶层），只需新建索引 + 迁移数据，旧索引仍可用
统一前缀约定，区分索引类型与作用域
用前缀快速识别索引用途和范围，降低团队理解成本。常见且实用的前缀包括：
立即学习“前端免费学习笔记（深入）”；
-
by —— 单值精确查找（
"byOrderId"） -
byRange 或 range —— 范围查询（
"byRangeCreatedAt"） -
has —— 布尔存在性（
"hasAvatar"，对应 keyPath"avatarUrl"） -
v2、next —— 版本化索引，用于平滑迁移（
"byUserNameV2"）
避免在索引名中嵌入版本号或环境标识
索引名是运行时逻辑的一部分，不应包含构建时信息。像 "byEmail_dev"、"byEmail_v1_2024" 这类名字会导致测试/生产环境行为不一致，也妨碍自动化脚本识别索引意图。
- 环境差异应通过配置或初始化逻辑控制（例如 dev 环境多建一个调试索引），而非污染命名
- 版本迭代靠新增+废弃策略，不靠改名；废弃索引可通过注释或文档标记，不删除以防历史数据访问失败
- 所有索引名应在项目初期纳入命名规范文档，并在 PR 检查中做基础校验（如正则
/^by[A-Z]/）
