Mac后台服务需分层排查：先用活动监视器（启用“所有进程，分层显示”）查CPU占用；再用launchctl list验证launchd加载状态；最后用ps -axu | grep '?'捕获非launchd托管的守护进程。
当你发现Mac变慢、风扇狂转或电池耗电异常快，却找不到对应界面程序时，说明有后台服务在持续运行。这些服务不显示窗口，但可能长期占用CPU、内存或网络资源，必须分层识别才能准确定位。
用活动监视器快速图形化定位
这是最直观、无需记忆命令的方式，适合所有用户，尤其适合排查突发性能问题。
按下 Command + 空格 打开聚焦搜索，输入“活动监视器”并回车启动。
点击顶部菜单栏的“显示”→“所有进程，分层显示”——【这一步必须执行】，否则系统级守护进程（如 launchd、kernel_task）会被折叠隐藏，你将漏掉真正的后台源头。
切换到“CPU”标签页，点击“% CPU”列标题排序，重点关注长期稳定高于15%的进程；若数值在5%–10%之间持续跳动，大概率是iCloud同步、Spotlight索引或第三方应用后台更新任务。
右键列标题空白处，勾选“PID”“用户”“命令行”三项：用户为 root 的多为系统守护；用户为你当前用户名的，通常是微信、飞书、1Password等应用注册的Launch Agent；“命令行”字段能暴露真实路径，可一眼区分是官方二进制还是被注入的脚本。
用 launchctl 查看已加载的 launchd 服务
macOS用launchd统一管理自启与后台服务，launchctl list是判断“是否真被系统激活”的权威依据，它不显示临时进程，只反映launchd当前加载状态。
打开终端，执行：launchctl list | grep -v "0x" | grep -v "PID"
输出中第三列为 - 表示该服务已加载且正在运行；若为数字（如1234），说明进程曾启动过但已退出；若为 0x... 开头的十六进制值，属于内部状态条目，直接过滤掉更清晰。
查某个具体服务是否真活：launchctl print gui/$(id -u)/com.tencent.xinWeChat
把 com.tencent.xinWeChat 换成你要查的服务ID，输出里出现 state = running 才算真正运行中。
系统级服务需加 sudo：sudo launchctl list | grep -v "PID"
注意：/System/Library/LaunchDaemons 中的服务受SIP保护，不能卸载或修改，也不建议强行干预。
用 ps 命令捕获“野生”后台进程
有些程序根本没走launchd机制，而是直接启动的守护进程（比如某些Java工具、Python后台脚本、Docker Desktop的辅助进程），它们不会出现在 launchctl list 里，但确实在后台占资源。
方法一：筛选无终端关联的典型守护ps -axu | grep '?' | grep -v grep
【TTY为?代表该进程没有关联任何终端会话，是典型的后台守护进程】，例如 mdnsresponder、distnoted、apsd 全都会被精准捕获。
方法二：按关键词搜索特定进程ps -axu | grep -i wechatps -axu | grep -i alfred
输出中“USER”列显示运行身份，“COMMAND”列显示完整启动命令，便于判断是否为预期行为。
方法三：实时盯梢资源波动
输入 top 启动后，按 Shift + P 按CPU排序，按 Shift + M 按内存排序，按 H 切换线程视图——比静态列表更能捕捉瞬时峰值。
确认服务是否开机自启而非仅当前运行
第一步：定位plist配置文件
用户级服务通常存于：ls ~/Library/LaunchAgents/
系统级服务存于：ls /Library/LaunchDaemons/
/System/Library/LaunchDaemons 中的文件受SIP保护，不可修改。
第二步：检查Disabled键值
用nano打开任一plist文件：nano ~/Library/LaunchAgents/com.feishu.desktop.plist
查找 <key>Disabled</key><true/> —— 若存在且值为 true，说明该服务已被禁用，即使设置了 RunAtLoad 也不会自启。
第三步：验证加载状态与自启逻辑是否一致
一个服务在 launchctl list 中显示为 -，只说明它当前正被launchd管理运行；但它是否会在下次开机/登录时自动拉起，完全取决于对应plist文件中 Disabled 键的布尔值和用户登录状态。
