用途与实际影响
这项功能怎样使用
为什么需要它
内存盘占用系统真实RAM。只看计划任务返回0会漏掉内存紧张；每次警告都弹窗又会干扰使用。项目把执行结果和健康状态分开，并保留警告日志。
举个实际例子
“我刚才看到WARN，现在还要处理吗？”先看最近一轮：9月14日04:03Z这次提交余量已回到17.2GiB，状态为OK。旧告警说明当时余量偏小，不证明Primo坏了，也不是一直有效的清盘指令。
最后我会得到什么
最近状态和过程写入可读文件；普通内存警告不弹窗，严重错误从正常转入时才尝试提醒。
正常工作
本轮空间和内存读数没有触发警告，记录正常。
发现问题
资源紧张或部分读数失败时留下具体警告，不自动结束应用。
暂不可用
某项读数取得不到就写未知，不能把缺值解释成一切正常。
从哪里开始
在已接通这台电脑的 AI 对话中问“Z 盘最近空间和内存巡检怎样”；AI 读取 STATUS 与 guardian.log，普通 WARN 不会弹窗。
需要准备什么
- 想查看哪台电脑最近的巡检
- 遇到的内存或缓存症状
从开始到拿到结果
- 1
守护器定期读取
查看内存盘空间和主机内存，判断是否出现值得提醒的问题。
- 2
把结果留在状态里
最近一轮和过程可回看；普通警告安静记录，严重错误变化才尝试提示。
- 3
按时间解释
这不是实时监控；电脑关机或任务没运行时，上次正常不代表此刻正常。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
9月14日04:03Z自然巡检OK；WARN仍按设计静默关键规则与设计选择
可用内存<8GiB、提交余量<4GiB、Z空闲<2GiB或已用>8GiB会提醒。
WARN写STATUS、.lasthealth和guardian.log；只有进入ERROR才写alerts.log并调用msg.exe。
不自动关闭高内存应用，不调整分页文件；若满足紧急条件，另进入驱动重建分支。
本模块用到的名词
- 提交余量
- CommitLimit减CommittedBytes，是新内存申请的剩余预算，不等同于磁盘空闲或物理可用内存。
- 状态变化提醒
- 上次不是ERROR、本次是ERROR才尝试提醒，包括WARN转ERROR；持续同一ERROR不重复弹。
专业定义
记录空间、内存和提交余量；WARN静默，进入ERROR时提醒。
解决什么
任务返回0只能表明脚本结束。已有部分早期ERROR路径也会返回0，必须同时读取健康状态；新修复的紧急恢复失败明确返回非零。
当前怎样实现
- Win32_PerfFormattedData_PerfOS_Memory提供AvailableMBytes、CommitLimit、CommittedBytes。
- Read-RamDiskSpace优先Get-Volume，必要时用System.IO.DriveInfo，最多尝试3次。
- guardian.log超过1MiB时轮换到guardian.log.1；这是运行日志，不是用户文件备份。
- 2026-09-14T04:03:49Z记录：Z已用0.2GiB/空闲11.8GiB，可用内存30.3GiB、提交余量17.2GiB、不可归属估算-9.6GiB。
执行流程
- 1
任务进入一轮巡检并采集空间。
- 2
读取系统内存和相关估算，汇总触发的阈值。
- 3
写入最近健康与日志，仅按ERROR状态变化发出提醒。
边界
- 定期采样不是实时监控，电脑关机或未满足用户会话条件时不会照常执行。
- 无窗启动代码和日志不单独证明每次实际桌面都从未出现窗口。
失败与恢复
- 长期提交余量偏低
- 结合其他系统工具查实际占用；守护器不从一个数值猜进程，也不自行改系统内存配置。
- 采样返回未知
- 保留采集失败与缺值，不能把旧数或0顶上去宣称健康。
真实入口
zguardian.ps1空间采样、内存阈值与Set-Health。
logs/STATUS.txt最近一次健康快照。
run_hidden.vbs隐藏运行并等待退出。
如何验证
- 03:43Z已验收的15项静态检查保留WARN静默断言，代码输入未变，本次不机械重跑。
- 9月14日04:03Z自然任务返回0，STATUS另行回读为OK；9月8日03:37Z曾返回0但STATUS为WARN，任务结果与健康状态分别判断。
与其他模块的关系
这些读数既用于日常解释，也为下一模块的有条件驱动恢复提供输入。