1. 安卓 SQLite 事务为什么总在真机上翻车安卓 SQLite 事务这件事看起来就是beginTransaction开头、setTransactionSuccessful标记、endTransaction收尾三步走但真正放到真机上跑尤其是涉及转账、库存扣减、订单状态流转这类必须保证原子性的场景翻车概率远比想象中高。核心检索词先摆出来安卓 SQLite 事务的原子性与并发写入一致性验证是每个做本地数据持久化的 Android 开发者绕不开的基本功。它解决的是「一组 SQL 要么全成功、要么全回滚」的问题适合所有需要在手机本地维护账户余额、积分、库存、离线队列的 App 开发者。我见过太多代码长这样beginTransaction()之后直接execSQL两条更新中间没有任何异常捕获setTransactionSuccessful()写在最后endTransaction()放在finally里。表面没问题但一旦第二条 SQL 抛异常第一条已经执行、事务没标记成功endTransaction()会回滚——这逻辑是对的。真正的问题出在别处有人把db.close()写在endTransaction()之前有人用getWritableDatabase()每次新建 helper有人在事务里嵌套查询另一个库还有人根本没意识到money字段用了varchar(2)存金额转账 100 直接截断成10。这篇就围绕一个可复制的转账场景把事务模板、异常回滚、并发写入验证、adb 日志排查全部走一遍。同时我会用 TaoToken 的统一 Key 通道把同一段事务代码丢给多个模型做代码审查看看不同模型对「事务边界」「异常处理」「字段类型」这些点的判断差异。TaoToken 在这里的角色很明确一个 API Key 走通多个模型省去分别申请、分别配环境的麻烦专注在代码审查本身。先说清楚适用人群如果你写过SQLiteOpenHelper知道execSQL和rawQuery的区别但对「事务什么时候真的回滚」「并发写会不会丢更新」心里没底这篇就是给你准备的。全程用 Android Studio 自带模拟器或真机都能跟做adb 命令直接复制即可。2. TaoToken 统一 Key 通道准备与多模型审查环境在动手写事务之前先把代码审查的通道搭好。为什么要在 SQLite 事务这种偏底层的主题里引入模型审查因为事务的坑往往不在语法而在语义字段类型选错、异常吞掉、事务范围过大导致锁竞争这些靠肉眼 review 容易漏。用多个模型交叉看同一段代码能快速暴露盲区。TaoToken 的定位是统一 Key 通道你在官网注册后拿到一个 API Key就能通过同一套接口调用不同模型。对做代码审查来说这意味着你可以把同一段BankDBOpenHelper和转账逻辑分别发给擅长 Java/Android 的模型和擅长并发分析的模型对比它们指出的问题。接入信息如下建议直接记下来官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址https://taotoken.net/api模型对话页https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite拿到 Key 之后最省事的验证方式不是写代码而是先用 curl 打一发确认通道通。下面这条命令把YOUR_API_KEY换成你自己的 Key模型 ID 换成文档里列出的任意一个即可curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer YOUR_API_KEY \ -d { model: claude-sonnet-4-20250514, messages: [ {role: user, content: 用一句话说明 Android SQLite 事务中 setTransactionSuccessful 的作用} ] }返回里能看到choices[0].message.content就说明通道正常。这一步很关键因为后面做代码审查时如果请求失败你要能区分是「模型没返回」还是「Key/网络配置错了」。如果你更习惯在编辑器里做审查可以把 TaoToken 配到支持自定义 Base URL 的编码工具里。以 Claude Code 这类工具为例需要配全三件套Base URL 填https://taotoken.net/apiKey 填你的 API KeyModel ID 填文档里对应的模型标识。三者缺一不可只填 Base URL 不填 Model ID 是最常见的配置错误。配好之后把下面这段有问题的转账代码发给模型让它审查public void click(View view) { BankDBOpenHelper helper new BankDBOpenHelper(this); SQLiteDatabase db helper.getWritableDatabase(); db.beginTransaction(); try { db.execSQL(update account set moneymoney-100 where namezhangsan); String s null; s.endsWith(haha); db.execSQL(update account set moneymoney100 where namelisi); db.setTransactionSuccessful(); } finally { db.endTransaction(); } db.close(); }多模型审查的价值在这里体现得很直接有的模型会先指出money字段是varchar(2)存不下三位数金额有的会指出s.endsWith触发空指针后finally里endTransaction会回滚但db.close()在事务结束后执行没问题还有的会提醒getWritableDatabase每次调用返回同一实例但 helper 重复 new 会造成资源浪费。这些点单独看都不难但一次性收齐能省很多调试时间。3. 可复制的 SQLite 事务模板与配置片段这一节给出可以直接抄进项目的完整模板。先修正原 excerpt 里的两个硬伤money字段用varchar(2)是错的金额应该用integer存分或者real存元onUpgrade空实现会导致版本升级时表结构不更新。下面是修正后的BankDBOpenHelperimport android.content.Context; import android.database.sqlite.SQLiteDatabase; import android.database.sqlite.SQLiteOpenHelper; public class BankDBOpenHelper extends SQLiteOpenHelper { private static final String DB_NAME bank.db; private static final int DB_VERSION 1; public BankDBOpenHelper(Context context) { super(context, DB_NAME, null, DB_VERSION); } Override public void onCreate(SQLiteDatabase db) { db.execSQL(create table account ( _id integer primary key autoincrement, name varchar(20), money integer not null default 0)); } Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { if (oldVersion 2) { db.execSQL(alter table account add column updated_at integer); } } }注意money integer单位是分。转账 100 元就是 10000 分避免浮点误差和字段截断。接下来是事务模板。核心原则事务范围尽量小异常必须显式处理endTransaction放finallysetTransactionSuccessful只在所有操作成功后调用。public boolean transfer(String from, String to, int amountInCents) { BankDBOpenHelper helper new BankDBOpenHelper(context); SQLiteDatabase db helper.getWritableDatabase(); db.beginTransaction(); try { db.execSQL(update account set money money - ? where name ?, new Object[]{amountInCents, from}); db.execSQL(update account set money money ? where name ?, new Object[]{amountInCents, to}); db.setTransactionSuccessful(); return true; } catch (Exception e) { Log.e(Transfer, transfer failed, rolled back, e); return false; } finally { db.endTransaction(); } }这段代码的关键点用?占位符而不是字符串拼接避免 SQL 注入和引号问题catch里记录日志但不吞异常语义返回 false 让调用方知道失败endTransaction在finally里保证一定执行。如果setTransactionSuccessful没被调用endTransaction会自动回滚。如果你用 Kotlin模板等价如下fun transfer(from: String, to: String, amountInCents: Int): Boolean { val db helper.writableDatabase db.beginTransaction() return try { db.execSQL(update account set money money - ? where name ?, arrayOf(amountInCents, from)) db.execSQL(update account set money money ? where name ?, arrayOf(amountInCents, to)) db.setTransactionSuccessful() true } catch (e: Exception) { Log.e(Transfer, transfer failed, e) false } finally { db.endTransaction() } }对于需要批量写入的场景比如离线队列一次同步 500 条记录事务模板要加上yieldIfContendedSafely或分批提交避免长时间持锁。下面是一个批量插入的配置片段public void batchInsert(ListRecord records) { SQLiteDatabase db helper.getWritableDatabase(); db.beginTransaction(); try { for (Record r : records) { db.execSQL(insert into record (payload, created_at) values (?, ?), new Object[]{r.payload, r.createdAt}); } db.setTransactionSuccessful(); } finally { db.endTransaction(); } }如果你在项目里用 Gradle 管理依赖确认android.database.sqlite是系统自带不需要额外引入。但如果你用 Room事务写法不同Room 用Transaction注解或runInTransaction底层仍是 SQLite 事务。这里不展开 Room专注原生 API。配置层面还有一个容易忽略的点SQLiteDatabase默认是ENABLE_WRITE_AHEAD_LOGGING关闭状态。WAL 模式能提升并发读性能但会生成-wal和-shm文件。如果你在验证数据一致性时发现查不到刚写入的数据先确认是不是 WAL 模式下读连接没看到最新提交。开启方式Override public void onConfigure(SQLiteDatabase db) { super.onConfigure(db); db.enableWriteAheadLogging(); }把上面这些片段拼起来你就有了一个可运行、可审查、可验证的事务基础。下一节用 adb 和日志实际跑一遍看数据到底有没有一致。4. 用 adb 与日志验证事务原子性与并发写入代码写完了怎么证明事务真的生效不能只看「没报错」要实际查库、看日志、模拟异常。这一节给出完整验证步骤。第一步把 App 装到模拟器或真机确保adb devices能看到设备。然后插入两条初始数据。最直接的方式是在 App 启动时执行一次初始化或者用 adb shell 直接操作数据库。注意非 root 设备不能直接访问 App 私有目录下的 db 文件所以推荐在 App 里加一个调试入口或者用run-as命令仅 debug 包可用adb shell run-as com.example.myapp ls databases/如果能看到bank.db说明路径正确。接着插入初始账户adb shell run-as com.example.myapp sqlite3 databases/bank.db \ insert into account (name, money) values (zhangsan, 10000); adb shell run-as com.example.myapp sqlite3 databases/bank.db \ insert into account (name, money) values (lisi, 10000);注意有些设备自带sqlite3有些没有。如果没有可以在 App 里写一个查询方法把结果打到 Logcat或者把 db 文件 pull 出来用本地工具查adb exec-out run-as com.example.myapp cat databases/bank.db /tmp/bank.db sqlite3 /tmp/bank.db select name, money from account;第二步触发正常转账。调用transfer(zhangsan, lisi, 10000)然后查库adb shell run-as com.example.myapp sqlite3 databases/bank.db \ select name, money from account;预期结果zhangsan 变成 0lisi 变成 20000。如果两个都变了说明事务提交成功。第三步触发异常回滚。把转账方法里的第二条 SQL 改成会抛异常的语句比如查询一个不存在的表db.execSQL(update account set money money - ? where name ?, new Object[]{amountInCents, from}); db.execSQL(update not_exist_table set x 1); // 抛异常 db.setTransactionSuccessful();重新跑一次然后查库。预期结果zhangsan 的余额不变仍是上一步的值。因为异常导致setTransactionSuccessful没执行endTransaction回滚了第一条更新。这一步是验证原子性的核心一定要亲手跑一遍。第四步看 Logcat 确认回滚日志。在catch块里打的Log.e(Transfer, ...)应该能在 Logcat 里看到adb logcat -s Transfer:E输出类似E/Transfer: transfer failed, rolled back E/Transfer: android.database.sqlite.SQLiteException: no such table: not_exist_table第五步并发写入验证。开两个线程同时转账一个从 zhangsan 转 lisi一个从 lisi 转 zhangsan各转 100 分循环 100 次。理论上总金额不变。用下面的代码跑ExecutorService pool Executors.newFixedThreadPool(2); for (int i 0; i 100; i) { pool.submit(() - transfer(zhangsan, lisi, 100)); pool.submit(() - transfer(lisi, zhangsan, 100)); } pool.shutdown(); pool.awaitTermination(30, TimeUnit.SECONDS);跑完后查库zhangsan lisi 的总和应该还是 20000。如果少了说明有更新丢失通常是事务没包住读-改-写或者用了insertWithOnConflict之类的替换逻辑导致覆盖。这里有个坑SQLiteDatabase默认是串行化的同一进程内多个线程写会排队所以上面的并发测试在单进程内通常不会丢更新。真正会出问题的是多进程同时写同一个库或者事务里先rawQuery读余额再execSQL更新读和写之间被其他事务插入。要验证这一点可以在事务里加Thread.sleep模拟耗时再用两个进程同时跑。日志验证还有一个技巧在beginTransaction和endTransaction前后打时间戳观察事务持锁时长。如果某个事务持锁超过几百毫秒就要考虑拆分。long start System.currentTimeMillis(); db.beginTransaction(); // ... 操作 db.setTransactionSuccessful(); db.endTransaction(); Log.d(TxTime, transaction took (System.currentTimeMillis() - start) ms);实测下来单条 update 的事务通常在 1-5ms批量 500 条插入在 50-200ms。如果你的事务动辄几百毫秒检查是不是在事务里做了网络请求或大量计算。5. 事务报错排查401、local proxy failed、reading choices 与 OAuth这一节把实际会撞到的报错列出来对照解决。分两类一类是 TaoToken 通道侧的一类是 SQLite 事务本身的。先看通道侧。如果你在调用模型审查代码时遇到401 Unauthorized九成是 Key 没带对或过期了。检查请求头是不是Authorization: Bearer YOUR_API_KEY注意 Bearer 后面有一个空格。如果 Key 是从控制台复制的确认没有多余换行。重新生成一个 Key 再试curl -i https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-20250514,messages:[{role:user,content:ping}]}如果返回local proxy failed说明请求根本没到服务端通常是本地网络配置或 Base URL 写错。确认 Base URL 是https://taotoken.net/api不要多加/v1之外的路径也不要用 http。如果你在编码工具里配了自定义地址检查是不是把 Base URL 和完整 endpoint 搞混了。reading choices这类报错通常出现在解析响应时说明返回结构和你预期的不一致。先看原始返回curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-20250514,messages:[{role:user,content:ping}]} | head -c 500如果返回里有error字段按错误信息处理。如果是空响应检查模型 ID 是否拼错。模型 ID 必须和文档里列出的完全一致大小写敏感。OAuth相关报错一般出现在用 Claude Code 这类工具时工具默认走 OAuth 登录而不是 API Key。如果你要用 TaoToken 的 Key需要在工具配置里显式指定 API Key 模式并把 Base URL、Key、Model ID 三件套填全。只填 Key 不填 Base URL工具会走默认端点自然失败。再看 SQLite 侧。最常见的报错是android.database.sqlite.SQLiteException: no such table原因通常是onCreate没执行或表名拼错。检查SQLiteOpenHelper的构造函数里数据库名和版本号版本号变了才会触发onUpgrade第一次安装触发onCreate。如果你改了表结构但没升版本号旧库不会更新。database is locked是多进程或多线程写冲突。单进程内SQLiteDatabase会自己排队但如果你开了 WAL 又用多个连接可能撞上。解决办法是确保所有写操作走同一个SQLiteDatabase实例或者用beginTransactionNonExclusive配合 WAL。attempt to re-open an already-closed object是db.close()之后又用了这个 db。事务模板里close要放在endTransaction之后且确认没有其他线程还在用。更好的做法是不要手动 close让 helper 管理生命周期。UNIQUE constraint failed在转账场景里不常见但如果你用insert而不是update重复插入会撞。检查是不是把「更新余额」写成了「插入新账户」。还有一个隐蔽的坑money字段如果用了varcharupdate account set money money - 100在 SQLite 里会做类型转换10000 - 100得到 9900看似正常但一旦有非数字字符就会变 0。所以字段类型一定要用integer。排查顺序建议先确认通道通curl 能返回再确认 SQL 能单独执行sqlite3 命令行最后确认事务边界日志时间戳。三步定位比盲目改代码快得多。6. 把事务验证接进日常开发流事务验证不该是一次性动作而应该接进日常开发流。我的做法是在 debug 包里加一个「数据一致性自检」入口每次改完数据库相关代码点一下就跑一遍插入初始数据、正常转账、异常回滚、并发转账、查总和。全部通过才提交。自检的核心断言就一条转账前后总金额不变。用 SQL 表达select sum(money) from account;正常转账前后这个值必须相等。异常回滚后也必须相等。并发转账后还是相等。如果不等说明事务没兜住。配合 TaoToken 的多模型审查可以把自检脚本和事务代码一起发给模型让它检查「有没有漏掉的异常路径」「事务范围是否过大」「字段类型是否合理」。我试过把同一段代码发给三个模型一个指出money类型问题一个指出catch里应该区分异常类型一个指出helper重复创建。三个问题都是真实存在的人工 review 未必一次看全。如果你做的是离线优先的 App事务还会和同步逻辑交织。建议把「本地事务」和「同步队列」分开本地事务只保证单机一致性同步队列负责把变更推到远端。两者用同一个事务边界包住会导致锁竞争拆开更稳。最后给一个实用技巧在onConfigure里开启外键约束。SQLite 默认不强制外键转账场景如果有关联表不开外键可能留下孤儿记录。Override public void onConfigure(SQLiteDatabase db) { super.onConfigure(db); db.setForeignKeyConstraintsEnabled(true); }把上面这些串起来你的安卓 SQLite 事务就从「能跑」变成「可验证、可审查、可回归」。下次再遇到余额对不上、库存扣成负数先跑一遍自检再让模型看一眼事务边界基本能定位到问题。