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

最后更新: 2026-07-31

它是什么

appstored 是 macOS 为 App Store 提供的系统守护进程。它由 launchd 启动，运行时使用专门的 _appstore 账户。Apple 给它分配的标识符是 com.apple.appstored，系统程序位于 /System/Library/PrivateFrameworks/AppStoreDaemon.framework/Support/appstored。

它不负责显示 App Store 窗口，也不是用户平时点击和浏览的那个 App。它待在系统后台，协调应用商店相关工作，包括发现可用更新、安装应用、恢复应用以及重新下载已经获取过的应用。因此，即使眼前没有打开 App Store 窗口，只看到这个进程也不能说明它来历异常。

需要注意的是，App Store 后台并不只有 appstored。Apple 还使用 appstoreagent、storedownloadd、storeassetd 等相关进程。它们之间究竟怎样分工，Apple 没有公开完整说明。比较稳妥的说法是：appstored 支持并协调 App Store 操作。不能仅凭进程名，就断言每一次下载、验证或网络请求都由它独立完成。

它为什么要联网

检查应用有没有新版本，会触发 App Store 后台联网。下载或安装更新、购买应用、重新下载应用，也会带来网络活动。如果用户在另一台设备上购买了应用，而这台 Mac 开启了相应的自动下载选项，后台同样可能开始获取应用。某些应用还会按需下载可选内容，这也是可能的触发条件。

连接对象大致分为几类。查询更新、处理账户或购买操作时，App Store 子系统需要访问 Apple 的元数据和账户服务。应用及相关资源可能来自 *.apps.apple.com、*.itunes.apple.com 和 *.mzstatic.com 下的内容主机。附加内容也可能通过第三方 CDN 提供。如果当前网络里部署了 macOS 内容缓存，所需内容还可能由本地缓存提供。

这些域名和服务类别描述的是整个 App Store 子系统可能接触的对象，并不是 appstored 专属的端点表。Apple 没有公布一份完整清单，说明哪个进程负责哪条连接、哪个载荷一定属于谁。因此，看到 appstored 活跃，可以确认它与 App Store 工作有关；但要把某条具体连接完全归到它名下，还缺少公开依据。

正常流量应该是多少

没有一个可靠的固定数字可以回答这个问题。Apple 没有公布 appstored 单进程每小时或每天应当使用多少流量，也没有给出可以套用到所有 Mac 的正常区间。给它写一个具体的 MB 标准，看起来直观，实际上没有依据。

如果系统只是在检查应用更新，通常只会间歇传输元数据。与下载一整个应用相比，这部分流量应该较小。但只要进入安装、更新、恢复、重新下载或附加内容下载阶段，情况就不同了。此时用了多少数据，主要取决于用户请求的应用或资源有多大。下载期间，相关流量完全可能暂时成为这台 Mac 网络用量中的主要部分。

判断时应当先看当时发生了什么。如果刚好在安装或更新应用，出现明显增长有正常解释。如果没有任何已知操作，也可以继续调查，但不能只根据字节数下结论。流量高低既不能直接说明具体任务，也不能证明每条连接都由 appstored 自己发起。

能不能关掉

结论是：Apple 没有提供关闭 appstored 本身的系统设置开关。没有可填写的“系统设置路径”，也不应该为了关掉它去删除启动配置、反复结束进程或拦截整个 App Store 服务。这样做可能让应用安装、更新、恢复、重新下载以及相关验证停住或失败。launchd 也可以在系统再次需要它时重新启动进程，所以反复杀掉它并不能可靠地控制流量。

如果只是希望减少后台自动更新，可以使用范围更小的官方选项：打开 App Store，进入 App Store > 设置 > 自动更新。关闭后，App Store 应用需要手动更新。这个选项不会停用 appstored，也不会阻止手动安装、手动更新、重新下载，或其他仍然开启的下载功能产生流量。

当后台正在传输较大的内容，而当前网络需要优先处理别的任务时，可以考虑降低这类后台传输的优先级。这个结论只适用于对大体量后台下载进行适度限速，不代表可以封锁 App Store 服务主机或强行停用守护进程。如果安装或更新是用户刚刚主动发起的，限速会直接延长等待时间，应该明确说明这个后果。

常见的误解

1. “没有打开 App Store，appstored 却在运行，所以它是恶意程序。” 不能这样判断。位于 Apple 系统保护路径、标识符为 com.apple.appstored 的 appstored 是 Apple 的系统守护进程。它本来就在后台工作，不需要显示窗口。如果在其他目录发现一个同名可执行文件，那是另一个问题，应当根据它自己的路径和身份单独调查。

2. “appstored 只负责检查更新，所以它传输的每一个字节都是自动更新。” App Store 子系统处理的事情不止自动更新。手动安装、购买、重新下载、从另一台设备的购买记录自动下载，以及获取可选内容，都可能产生网络活动。具体由 appstored 还是其他相关进程承担某条连接，Apple 没有完整公开。

3. “所有 macOS 系统更新都由 appstored 负责。” Apple 对它的定位是 App Store 支持守护进程，并没有把它描述为 macOS 软件更新的唯一引擎。看到它与应用商店更新有关，不能进一步推断整个操作系统的每一次更新都归它处理。

4. “关闭自动更新，就等于彻底关闭 appstored。” 自动更新开关只控制 App Store 应用是否自动更新。关闭后，守护进程依然存在，也仍然可以为手动安装、手动更新、恢复、重新下载和其他 App Store 操作提供支持。

5. “删掉它的 launchd 配置，或者不断结束进程，是一种没有副作用的系统优化。” 这不是 Apple 支持的控制方式。干预后，正常的安装、更新或验证可能受损；系统需要相关服务时，launchd 还可能再次启动它。既不能保证省下流量，也不能保证 App Store 继续正常工作。

6. “appstored 流量很高，说明它一定在上传遥测数据。” 应用下载、更新和附加内容下载本身就可能产生大流量，这是正常解释。仅凭进程名和总字节数，无法判断某条连接传输了什么。要把一次传输��性为遥测，必须拿到那条连接本身的证据。

怎么看它到底用了多少

下一步是按具体时间段查看 appstored 的实际用量，再对照当时是否发生过安装、更新或重新下载。Bytetally 的逐进程统计可以显示这个时间段内归到 appstored 的流量。统计结果能回答“用了多少”，但要判断具体载荷或确认每条连接的归属，仍然需要连接层面的证据。

相关进程

常见问题