PHP 页面出现 Notice 时，先保留具体提示并定位代码，再决定信息显示在哪里。屏蔽 Notice、禁止对外显示和真正修好触发代码，是三件不同的事。

逻辑或不是错误级别位掩码

2018 年写 WordPress PHP 时，用过类似表达式：

error_reporting(E_ALL || ~E_NOTICE); // 错误：这里得到逻辑运算结果

error_reporting 接受错误级别的位掩码。如果只是解释“排除 E_NOTICE”应写：

error_reporting(E_ALL & ~E_NOTICE);

含义是保留 E_ALL 中除 E_NOTICE 之外的位；&、~ 不能换成逻辑 ||。PHP error_reporting 手册 有对应说明。这个片段用于说明运算，不是建议开发时隐藏诊断。

报告、页面展示和日志分别控制

开发环境通常需要充分报告错误；生产响应则不应向访问者泄漏路径、堆栈、SQL 或配置细节。PHP 分别提供 error_reporting、display_errors 和 log_errors，详见 错误处理运行配置。

例如下面表达的是生产配置方向，实际值和日志去向应由部署环境管理，而不是直接复制覆盖所有站点：

error_reporting = E_ALL
display_errors = Off
log_errors = On

还需确认 PHP-FPM/Apache 与命令行使用的配置是否一致、日志可写且不在公开目录、保留策略是否合适。WordPress 或自定义错误处理器可能影响输出，不能只改一个 php.ini 就认定生效。

按具体提示修，而不是让页面看不见

保存脱敏后的错误级别、文件行号与触发输入，检查变量初始化、数组键和对象属性访问。不要仅给所有缺失值加默认值，以免把本应存在的数据缺失掩盖掉。

不同 PHP 版本可能对同一问题采用不同级别；过去的 Notice 在另一版本可能表现为 Warning，所以不能靠排除一个常量处理全部情况。修复后重新触发原输入，确认日志中也不再出现该问题，并检查 JSON、下载和回调响应没有混入诊断文字。