xdebug_start_error_collection() 在 Xdebug 3.1+ 才引入，低版本直接不可用；3.1.0+ 需同时启用 xdebug.mode=develop,debug 且手动调用，CLI 下尤其需注意配置与时机。
为什么 xdebug_start_error_collection() 不起作用
这个函数在 Xdebug 3.1+ 才正式引入，低版本调用会静默失败或抛出 Call to undefined function。确认版本最直接的方式是运行 php -v 并检查是否含 Xdebug v3.1.0+；若为 3.0.x 或更早，该函数根本不存在，不是配置问题，而是版本不支持。
- 3.0.x 及之前：只能靠
xdebug_disable()临时关闭，无法“收集”错误 - 3.1.0+：需确保
xdebug.mode=develop,debug（不能只设debug），否则错误收集被禁用 - CLI 模式下默认不加载 Xdebug 的 error collection 功能，必须显式启用：
xdebug.start_with_request=trigger或手动调用xdebug_start_error_collection()
如何真正“隐藏”调试时的报错输出
隐去报错 ≠ 屏蔽错误，而是让错误不输出到页面/终端，但仍可被捕获、记录或用于断点调试。关键在分离「错误发生」和「错误呈现」：
- 调用
xdebug_start_error_collection()后，所有E_WARNING、E_NOTICE等会被暂存，不再自动输出 - 用
xdebug_get_collected_errors()获取数组，结构为[['type'=>2, 'message'=>'Undefined variable', 'file'=>'a.php', 'line'=>12]] - 配合
error_reporting(0)和ini_set('display_errors', '0')双保险，防止未被 Xdebug 拦截的错误漏出 - 注意：PHP 致命错误（
E_ERROR、E_PARSE）仍会中止脚本，Xdebug 不会“捕获”它们——这是 PHP 底层行为，无法靠此函数隐藏
xdebug.mode=develop 和 debug 的区别直接影响错误收集
很多人只开 debug 模式，结果 xdebug_start_error_collection() 返回 false。这是因为错误收集属于 develop 模式的能力范畴，而非 debug：
-
xdebug.mode=debug：仅启用远程调试（IDE 断点、步进），不激活错误收集、堆栈追踪等开发辅助功能 -
xdebug.mode=develop：启用错误收集、xdebug_info()、增强的var_dump()等，但不开启远程连接 - 要同时用断点 + 隐藏报错，必须设为
xdebug.mode=develop,debug，且确保xdebug.start_with_request=trigger或手动启动 - 修改后务必重启 Web 服务或 CLI 进程，
php --ri xdebug中的Mode行必须显示develop,debug
CLI 脚本里调用失败的常见原因
在命令行跑 PHP 时，xdebug_start_error_collection() 很容易返回 false，不是代码写错，而是环境没准备好：
立即学习“PHP免费学习笔记（深入）”；
- Xdebug 默认在 CLI 下禁用大部分开发功能，除非明确配置
xdebug.mode=develop,debug（不只是 INI 文件里写了，还要确认 CLI 读的是哪个 INI） - CLI 模式下
xdebug.start_with_request无效，必须手动调用xdebug_start_error_collection()，且要在任何错误触发前执行 - 如果用了
set_error_handler()，Xdebug 的收集机制可能被绕过——它只拦截 PHP 原生错误分发链，不接管自定义 handler - 验证是否生效：在调用后故意触发一个
trigger_error('test')，再立刻var_dump(xdebug_get_collected_errors())，有数据才是真生效
