xdebug 3.2.x 升级后断点失效主因是默认行为收紧：xdebug.start_with_request仅认yes/trigger（不再支持1）、xdebug.log_level必须显式设为1023才输出日志、client_host/port校验更严格且无回退，同时禁用默认函数跟踪与降低嵌套深度。
Xdebug 3.1.x 升级到 3.2.x 不是“小版本微调”，而是关键机制的加固与默认行为的收紧。多数升级后断点失效、日志不输出、IDE 连接失败的问题，并非配置写错，而是忽略了 3.2.x 引入的强制校验逻辑和默认禁用策略。
启动触发方式更严格
Xdebug 3.2.x 默认关闭所有自动调试启动行为，xdebug.start_with_request 不再接受 on 或 1，只认 yes 和 trigger；若仍沿用旧值（如 xdebug.start_with_request = 1），该配置会被静默忽略，导致断点完全不生效。
- 必须改为
xdebug.start_with_request = trigger（配合XDEBUG_TRIGGER参数）或yes（全请求监听） -
trigger模式下，需在 URL 加?XDEBUG_TRIGGER=1或设置浏览器插件激活，否则不连接 IDE - 旧版中靠
xdebug.remote_autostart=1实现的“无感调试”在 3.2.x 已彻底失效
日志与错误反馈更明确
3.2.x 增强了调试通道初始化阶段的诊断能力，新增 xdebug.log_level 控制粒度，但同时默认关闭日志输出——即使配置了 xdebug.log 路径，若未显式设 xdebug.log_level = 1023（全量），也不会写任何调试日志。
- 推荐开发时设为
xdebug.log_level = 1023，上线前务必降为0或128（仅错误） -
xdebug.log路径需确保 PHP 进程有写权限，否则日志静默失败，无报错提示 - 可通过访问
xdebug_info()页面查看 “Log” 行是否显示有效路径与级别
客户端连接验证更严谨
3.2.x 对 xdebug.client_host 和 xdebug.client_port 的可达性做了预检：若配置的 host 不可路由（如 host.docker.internal 在 Linux 宿主机未配置 DNS），或端口被占用/防火墙拦截，Xdebug 将拒绝建立 DBGp 连接，且不回退到其他机制。
- Docker 场景下，Linux 用户需手动在
/etc/hosts添加host.docker.internal映射，不能只依赖 macOS/Windows 的内置支持 - VS Code 的
launch.json中"port": 9003必须与xdebug.client_port = 9003严格一致；写成 9000 会连接超时，界面仅显示“正在等待”，无明确错误 - 建议用
telnet 127.0.0.1 9003验证端口连通性，而非仅依赖 IDE 状态图标
性能相关默认值调整
3.2.x 进一步降低默认开销：启用 xdebug.mode = debug 时，不再默认启用函数跟踪（xdebug.collect_functions）和内存分配统计，这些需单独开启，避免误启导致响应延迟翻倍。
- 如需函数调用分析，必须额外加
xdebug.collect_functions = 1 -
xdebug.max_nesting_level默认值从 256 降至 128，递归深的项目需手动调高，否则直接报 “Maximum function nesting level” 错误 - 使用
xdebug.mode = develop可安全启用 var_dump 美化、堆栈美化等辅助功能，完全不走调试通道，零连接开销
