performancecounter是windows下最稳、最低开销、无需管理员权限的监控方案；需首次调用nextvalue()预热并等待500ms以上再取值，且必须dispose或using释放资源。
直接用 PerformanceCounter，别绕弯——这是 Windows 下最稳、最低开销、无需管理员权限的方案；但第一次 NextValue() 必须丢弃，且第二次调用前至少等 100ms（推荐 500ms+），否则 CPU 值恒为 0 或乱跳。
为什么 NextValue() 第一次总返回 0？
因为 PerformanceCounter 的 CPU 计数器是差分式采样：它靠两次时间点的计数差值除以时间间隔算出百分比。首次调用时没“上一次值”，只能返回 0 或未定义值。
内存计数器（如 "Available MBytes"）虽非差分，但首次读也可能因系统缓存未就绪而偏差较大。
- 必须显式调用一次
NextValue()预热，然后Thread.Sleep(500)再取真值 - 不要在循环开头直接
Console.WriteLine(cpuCounter.NextValue())—— 这等于每轮都重置采样起点 - 若用
Timer定期采集，确保初始化阶段已预热过，且 Timer 间隔 ≥500ms
"Processor" 和 "Memory" 计数器怎么配才不出错？
类别名、计数器名、实例名三者必须严格匹配系统注册表中定义的名称，大小写敏感，拼错一个字符就抛 InvalidOperationException。
- CPU 全局使用率：
new PerformanceCounter("Processor", "% Processor Time", "_Total")—— 注意是"_Total"（下划线开头），不是"Total"、"0"或空字符串 - 内存可用量：
new PerformanceCounter("Memory", "Available MBytes", null)——"Memory"不是"memory"，"Available MBytes"中间有空格，不能写成"AvailableMB" - 如果程序跑在 Win10/11 家庭版或精简容器里，可能根本没加载性能计数器定义，需手动执行
lodctr /R（管理员命令行）修复
内存使用率怎么算才接近任务管理器？
任务管理器显示的“内存使用率” = (总物理内存 − Available MBytes) / 总物理内存。千万别用 "% Committed Bytes In Use"，那是虚拟内存提交比例，和你看到的“内存条快满了”完全不是一回事。
-
Available MBytes是实时空闲物理内存（MB），单位固定，不用自己除 1024 - 总物理内存不能用
GC.GetTotalMemory()（那是托管堆大小），也不能硬编码；推荐用new ComputerInfo().TotalPhysicalMemory（需引用Microsoft.VisualBasicNuGet 包） - 若不想引 VB 包，可用
GlobalMemoryStatusExP/Invoke，但要处理ulong和平台差异 - 公式示例：
float memPct = (totalMb - availMb) / totalMb * 100;
监控循环里最容易漏掉的三件事
长期运行的监控逻辑（比如后台服务）不注意这些，几天后句柄泄漏、CPU 毛刺、数值失真全找上门。
- 每个
PerformanceCounter实例必须Dispose()或用using包裹，否则计数器内核句柄持续累积 - 不要在每次循环里
new PerformanceCounter(...)—— 初始化开销大，且易触发句柄泄漏；应复用单例实例 - 若监控多个进程（比如按名查
"Process"类别），InstanceName必须是当前存活的进程名，进程退出后继续查会抛异常，需加try/catch并重建实例
真正难的不是写对那几行代码，而是记住“差分采样必须两次+延时”这个反直觉点——几乎所有线上 CPU 监控失准，源头都在这儿。
