协程数据库操作必须使用可挂起的awaitable类型，禁用阻塞api；需非阻塞socket、raii事务管理、协程安全连接池及显式提交/回滚。
协程函数必须用 co_await 等待数据库操作，不能直接调用同步接口
异步事务不是把同步代码包一层 co_await 就完事。C++20 协程要求所有挂起点必须是可挂起的 awaitable 类型，而传统数据库驱动（如 libpq、sqlite3）的阻塞式 API（PQexec、sqlite3_step）会直接卡死线程，彻底破坏协程调度模型。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用支持异步 I/O 的底层驱动：PostgreSQL 推荐
libpq的非阻塞模式 +poll()/epoll()集成；SQLite 推荐sqlite3_blocking_step不可用，得换sqlite3_async或用线程池封装 - 自己实现
awaitable：包装 socket 读写状态，例如封装PQisBusy+PQconsumeInput循环为一个await_ready/await_suspend完整的类型 - 别在协程里调
std::this_thread::sleep_for或任何同步等待——它会让整个协程执行器停摆
事务生命周期必须绑定协程栈，不能跨 co_await 边界持有裸连接指针
协程可能在任意 co_await 处挂起、恢复，甚至被调度到不同线程。如果事务对象内部只存一个 PgConnection*，恢复时该指针可能已失效（连接被回收/重连/超时关闭），或引发并发访问冲突。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 事务对象应管理连接生命周期：用
std::shared_ptr持有连接，并在析构时自动 rollback 或 commit（取决于状态） - 禁止把裸指针、引用、FILE* 等传入 lambda 捕获列表后用于
co_await后续逻辑 - 若用连接池，获取连接必须是协程安全的：比如
co_await pool.acquire()返回的是带所有权语义的 wrapper，而非原始句柄
co_await 数据库操作前必须确保 socket 处于非阻塞模式
Linux 下默认 socket 是阻塞的，libpq 在非阻塞模式下才返回 PGRES_POLLING_READING/PGRES_POLLING_WRITING，否则 PQconnectPoll 或 PQgetResult 会直接阻塞，导致协程“假挂起”——看起来没卡，但实际线程被占住，吞吐崩盘。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 创建连接前必须调
fcntl(sock_fd, F_SETFL, O_NONBLOCK)，且检查返回值（fcntl可能失败） - libpq 初始化后立即调
PQsetnonblocking(conn, 1)，并验证返回值是否为 0（失败则 abort 或抛异常） - 错误信息
"server closed the connection unexpectedly"常因非阻塞未设好，导致后续PQgetResult返回NULL而未处理
事务回滚不能依赖 co_return 自动触发，必须显式控制退出路径
协程函数退出不等于事务结束。如果协程因异常退出、提前 co_return、或被取消（std::coroutine_handle::destroy()），而事务对象没做 RAII 清理或没监听 cancellation，就会留下未提交/未回滚的事务，锁表、拖慢集群。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 事务类构造时标记
m_state = active，析构时若仍为active则强制rollback（需保证 rollback 本身是 async-safe） - 提供
commit()和rollback()成员函数，都返回task<bool></bool>，使用者必须显式co_await tx.commit() - 协程取消（cancellation）需注册回调：用
promise_type::unhandled_exception()和cancellation_token配合，避免异常绕过清理逻辑
真正难的不是写几个 co_await，而是让每个数据库交互点都可中断、可恢复、可超时、可取消，同时不泄露连接、不残留锁、不破坏 ACID。这些边界条件在压测和网络抖动时才会暴露，但修复成本远高于初期设计时多加两行状态检查。
