itunesstored 是什么进程，为什么会联网？

最后更新: 2026-07-31

它是什么

itunesstored 是 iOS 和 iPadOS 自带的系统守护进程。Apple 的媒体商店和 App Store 要处理账户状态、购买、重新下载、下载队列以及应用安装，这个进程会参与其中。部分 StoreKit 购买或恢复交易也会经过它协调。

它不是单独包办所有商店工作的“大总管”。appstored、storekitd、nsurlsessiond 等进程也会参与。某项内容究竟由哪个进程处理，属于 Apple 没有公开的内部实现；不同系统发布版、不同内容类型都可能采用不同分工。因此，只能确认 itunesstored 涉及哪些类别的任务，不能把每一笔商店操作都算在它头上。

更需要注意的是平台归属：itunesstored 不是当前 macOS 的后台进程。调研在 Apple 提供的 iOS Simulator runtime 中找到了它的启动配置和可执行文件，并确认它以 mobile 用户运行；在当前 Mac 系统中，则没有找到对应的 launch service、可执行文件或 man page。macOS 上能看到一些功能相关但名称不同的服务，例如 appstoreagent、storeaccountd、storedownloadd 和 itunescloudd，不能把这些进程与 itunesstored 混为一谈。

它为什么要联网

购买或重新下载内容时，itunesstored 可能开始联网。自动下载被触发、App Store 安装或更新应用时，它也可能参与。StoreKit 发起购买、恢复交易，或者系统刷新账户与 storefront 状态，同样可能产生连接。这里既有用户刚刚发起、能直接看到的操作，也有后台进行的状态同步。

连接对象主要分成几类：Apple Media Services、iTunes Store 或 App Store 使用的账户与交易服务、Apple 推送服务，以及存放清单或内容的 Apple CDN。现有调研只能确认这些服务类别，不能据此列出固定域名，也不能假定每次操作都会连接同一组服务。

还要分清“谁协调下载”和“谁真正传输数据”。商店操作可以由 itunesstored 发起或安排，但后台传输可能交给 nsurlsessiond。这时，大量字节会记录在 nsurlsessiond 名下，而 itunesstored 自身看起来只有少量流量。反过来，只盯着 itunesstored 的数字，也无法完整还原一次应用或媒体下载。

正常流量应该是多少

目前没有可靠的 itunesstored 进程级流量统计，也没有一个可以通用套用的 MB 数字。设备空闲时，它通常只有少量可见流量，甚至完全看不到活动。购买、安装、更新或重新下载开始后，流量可能明显上升，量级也可能接近正在获取的应用或媒体内容。

不过，这不等于看到较小数字就能断定没有下载，也不等于流量上升便一定异常。内容本身大小不同，账户刷新与交易操作产生的数据也不同；更大的变量是后台传输可能由 nsurlsessiond 承载。判断一次商店活动时，需要把相关进程放在一起看，不能靠 itunesstored 的单个数值下结论。

能不能关掉

Apple 没有提供关闭 itunesstored 的受支持开关，因此也没有可以填写的“系统设置”路径。Music 或 TV 应用里的自动下载选项，只控制对应应用是否自动获取内容；它们不是关闭 itunesstored 的开关，也不是 macOS 的系统级停用办法。

在 iOS 或 iPadOS 上强行停用这个进程，可能影响 App Store 登录、购买、应用安装、应用更新、重新下载、下载队列以及 StoreKit 交易。结果不一定表现为一个清楚的错误提示，也可能只是操作超时或无法完成。当前 macOS 本来就没有这个系统进程，因此不存在需要关闭的问题。

删除 launch plist 或偏好文件也不是安全、无害的“系统优化”。Apple 不支持这种做法。它可能破坏商店服务，引发进程反复重启，或者让交易无法完成。

常见的误解

• “itunesstored 就是当前 macOS 上的 iTunes 或媒体下载进程。” 这个判断不准确。调研在 iOS Simulator runtime 中确认了它，却没有在当前 macOS 中找到对应的启动服务、可执行文件或 man page。如果 Mac 上的日志出现这个名字，来源可能是 Simulator、连接设备的日志，或者采集工具把进程归错了类。

• “它主要负责批量下载，限速不会影响别的功能。” itunesstored 还会协调账户、购买、下载队列、应用安装以及部分 StoreKit 流程。限速可能让商店操作变慢、超时或失败。与此同时，真正占用大量带宽的传输可能落在 nsurlsessiond 名下，只限制 itunesstored 未必能限制实际下载。

• “App Store 的所有 receipt checks 都由 itunesstored 完成。” 没有可靠依据支持这个说法。Apple 的 StoreKit 文档说明，收据或交易可以由应用在设备端验证，也可以交给开发者服务器或 StoreKit 的验证机制处理；文档没有把通用收据验证归给这个私有守护进程。不能因为它参与部分交易流程，就把所有验证工作都推定为它负责。

• “看到 itunesstored 就说明设备中了恶意软件。” 在 iOS 和 iPadOS 上，它是 Apple 随系统提供的组件，名称本身不能作为感染证据。但如果 Mac 上真的出现了同名可执行文件，应先检查实际路径与代码签名。仅凭进程名，无法排除 Simulator、设备日志或错误归类等情况。

• “删掉它的启动文件或偏好设置，可以无害地优化系统。” 这不是 Apple 支持的维护方式，也没有依据表明它能安全改善性能。这样做可能损坏商店功能，造成反复重启，或让购买与交易失败。

怎么看它到底用了多少

如果 Mac 的流量记录里出现 itunesstored，下一步先核对可执行文件路径和代码签名，排除 Simulator、连接设备日志或错误归类。然后用 Bytetally 的逐进程统计对照 itunesstored、nsurlsessiond 以及相关商店进程的流量。后台下载可能把实际字节记到另一个进程名下，因此应把这些记录当作归因线索一起判断。

相关进程

常见问题