Mac 上的 SubmitDiagInfo 为什么联网？

最后更新: 2026-07-31

它是什么

SubmitDiagInfo 随 macOS 一起安装，后台运行，并由 Apple 签名。可执行文件位于 /System/Library/CoreServices/SubmitDiagInfo。com.apple.SubmitDiagInfo 同时是代码签名标识和 launchd 标签。由于这个可执行文件没有绑定 Info.plist，严格来说，不宜把该标识直接称为 App 的 bundle ID。

它处理的是符合提交条件、但还没有发出的诊断信息，包括崩溃报告、系统事件和使用情况分析。发送只是工作的一部分。SubmitDiagInfo 还会查看有没有待处理报告，把暂时发不出去的内容留在队列中，并清理生成已超过一个月、以后也不再需要的诊断信息。

所以，在“活动监视器”里看到 SubmitDiagInfo，并不能据此判断 Mac 正在上传数据。它可能只是在检查队列，也可能正在整理和删除本地旧报告。要确认有没有产生网络流量，不能只看进程是否存在。

它为什么要联网

打开“共享 Mac 分析”后，如果又有符合条件的报告等待发送，SubmitDiagInfo 会连接 Apple 的诊断与分析接收服务。自动发送以用户同意为前提；不能因为进程启动了，就反过来推断共享已经开启。

Apple 明确列出的自动发送触发事件包括：App 意外退出、用户强制退出 App，以及导致 Mac 重启或要求重启的系统错误。除此之外，用户同意共享范围内的其他系统事件和使用情况数据也可能进入待发报告。

报告产生后不一定立刻送出。Mac 处于离线状态时，报告会先保留；网络恢复后，SubmitDiagInfo 才可能继续发送。因此，一段时间没有联网之后出现短时流量，也可能只是此前积累的报告集中提交。用户主动选择报告问题时，相关分析信息也可能随这次操作发出，这与后台自动共享并不是同一项决定。

“与 App 开发者共享”是另一个开关。开启后，Apple 可能把相关分析数据中无法用于个人识别的部分提供给开发者。目前没有证据表明 SubmitDiagInfo 会绕过 Apple，直接连接第三方服务器。

它在当前运行环境中究竟会使用哪些主机，没有得到可靠验证。虽然可以从可执行文件里找到若干 Apple 提交地址字符串，但静态字符串只能说明代码里存在这些文本，不能证明当前提交一定连接其中某个地址。因此，不能据此给页面补上一份具体域名清单。

正常流量应该是多少

SubmitDiagInfo 的正常流量可能是零，也可能是在某个事件发生后短时间集中上传一批报告。没有同意共享时，不会自动发送分析信息；即使已经同意，只要当前没有待发报告，流量同样可以是零。

Apple 没有公布可信的典型字节数，也没有给出可当作判断标准的流量上限。因此，无法负责任地写出“每次通常几 MB”或“超过多少就异常”这样的数字。实际大小取决于积累了多少份报告，以及每份报告包含哪些内容。

从已核实的用途来看，它更接近偶尔发送日志，而不是持续传输音视频或同步云盘文件。App 崩溃、被强制退出、系统错误、断网后重新连接，或者用户主动报告问题，都可能让流量集中出现在某一小段时间内。但这些事件只能解释可能的时机，不能单独证明某次上传已经发生。

周期运行也不等于持续联网。是否真正传输，还要同时看共享设置、有没有符合条件的待发报告，以及当时能否访问网络。仅凭进程隔一段时间出现一次，无法推导出固定的上传周期。

能不能关掉

可以选择关闭分析共享。这里能关的是“自动向 Apple 共享分析”，不是建议结束、删除或封锁 SubmitDiagInfo。

具体路径是：苹果菜单 > 系统设置 > 隐私与安全性 > 分析与改进 > 关闭“共享 Mac 分析”。如果也不希望 Apple 把相关分析中的非个人识别数据提供给开发者，再关闭 “与 App 开发者共享”。

关闭后，Mac 不再自动向 Apple 提供崩溃、诊断、系统事件和使用情况分析。相应地，这台 Mac 以后不会再通过自动共享，为 Apple 基于这些信息开展的质量改进提供数据。

不过，本地诊断机制并不会因此停止。即使没有选择自动发送，仍然可以在“控制台”的“Mac 分析数据”中查看诊断信息。SubmitDiagInfo 也不一定从此完全消失，因为清理过期报告仍是它的本地职责。以后如果用户明确选择手动提交问题报告，那是一次新的主动操作，不应和已经关闭的后台自动共享混为一谈。

现代 macOS 初次启用时，这项设置是否存在统一的默认状态，目前没有得到验证。旧资料不能用来证明今天的新系统一定默认打开或关闭。实际状态还可能取决于首次设置时的选择，或设备管理策略。最可靠的做法是直接查看当前开关，而不是根据系统版本、进程是否运行或网上的旧说法猜测。

常见的误解

• “SubmitDiagInfo 是恶意软件，或者某家公司安装的遥测程序。” 这不符合已经核实的身份信息。它位于 macOS 系统目录，带有 Apple 代码签名，对应的 launchd 标签也是 com.apple.SubmitDiagInfo。这些信息都指向同一个结论：它是 Apple 的系统组件。

• “只要 SubmitDiagInfo 出现在活动监视器里，Mac 就在偷偷上传。” 进程运行和网络传输是两件事。检查报告、维护待发队列、清理一个月以前且不再需要的诊断信息，都会让它运行。自动发送分析信息还需要用户同意，不能只凭进程出现就断定发生了上传。

• “它会一直占用网络，把个人文件和浏览内容全部传走。” 没有证据支持这种说法。Apple 说明的提交内容是符合条件的崩溃信息、诊断信息、系统事件、使用情况，以及软硬件规格信息，不是任意用户文件。另一方面，也不能把这理解为报告完全不涉及隐私：诊断内容仍可能带有设备和软件环境的元数据。准确的说法应当同时保留这两个边界。

• “关闭共享后，macOS 就不会再生成诊断报告。” 这也不正确。关闭的是自动发送，不是本地诊断。Apple 明确说明，没有选择自动发送时，诊断信息仍可在“控制台”的“Mac 分析数据”中看到。

• “删除 SubmitDiagInfo，或者长期用防火墙封锁它，可以优化 Mac。” 这种建议忽略了系统已经提供正式开关。没有同意共享时，分析信息不会自动发送；如果不想参与，直接关闭“共享 Mac 分析”即可。删除或强行禁用系统���程没有必要，还可能影响它清理旧报告。

• “SubmitDiagInfo 会周期运行，所以它一定在持续联网。” 周期启动只说明系统会定期让它检查是否有工作，不能证明每次都发生传输。真正上传仍取决于用户是否同意、队列里是否有待发报告，以及网络是否可用。

怎么看它到底用了多少

下一步应当查看实际的逐进程流量，而不是继续根据进程名称猜测。可以在 Bytetally 中找到 SubmitDiagInfo，核对它真正产生的流量，再对照崩溃、重启、网络恢复或手动报告问题的时间。这样才能分清它只是运行过、短时发送了一批报告，还是出现了需要继续检查的流量模式。

相关进程

常见问题