launchctl list 查不到可疑服务是因为默认只显示当前用户 LaunchAgents，系统级 LaunchDaemons 或其他用户域服务需用 sudo launchctl list 或 launchctl print-system/print-user 查看；恶意 plist 可能随机命名、路径异常，卸载后须彻底删除文件并清空废纸篓；登录项和 ScriptingAdditions 目录也可能是隐蔽干扰源。
launchctl list 查不到可疑服务？先确认用户域加载范围
默认 launchctl list 只显示当前用户的 LaunchAgents，而系统级服务（LaunchDaemons）或其它用户域的服务不会出现。如果你怀疑是后台服务干扰，但 launchctl list 输出空或没找到关键词，大概率是因为没切对域。
实操建议：
- 查当前用户服务：
launchctl list | grep -i 关键词（如wechat、sync） - 查系统级服务（需 sudo）：
sudo launchctl list | grep -i 关键词 - 查所有已加载的 plist 路径：
launchctl print-system 2>/dev/null | grep path或launchctl print-user $(id -u) 2>/dev/null | grep path
注意：部分恶意 plist 会故意用随机字符串命名（如 com.apple.updater.8a3f9d.plist），不依赖关键词也能暴露——只要路径不在 /System/Library/LaunchDaemons/ 或 ~/Library/LaunchAgents/ 的常规位置，就该重点盯防。
停用 .plist 后应用仍异常？检查是否被 reload 自动重载
执行 launchctl unload ~/Library/LaunchAgents/com.example.bad.service.plist 只是临时卸载，不代表文件失效。只要该文件还留在原目录，下次登录、重启、甚至某些应用启动时触发的 launchctl load 都可能让它复活。
容易踩的坑：
- 只
unload不删文件 → 服务随时可能回归 - 移入废纸篓但没清空 → macOS 仍可通过 Spotlight 或备份机制重建索引并 reload
- 误删系统 plist（如
com.apple.speech.speechrecognitiond.plist）→ 可能导致语音、听写等基础功能瘫痪
正确做法：先 unload，确认应用恢复后再把对应 .plist 文件拖进废纸篓 → 立即右键“清空废纸篓”。别跳过清空这步。
登录项里藏着伪装服务？识别 HelperTool / SyncAgent 类命名陷阱
“系统设置 > 用户与群组 > 登录项”界面显示的名称常是美化后的展示名，实际背后可能是任意 Bundle ID。像 HelperTool、Updater、SyncAgent 这类名字几乎从不来自 Apple，而是第三方 installer 的惯用掩护。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
验证方式：
- 在登录项列表中右键某条目 → “在访达中显示”，看它指向哪个 app 或脚本
- 若指向
~/Library/Application Support/下某个陌生子目录，大概率是自启组件 - 终端查其真实标识：
mdls -name kMDItemCFBundleIdentifier /path/to/app
特别注意：有些应用卸载不干净，登录项残留但主程序已删。这时点击“−”删除后，还要去 ~/Library/Preferences/ 手动搜 com.vendor.*.plist 并删掉，否则下次开机可能因读取失败引发静默崩溃。
ScriptingAdditions 目录被注入？非 Apple .osax 是高危信号
/Library/ScriptingAdditions/ 是系统级扩展入口，Apple 官方只放 StandardAdditions.osax。任何其他 .osax 文件（尤其是名字带 Patch、Loader、Hook、Crack 的）都极可能是劫持源，会在应用启动早期注入代码，导致闪退或功能错乱。
检查命令：
- 列出全部：
ls -l /Library/ScriptingAdditions/ - 过滤非 Apple：
ls /Library/ScriptingAdditions/ | grep -v "StandardAdditions"
处理原则：只要不是你明确安装并信任的（比如 Alfred、BetterTouchTool 的合法 osax），一律移出该目录并清空废纸篓。这类注入不走 launchd 流程，launchctl 根本查不到，却能深度干扰 NSApp 初始化阶段。
真正难定位的，往往是那些不报错、不弹窗、只让应用卡在启动动画或白屏几秒后自动退出的服务——它们往往混在 ScriptingAdditions 或 Login Items 里，靠名字伪装，靠路径隐蔽。动手前先做快照：launchctl print-user $(id -u) > before.txt，操作后再比对，比盲目删更稳。
