这不是 bug，是 PHP 7.1+ 主动暴露的类型隐患；修复核心是确保参与算术运算的值真正可转为数字，而非屏蔽警告——字符串如 '123a' 或 'b456' 在 + 运算中因非法数值转换触发 E_NOTICE 或 E_WARNING，需用 filter_var、is_numeric 预检或 (int)/(float) 显式转换。
直接结论：这不是 bug，是 PHP 7.1+ 主动暴露的类型隐患；修复核心不是屏蔽警告，而是让参与算术运算的值真正可转为数字。
为什么 + 运算会触发 A non-numeric value encountered
PHP 7.1 起，当字符串被隐式转为数字用于 +、-、/、* 等算术操作时，引擎会严格检查转换合法性：
- 字符串以数字开头但带尾随非数字（如
'123abc'）→ 触发E_NOTICE - 字符串不以数字开头（如
'abc123'或空字符串''）→ 触发E_WARNING - 常见诱因包括：表单未提交字段返回空串、数据库字段为 NULL/TEXT 类型但误作数值参与计算、时间戳解析失败返回
false后直接参与加减
别用 ini_set("error_reporting", "E_ALL & ~E_NOTICE") 掩盖问题
临时关掉警告看似“修复”，实则掩盖真实数据异常：
- 它不会改变
$a + $b的实际计算结果（'123a' + 'b456'永远是0 + 0 = 0） - 线上环境可能因此把错误数据写入数据库或返回给前端
- TP5/6、Laravel 等框架中，该警告常指向模型时间字段自动写入逻辑缺陷，关警告等于跳过关键校验
用对转换函数：优先 filter_var($x, FILTER_VALIDATE_FLOAT) 或 is_numeric() 预检
比盲目套 intval() 更安全，尤其涉及金额、精度场景：
立即学习“PHP免费学习笔记（深入）”；
-
intval('123.45')→123（截断，丢失小数） -
(float) '123.45'或floatval('123.45')→123.45（保留精度，但注意浮点误差） -
filter_var($x, FILTER_VALIDATE_FLOAT) !== false→ 显式验证是否合法浮点格式，推荐用于表单输入校验 - 若必须整数运算，且允许截断，用
(int) $x比intval($x)更快（无函数调用开销）
特殊场景：date() 和 strtotime() 组合出错
报错常出现在类似 date('Y-m-d', strtotime($input) + 86400) 这类代码中：
-
strtotime($input)对非法时间字符串（如'2026-13-01'、NULL）返回false -
false + 86400→0 + 86400 = 86400，但会触发警告 - 正确写法：
$ts = strtotime($input); if ($ts === false) { /* 处理错误 */ } else { date('Y-m-d', $ts + 86400); } - ThinkPHP 中遇到
A non well formed numeric value encountered，大概率是formatDateTime()收到了非时间戳值却没做is_numeric()判断
最易被忽略的一点：这个警告从不单独出现——它背后一定存在一个本不该参与算术运算的“假数字”。定位时不要只看报错行，要逆向追踪每个操作数的来源，尤其是用户输入、数据库读取、API 返回值。修复动作越靠近数据入口（比如在接收 POST 参数时就过滤），后续逻辑就越干净。
