notice错误开发时出现而上线不报，因生产环境常屏蔽e_notice；应通过isset()、空合并操作符、函数默认值等主动预防，而非关闭错误报告。
为什么 Notice 错误总在开发时冒出来，上线却没报？
因为 PHP 默认错误报告级别通常不包含 E_NOTICE（比如生产环境设为 E_ALL & ~E_NOTICE），但这不代表问题不存在——未定义变量、访问数组不存在的键、用空值当字符串拼接，都会触发 Notice，轻则日志刷屏，重则逻辑错位。
真正要避免的不是“不让它显示”，而是“不让它发生”。靠关掉 error_reporting 掩耳盗铃，迟早会在某个条件分支里漏掉关键逻辑。
isset() 和 array_key_exists() 到底该用哪个？
判断数组键是否存在时，二者行为不同：前者会同时检查“键存在”且“值不为 null”，后者只关心键本身。很多 Notice 来自直接读取 $arr['missing']，但盲目套 isset() 可能掩盖 null 值本应被处理的业务场景。
- 读取配置或 GET/POST 参数时，优先用
isset($arr['key'])—— 大多数情况你确实需要“有且非空” - 明确允许
null是合法值（比如数据库字段可空），改用array_key_exists('key', $arr) - PHP 7.4+ 可用空合并操作符：
$val = $arr['key'] ?? 'default';，比isset()更简洁安全 - 别写
if ($arr['key'])—— 这既可能触发 Notice，又会把0、false、''当作假值误判
函数参数未传全就调用，Undefined variable 怎么防？
常见于自定义函数里直接用未声明的形参变量，或依赖全局作用域的变量（比如忘了 global $db;）。这类 Notice 往往出现在函数首次执行路径之外，测试容易遗漏。
立即学习“PHP免费学习笔记（深入）”；
- 所有函数参数都应设默认值：
function logMsg($msg = '', $level = 'info') { ... } - 禁用
register_globals（已废弃，但老项目可能残留），绝不依赖自动注入的变量名 - 用
func_get_args()+func_num_args()做运行时校验太重，优先靠类型声明和默认值解决 - 启用严格模式后，PHP 7.0+ 的类型声明（如
string $name）会在参数缺失时直接报Fatal error，比 Notice 更早暴露问题
开启 E_STRICT 和静态分析真有用吗？
有用，但得配合正确姿势。单纯在 php.ini 加 E_ALL | E_STRICT 可能让你被第三方库的老旧写法淹没；而只靠 IDE 提示又容易忽略动态构造的变量名。
- 开发环境设置：
error_reporting(E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED);—— 先屏蔽干扰项，聚焦自己代码的问题 - 用
php -l检查语法没问题，但发现不了Notice；必须实际运行（哪怕最小单元测试）才能触发 - Composer 包建议加
"require-dev": {"phpstan/phpstan": "^1.10"}，跑phpstan analyse src/能提前揪出未初始化变量、无效数组访问等 - CI 流程里加一条
php -d error_reporting=32767 script.php 2>&1 | grep "Notice\|Warning"，比靠人眼扫日志靠谱
最易被忽略的是动态变量名（$$var）、可变函数调用（$func()）和反射操作——这些地方 PHP 静态分析基本失效，只能靠防御性检查和完整路径覆盖测试来兜底。
