Mac 上的 swcd 是什么，为什么会联网？

最后更新: 2026-07-31

它是什么

swcd 是 macOS 自带的系统进程，按用户分别运行。平时不需要常驻；系统需要它时，launchd 会把它启动起来。因此，即使手动结束了进程，之后再次看到它也很正常。系统可执行文件位于 /usr/libexec/swcd，Apple 平台签名中的标识是 com.apple.swcd。

它管理的是“关联域”，也就是 Associated Domains。带有相应 entitlement 的 App 可以声明自己与哪些网站有关联。swcd 随后获取并验证这些网站提供的 Apple App Site Association 文件，通常简称 AASA，再把验证结果维护在关联域数据库中。

这层关联会被多个系统功能使用。点击符合规则的 Universal Link 时，系统可以把链接交给对应 App，而不是只在浏览器里打开。App 与网站之间的共享凭据、App 内 Password AutoFill 的资格判断，以及一部分从网页转到原生 App 的 Handoff，也依赖同一套关联机制。

这里容易混淆的一点是：swcd 参与确认“哪个 App 可以和哪个网站建立关系”，但它不是保存密码的密码库。看到它与密码自动填充有关，不等于密码由它存放，也不等于它会把密码发给网站。

它为什么要联网

最常见的触发时机是安装 App。只要这个 App 带有 Associated Domains entitlement，系统就需要取得相应网站的 AASA 文件，确认 App 声明的关系是否成立。App 被重新注册时也可能触发同类工作。安装完成后，已保存的关联数据还会定期刷新。Apple 的文档称设备大约每周检查一次更新；不同 macOS 发布版本是否始终采用完全相同的内部调度方式，目前没有得到独立验证。

正常模式下，Mac 通常向 Apple 管理的关联域 CDN 请求 AASA 元数据。CDN 如果已有有效缓存，就直接返回；缓存缺失或过期时，再由 Apple CDN 联系网站源站。网络监控里出现 CDN 请求，并不代表 swcd 正在向某个网站上传用户数据。

另外还有 developer 和 managed 两种 alternate mode。App 使用这些模式时，Mac 可以直接连接 entitlement 中写明的网站域名。因此，swcd 的连接对象并非在所有场景下都一样：常规模式主要经过 Apple CDN，特定替代模式则可能直连声明的域名。

每次点击 Universal Link，通常不会重新下载一次 AASA。验证结果会缓存，下载主要集中在 App 安装、重新注册和后续刷新时。AASA 本质上是配置类 JSON 元数据，内容包括 App 标识、服务类型和 URL 匹配规则。

正常流量应该是多少

swcd 的正常流量通常很低，甚至非常低。它不像视频播放、系统更新或云盘同步那样持续传输大量内容。更常见的形态是：平时没有明显活动，偶尔出现一小段突发请求，取回一些 AASA 配置数据后就结束。

短时间内安装了很多 App，流量可能暂时增加。某些 App 声明的关联域很多，需要检查的元数据也会随之增多。不过，这仍然只能说明请求数量可能上升，不能推出一个固定的字节额度。

Apple 没有公布 swcd 单次请求或每月流量的可靠数字。目前也没有经过核实的 MB 标准，可以用来断言“低于多少一定正常”或“高于多少一定异常”。给出一个看似精确的数值反而会误导判断。实际用量应按本机、具体时间段和当时安装或注册 App 的情况来观察。

能不能关掉

结论是保留 swcd。Apple 没有提供关闭整个服务的系统设置，因此也不存在可供操作的系统设置路径。AirDrop 与接力相关设置中的 Handoff 开关只负责关闭 Handoff，并不是 swcd 或 Associated Domains 的总开关。

强制阻断网络后，已经缓存的关联不一定马上失效，所以部分 Universal Links 可能暂时仍能正常打开 App。但新安装 App 所需的关联无法验证时，链接可能改为打开网页。网站更新了规则、App 的关联发生变化，或者旧数据需要刷新时，也可能因为无法取得新数据而继续使用不了相关功能。

影响不只在链接跳转。依赖关联域的 App 内密码建议、共享 Web 凭据和部分 Handoff 场景也可能失效。这些问题未必会弹出明确错误，表面现象往往只是链接回到网页、密码建议不再出现，或者网页无法顺利接续到 App。

反过来说，“阻断后所有 Universal Links 和所有密码自动填充都会立刻坏掉”也不准确。缓存结果可能继续有效，Safari 普通网页中的密码自动填充也不等同于 App 与网站之间的关联域验证。结束 swcd 进程同样不算永久关闭；系统再次需要这项服务时，launchd 仍可重新启动它。

常见的误解

• “swcd 是第三方软件，甚至可能是恶意进程。” 这与系统文件核验结果不符。macOS 自带的 swcd 位于 /usr/libexec/swcd，使用 Apple 平台签名，签名标识为 com.apple.swcd。仅凭名称陌生，不能把它判断成外来软件。

• “swcd 会把密码或浏览历史上传给网站。” 没有可靠依据支持这种说法。已经核实的联网职责是获取 App 与网站之间的关联元数据。AASA 文件记录 App 标识、服务类型和 URL 匹配规则，不包含用户密码。它与共享凭据功能有关，指的是它验证双方关联资格，并不表示密码内容由它上传。

• “每点一次 Universal Link，swcd 都会访问目标网站。” 实际机制不是逐次点击、逐次下载。关联结果会缓存，网络请求主要出现在 App 安装、重新注册和定期刷新阶段。常规模式下，请求通常发往 Apple 管理的 CDN，也不是每次都由 Mac 直接连接目标网站。

• “阻断 swcd 只会关闭 Universal Links。” 影响范围比链接跳转更广。Associated Domains 同时参与共享 Web 凭据、App 内 Password AutoFill 资格判断，以及部分网页到原生 App 的 Handoff。阻断更新后，这些依赖同一关联关系的功能都可能受到影响。

• “只要阻断 swcd，所有 Universal Links 和所有自动填充一定马上失效。” 这个说法又走到了另一个极端。旧关联可能还在缓存中，因此不会保证立刻全部失效。普通浏览器自动填充与 App、网站之间的关联验证也不是同一件事，不能把两者混为一谈。

• “关闭 swcd 可以明显节省流量，或者让 Mac 变快。” 目前没有可靠依据支持这个结论。正常情况下，它只会间歇获取少量元数据。阻断后能省下多少流量没有经过核实，关联功能却可能在没有明显提示的情况下停止更新或失效。

怎么看它到底用了多少

如果想知道这台 Mac 上的实际数字，下一步是按进程查看 swcd 在目标时间段内的上传量、下载量和活动时间。Bytetally 可以把它与其他系统进程的流量分开统计。再把曲线与近期 App 安装或重新注册的时间对照，比套用一个未经验证的固定 MB 阈值更有意义。

相关进程

常见问题