IndexedDB事务分readonly、readwrite和versionchange三种模式：readonly仅支持读取操作且可并发执行；readwrite支持读写但同一对象仓库仅允许一个活跃事务；versionchange用于数据库结构变更，自动触发且会阻塞其他事务。
在 HTML5 的 IndexedDB 中，transaction（事务）是执行数据库操作的基本单元，而 readonly 与 readwrite 是事务的两种核心模式，它们决定了该事务能对对象仓库（object store）进行哪些操作。
readonly 事务：只读，安全高效
适用于仅需查询、遍历或读取数据的场景，比如渲染列表、校验字段、生成报表等。
- 只能调用
get()、openCursor()、count()等读取方法 - 不能修改任何数据，也不能新增、删除、更新对象仓库中的记录
- 允许多个
readonly事务并发执行，互不阻塞，性能开销小 - 是默认事务模式，若未显式指定，
db.transaction(storeNames)就是readonly
readwrite 事务：读写兼备，支持变更
用于需要持久化修改数据的操作，如表单提交、本地缓存更新、离线队列同步等。
- 可执行所有读操作，同时支持
add()、put()、delete()、clear()等写入方法 - 同一时刻，一个对象仓库最多只能有一个
readwrite事务处于活跃状态，其他同名仓库的readwrite事务会被排队等待 - 必须显式声明：
db.transaction(storeNames, 'readwrite') - 若在
readwrite事务中只做读取，也不会自动降级为readonly；它仍占用排他资源，影响并发性
versionchange 事务：唯一可改结构的特殊类型
它不属于常规数据操作事务，而是用于数据库版本升级时创建/删除对象仓库、添加索引等元数据变更。
立即学习“前端免费学习笔记（深入）”；
- 自动由
indexedDB.open(dbName, newVersion)触发，无法手动开启 - 具有隐式的
readwrite权限，但仅限于修改数据库结构，不能操作数据 - 执行期间会中断所有其他事务（包括其他
readwrite），确保结构变更安全 - 代码必须写在
onupgradeneeded事件处理函数中
选错事务模式可能导致操作失败或性能下降。比如用 readonly 调 put() 会直接报 InvalidStateError；而滥用 readwrite 则可能造成不必要的锁竞争。合理区分用途，是写出健壮 IndexedDB 代码的关键一步。
