为什么坦克几乎不用 Windows？

正文

早期刚入行那几年，我和不少同行一样，有个挺幼稚的偏见。

每次在新闻里看到某个军用装备、ATM 机或者地铁闸机弹出一个 Windows 蓝屏，大家就会在群里嘲笑一番：“这都什么时代了，怎么还在用 Windows？”“这种要命的系统，用 Windows 简直是开玩笑。”

后来我读到过一个真实的军工事故。1997 年，美国海军的“约克城号”导弹巡洋舰在海上试验时，因为一名船员在一个运行 Windows NT 4.0 的终端里输入了一个“0”，导致除以零错误（Divide-by-zero）。这个未被捕获的异常一路向上穿透，把整个数据库搞崩溃了，最终导致整艘巡洋舰的推进系统停摆，在海上漂了四个多小时。

这个例子后来被各种技术文章引用，用来证明“微软的系统不能用于严肃的军用场景”。

但我后来去查现代主战坦克的火控和战术终端资料，发现事情根本没那么简单。

比如美军 M1A2“艾布拉姆斯”主战坦克的 IVIS（车载信息系统），或者德国“豹 2”的指挥控制系统，不仅不用 Windows，甚至连 Windows Embedded（后来的 Windows IoT）都极少出现在核心控制链路里。

很多人以为坦克不用 Windows 是因为蓝屏、因为不稳定、因为不实时。

但其实，Windows 早期做过实时版本，比如 Windows CE；微软也花了很大力气做内核防护。如果纯粹从软件崩溃率来看，调优过的 Windows Embedded 并不比某些 Linux 发行版差。

真正让坦克把 Windows 排除在外的，是一个很多程序员写代码时几乎不会考虑的问题：系统状态的可预测性，以及极端硬件环境下的“断电韧性”。

我们可以试着想象一下主战坦克在战场上的真实工作环境。

坦克不是数据中心。数据中心有双路冗余电源、UPS、恒温恒湿的机房，甚至有运维人员随时待命。

而坦克里的计算机要面对什么？

发动机剧烈震动、主炮发射时的强物理冲击、电磁干扰，以及最致命的一点：不规律的瞬间断电与电压骤降。

当主炮开火的一瞬间，或者坦克掉进掩体、电源线断开时，车载计算机可能会在没有任何警告的情况下直接失去电力。

这时候，Windows 的架构设计就显露出一个致命伤：巨大的状态隐藏与复杂的后台机制。

Windows 核心的设计思路，是为“人”服务的。为了给用户提供良好的交互体验、设备即插即用（PnP）、复杂的注册表配置、系统恢复点以及延迟写入的文件系统缓存，Windows 在后台维护着庞大且密不可分的状态机。

你在 Windows 上点击关机，内核需要依次通知服务、刷新磁盘缓存、写入注册表状态、保存会话。

如果在写入注册表或者文件系统分配表（FAT/NTFS）的微秒级瞬间突然断电，会发生什么？

在普通 PC 上，大不了下次开机花几分钟走一遍磁盘检查（Chkdsk），或者弹出一个修复界面。

但在战场上，如果主炮刚打完一发炮弹，系统断电重启，车载电脑亮起来，屏幕上显示一行：

Updating your system, please do not turn off your computer...

或者直接卡在磁盘检测界面等待按 F1 继续——这种代价是整个车组的性命。

Windows 很难做到真正意义上的 Stateless（无状态）。它的内核天生就希望记录东西、保存状态。即使后来微软推出 UWF（统一写入筛选器），把系统盘强制变成只读，把写入重定向到 RAM，这种覆盖在复杂内核上的“补丁”依然无法改变 Windows 庞大的启动依赖链。

坦克需要的是什么系统？

你去翻看主流坦克的电子系统方案，会发现它们的核心火控和驱动控制大量采用 VxWorks、LynxOS，或者非常底层的 Bare-metal（裸机 C/C++ 加上极简微内核）。

这些系统有一个共同特征：没有历史包袱，也没有“智能”的后台逻辑。

给它通电，100 毫秒内必须完成内核加载并进入主循环；直接拉闸拔掉电源，系统瞬间死亡，没有任何缓存未写入，没有任何状态损坏；下一次再通电，它依然可以在 100 毫秒内恢复到上一秒的工作状态。

它不需要注册表，不需要复杂的驱动仲裁，甚至不需要桌面和窗口管理器。

这种“死得干脆，活得极快”的特性，看似极其原始，却是在物理世界极其恶劣的干扰下，唯一能给人类安全感的东西。

微软在桌面领域的成功，建立在“用海量硬件资源和软件复杂度去屏蔽底层硬件差异，从而降低软件开发门槛”这个逻辑上。

但坦克的逻辑完全相反：它愿意付出极高昂的定制开发成本，去换取内核极致的简单与可控。

我后来在做工业控制项目时，有一次现场设备因为频繁非法断电导致嵌入式系统文件损坏。当时有工程师提出直接换上 Windows IoT，说开发快，界面好做。

我当时就想起了坦克的火控系统。

我们很多时候太依赖现代操作系统提供的便利了。我们习惯了自动垃圾回收，习惯了后台服务自动重试，习惯了操作系统帮我们处理掉绝大多数硬件异常。

但如果一个系统要被用在最极端的场景里，技术选型最终拼的往往不是“它能做多少复杂逻辑”，而是“当最坏情况发生时，它死得够不够透明、复活得够不够快”。

Windows 统治了桌面，不是因为它足够简单，而是因为它足够包容。坦克不需要包容，它只需要确定。

思想框架

文章先用“约克城号”事故拆开对 Windows 的直觉批评：崩溃案例存在，但平均稳定性或实时版本并非坦克排除它的唯一理由。论证随后把场景从数据中心换到战场，突出震动、冲击、电磁干扰和无预警断电；在这种环境里，Windows 为易用性维护的注册表、缓存、后台服务和启动依赖会变成难以预测的状态。VxWorks、LynxOS 和裸机系统牺牲通用性与开发便利，换取断电透明、百毫秒启动和确定恢复。作者最后把这条取舍带回工业控制：极端系统的核心能力不是功能最多，而是最坏情况能被清楚理解并快速恢复。