这种本地复现不了的线上CPU占用问题确实挺头疼的，我之前也碰到过类似的棘手情况，给你分享几个实战性强的排查方向：

1. 用系统自带工具抓持续CPU活动日志 #

单次进程dump只能看某一瞬间的状态，没法反映CPU占用的持续规律，推荐用Windows官方的**WPR（Windows Performance Recorder）+ WPA（Windows Performance Analyzer）**组合：

• 让用户打开WPR，选择「CPU Usage」场景，点击「Start」录制5-10分钟（覆盖CPU持续占用的时间段），然后点击「Save」生成.etl日志文件发给你
• 你用WPA打开这个日志，过滤到目标进程，就能看到这段时间里该进程的哪些线程、哪些函数一直在消耗CPU，甚至能定位到具体代码行（如果有符号文件的话）
• 如果用户嫌GUI麻烦，也可以用命令行工具xperf，比如执行xperf -on PROC_THREAD+LOADER+CPU开始录制，xperf -d cpu_trace.etl停止并保存，效果和WPR一致

2. 用Process Explorer深入分析线程级CPU占用 #

Process Explorer比系统自带任务管理器强太多，能精准定位问题线程：

• 让用户下载打开Process Explorer，找到目标进程，右键选择「Properties」→ 切换到「Threads」标签
• 这里能看到每个线程的ID、实时CPU使用率、累计CPU时间，找到占用CPU最高的几个线程
• 右键这些线程选择「Stack Trace」，就能看到该线程当前的调用栈（如果有符号文件，能显示具体函数名），大概率能找到一直在循环或者频繁执行的代码逻辑

另外搭配**Process Monitor（ProcMon）**也很有用：让用户录制一段时间的进程活动，过滤目标进程的所有操作，看有没有频繁重复的文件读写、注册表访问、网络请求——有时候CPU高不是因为计算多，而是因为一直在循环重试某个失败的IO操作。

3. 针对「回归问题」的定向排查 #

既然确定是回归，重点对比出问题版本和正常版本的差异：

• 先确认用户的版本号，和你本地正常的版本号，拉取这两个版本之间的代码变更记录，重点检查：
  • 新增的定时任务、循环逻辑（比如有没有把退出条件写错导致死循环）
  • 异步回调、事件监听的代码（比如有没有某个事件被频繁触发）
  • 第三方依赖的版本变更（比如引入了新的SDK、库）
• 如果用户那边可以，让他们临时回退到之前正常的版本，确认CPU占用是否恢复，进一步验证是版本变更导致的问题

4. 收集更多进程上下文信息 #

有时候问题出在用户的特定环境里，让用户提供这些信息：

• 用命令tasklist /v /fi "imagename eq yourprocess.exe"获取进程的命令行参数、工作目录，看是不是启动方式和你本地不一样（比如加载了额外的配置、插件）
• 用wmic process where name='yourprocess.exe' get Caption,CommandLine,ProcessId,ThreadCount看线程数量，对比正常版本的线程数，有没有异常增多
• 让用户截图任务管理器的进程详情页，重点看「CPU时间」（不是实时CPU），确认是持续累积的占用，而不是偶尔的波动

5. 远程调试（如果用户允许） #

如果用户那边配合，可以尝试远程调试：

• 用Visual Studio的远程调试功能，或者WinDbg远程连接到用户的机器
• 实时attach到目标进程，查看线程的调用栈，甚至设置断点跟踪循环逻辑的执行情况，这是最直接的排查方式，但需要用户配合做一些配置

6. 补充日志排查 #

如果程序本身有日志模块，让用户开启详细日志级别，重点记录：

• 循环逻辑的执行次数、耗时
• 定时器、异步任务的触发频率
• 关键函数的调用次数
  如果没有现成日志，可以临时给程序加一些轻量日志（不要影响性能），让用户运行一段时间后把日志发给你，看有没有异常频繁的函数调用

备注：内容来源于stack exchange，提问作者rsp