从熟悉的界面追溯来源
先想一想最近启动过什么：本地开发服务、测试、打包任务，或某个工具的后台功能。即使终端窗口已经不在眼前，也不能假定后台任务已经结束。
在活动监视器搜索 node，按 CPU 排序，查看目标详情并记下当前 PID。Apple 提供“所有进程（分层）”视图，能帮助查看父子关系；它是追溯来源的线索，不能单独证明某个项目有问题。
- 对照编辑器的任务面板和各个终端标签，寻找仍在执行的测试、开发服务或脚本。
- 结合 PID、启动时间和父进程核对同一个任务；不要只看列表中是否同名。
- 有路径或启动命令可查看时，用项目目录和脚本名辅助确认。命令可能包含敏感参数，不要原样发到聊天或工单。
- 熟悉终端时可用 ps 做只读查询，补看父进程和命令。查询结果只是一刻的状态，进行任何退出前都要重新确认对象。
确认任务还在做什么
测试输出还在出现、构建阶段在推进时，node 忙碌可能符合预期。若原本应该空闲的开发服务持续忙碌，可以留意是否反复触发同一轮构建、相同输入是否不断重复。这里的现象是排查线索，不是自动结论。
Node 官方文档说明，耗时的 JavaScript 回调会占住事件循环，让其他工作难以及时获得处理。单看 CPU 数字，仍无法区分合理计算、重复工作和代码缺陷。也不要仅因进程名相同，就把一个项目的现象归到另一个项目。
优先在启动它的地方停止
确认不再需要该任务后，先保存工作，再使用编辑器的停止按钮，或在确切的前台终端任务中中断它。若任务仍不退出，再回到进程详情核对身份，选择正常退出；强制结束应留到你能接受未完成输出和未保存工作丢失的时候。
不要对所有 node 使用 killall，也不要复制文章、截图里的示例 PID 直接结束进程。PID 会被系统复用，同名任务也可能服务于不同项目。停止后如果任务重新出现，应检查开发工具或上级任务是否在自动拉起它。
反复出现时，记录可复现条件
保留项目、命令、触发操作和占用开始时间，在可控环境重现。若问题总在同一种输入之后出现，比“node 很高”更能缩小范围；每次只改变一个条件，避免同时重装依赖、换版本和改配置。
对于自己维护的代码，可以进一步使用 Node 官方性能分析工具。CPU profile 用来寻找时间花在哪些函数或调用路径，而不是只得到另一个百分比。采集会产生额外开销和文件，应在合适的测试环境进行；分享前检查其中的路径和其他项目信息。
巡航帮助发现任务，不代替代码分析
QuietWatch 可以根据可读取的路径和命令提供来源线索，并记录持续高 CPU 的观察时长；信息受系统权限和启动方式限制，不保证每个项目都能准确识别。
它不会采集源码或自动执行修复。可选 AI 只在预览并确认后接收资源摘要，不收到原始命令、路径或 PID，因此不能替代项目日志和 CPU profile 对根因的分析。