这次我们来看一个叫AIRPLANE MODE（飞行模式）的工程主题。标题副句是“我将独自飞行，无人理会”，放到开发场景里其实非常贴切：很多服务要在完全断网、不依赖公网 API 的环境里独立跑起来，没有外部依赖，没人帮你排查，只能靠本机日志和一套可靠的离线部署流程。这篇文章不做文艺解读，直接把飞行模式拆成工程问题来写：系统层面怎么用命令开关飞行模式，离线环境下怎么做本地部署，本地 AI 模型怎么在断网状态下独立推理，以及如何把这类场景接入自动化测试和批量设备管理。
核心看点可以提前列出来：飞行模式不只是手机上的一个按钮，它背后是射频、基带、无线网卡、蓝牙和 GPS 的联动关闭；Windows、Linux、Android 都提供了可脚本化控制的方式；在航空、工业、内网开发等场景里，主动进入“飞行模式”是保证数据安全和系统稳定性的常见手段。文章会演示一套可落地的离线部署验证流程，包含系统命令、依赖缓存、模型文件组织、离线推理和自动化开关脚本。适合做端侧开发、嵌入式运维、内网部署，以及想在无网条件下跑本地 AI 的读者收藏。
1. 核心能力速览
先把飞行模式相关的核心工程能力整理成表格，方便快速判断哪些内容对你的项目有用。
| 能力项 | 说明 |
|---|---|
| 技术本质 | 统一关闭蜂窝网络、Wi-Fi、蓝牙、GPS 等无线射频模块，保留核心计算能力 |
| 系统支持 | Android、iOS、Windows、Linux、macOS 均有对应实现或脚本控制接口 |
| 可脚本化 | Android 可通过 adb 命令控制，Linux 可通过 rfkill/nmcli 控制，Windows 可通过 PowerShell 或网络适配器管理 |
| 离线部署 | 通过 Docker 离线镜像、pip/npm 离线包、本地模型权重实现无网部署 |
| 本地推理 | 可在 CPU/GPU 上运行本地开源模型，不依赖公网 API |
| 适合场景 | 航空环境、保密内网、工业现场、无信号区域、稳定复现测试 |
| 使用边界 | 需要遵守航空法规、设备厂商规范；涉及模型和素材时需确认授权 |
从技术角度看，飞行模式的核心不是“断网”这一个动作，而是把设备上所有可能收发信号的组件一次性隔离。对于开发者和运维人员，飞行模式的价值不只是省电，更是可控地创建一个不受外部干扰的运行环境。这比单纯拔网线更彻底，也比手动关掉每个无线服务更可靠。
2. 适用场景与使用边界
飞行模式听起来是个很基础的功能，但真正需要主动进入飞行模式的工程场景比想象中多。
第一类是航空与运输场景。飞机起飞和降落阶段，民航法规普遍要求关闭或隔离无线发射设备。对个人设备来说，飞行模式是合规要求；对嵌入式设备来说，需要软件层面实现“静默模式”，确保设备不会在网络切换、基站扫描等行为上消耗电力或对航空通信造成干扰。
第二类是保密与内网环境。很多企业研发环境不允许设备连接公网，也不允许随意开启 Wi-Fi 和蓝牙。通过系统策略强制进入类似飞行模式的状态，能减少数据外泄通道。配合离线安装包和本地模型服务，开发人员可以在完全隔离的网络里完成训练、推理和应用联调。
第三类是无人值守和野外设备。在偏远地区、海洋、矿区等没有稳定信号的环境中，设备反复搜索网络的功耗非常高。提前进入飞行模式或长期保持离线运行，能让设备把算力集中在业务处理上，同时避免网络模块异常唤醒导致的稳定性问题。
使用边界必须明确：飞行模式涉及无线射频的开关，在航空器上操作要严格遵守航空公司和民航部门的规定，不要在任何明令禁止的信号环境下尝试强行开启无线模块。在工业或医疗设备上做射频关闭实验前，需要确认设备不会影响所在场景的通信安全。离线部署模型时，要检查模型权重和训练数据的许可协议，版权不清的数据集不要进入生产流程。
3. 操作系统层面的飞行模式控制命令
很多开发任务需要程序化控制飞行模式，而不是手动点按钮。这里按平台给出通用控制方法，实际命令在不同系统版本上可能略有差异。
3.1 Android 设备：adb 命令控制
Android 的飞行模式状态存储在系统设置中，通过 adb 可以快速切换。这是做设备批量测试时最常用的方式。
# 开启飞行模式 adb shell settings put global airplane_mode_on 1 adb shell am broadcast -a android.intent.action.AIRPLANE_MODE --ez state true # 关闭飞行模式 adb shell settings put global airplane_mode_on 0 adb shell am broadcast -a android.intent.action.AIRPLANE_MODE --ez state false # 查询当前状态 adb shell settings get global airplane_mode_on还需要注意，部分 Android 设备在开启飞行模式后会自动关闭 Wi-Fi 和蓝牙。如果自动化测试中需要“飞行模式 + Wi-Fi 开启”的组合，可以通过系统接口单独恢复 Wi-Fi：
adb shell svc wifi enable adb shell svc bluetooth enable3.2 Linux 设备：rfkill 与 nmcli
Linux 上控制无线射频的通用工具是rfkill，它可以列出所有射频设备并统一关闭。
# 查看当前射频设备状态 rfkill list # 关闭所有无线设备 sudo rfkill block all # 打开所有无线设备 sudo rfkill unblock all # 只关闭 WiFi sudo rfkill block wifi # 只关闭蓝牙 sudo rfkill block bluetooth如果设备使用 NetworkManager 管理网络，也可以直接操作网络连接：
# 关闭 WiFi nmcli radio wifi off # 开启 WiFi nmcli radio wifi on # 查看无线状态 nmcli radio3.3 Windows 设备：PowerShell 禁用网络适配器
Windows 中没有飞行模式的统一命令行接口，但可以禁用所有物理和虚拟网络适配器来达到等效目的，需要以管理员身份运行 PowerShell。
# 禁用所有有线、无线和虚拟网卡 Get-NetAdapter | Where-Object { $_.Status -eq "Up" } | Disable-NetAdapter -Confirm:$false # 重新启用全部网卡 Get-NetAdapter | Enable-NetAdapter -Confirm:$false # 查看网络适配器状态 Get-NetAdapter这里要注意，禁用虚拟网卡可能会影响虚拟机、容器和远程桌面的连接，执行前要确认当前会话不会因为断网而失去远程控制能力。更稳妥的做法是只禁用无线网卡和蓝牙，保留有线管理的优先级。
4. 离线环境下的本地部署环境准备
进入飞行模式的最终目的是在无网环境下跑服务。这里常见的卡点不是应用代码，而是依赖安装。没有外网，pip install、npm install、apt install都会失败，所以需要提前准备离线依赖。
4.1 Python 依赖离线包准备
在一台有网的机器上，用pip download把所有依赖打包到本地目录，然后拷入内网机器安装。
# 在有网环境下载依赖到本地目录 pip download -r requirements.txt -d ./offline_packages/ --platform manylinux2014_x86_64 --only-binary=:all: # 内网环境下离线安装 pip install --no-index --find-links=./offline_packages/ -r requirements.txt如果没有办法锁定二进制平台，可以直接打包整个 Python 虚拟环境，但要注意虚拟环境中可能存在绝对路径，迁移后需要做路径修正。
4.2 Node.js 依赖离线准备
使用npm cache可以提前缓存所有包，然后离线安装。
# 有网环境准备 npm 缓存 npm install --cache ./npm_cache --registry https://registry.npmjs.org/ # 离线环境使用缓存安装 npm install --cache ./npm_cache --offline也可以直接把node_modules目录完整拷贝到目标机器，但这种方式不够干净，跨平台时容易出现二进制兼容问题。
4.3 Docker 离线镜像迁移
Docker 离线部署是最常见的方案。在有网机器上拉取镜像并保存为文件，再到目标机器导入。
# 有网环境导出镜像 docker save -o myapp-image.tar myapp:latest # 离线环境导入镜像 docker load -i myapp-image.tar # 查看导入结果 docker images如果需要批量部署到多台设备，建议把镜像文件和安装脚本放在同一个目录，配合docker-compose.yml统一管理服务和端口映射。离线环境下docker pull无法使用，所有基础镜像都要提前准备好。
4.4 模型文件与语言模型权重管理
离线跑 AI 模型时，模型权重要提前下载。无论是 Hugging Face 上的开源模型、Ollama 镜像，还是本地训练好的权重文件，都要按日期和版本单独管理。建议目录结构如下：
models/ llm/ qwen2-7b-instruct/ llama3-8b/ ... embedding/ bge-m3/ vision/ clip-vit-base/ test_assets/ images/ audio/模型文件通常很大，传输时建议先计算 SHA256 校验值，避免文件损坏导致加载失败。
5. 本地 AI 模型离线推理：飞行模式下的独立运行
离线场景里最有价值的一件事，是让本地模型在完全无网状态下独立完成推理。这一步不需要公网 API，也不需要外部鉴权服务，启动后整个推理链路就是独立的。
5.1 通用部署思路
本地推理工具的选择取决于硬件和模型格式。常见的做法是使用 llama.cpp 或 Ollama 加载 GGUF 格式模型。以 Ollama 为例，在有网环境预先下载并导出模型，再迁移到离线机器：
# 有网环境拉取模型 ollama pull qwen2.5:7b # 查看本地模型列表 ollama list离线机器上安装 Ollama 后，模型文件会放在本地模型目录。启动服务时保持OLLAMA_HOST=127.0.0.1，避免服务暴露到外部网络：
export OLLAMA_HOST=127.0.0.1 ollama serve如果设备完全处于飞行模式，本地模型服务依然可以正常工作。输入输出不走公网，延迟取决于 CPU 或 GPU 性能。显存占用需要以实际模型版本和推理参数为准，不同量化等级、不同上下文长度会带来明显差异。
5.2 CPU 与 GPU 推理观察方法
在飞行模式下做推理测试，可以重点观察三个指标：
- 首次回复延迟：从提交请求到生成第一个 token 的时间。
- 稳定生成速度：连续多轮请求的平均 token 吞吐。
- 资源占用：CPU 使用率、内存占用、GPU 显存占用。
可以使用nvidia-smi观察 GPU 状态，使用top或htop观察 CPU 和内存。如果显存不足，常见方案是换更小尺寸的模型、降低上下文长度、使用量化版本，或把部分层卸载到 CPU 计算。具体优化空间要以本机测试为准。
5.3 离线推理验证流程
一个最小验证流程可以按下面步骤执行：
- 确认设备已进入飞行模式，断开 Wi-Fi、蓝牙、蜂窝网络。
- 启动本地模型服务。
- 发送一条简单请求，确认模型能正常返回。
- 检查系统日志中是否存在外部网络请求的报错。
- 多次发送请求，观察服务稳定性和资源占用。
- 将输出结果保存到指定目录，检查文件完整性和格式。
判断成功的标准很简单：整个过程没有任何外网请求，模型能持续生成结果，资源占用没有持续异常增长。
6. 接口调用与批量任务自动化
飞行模式不意味着停止自动化。相反，很多自动化测试场景需要反复切换飞行模式，验证应用在断网重连时的表现。
6.1 本地服务的接口调用
如果离线环境中启动了本地模型服务，可以使用 HTTP 接口调用，例如基于 OpenAI 兼容接口的常见调用方式：
import requests # 默认本地地址，端口以实际服务为准 url = "http://127.0.0.1:11434/api/generate" payload = { "model": "qwen2.5:7b", "prompt": "请用一句话解释什么是飞行模式", "stream": False } response = requests.post(url, json=payload, timeout=120) print(response.json())接口地址、模型名称和端口不能想当然，要以你安装的工具版本和配置文件为准。在验证接口时，先查看服务启动日志，确认监听地址和端口是否正常。
6.2 批量设备飞行模式切换脚本
当手里有多台 Android 设备，需要统一进入飞行模式做离线测试时，可以写一个简单的批量脚本。以下是一个 Python 示例，通过 adb 依次操作多台设备：
import subprocess devices = ["emulator-5554", "emulator-5556", "device123"] def set_airplane_mode(device_id, state): value = "1" if state else "0" subprocess.run(["adb", "-s", device_id, "shell", "settings", "put", "global", "airplane_mode_on", value], check=True) subprocess.run([ "adb", "-s", device_id, "shell", "am", "broadcast", "-a", "android.intent.action.AIRPLANE_MODE", "--ez", "state", "true" if state else "false" ], check=True) print(f"{device_id} airplane_mode={state}") # 批量开启飞行模式 for device in devices: try: set_airplane_mode(device, True) except subprocess.CalledProcessError as e: print(f"{device} failed: {e}")批量任务必须有日志和失败重试机制。建议把每次操作结果写入文件，方便后续排查是哪台设备执行失败。如果批量任务中途卡住，先检查 adb 连接是否断开，再检查设备是否进入了异常休眠状态。
6.3 断网重连稳定性测试
飞行模式非常适合做应用断网重连的稳定性测试。测试思路是：应用正常运行时，强行开启飞行模式，观察应用是否出现崩溃或连接池耗尽；等待一段时间后关闭飞行模式，观察应用能否自动恢复网络连接。
这种测试可以写成定时任务，循环执行多次。测试结果应记录网络断开时刻、恢复时刻、应用恢复耗时、有无异常日志。稳定的应用应当在网络恢复后自动重连，而不是要求用户手动重启。
7. 资源占用与性能观察
飞行模式对系统资源的影响，主要体现在网络模块的功耗和行为差异，而不是 CPU 算力本身的变化。
7.1 如何观察资源占用
在 Android 设备上，可以通过adb shell dumpsys查看系统服务状态和电量统计。在 Linux 设备上，使用powerstat、powertop或top观察功耗和进程状态。Windows 上可以使用性能监视器或Get-Counter命令。
# Windows 查看关键性能计数器 Get-Counter "\Processor(_Total)\% Processor Time", "\Memory\Available MBytes"飞行模式开启后，最容易观察到的变化是无线模块的唤醒减少。对于依赖定时轮询网络的应用，断网后它会反复触发超时重试，CPU 占用反而可能升高。这不是飞行模式的问题，而是应用没有做好离线状态处理。
7.2 影响资源占用的因素
- 网络重试机制：断网后应用反复重试连接，会增加 CPU 和电量消耗。
- 日志输出量：离线模式下错误日志可能成倍增加，需要关注磁盘写入量。
- 缓存任务堆积：未发送的业务数据不断写入缓存，会增加内存和磁盘压力。
- 本地模型推理：模型大小、上下文长度、并发请求数直接影响显存和内存占用。
降低资源的常见手段包括：为应用增加离线模式判断，网络不可用时直接进入降级逻辑，避免高频重试；限制日志输出；定期清理堆积的待发送数据。更稳妥的方式是在代码里监听网络状态变化事件，网络恢复后再触发同步。
8. 常见问题与排查方法
离线部署和飞行模式控制过程中，有很多问题是固定套路，列成一个排查表会非常方便。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 开启飞行模式后 Wi-Fi 被强制关闭 | 系统默认行为，部分厂商定制 ROM 的策略 | 查看系统设置中的 Wi-Fi 开关状态 | 使用 svc wifi enable 重新打开，或改为只关闭蜂窝网络 |
| 关闭飞行模式后网络无法自动恢复 | 网络优先级配置异常或数据连接未重新建立 | 检查当前网络状态和 APN 配置 | 重启数据连接或恢复默认网络设置 |
| 本地模型服务启动慢 | 模型加载需要读取大量文件，磁盘是瓶颈 | 观察磁盘 I/O 和服务启动日志 | 更换 SSD、预加载模型到内存 |
| 调用本地接口返回超时 | 模型仍在加载或请求参数过大 | 检查服务日志和资源占用 | 增大超时时间，或先发送短文本测试 |
| 离线导入 Docker 镜像失败 | 镜像文件损坏或磁盘空间不足 | 使用 docker load 查看具体报错，检查磁盘空间 | 重新导出镜像，清理磁盘 |
| pip 离线安装找不到依赖 | 下载的依赖包不完整或平台不匹配 | 查看 pip 报错，确认包文件是否齐全 | 使用相同 Python 版本和平台重新下载 |
| adb 批量执行脚本卡住 | 设备休眠、连接断开或 adb 服务异常 | 执行 adb devices 查看设备状态 | 重新连接设备，重启 adb 服务 |
| 断网后应用反复卡死 | 应用未处理离线异常，网络请求长时间阻塞 | 查看应用日志和 ANR 日志 | 为网络请求增加超时和离线降级逻辑 |
这些问题里，最容易被忽略的是“关闭飞行模式后网络不恢复”。很多设备在恢复网络时不会自动重连到已保存的 Wi-Fi，尤其是企业级加密网络。遇到这种情况，优先手动确认 Wi-Fi 开关和数据连接状态，再去检查网络配置。
9. 最佳实践与合规建议
飞行模式不是简单的“断网开关”，把它用好需要沉淀一套工程规范。
第一，第一次进入离线环境前，先做小范围验证。不要直接在关键生产服务上关闭所有网络端口。先在测试机跑通依赖安装、模型加载、接口调用，再复制到生产环境。
第二，保留一套最小可运行配置。把 Python 依赖列表、Docker Compose 文件、模型启动命令固定下来，记录在项目 README 中。这样下次换机器时不需要重新摸索。
第三，模型文件、输入素材、输出结果要分目录管理。离线环境下的文件流转路径往往很单一，目录混乱会导致后续维护成本翻倍。建议使用固定的input/、output/、models/目录结构。
第四，批量任务必须加日志和失败重试。无论是批量切换飞行模式，还是批量执行离线推理，都要把每一步的执行结果记录下来。特别在网络模块操作上，失败后要及时恢复状态，避免设备长时间处于不可控的半离线状态。
第五，涉及人脸、声音、版权素材时，必须确认授权。如果离线部署涉及图片生成、声音合成、OCR 文档解析，要确保训练数据和推理输入都有合法来源。对敏感数据加密存储，使用后及时清理。
第六，接口服务要限制访问范围。在本机或内网运行时，绑定127.0.0.1或内网 IP，不要直接暴露到公网。飞行模式不等于安全模式，离线服务同样需要鉴权和访问控制。
10. 总结与下一步
AIRPLANE MODE 这个主题最值得动手验证的点，不是手机上的那个开关，而是一整套“断网可运行”的工程能力。建议你先在一台 Linux 机器上跑通rfkill block all，再把本地模型服务启动起来，确认断网情况下调用正常。这个流程一旦稳定，后续做内网部署、野外测试、车载设备和保密环境开发都会省很多事。
最容易踩的坑有两个：一个是离线依赖准备不完整，导致部署到一半才发现缺包；另一个是应用没有做离线降级，断网后反复重试把系统资源耗尽。先把这两个问题处理好，离线环境下的 AI 服务才能真正做到“独自飞行，无人理会”也照样稳定运行。
下一步可以扩展的方向很多：把飞行模式切换脚本接入 CI/CD 自动化测试，在夜间跑断网重连回归；用 Docker 镜像固化整个离线推理环境，做到秒级迁移；或者在嵌入式设备上验证低功耗离线推理，把本地模型跑到更受限的硬件上。先跑通最小链路，其余功能慢慢加。
