macOS 上的 commerce 进程

最后更新: 2026-07-31

它是什么

commerce 是 macOS 自带的后台服务，属于 Apple 私有的 CommerceKit 框架。用户登录后，launchd 会按用户启动这项服务；它不是全系统只运行一份的守护进程。在已经核实的本机系统中，它的代码签名标识和 launchd 服务标签都是 com.apple.commerce，可执行文件位于 /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Resources/commerce。

系统里的商店客户端需要访问购买账户、读取商店信息或者处理交易时，可以调用 commerce。本机二进制留下的直接证据还包括 storefront、购买交易队列、商店请求和认证等能力。这里的 storefront 可以理解为账户所对应的商店地区及其可用内容范围。

这些证据足以确认 commerce 属于 Apple 的商店与购买基础设施，但不能据此列出它的全部职责。Apple 没有发布专门介绍 commerce 的文档，也没有提供 man page；CommerceKit 本身又是私有框架。因此，不同 macOS 版本如何分配具体任务，目前没有完整的公开答案。

它为什么要联网

从本机二进制可以直接确认，commerce 能获取商店配置，处理账户和 storefront 信息，发起购买请求，检查服务器上的购买队列，并完成认证。这些工作离不开 Apple 的商店服务，所以看到它建立网络连接，与已经核实的用途并不矛盾。

可能触发联网的情况包括：在 App Store 或其他 Apple 媒体商店购买内容；执行 StoreKit 交易或恢复购买；账户发生变化；切换地区 storefront；通过旧版 StoreKit 刷新收据。这些触发条件来自它已经确认的能力以及相关 StoreKit 流程。不过，Apple 的 StoreKit 文档没有说上述每一种请求都一定交给 commerce。因此，这份清单只能说明哪些场景可能有关，不能当成完整调用表，也不能仅凭时间重合就断定某次连接的用途。

连接对象大体属于 Apple Media Services，以及 App Store 或 iTunes Store 使用的配置、认证和交易服务。本机二进制里可以核实测试环境配置地址 sandbox.itunes.apple.com。生产环境到底会访问哪些主机，目前没有经过验证的完整清单。不能为了给流量贴标签，就补写未经核实的生产域名。

正常流量应该是多少

目前没有可靠的正常区间。Apple 没有公布 commerce 的单进程流量基线，也没有公布正常请求频率、常见峰值或统一上限。因此，无法负责任地给出一个具体的 KB、MB 数字，更不能把某个固定数值写成“超过就异常”的判断线。

已经确认的职责主要涉及商店配置、账户、认证和交易元数据。按这些数据的性质推断，单次请求通常应该比完整应用安装包或影音内容小得多。但这只是根据职责作出的合理推断，不是 Apple 公布的标准，也不是对实际流量做出的保证。

短时间内会不会连续请求、恢复交易时可能出现多大峰值，以及某些 macOS 版本是否会让 commerce 直接承载较大的下载，现在都缺少可靠依据。大文件下载究竟由哪些 App Store 相关服务分工处理，也属于 Apple 没有公开的内部实现。看到流量较大，只能说明值得结合当时的操作继续观察；它本身不能证明 commerce 下载了应用包，也不能证明进程出了问题。

能不能关掉

结论是保留 commerce，不要把进程级拦截当成常规优化。这并不表示 macOS 的基本运行离不开它，而是因为 Apple 没有提供受支持的关闭方式，强行处理又可能破坏购买相关功能。

Apple 没有提供关闭 commerce 的系统设置，也就没有可填写的“系统设置路径”。强制卸载、删除可执行文件或长期阻断网络，可能导致商店认证失败、无法购买、恢复交易失败、StoreKit 状态不同步，或者旧版收据刷新无法完成。单纯结束进程也不等于永久关闭：客户端再次请求它的 Mach 服务时，launchd 可以重新将它启动。

退出“媒体与购买项目”账户会改变账户状态，但不是 commerce 的总开关。关闭 App Store 自动更新也只会停止自动更新，不会关闭购买、认证、StoreKit 交易和其他商店请求所依赖的后台服务。

常见的误解

• “commerce 是恶意软件，或者是挖矿程序。” 位于已核实系统路径、代码签名标识为 com.apple.commerce 的实例，是 Apple 随 macOS 提供的组件。这个判断只适用于路径和签名都能对上的文件。其他目录出现同名程序时，需要另行检查，不能因为名字一样就认定安全。

• “禁用 commerce 是没有副作用的系统优化。” 这项服务参与购买和商店交易相关流程，Apple 也没有提供受支持的禁用方法。强行卸载或拦截可能换来认证、购买和交易同步故障，并不是无成本的精简操作。

• “commerce 的全部流量都是应用安装包或媒体下载。” 这个说法没有得到证实。能够直接确认的内容，主要是商店配置、账户、认证、购买请求和交易处理。大文件在多个 App Store 服务之间如何分工，Apple 没有公开。

• “每次打开 App，commerce 都会联网检查许可证。” 这把多个验证路径混成了一个。收据或交易可以由 StoreKit 验证，也可以由应用本地代码处理，还可能交给开发者服务器。没有证据表明每次启动都会经过 commerce。

• “服务器端 verifyReceipt 验证由 commerce 自己完成。” 这也不准确。Apple 明确建议由开发者的安全服务器调用相关服务；现代 StoreKit 还可以验证 Apple 签名的交易。本机 commerce 在这些验证路径里具体参与到哪一步，目前没有核实清楚。

• “com.apple.commerc 是另一个正式 bundle ID。” 当前核实到的正式标识只有 com.apple.commerce。少一个字母的 com.apple.commerc 更可能是采集工具或显示界面截断后的名称，但截断究竟发生在哪一层，仍需人工复核。它可以作为搜索别名保留，不能当成已经确认的正式标识。

• “关掉 App Store 自动更新，commerce 就不会再运行。” 自动更新设置只控制自动更新。购买、认证、恢复交易、StoreKit 操作以及其他商店请求仍可能需要相关后台服务，所以这个设置不能停用 commerce。

怎么看它到底用了多少

如果要判断自己这台 Mac 上的情况，下一步应当是查看实际记录，而不是套用不存在的统一阈值。可以用 Bytetally 的逐进程统计观察 commerce 在目标时段产生了多少网络流量，再对照当时是否进行过购买、恢复交易、账户调整或其他商店操作。时间重合只能帮助缩小范围，不能单独证明某次连接具体做了什么。

相关进程

常见问题