PerformanceCounter首次调用NextValue()返回0是正常行为，因其需两次采样计算差值，首次无基准故返回0；必须间隔≥100–500ms（建议≥1秒）调用第二次才获有效值。
PerformanceCounter第一次调用NextValue()为什么总是0
因为 NextValue() 不是读快照，而是计算两个采样点之间的差值；首次调用时没有前序基准，只能返回 0 或无效值。这不是 bug，是 Windows 性能计数器的固有行为。
- 必须调用两次
NextValue()，且中间至少间隔 100–500ms（官方建议 ≥1 秒才最稳） - 不要在循环里每轮都新建
PerformanceCounter实例——构造开销大，且可能触发计数器重初始化，导致连续返回 0 - 若需高频采集（如每 200ms 一次），应复用同一实例，并确保每次调用前已“预热”过（即至少成功调用过一次有效
NextValue()） - 在 .NET 6+ 中，
NextValue()可能因系统计数器未就绪而抛出InvalidOperationException，建议包裹 try/catch 并重试 1–2 次
CPU使用率为什么算不准：_Total 和 0,1,2… 实例的区别
用 "Processor" 类别时，instanceName 决定了你监控的是整体还是单核——选错会导致数据语义错误。
-
"_Total"：所有逻辑处理器（含超线程）的加权平均使用率，适合判断整体负载是否过高 -
"0"、"1"等数字实例：对应第 1、2 个逻辑处理器，可用于识别单核打满、其他核空闲的不均衡现象（常见于锁竞争或非并行友好代码） - 别用
""（空字符串）或未枚举的实例名，会直接抛InvalidOperationException: Instance 'xxx' does not exist - 获取可用实例列表可调用
PerformanceCounterCategory.GetCategories().FirstOrDefault(c => c.CategoryName == "Processor")?.GetInstanceNames()，但生产环境不建议每次采集前都查——缓存一次即可
内存使用率不能直接读 % Committed Bytes In Use
这个计数器反映的是分页文件提交比例，不是物理内存真实压力；它受虚拟内存配置影响极大，和“系统卡顿”无强相关性。真正该盯的是可用物理内存。
- 推荐组合：
"Memory"类别 +"Available MBytes"计数器，再配合总物理内存算使用率 - 总内存获取方式有两个主流选择：
— 引用Microsoft.VisualBasic.Devices.ComputerInfo（需 NuGet 包Microsoft.VisualBasic），调用new ComputerInfo().TotalPhysicalMemory
— 用 WMI 查询Win32_ComputerSystem.TotalPhysicalMemory，不依赖 VB 库但稍慢 - 千万别用
GC.GetTotalMemory(false)—— 它只返回托管堆大小，和系统内存完全无关 - 注意单位：Available MBytes 返回的是整数 MB 值，不是字节；计算使用率公式为
(totalMB - availableMB) / totalMB * 100
并行任务中监控 CPU/内存容易漏掉的关键点
在 Parallel.ForEach 或 Task.Run 场景下，光看系统级指标不够——你得区分“是业务逻辑真忙，还是调度/同步开销大”。
- CPU 长期 >90% 但吞吐量不升反降？大概率是上下文切换或锁争抢，此时应叠加监控
"System\Context Switches/sec"和"Process\Thread Count" - 内存缓慢上涨但 GC 不回收？检查是否在并行循环里不断 new List
或 StringBuilder 且未释放引用——这时 "Process\Working Set"比系统内存更敏感 - 不要把监控逻辑塞进 hot path（如每个 Task 内部反复创建计数器），应抽成独立后台线程定时采样，避免干扰主业务性能
- Production 环境务必设阈值自动告警，而不是只打日志——等人工翻 log 时，OOM 或线程饿死往往已经发生
实际部署时最容易被忽略的，是计数器初始化失败的静默降级。比如在容器化环境或最小化 Windows Server 上，性能计数器服务可能被禁用，PerformanceCounter 构造会成功，但 NextValue() 始终返回 0 或抛异常。上线前必须验证计数器能否返回合理数值，不能只靠本地开发机测试通过就认为 OK。
