com.apple.WeatherKitService 为什么在联网？

最后更新: 2026-07-31

它是什么

com.apple.WeatherKitService 是旧版 macOS 随系统提供的沙盒化 XPC 服务。日历或通知中心需要天气资料时，系统才会启动它；一段时间没有任务，它也可以自行退出。因此，偶尔看到它出现、随后又消失，符合按需服务的运行方式。

历史进程采样记录了几个调用方：CalendarAgent、Calendar 和 NotificationCenter。它们对应的用途也比较明确。旧版通知中心里的天气组件刷新时，会请它查询天气；日历遇到带有可识别地点的事件，并准备显示相关天气资料时，也可能调用它。

这里的“旧版”很重要。com.apple.WeatherKitService 不能概括今天所有 macOS 天气功能。它也不是 Apple 后来向开发者开放的现代 WeatherKit 服务。当前天气 App、现代 WeatherKit 框架和第三方天气 App 可能使用其他组件与服务标识，不能因为名字里都有 WeatherKit，就把它们的网络活动全部记到这个进程名下。

有些 macOS 系统已经不再包含这个标识，改用名称不同的天气相关组件。若系统里找不到 com.apple.WeatherKitService，不代表某个隐藏开关关闭了它，只能说明当前系统没有这个旧组件。

它为什么要联网

目前核实过的触发场景有两类。第一类来自旧版通知中心天气组件：组件更新天气内容时，com.apple.WeatherKitService 会发起查询。第二类来自日历：事件中写了系统能够识别的地点，而且界面需要显示天气资料时，日历会调用这个服务。

服务随后通过 HTTPS API 向天气数据提供方取得结构化天气资料。不过，Apple 没有公开这项私有服务使用的完整端点清单，也没有承诺它会长期连接某一家供应商。

旧版系统曾出现过连接 api.wunderground.com 的第三方观测。这只能证明某个旧系统在当时使用过该地址，不能证明所有系统、地区和时期都一样。供应方可能随着系统版本而变化，端点也可能调整。

因此，把它固定解释成“Yahoo 天气进程”“Weather Underground 后台”或“当前 Apple Weather 的全部流量”都不准确。现有证据只支持一个范围有限的结论：旧版日历或通知中心提出天气查询后，com.apple.WeatherKitService 会联系当时使用的天气数据提供方。至于完整域名列表、每个地区对应的供应商以及内部选择规则，Apple 没有公布，现有资料也不足以确认。

正常流量应该是多少

正常情况下，com.apple.WeatherKitService 的流量应当处于低到很低的量级。它处理的是少量、间歇性的结构化天气资料请求。与音视频播放、云盘同步或系统更新相比，这类活动通常小得多。

但这里不能给出一个可靠的 MB 数字。Apple 没有公布该进程一次查询会传输多少字节，也没有公布每天刷新多少次，更没有给出可以套用到所有 Mac 的正常流量区间。网上常见的“每次固定下载多少”“每隔多少分钟刷新一次”等说法，如果没有写清系统环境、测量时间窗和测量方法，就缺少可复现依据。

所以，判断它是否正常，只能先把握定性范围：请求通常少、持续时间短、出现时间不固定。不能把一个未经验证的固定数字当成标准线，也不能因为某次记录略高于别人提供的数字，就直接认定系统异常。

反过来，持续不断的大流量也不应被当成 com.apple.WeatherKitService 的正常特征。遇到这种记录时，需要查看这台 Mac 实际归到该进程名下的用量，而不是先假设旧版天气查询本来就会大量传输数据。现有调研没有可靠依据证明它在正常状态下会长期占用大量带宽。

能不能关掉

Apple 没有提供停用 com.apple.WeatherKitService 的系统设置开关，也就没有可填写的“系统设置路径”。这个服务适合保留原状。

在活动监视器里结束进程，只会结束当次运行。它采用按需启动方式；日历或通知中心下次需要天气资料时，系统仍可能把它重新拉起。因此，结束一次进程并不是持久停用方案，也不能视为可靠的网络优化。

强行删除服务、卸载系统组件、删除容器或长期阻断连接，可能让旧版通知中心天气组件无法刷新，也可能让日历事件中的天气资料消失。这些做法会影响功能，却不能提供受系统支持的服务级控制。若当前 macOS 已经不含这个旧组件，则无需额外处理。

天气定位权限与服务开关也不是一回事。在“隐私与安全性”中关闭 Weather 获取当前位置的权限，只会限制它读取当前位置，并不会停用 com.apple.WeatherKitService，也不能保证所有天气请求从此停止。用户保存过的地点，或者日历事件中已经写明的地点，仍可能触发不依赖当前位置的天气查询。

常见的误解

• “名字这么长，看起来像恶意软件。” 进程名长短不能说明来源。在包含它的旧版 macOS 中，com.apple.WeatherKitService 是 Apple 随系统提供的 XPC 组件，不是因为采用反向域名格式就成了第三方程序，更不能只凭名称把它判定为恶意软件。

• “它就是现代 WeatherKit 的后台服务。” 两者不能画等号。这里讨论的是旧版 macOS 中的私有 XPC 组件；面向开发者的现代 WeatherKit 属于另一套服务。当前天气 App 和其他天气软件的全部网络活动，也不能统一归到 com.apple.WeatherKitService 名下。

• “结束进程或者删掉容器，就能长期节省网络流量。” 这个结论不成立。按需 XPC 服务被结束后可以再次启动。删除容器或系统组件还可能破坏日历与旧版天气功能，而正常天气查询本身也没有被证实会消耗大量带宽。

• “关闭 Weather 的定位权限，这个服务就彻底停用了。” 定位权限控制的是当前位��访问，不是 XPC 服务的启停。保存过的城市不需要重新读取当前位置；日历事件里已有明确地点时，也可能直接查询对应天气。因此，关闭定位权限不等于阻止所有天气请求。

• “它始终连接 Yahoo、Weather Underground 或某个固定域名。” Apple 没有公布稳定的旧版端点清单。api.wunderground.com 只在旧版系统的历史观测中出现过，不能推广到所有版本和地区。供应商可能变化，固定归因给 Yahoo、Weather Underground 或当前 Apple Weather 都缺少充分依据。

• “它每次固定消耗多少 MB，而且按固定周期刷新。” 没有可靠资料支持这种精确说法。Apple 未公布字节量、刷新周期或可信的正常区间。若一个数字没有配套可复现的系统环境、时间窗和测量方法，就不能拿来判断另一台 Mac 是否正常。

怎么看它到底用了多少

如果真正关心的是这台 Mac 上的实际用量，下一步应当查看进程本身的统计，而不是套用网上未经核实的固定数字。在 Bytetally 的逐进程统计中查找完整名称 com.apple.WeatherKitService，即可看到实际归到它名下的流量。这样不必预设供应商、刷新周期或“正常 MB 数”。

相关进程

常见问题