# 如何調查不熟悉的 Mac 行程

> 依行程擁有者、路徑、父行程、簽章、資源趨勢、開啟檔案與行程取樣判斷，而非只看名稱。

Published: 2026-06-16 | Updated: 2026-09-05

「活動監視器」會列出應用程式、輔助程式、代理、守護行程和系統服務。行程名稱只能作為線索：不同軟體可能使用相似名稱，惡意軟體也可以偽裝。判斷時要結合所屬使用者、路徑、父行程、程式碼簽名、資源趨勢和觸發操作。

選擇「顯示 > 所有行程」，再加入使用者、CPU 時間、執行緒和種類等欄。按兩下行程可查看父行程、開啟的檔案與連接埠。Apple 的[活動監視器說明](https://support.apple.com/guide/activity-monitor/actmntr1001/mac)還介紹了分層與系統行程檢視。行程疑似卡住時，先用「取樣行程」記錄一小段執行緒活動，不必立刻結束。

## 常見的高占用行程

- **kernel_task：** 反映 macOS 核心工作。高 CPU 可能與溫度控制有關，但不能只憑使用率判斷，見 [kernel_task 高 CPU](https://mole.fit/tw/blog/kernel-task-high-cpu-mac)
- **WindowServer：** 負責合成螢幕，負載會隨顯示器、視窗和動畫增加，見 [WindowServer 高 CPU](https://mole.fit/tw/blog/windowserver-high-cpu-mac)
- **mds、mds_stores、mdworker：** 負責 Spotlight 索引，見 [mds 與 mdworker 高 CPU](https://mole.fit/tw/blog/mds-mdworker-high-cpu-mac)
- **Google Chrome Helper：** 承載 Chrome 分頁、擴充功能和瀏覽器服務，見 [Chrome Helper 高 CPU](https://mole.fit/tw/blog/google-chrome-helper-high-cpu-mac)

## 常見的背景守護行程

- **launchd：** macOS 的第一個使用者空間行程（PID 1），管理許多系統服務，但不一定是每個服務的直接父行程。始終執行是正常行為
- **trustd：** 在應用程式啟動或建立安全連線時檢查憑證與簽名，短暫升高很常見
- **nsurlsessiond：** 處理 iCloud、應用程式下載和更新等背景網路傳輸
- **cloudd、bird：** 負責 iCloud 同步。剛登入或加入大量檔案後會較忙
- **coreaudiod：** 系統音訊引擎。持續高 CPU 可能與音訊應用程式或外掛有關
- **photoanalysisd：** 分析照片中的人物和物體，排程會受電源、溫度和圖庫變化影響
- **backupd：** Time Machine 備份行程，備份期間活躍很正常
- **syspolicyd：** 執行應用程式評估等系統安全策略，安裝或首次啟動應用程式時可能短暫升高

## 看變化模式，不看固定時長

行程在打開應用程式、接入磁碟或開始同步後升高，工作有進展並最終下降，通常不必處理。CPU 長期不退、記憶體快速成長、反覆當機，或每次同一操作都觸發異常峰值，才需要深入檢查。

強制結束前，查看行程取樣、開啟檔案和記錄。許多系統服務會自動重新啟動，因為請求它的應用程式或啟動策略還在。

第三方行程的路徑和簽名可以用來核對廠商身分。Apple 服務出現異常時，工作量通常來自某個應用程式、檔案、裝置或網路操作，直接修改系統啟動設定很少能解決源頭。

## 結束前先證明它屬於誰

活動監視器的檢查器最直觀。終端機裡從 PID 開始：

```
PID=1234
ps -p "$PID" -o pid=,ppid=,user=,etime=,comm=
lsof -p "$PID" | head
```

父行程與可執行檔路徑可用來查找輔助程式所屬的 App，開啟的檔案則有助於確認它正在處理哪個專案、圖庫、裝置或資料庫。如果路徑屬於第三方 App，可以唯讀檢查簽章：

```
codesign -dv --verbose=4 "/path/to/the/binary" 2>&1
```

熟悉名稱卻落在意外路徑或由陌生身分簽署，才值得繼續調查。陌生名稱位於簽章正常的 Apple 系統位置，不會因為名稱陌生就可疑。先退出所屬 App，再看 helper 是否安靜或自行結束，不要直接強制結束子行程。

## 為什麼背景行程會不斷變化

launchd 是 PID 1，負責註冊和按需啟動大多數服務。安全連線需要 trustd、檔案需要中繼資料匯入、應用程式送來 XPC 訊息時，對應服務才會啟動，工作結束後再回到閒置。

因此，行程列表會隨操作變化。強制結束某個服務後，下一次觸發條件出現，launchd 仍會把它重新啟動。某個名字是否存在並不重要，長期行為才是異常訊號。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/launchd-on-demand.webp" width="1360" height="454" loading="lazy" alt="launchd 位於中心，在連線、檔案或 XPC 訊息等觸發條件出現時按需啟動小型服務，工作完成後再讓它們閒置，因此執行中的集合會不斷變化">
  <figcaption>launchd 依觸發條件啟動服務，工作結束後讓它們閒置。強制結束通常只能維持到下一次觸發。</figcaption>
</figure>

## 解釋層的邊界

「活動監視器」提供權威的行程資料，[Mole](https://mole.fit/tw/) 的「狀態」頁可以補充通俗說明和趨勢。但按名稱給出的解釋只是起點，路徑、使用者、簽名和行為才能確認目前行程的身分。

## 一套可重複的行程檢查

遇到異常時，記錄名稱、使用者、路徑、父行程、簽名、CPU 與記憶體趨勢、開啟檔案和觸發條件。問題發生時取樣，再先停止發起請求的應用程式或輸入來源。這樣更容易分清正常背景工作、卡住的廠商輔助程式和冒用名稱的行程。

---

Canonical HTML page: https://mole.fit/tw/blog/mac-processes-explained
Blog index for agents: https://mole.fit/tw/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
