该错误源于PHP 7.1+对非规范数值字符串隐式转换的严格警告，非phpEnv导致；需检查表单输入、数据库字段、CSS/JS混合值三类场景，用filter_var、CAST或floatval等安全处理，而非关闭E_NOTICE。
这个错误跟 phpEnv 本身无关，phpEnv 只是 Windows 下的 PHP 集成环境（类似 XAMPP），它不修改 PHP 的底层行为。真正触发 Notice: A non well formed numeric value encountered 的，是你代码里对字符串做算术运算或数值转换时，传入了格式不合法的值。
为什么在 phpEnv 里特别容易看到这个 Notice
因为 phpEnv 默认开启 error_reporting = E_ALL（或至少包含 E_NOTICE），而很多老项目、模板引擎、或从低版本 PHP 迁移过来的代码，习惯性地把带单位、空格、字母后缀的字符串直接用于加减，比如：
$width = "100px" + 20;$time = "2026-04-25" + 86400;-
$score = $_GET['score'] + 10;（但用户输入了95.5abc）
PHP 7.1+ 开始对这类隐式转换更严格：只要字符串开头是数字但后面拖着非数字字符（如 "123abc"），就抛 E_NOTICE；如果完全不以数字开头（如 "abc123"），则抛 E_WARNING。
别改 phpEnv 的 error_reporting 来“解决”它
临时关掉 Notice 看似简单，但等于掩盖问题：
立即学习“PHP免费学习笔记（深入）”；
- 在
php.ini里改成error_reporting = E_ALL & ~E_NOTICE，会让后续类型错误更难定位 - phpEnv 的配置分散在多个 ini 文件（
php.ini、php-cli.ini、甚至 Apache/Nginx 模块级覆盖），容易漏改或冲突 - 上线环境通常不会关 Notice，本地绕过只会让问题延迟暴露
这不是环境问题，是代码健壮性问题。你该处理数据，而不是压制提示。
真正该检查的三类高频场景
对照你的报错行号，重点看这些位置：
-
表单输入直接参与运算：比如
$_POST['price'] * $_POST['qty']，但用户填了"¥199"或"2.5kg"—— 必须先用filter_var($val, FILTER_SANITIZE_NUMBER_FLOAT, FILTER_FLAG_ALLOW_FRACTION)或正则提取数字部分 -
数据库字段类型和 PHP 运算不匹配：比如 MySQL 的
DATETIME字段被 ThinkPHP 自动转成字符串后，又丢给strtotime()或+运算 —— 解决方法是查库时用CAST(created_at AS UNSIGNED)，或模型里关掉自动时间转换（'datetime_format' => false） -
CSS/JS 混合值未剥离单位：像
"20em"、"1.5rem"、"auto"被当数值加减 —— 用rtrim($val, 'pxemrem%vhvw')或floatval($val)更安全（floatval("20em") === 20.0）
最常被忽略的是：这个 Notice 往往出现在深层调用链里（比如某个 Composer 包的辅助函数里做了 $x + 0），只看报错行号不够，得配合 debug_backtrace() 或 Xdebug 断点，确认源头值从哪来、是否可控。修代码比调环境靠谱得多。
