本文详解 pg-promise 批量数据库操作中因 promise 传递不当导致的未捕获异常问题，指出 `t.batch()` 已废弃，并提供基于显式 `await` 和统一错误处理的现代事务写法。
在使用 pg-promise 构建事务性数据库操作时，一个常见陷阱是：将已执行（即已返回 Promise 实例）的查询函数直接传入 t.batch()，而非在事务上下文内按需构造 Promise。这会导致错误无法被事务层捕获，进而引发 Uncaught Exception——尤其在数据库连接失败、SQL 语法错误或约束冲突等场景下，Node.js 进程可能意外崩溃。
根本原因在于：
- addToColumn(...) 若不接收事务对象 t，默认使用全局 db 实例执行，其返回的 Promise 脱离事务上下文；
- 当该 Promise 被提前调用（如 batchQuery([...]) 中直接传入 addToColumn(...) 调用结果），它会在 db.tx() 启动前就已开始执行，甚至可能在事务开启失败后仍尝试连接数据库；
- 此时 .catch() 仅作用于 db.tx() 返回的 Promise，而内部“游离”的 Promise 抛出的错误无人监听，最终成为未捕获异常。
✅ 正确做法：所有数据库操作必须在事务回调函数内、通过事务对象 t 执行，并避免过早求值。推荐使用 async/await 显式控制流程，而非依赖已废弃的 t.batch()：
// ✅ 推荐：参数化 + 可选事务上下文
const addToColumn = (tableName, columnName, entryId, amountToAdd, t = db) => {
return t.one(
'UPDATE ${table:name} SET ${column:name} = ${column:name} + ${amount:csv} WHERE id = ${id:csv} RETURNING *',
{
table: tableName,
column: columnName,
amount: amountToAdd,
id: entryId,
}
);
};
// ✅ 推荐：事务内显式 await，自动回滚 + 统一错误传播
const transferEnvelopeBudgetByIds = async (req, res, next) => {
try {
const result = await db.tx(async t => {
const from = await addToColumn(
'envelopes',
'budget',
req.envelopeFromId,
-req.transferBudget,
t
);
const to = await addToColumn(
'envelopes',
'budget',
req.envelopeToId,
req.transferBudget,
t
);
return { from, to }; // 可选：返回结构化结果
});
req.updatedEnvelopes = result;
next();
} catch (err) {
// 所有错误（连接失败、SQL 错误、约束冲突）均由此处统一捕获
// pg-promise 自动回滚事务，无需手动处理
next(err);
}
};⚠️ 注意事项：
- 不要使用 t.batch()：官方文档明确标注其为 obsolete，且语义模糊（易误解为“并发执行”，实则顺序 resolve）；现代写法应使用 await 链式调用，语义清晰、调试友好、错误可追溯。
- 禁止提前执行查询：切勿在 db.tx() 外调用 addToColumn(...) 并将返回的 Promise 塞入数组——这等于绕过事务控制。
- 错误处理集中化：事务内的 try/catch 或顶层 catch() 已足够；每个查询函数内部 .catch()（如原代码中的 handleQueryErr）反而会吞掉关键错误，破坏事务原子性。
- 事务对象 t 是必需的：确保所有参与事务的查询都显式传入 t，否则它们运行在独立连接上，既不共享事务隔离级别，也无法联动回滚。
总结：pg-promise 的事务可靠性取决于 Promise 的构造时机与执行上下文。坚持“事务内构造、事务内执行、顶层捕获”的三原则，即可彻底规避未捕获异常，并获得强一致的 ACID 保障。
