frankenphp worker模式下symfony事务自动提交失效，因进程复用导致doctrine连接与事务状态跨请求残留；需禁用持久连接和模拟预处理、在kernel.terminate中调用$connection->reset()、关闭auto_commit并启用严格错误模式。
FrankenPHP worker 模式下 Symfony 事务自动提交失效
FrankenPHP 启用 worker 模式后，Symfony 的 Doctrine ORM 事务常出现“看似执行了 beginTransaction()，但中间任何异常都未触发 rollback()”——数据已写入数据库，日志里也看不到回滚动作。这不是 Symfony bug，而是 FrankenPHP 的 PHP 进程复用机制与 Doctrine 默认连接生命周期不匹配导致的。
关键点在于：FrankenPHP worker 进程常驻，PDO 连接不会随请求结束而关闭，PDO::ATTR_EMULATE_PREPARES 和 PDO::ATTR_PERSISTENT 若被意外启用，会导致事务状态跨请求残留；更隐蔽的是，Doctrine 默认在每次请求结束时调用 $connection->close() 来清理事务，而 worker 模式下这个钩子根本没机会运行。
- 检查是否启用了持久连接：
doctrine.dbal.url中避免含persistent=true或attr_persistent=1 - 强制禁用模拟预处理语句：
doctrine.dbal.options: { pdo_attr_emulate_prepares: false } - 在
kernel.terminate事件中手动清理事务状态（见下条）
Symfony 请求结束时必须显式 reset 事务状态
FrankenPHP worker 不会销毁整个 PHP 进程上下文，所以 Doctrine 的 Connection 实例可能仍处于 inTransaction === true 状态，下个请求进来直接复用，beginTransaction() 就会抛出 DriverException: Already in transaction 或静默失败。
正确做法是在每次请求生命周期末尾，无论是否发生异常，都确保事务被显式结束或重置：
- 监听
kernel.terminate事件，在事件处理器中调用$connection->reset()（推荐） - 不要依赖
__destruct或register_shutdown_function，worker 模式下这些不一定触发 - 若使用自定义事务管理器，确保其
end()方法在kernel.terminate中被调用，而非仅靠 try/catch + finally
示例（src/EventListener/TransactionResetListener.php）：
public function onKernelTerminate(TerminateEvent $event): void
{
$connection = $this->entityManager->getConnection();
if ($connection->isTransactionActive()) {
$connection->rollBack(); // 防止残留 active 状态
}
$connection->reset(); // 清除内部状态，为下次请求准备
}
Doctrine 配置必须关闭 auto-commit 并启用 strict mode
FrankenPHP worker 下，若 Doctrine 允许自动提交（auto_commit: true），哪怕你手动调用了 beginTransaction()，某些边缘路径（如查询失败、连接中断）仍可能绕过事务控制，直接落库。
务必在 doctrine.yaml 中锁定行为：
- 显式设置
doctrine.dbal.auto_commit: false - 添加
doctrine.dbal.options: { pdo_attr_errmode: PDO::ERRMODE_EXCEPTION }，确保所有 DB 错误都抛异常，不被静默吞掉 - 禁用连接池相关选项：
doctrine.dbal.pool: { enabled: false }（FrankenPHP 自身不提供连接池，开启反而干扰）
错误配置示例（会导致事务错乱）：
# ❌ 危险：auto_commit 默认 true，且未设 ERRMODE_EXCEPTION
doctrine:
dbal:
url: '%env(DATABASE_URL)%'
别忽略 Symfony Messenger 与事务的耦合问题
如果你在 worker 模式下同时用 Symfony Messenger 处理消息（比如异步发邮件、更新搜索索引），事务错乱会更隐蔽：一个 HTTP 请求内开启事务，又 dispatch 了一个消息，该消息被同一个 worker 进程立即消费——此时它复用的是同一个未关闭的 Doctrine 连接，beginTransaction() 直接报错或覆盖前序状态。
解决方案不是禁用 Messenger，而是切断连接复用链：
- 为 Messenger 消费器单独配置独立 DB 连接（通过
doctrine.connections.async） - 或在 dispatch 前手动
$entityManager->clear()+$connection->close()，确保后续消息使用全新连接 - 更重要的是：所有消息处理器必须自己管理事务，不能假设“外层 HTTP 请求的事务还活着”
最容易被忽略的一点：FrankenPHP 的 worker 模式本身不感知 Symfony 的请求-响应周期边界，所有“请求结束即清理”的惯性思维在这里都会失效。你得亲手把每个连接、每个事务、每个 EntityManager 实例的生命周期，按 worker 的节奏重新对齐。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
