我刚好深入研究过这个库的源码，来给你逐个拆解问题：

1. Reachability类的底层工作机制 #

Reachability.swift本质是对苹果系统原生网络可达性API的Swift封装，底层依赖两种核心系统组件：

• iOS 12及以下：基于SCNetworkReachability（Core Foundation框架下的C语言API），它会监听设备的网络接口状态变化（比如WiFi开关、蜂窝网络切换），通过注册回调的方式在状态改变时通知上层。
• iOS 12+ / macOS 10.14+：自动切换到NWPathMonitor（Network框架），这是苹果推出的更现代、更精准的网络状态监测API，不仅能检测网络是否可用，还能区分网络类型（WiFi/蜂窝/有线）、是否受限于低数据模式等。

这个库做的主要工作就是把底层C/Objective-C风格的API封装成更符合Swift习惯的面向对象接口，处理回调的线程切换、状态转换（比如把系统返回的枚举转成库自己的Connection类型），还有提供便捷的监听方法（比如startNotifier()）。

2. 获取网络更新的实现方式 #

答案是依赖操作系统的原生状态更新，而非定期ping网站：

• 默认情况下，库只是监听设备的网络接口状态，当系统检测到网络连接/断开、类型切换时，会主动触发回调通知Reachability，再由Reachability把事件传递给你的代码。
• 如果你创建了针对特定主机的Reachability实例（比如try! Reachability(hostname: "example.com")），它会检测该主机是否可达，但这也不是主动ping，而是通过系统的路由表和网络栈判断是否能建立连接，本质还是依赖系统的网络状态检测，不会发起实际的HTTP/ICMP请求。

简单说：它是被动接收系统通知，不是主动轮询，这也是它高效的核心原因。

3. 电量消耗问题 #

在默认使用方式下，电量消耗可以忽略不计：

• 因为它只是注册了系统的网络状态监听，系统本身就会持续监控网络变化，这个库并没有额外的后台任务或轮询操作。
• 对比定期ping的方案（比如每隔30秒发一次请求），Reachability.swift完全不会产生额外的网络流量，也不会唤醒CPU做无用功，所以对电池续航几乎没有影响。

唯一需要注意的是：如果你自己额外添加了频繁的主动状态检查（比如在定时器里反复调用connection.description），那可能会有微小的消耗，但这属于不当使用，不是库本身的问题。

内容的提问来源于stack exchange，提问作者surToTheW