php探针应通过配置数组按需采集模块并条件渲染，禁用phpinfo()；扩展检测需异常防护与版本获取；必须结合web服务器层ip白名单与php层校验实现权限控制。
PHP探针怎么控制哪些模块显示
PHP探针（如 phpinfo() 衍生的自定义页面）默认会输出全部环境信息，但实际部署时往往只需暴露部分模块（比如只看 memory_limit、upload_max_filesize、opcache 状态），其余敏感项（如 $_SERVER、mysql.default_password）必须隐藏。核心方法不是“删代码”，而是「按需采集 + 条件渲染」。
- 不要直接修改
phpinfo()输出——它不可控、无法过滤、且调用后整个页面结构固定 - 改用
ini_get()、extension_loaded()、function_exists()等函数主动查询目标项 - 把要显示的模块写成配置数组，例如：
$show_modules = ['php_version', 'memory_limit', 'opcache_status', 'gd_support'];
- 每个模块对应一个独立函数封装，比如
get_opcache_status()内部用opcache_get_status()判断是否启用并返回简明状态
如何安全地显示扩展状态（如 Redis、Swoole、Imagick）
直接调用 extension_loaded('redis') 只能返回布尔值，但用户常需要版本号或运行状态。这时必须加异常防护和降级逻辑，否则探针页面可能因扩展未安装而报错中断。
- 用
@version_compare(phpversion('redis'), '5.3.0', '>=')获取版本前加@抑制警告，再配合extension_loaded()双重判断 - Swoole 需区分
swoole扩展和swoole_loader，二者phpversion()返回值不同，不能混用 - Imagick 建议调用
new Imagick() → getVersion()而非依赖phpversion('imagick')，后者在某些编译环境下为空 - 所有扩展检测都应包裹在
try/catch中，捕获ImagickException、RedisException等具体异常类型
为什么不能用 phpinfo(INFO_MODULES) 替代手动检测
看起来 phpinfo(INFO_MODULES) 只输出已加载模块列表，似乎更省事。但它存在三个硬伤：
- 输出是 HTML 片段，无法提取结构化数据，正则解析极不可靠（不同 PHP 版本
phpinfo表格结构有差异） - 不包含扩展版本号，比如 Redis 模块只写 “redis support => enabled”，没版本字段
- 若某扩展崩溃（如旧版 Xdebug 与 PHP 8.2 不兼容），
phpinfo()可能直接 fatal error，整个探针挂掉 - INFO_MODULES 仍会泄露模块名，攻击者可据此判断是否具备利用条件（如存在
exif模块就可能尝试图像元数据注入）
自定义探针里最容易被忽略的权限控制点
很多人做完功能就扔到服务器上，忘了加访问控制。最简方案不是写登录页，而是利用 Web 服务器层拦截：
立即学习“PHP免费学习笔记（深入）”；
- Nginx：在 location 块中加
allow 192.168.1.100;+deny all;，比 PHP 层判断 IP 更早生效 - Apache：用
.htaccess的Require ip 2001:db8::1支持 IPv6，注意AllowOverride None会禁用该文件 - PHP 层兜底：检查
$_SERVER['REMOTE_ADDR']前必须先验证$_SERVER['HTTP_X_FORWARDED_FOR']是否可信（即确认前端 Nginx/Apache 确实设置了该 header） - 绝对禁止将探针放在
webroot下无保护路径，如/probe.php—— 应放在/admin/probe-<strong>随机串</strong>.php并加入exit('Access denied');开头作为双保险
