php探针显示的内存使用率高于memory_get_usage()是因为前者统计进程级RSS内存（含扩展、OPcache等），后者仅统计脚本堆内存；两者维度不同。
PHP探针显示内存使用率远高于 memory_get_usage()
PHP探针页面里看到的“已用内存”常比 memory_get_usage() 返回值高出数倍，这不是探针出错，而是它默认读取的是进程级 RSS 内存（含 PHP 扩展、OPcache、共享库等），而 memory_get_usage() 只统计当前脚本堆内存。两者统计维度不同。
- 若需验证脚本真实内存消耗，用
memory_get_usage(true)（返回实际分配的内存块大小，含对齐开销） - 探针中“内存限制”字段来自
ini_get('memory_limit')，但若值为-1，说明未设限，此时 RSS 增长不受该配置约束 - OPcache 启用后，
opcache_get_status()['memory_usage']的数值会单独计入 RSS，但不反映在memory_get_usage()中
探针显示的 max_execution_time 与实际超时不符
探针读取的是 ini_get('max_execution_time')，但该值在 CLI 模式下默认为 0（不限时），而在 Web SAPI（如 apache/mod_php 或 FPM）中可能被服务器层覆盖：nginx 的 fastcgi_read_timeout、Apache 的 Timeout、PHP-FPM 的 request_terminate_timeout 都可能先于 PHP 层触发终止。
- 检查超时根源，优先看 Web 服务器日志中的 “upstream timed out” 或 “pool … has been disabled”
- PHP-FPM 模式下，
request_terminate_timeout优先级高于max_execution_time，且不抛出E_ERROR，而是直接 kill 进程，导致探针无法捕获真实超时原因 - 用
get_cfg_var('max_execution_time')替代ini_get()，可绕过某些运行时修改（如ini_set()）造成的误读
探针中 upload_max_filesize 和 post_max_size 显示为 0 或空
这通常不是配置丢失，而是探针脚本自身执行权限或 ini_get() 调用时机问题。当 PHP 运行在 php_admin_value 或 php_admin_flag 严格模式下（常见于 cPanel 或 Plesk 环境），部分配置项会被禁止运行时读取。
- 确认是否启用
disable_functions—— 若其中包含ini_get，探针将无法获取任何配置，需改用解析php_ini_loaded_file()返回的 .ini 文件内容（需文件读取权限） -
upload_max_filesize和post_max_size是字节单位字符串（如"2M"），探针若未做单位换算（return_bytes()类函数缺失），会直接显示原始值，看起来像“异常” - 某些探针用
getenv('PHP_INI_SCAN_DIR')尝试加载额外 ini，但若路径不可读或为空，会导致相关配置项 fallback 为默认值（如0）
为什么探针报告的 zend_version() 和 PHP_VERSION 不一致？
这是正常现象：zend_version() 返回 Zend Engine 版本（如 "4.3.0"），而 PHP_VERSION 是 PHP 解析器版本（如 "8.3.6"）。二者发布节奏不同，Zend Engine 可能小版本迭代不触发 PHP 主版本变更。
立即学习“PHP免费学习笔记（深入）”；
- 不要用
zend_version()判断 PHP 兼容性，它不反映array_is_list()、str_contains()等函数是否存在 - 某些老旧探针把
zend_version()错误映射到 “PHP 引擎版本” 栏位，造成误导；应以PHP_VERSION_ID或version_compare(PHP_VERSION, '8.1.0', '>=')为准 - 若探针显示
zend_version()为"2.6.0"但PHP_VERSION是"7.4.33"，说明探针未适配 PHP 7+ 的 Zend API 分离机制，存在兼容性缺陷，建议更换或手动注释掉该字段
探针本质是多个 ini_get()、function_exists() 和系统调用的组合，它不运行完整请求生命周期，所以所有数值都是快照而非实时状态。最易被忽略的是：探针脚本自身的 require 开销、OPcache 预编译缓存命中率、以及是否在 chroot 或容器中丢失 /proc 访问权限——这些都会让“异常数值”变成必然结果。