① 304%：这个进程大约用了3.04个逻辑核

在一次 Microi吾码 当前节点观测中，8个逻辑处理器上出现了304.47%的进程原始CPU。它不是机器“超载到三倍”。

raw = ΔprocessCpuMilliseconds / ΔwallClockMilliseconds × 100
304.47% ≈ 3.04 个逻辑核

② 38%：把进程放回整机容量里看

同一份 Microi吾码 源码把原始值再除以逻辑处理器数。当前节点有8个逻辑处理器，所以304.47% ÷ 8 ≈ 38.06%。

③ 92.5%：整台机器仍然可能很忙

进程归一化只有38%，不代表主机只有38%。主机CPU还包括其它进程、系统服务与内核活动。

• 主机92.5%：全局确实接近饱和。
• 当前API进程38.06%：它不是主机全部压力的来源。
• 诊断方向：继续找其它进程或系统层负载，不能只优化当前API。

④ 78.2%：墙钟耗时贡献，不是CPU归因

系统把窗口内每次请求的 ElapsedMs 按路由相加，再除以窗口请求总耗时，得到 CostSharePercent。

CostSharePercent = route.TotalElapsedMs / window.TotalElapsedMs × 100
等待数据库、网络、锁也会增加ElapsedMs

所以78.2%只说明这个热点值得优先排查，不能写成“它吃掉了78.2%的CPU”。

⑤ 正确排查顺序不是盯着最大数字

1. 确认核数：把Raw翻译成等效逻辑核。
2. 看主机CPU：判断全局是否饱和。
3. 看进程Normalized：判断当前进程压力。
4. 看活动请求：识别并发堆积。
5. 看热点贡献：缩小范围，再结合P95、GC、数据库与外部依赖。