Mac 上的 sharingd 是什么，为什么一直联网？

最后更新: 2026-07-31

它是什么

sharingd 是 macOS 自带的系统后台进程。可执行文件位于 /usr/libexec/sharingd，代码标识是 com.apple.sharingd。登录用户进入系统后，launchd 会让它保持运行。它不是后来安装的第三方共享软件，也不能因为名称陌生，就把它当成可疑程序。

本机系统元数据已经明确列出几类服务：AirDrop、Handoff 广播与扫描、共享菜单中的接收者，以及传输观察。Apple 的文档还说明，通用剪贴板建立在 Handoff 之上。因此，在 Mac 与附近设备之间复制粘贴内容时，相关活动也落在这组功能范围内。

这些证据能说明 sharingd 参与哪些已登记的服务，却不能推出一份完整的职责清单。Apple 没有公开它负责的全部工作。其他 Continuity 功能是否由它直接处理、它和别的系统组件怎样分工，目前仍未验证。正文能确认的是系统元数据明确登记的部分，不应把所有跨设备行为都笼统算到 sharingd 头上。

它为什么要联网

打开 AirDrop 接收，或者在共享菜单里寻找附近接收者时，sharingd 会参与发现周围的 Apple 设备。AirDrop 先通过低功耗蓝牙发现设备，之后再协商加密的点对点 Wi‑Fi 连接，用这条连接传输内容。Apple 的安全文档说明，标准的附近传输会使用 TLS 加密。

Handoff 也会带来通信。启用后，登录同一 Apple Account 的附近设备会交换活动通告。Apple 说明，初次配对或一部分消息可能经过 APNs；内容较大时，可以通过点对点 Wi‑Fi 传输。通用剪贴板依赖 Handoff，所以在一台设备上复制、到另一台设备上粘贴，也可能触发这类活动。

连接对象并不局限于自己的设备。使用 AirDrop 给别人发送文件时，对端就是附近另一台 Apple 设备。身份验证、配对或消息转送还可能涉及 Apple 的 iCloud 或 APNs 基础设施。因此，把 sharingd 概括成“只在自己的设备之间做本地通信”并不准确。

“绝不访问互联网”同样不符合现有资料。Apple 当前的功能文档明确说明：AirDrop 传输开始后，即使两台设备后来离开蓝牙或 Wi‑Fi 范围，传输仍可能通过互联网继续。这不代表每个 AirDrop 文件都会先上传到 Apple 云端。标准附近传输仍是设备间的点对点 Wi‑Fi；至于互联网续传采用什么中继结构，现有资料没有完整公开。

还有一处不能过度推断：一次连接到底由 sharingd、apsd 和网络栈分别承担多少，Apple 没有公布。看到某个远端地址或一段流量时，不能仅凭功能名称断定所有字节都由 sharingd 直接发送。

正常流量应该是多少

Apple 没有公布 sharingd 的可靠正常字节范围。这里不能给出一个固定的 MB 数，也没有依据设置“超过多少就是异常”的统一门槛。

实际量级取决于当时发生了什么。设备发现、状态通告和 Handoff 活动广播通常只需要传递控制信息；用户主动发送 AirDrop 文件时，流量可能接近文件本身的大小；大型 Handoff 内容也可能产生明显传输。通用剪贴板则要看复制了什么，内容越大，相关数据通常也会增加。

即便知道操作内容，也不能把文件大小和 sharingd 的统计数字机械地一一对应。系统可能把部分通信记在 apsd 或其他网络组件名下，精确归属尚未公开。反过来，某次看到 sharingd 流量较大，也不能直接得出“系统正在后台泄露文件”的结论。需要把时间、共享操作、连接对象和网络路径放在一起看。

能不能关掉

Apple 没有提供关闭 sharingd 本身的系统设置开关，也没有对应的设置路径。它的 LaunchAgent 使用了 KeepAlive；只在活动监视器里结束进程，launchd 通常还会把它重新启动。

通过非官方方式删除、阻止或禁用 sharingd，可能影响 AirDrop、Handoff、通用剪贴板、共享菜单中的附近接收者和传输观察。由于 Apple 没有公开完整职责清单，其他 Continuity 行为也可能受到影响。目前没有可靠依据证明，强行关闭它可以安全提速，或者稳定省下大量网络流量。

如果只想停用某项功能，可以调整那项功能自己的设置。AirDrop 接收可在“系统设置 > 通用 > AirDrop 与接力”中设为“不允许任何人”；部分系统把这一页显示为“AirDrop 与 Handoff”。同一页里的“允许在这台 Mac 和你的 iCloud 设备之间使用 Handoff”关闭后，Handoff 和通用剪贴板也会停用。这些都是分功能控制，不等于关闭 sharingd。

常见的误解

• “sharingd 是病毒，或者来历不明的第三方共享程序。” 这个判断不成立。本机系统元数据显示，它位于 /usr/libexec，代码标识是 com.apple.sharingd，并由 /System/Library 下的 Apple LaunchAgent 启动。名称看起来陌生，不会改变它的系统组件身份。

• “sharingd 只给 AirDrop 使用。” 这个说法漏掉了已经确认的职责。本机 LaunchAgent 还登记了 Handoff 广播与扫描、共享菜单接收者和传输观察。Apple 又明确说明通用剪贴板依赖 Handoff，所以它涉及的范围不止 AirDrop。

• “sharingd 只和我自己的附近设备点对点通信，完全不会访问互联网。” 两部分都不准确。AirDrop 可以连接其他人的附近 Apple 设备；iCloud 或 APNs 可能参与身份验证、Handoff 配对和消息转送。已经开始的 AirDrop 传输还��能在设备离开本地无线范围后通过互联网继续。

• “AirDrop 会先把每个文件上传到 Apple 云端，再转给接收者。” 现有资料没有支持这个说法。Apple 的安全文档描述的是设备间点对点 Wi‑Fi，并使用 TLS 加密。互联网续传的具体中继结构没有在已查资料中完整公开，因此既不能说所有文件都会先上云，也不能擅自补出它的传输路线。

• “结束或删除 sharingd，可以安全地让 Mac 变快，还能省很多流量。” 没有可靠证据支持这两个效果。结束进程后，它通常会被 launchd 再次拉起；强行阻止它，明确可见的后果反而是多项共享和 Continuity 功能可能失效。至于能省多少流量，Apple 没有提供可用于估算的数据。

• “sharingd 一旦出现大流量，就说明 macOS 在后台泄露文件。” 单个进程的字节数不能证明文件泄露。主动发送 AirDrop 文件或传递大型 Handoff 内容时，本来就可能出现与内容大小相当的流量。还要核对当时是否进行了共享操作、对端是谁、走了本地连接还是互联网，以及系统把各部分流量记给了哪个进程。

这些误解常把“进程参与了某项功能”扩大成“进程独自完成了全部通信”。sharingd 与 apsd、蓝牙、Wi‑Fi 组件和网络栈之间的精确分工尚未公开。没有这层边界信息时，最稳妥的做法是保留条件，不从一个进程名推出完整的数据路径。

怎么看它到底用了多少

先按时间核对 AirDrop、Handoff、通用剪贴板和共享菜单操作，再查看连接对象与网络路径，不能只盯着进程名。Bytetally 的逐进程历史可以显示系统在什么时间把多少流量记给了 sharingd，但无法补全 Apple 未公开的组件分工。把统计记录和当时的实际操作对上后，再判断是否需要继续排查。

相关进程

常见问题