sys_getloadavg() 仅 Linux/Unix 可用，Windows 返回 false；需结合 CPU 核心数归一化判断过载，避免高频调用；网页监控优先用带超时的 curl；内存监控应解析 memory_limit 配置并跟踪峰值；采集须与 Web 请求解耦，用 cron 或后台进程实现。
sys_getloadavg() 在 Linux/Unix 上能直接拿到系统负载，但 Windows 下返回 false，别指望它跨平台工作。想靠 PHP 做监控，得先分清“查什么”和“在哪查”——服务器状态、网页可用性、内存水位、进程存活，每类指标的获取路径完全不同，硬套一个函数解决不了问题。
怎么用 sys_getloadavg() 判断服务器是否过载
它返回的是三个浮点数：1/5/15 分钟平均负载，但数值本身没意义，必须结合 CPU 核心数看。
- 先检查函数是否存在：
function_exists('sys_getloadavg')，Windows 或某些容器环境可能根本不可用 - 用
shell_exec('nproc 2>/dev/null')拿核心数，别硬写死为 4 或 8 - 归一化计算：若 5 分钟负载是
3.2、核心数是4，则实际负载率是3.2 / 4 = 0.8，超 0.9 才真该告警 - 别在每个 HTTP 请求里调用——高并发时
sys_getloadavg()虽快，但叠加 shell 调用或频繁读/proc就成瓶颈
监控网页是否宕机，curl 比 get_headers() 可靠得多
get_headers() 默认只发 HEAD 请求，很多 CDN 或 WAF 会拦截或返回缓存头，导致误判；curl 可控性强，还能测真实响应时间与内容。
- 必须设
CURLOPT_TIMEOUT_MS（比如 3000），避免 DNS 卡住整个脚本 - 加
CURLOPT_NOBODY => false和CURLOPT_RETURNTRANSFER => true，确保拿到完整响应体用于关键词校验 - 检查
curl_getinfo($ch, CURLINFO_HTTP_CODE)，但别只认200——503、429同样代表服务异常 - 如果要验证页面内容，用
strpos($content, '预期关键词')，别用==全文比对，HTML 可能有动态时间戳或随机 token
内存监控不能只看 memory_get_usage(true)
这个函数返回当前 Zend 内存分配量，但真正决定脚本能跑多远的是 memory_limit 配置值——而它可能是 -1（不限）、128M、2G 这类带单位的字符串。
- 用
ini_get('memory_limit')获取配置，再手动解析：遇到M就乘1024*1024，G就乘1024*1024*1024，-1则跳过阈值比较 - 单次请求中多次调用
memory_get_usage(true)并记录峰值，比只在脚本末尾取一次更有预警价值 - 配合
gc_collect_cycles()后再查一次内存，若回落不明显，大概率存在循环引用泄漏
定时采集必须和 Web 请求解耦
把监控逻辑塞进 monitor.php 然后靠 crontab 每分钟跑一次，看似简单，但一旦采集包含 curl、shell_exec 或读 /proc/meminfo，就会在高峰期拖慢主服务。
立即学习“PHP免费学习笔记（深入）”；
- 后台采集进程用
exec("nohup php collector.php > /dev/null 2>&1 &")启动，主请求完全无感知 - 采集结果写入 Redis 或本地 JSON 文件，Web 层只读缓存，避免重复 IO
- 容器环境注意权限：
/proc默认可读，但若用了securityContext.readOnlyRootFilesystem: true，就得显式挂载/proc - 别依赖
sleep()轮询——PHP CLI 进程长期运行易被 OOM killer 干掉，优先选 cron + 短生命周期脚本
/proc/stat 里算 CPU 使用率，需要两次采样做差值，中间隔 1 秒——这个 1 秒如果卡在用户请求链路里，就等于主动给接口加了延迟。所以采集时机、数据落盘方式、错误降级策略，每一步都得带着“它会不会拖垮线上”这根弦来设计。 
