symfony 7本地启动失败和日志不可见的根源在于启动方式与配置不匹配：必须用php -s localhost:8000 -t public，且.env中严格设置app_env=dev和app_debug=1；doctrine.dbal.logging: true仅启用收集，需显式绑定@monolog.logger.doctrine才能输出sql日志。
本地跑不起来、日志看不到——不是 Symfony 有问题，而是启动方式和日志配置没对上。Symfony 7 的内置服务器和日志机制跟以前版本有关键差异，直接套旧方法大概率失败。
php -S 启动失败：路径和环境必须严格匹配
常见错误是页面空白、404 或直接报 Class not found，根本原因是没走 Symfony 的请求入口或环境未激活。
- 必须用
php -S localhost:8000 -t public，-t public不可省略，也不能写成-t public/index.php或-t public/ -
.env中必须同时存在APP_ENV=dev和APP_DEBUG=1，缺一不可；仅设debug: true在 YAML 里无效 - 启动前先验证环境：
php bin/console about输出中必须看到Flex: enabled和Environment: dev - 如果用 Windows + WSL，注意路径权限问题：
var/log/目录需可写，否则后续日志会静默失败
Web Profiler 工具栏不显示：检查三处真实生效点
工具栏（WDT）没出来，90% 是调试模式没真正加载，而不是前端 JS 加载失败。
- 在任意控制器里加
dump($this->getParameter('kernel.debug'))，输出必须是true；若为false，说明APP_DEBUG=1没生效 - 查看页面 HTML 源码底部，必须存在
<script id="sfwdt"></script>；没有说明响应被截断（比如模板里写了exit、用了ob_end_clean()，或 base 模板漏了{{ render_profiler() }}） - 即使脚本存在但工具栏不显示，打开浏览器 Network 面板，筛选 XHR 请求，找带
X-Debug-Token响应头的请求，复制 token 访问/_profiler/{token}—— 能打开就证明 Profiler 数据已采集，问题出在前端注入环节
数据库 SQL 日志不输出：doctrine.dbal.logging 不等于日志落地
设了 doctrine.dbal.logging: true 却看不到 SQL？这是 Symfony 7+ 的典型认知偏差：该配置只启用内部收集，不自动绑定输出目标。
-
doctrine.orm.debug: true只影响 DQL 编译过程，和实际执行的 SQL 无关 - 必须显式绑定一个
Monolog\Logger实例到 DBAL 的logger选项，不能只写logger: '@logger'—— Doctrine 要求具体 channel，推荐用@monolog.logger.doctrine -
config/services.yaml中定义 logger 时，arguments必须传字符串 channel 名（如'doctrine'），handler 的路径要确保%kernel.logs_dir%/doctrine.log可写 - 生产环境严禁开启，SQL 日志含参数占位符，但语句本身可能暴露业务逻辑，且 I/O 压力极大
日志延迟或丢失：别忽略虚拟线程调度特性
Symfony 7 支持虚拟线程日志（需 JDK 21+ + RoadRunner 等协程运行时），但默认不启用；若你启用了，日志行为会和传统模式完全不同。
- 虚拟线程日志是异步非阻塞的，
$logger->info()调用后立即返回，内容提交队列后由 JVM 调度写入 —— 这意味着请求结束时日志可能还没落盘 - 日志中的线程标识变成类似
[VirtualThread[#22]]，无法像传统[worker-1]那样稳定追踪，排查链路需依赖 trace_id 而非线程名 - 若发现日志“有时出现有时不出现”，先确认是否混用了同步 handler（如
StreamHandler）和异步调度器；两者不兼容，会导致丢日志 - 本地开发建议禁用虚拟线程日志，用标准 Monolog 配置；高并发压测阶段再启用并配合
RotatingFileHandler控制体积
真正卡住的往往不是功能怎么写，而是环境变量有没有生效、日志 handler 有没有被 Doctrine 正确识别、以及异步日志里那条刚记录的 SQL 其实还在队列里没刷出去。
