根本解法是用SELECT ... FOR UPDATE在事务中原子化“读余额+更新”，MySQL需主键防表锁，PostgreSQL锁随语句释放须同事务执行，libSQL无行锁需乐观重试，Java调用须显式事务管理。
MySQL 存储过程中必须用 SELECT ... FOR UPDATE 显式加行锁
直接 UPDATE 余额再查余额，或先 SELECT 再 UPDATE，都会在两个语句之间产生竞态窗口。比如两个并发请求同时读到余额为 100，各自加 50，最终变成 150 而不是 200。根本解法是把「读余额 + 更新」封装成原子操作，靠 SELECT ... FOR UPDATE 实现。
它会在匹配行上加排他锁（X 锁），阻塞其他事务对该行的任何写操作，直到当前事务提交或回滚。注意：该语句必须在事务内执行，且表要有主键或唯一索引，否则会升级为表锁。
- 错误写法：
SELECT balance FROM accounts WHERE account_number = ?→ 然后单独UPDATE - 正确写法：
SELECT balance INTO @cur_balance FROM accounts WHERE account_number = ? FOR UPDATE - 若账户不存在，
FOR UPDATE不会报错，但INTO变量为空，需用ROW_COUNT()判断是否查到行
PostgreSQL 用 SELECT ... FOR UPDATE 更稳妥，但要注意 READ COMMITTED 隔离级行为
PostgreSQL 默认隔离级别是 READ COMMITTED，这意味着 SELECT ... FOR UPDATE 只锁定当前语句看到的快照中已存在的行——如果另一事务在你 SELECT 之后、UPDATE 之前插入了新行，你不会锁住它。对充值这种明确针对已有账户的操作影响不大，但务必确认账户记录已存在。
更关键的是：PG 的 FOR UPDATE 在语句结束时就释放锁，不像 MySQL 那样持续到事务结束。所以必须确保后续的 UPDATE 和 INSERT（如记录充值流水）都在同一个事务块里，且顺序不能颠倒。
- 必须写成：
BEGIN; SELECT ... FOR UPDATE; UPDATE ...; INSERT INTO recharge_log ...; COMMIT; - 不能把
SELECT FOR UPDATE和UPDATE拆成两个独立事务 - 避免在事务中调用外部 HTTP 或耗时操作，否则锁持有时间过长，拖垮并发能力
libSQL（SQLite 分支）不支持行级锁，充值逻辑必须绕开并发冲突
libSQL 底层仍是 SQLite，而 SQLite 的 WAL 模式只支持整库级别的写锁。哪怕你用 SELECT ... FOR UPDATE，它也不会真正加行锁，而是退化为写事务排队。这意味着高并发充值下，所有请求会串行执行，吞吐量直线下跌。
实际可行方案只有两个：一是业务层做请求合并（例如把同一账户的多次小额充值攒批处理）；二是改用乐观锁 + 重试机制——先读余额，计算新值，再用带条件的 UPDATE accounts SET balance = ? WHERE account_number = ? AND balance = ?，检查 ROW_COUNT() 是否为 1，失败则重试。
- libSQL 的
WASM函数无法替代锁机制，它只适合纯计算，不参与事务控制 - 不要试图在 libSQL 存储过程中模拟“锁等待”，它的事务模型不支持
- 如果必须强一致性，别选 libSQL 做核心账务，它定位是轻量嵌入式场景
Java 调用时，CallableStatement 必须配合事务管理器显式控制
很多人以为只要存储过程里写了 START TRANSACTION 就万事大吉，但 Java 侧如果用默认的自动提交模式，每条语句都会被 JDBC 驱动隐式提交，导致存储过程里的 COMMIT 失效，甚至抛出 Can't execute statement in a read-only transaction 错误。
正确做法是：在调用前关闭连接的自动提交，并在 Java 层统一管理事务边界。Spring 的 @Transactional 是最稳妥的选择；裸 JDBC 则必须手动调用 connection.setAutoCommit(false)，再 execute() 存储过程，最后 commit() 或 rollback()。
- 切勿在存储过程中混合使用
SET autocommit = 0和 Java 层事务控制，极易导致嵌套事务混乱 -
CallableStatement的参数绑定要严格对应存储过程定义的IN/OUT类型，否则充值金额可能被截断或类型转换失败 - 充值成功后，务必检查存储过程返回的
SQLSTATE或自定义错误码，而不是只看 JDBC 是否抛异常
并发安全的充值不是加个锁就完事，它卡在数据库锁粒度、事务生命周期、驱动行为和应用层控制四个层面的交界处。最容易被忽略的是：你以为锁住了行，其实锁住了表；你以为事务在数据库里，其实被 JDBC 悄悄拆成了多个；你以为存储过程兜底了，其实 Java 层早把它当普通 SQL 执行了。
