phpEnv中display_errors必须关，但需同步设log_errors=On且error_log路径有效并重启服务；Parse Error无法用ini_set关闭，须检查php.ini加载路径及语法错误；@操作危险，应改用空合并或isset判断。
phpEnv 里 display_errors 必须关，但不能只关 display_errors
phpEnv 是 Windows 下的 PHP 集成环境（类似 XAMPP），默认开启 display_errors = On，所以 Notice、Warning 会直接打在网页上。关掉它最可靠的方式是改 php.ini —— 但很多人只改了这一项，结果线上出错却完全没日志，问题更难定位。
你得同时确认这三件事：
-
display_errors = Off（关页面输出） -
log_errors = On（错误必须写进日志） -
error_log = "C:/phpEnv/logs/php_error.log"（路径要存在、可写；phpEnv 默认可能指向不存在的目录）
改完别忘了点 phpEnv 控制面板里的「重启 Apache」或「重启 PHP-FPM」—— 它不会自动热加载 ini 变更。
phpEnv 启动后报 Parse Error 却关不掉？那是 ini_set 失效了
ini_set('display_errors', '0') 在 phpEnv 里常被误用：它只能在脚本运行中起作用，而 Parse Error（比如少了个括号、引号不配对）发生在解析阶段，ini_set 根本没机会执行。
立即学习“PHP免费学习笔记（深入）”；
所以如果你改了代码却还看到白屏+错误，优先检查：
- 是不是入口文件（如
index.php）开头就有语法错误？ - phpEnv 当前用的是哪个 php.ini？运行
php --ini或新建一个info.php里写<?php phpinfo(); ?>查看「Loaded Configuration File」路径 - 是否改错了其他同名 ini 文件？phpEnv 有时会加载
php.ini-development或php.ini-production，而不是你编辑的那个
error_reporting(0) 在 phpEnv 里能临时用，但有兼容风险
在入口文件顶部加 error_reporting(0); 确实能屏蔽大部分运行时 Notice，但它不处理所有情况：
- PHP 8.5+ 的新错误类型（如
ValueError、UnhandledMatchError）本质是异常，error_reporting对它们无效 - 如果项目用了 Composer 自动加载，某些类加载失败触发的
Fatal error可能早于这行代码执行 - Windows 下路径分隔符问题可能导致
require失败并直接报错，这时error_reporting(0)还没生效
它适合本地快速验证逻辑，不适合长期用于 phpEnv 的“伪生产”调试环境。
@ 符号不是关闭 Notice 的正解，phpEnv 里尤其危险
有人在 phpEnv 里对 $_GET['id'] 加 @$_GET['id'] 来躲 Notice: Undefined index，这其实埋了三个坑：
-
@会抑制整个表达式的错误，包括后续可能的Warning（比如类型转换失败） - PHP 8.5 默认开启
exception.show_suppression_hint = On，日志里会额外记一条「Suppressed by @ operator」，干扰真实问题排查 - phpEnv 的 Apache 模块和 CLI 模式对
@的行为略有差异，同一段代码换种方式运行可能突然暴露错误
真要防 Undefined index，用 $_GET['id'] ?? null 或 isset($_GET['id']) ? $_GET['id'] : null 更干净，也避免性能损耗。
复杂点在于：phpEnv 的日志路径、PHP 版本切换、多站点共用 ini 的场景下，display_errors 设置很容易被覆盖或忽略。别依赖单一开关，盯住 phpinfo() 输出的「Loaded Configuration File」和「error_log」实际值，比任何文档都准。
