Symfony默认不支持数据库日志，需通过自定义Monolog处理器或第三方包实现；须创建LogEntry实体、注入EntityManager、重写write()方法，并在monolog.yaml中配置，同时注意降级处理、异步写入与性能优化。
数据库日志记录在Symfony里不是开箱即用的功能
Symfony 默认不把日志写入数据库，它用的是 Monolog，默认输出到文件（如 var/log/dev.log）。想存进数据库，得自己搭个“桥”——要么写个自定义 Monolog 处理器，要么用现成的第三方包。别指望改几行 doctrine.yaml 就能搞定。
推荐用 symfony/monolog-bundle + 自定义处理器
官方 MonologBundle 支持扩展，但不内置 DB 写入能力。你需要一个能连接 Doctrine 并插入日志的处理器。常见做法是实现 Monolog\Handler\AbstractProcessingHandler，并在构造函数里注入 Doctrine\ORM\EntityManagerInterface。
- 创建实体类
App\Entity\LogEntry，字段至少包含level、message、context（JSON）、loggedAt - 处理器中重写
write()方法，用$this->entityManager->persist($log)+flush() - 在
monolog.yaml里注册该处理器，注意设置channels和level，避免循环日志（比如别让 DB 写入失败又触发自身日志） - 别在
dev环境启用——每次请求多一次 DB 插入，会拖慢响应，且容易因事务冲突报错
doctrine/doctrine-bundle 的日志功能 ≠ 应用日志
有人混淆 doctrine.dbal.logging 和应用级日志。这个配置只控制 SQL 查询日志（是否打印 SELECT、INSERT 等），输出目标仍是 Monolog，默认还是文件。它不记录 PHP 异常、用户行为或业务事件。
- 开启方式：
doctrine:→dbal:→logging: true（仅开发环境） - 它依赖
logger服务，底层仍走 Monolog，所以想存 DB 还得回到上一步的处理器方案 - 生产环境关掉它，否则大量 SQL 日志会迅速撑爆表或拖慢 DB
性能和可靠性必须手动兜底
数据库日志最大的坑不是写不进去，而是写不进去时整个请求挂掉。比如 DB 连接超时、表锁死、字段长度不够，都会让 flush() 抛异常，进而中断当前请求流程。
- 所有 DB 操作必须包在
try/catch里，失败时降级为error_log()或丢弃，绝不能让日志逻辑影响主业务 - 考虑异步：用 Messenger 发消息到队列，由消费者写 DB，但会引入延迟和额外运维成本
- 定期清理：给
LogEntry加索引（如loggedAt），并配doctrine:database:delete-old-logs这类命令（需自己写）
真正上线前，得压测看单次请求是否多出 50ms+ 延迟，以及高并发下会不会批量失败。这些细节没人替你试。
