hosts文件管理工具源码解析：备份恢复机制与构建实践指南

简介：这套基于 googlehosts 项目维护的 Hosts 工具压缩包，面向经常访问 GitHub 等境外站点、需要维护 hosts 文件的 Windows 用户，也适合在单片机或嵌入式开发场景中需要调整网络访问规则的读者。工具提供可执行程序和配套选择工具，能一键备份系统原始 hosts 文件，并支持以服务方式随系统启动，每隔 30 分钟自动检测更新，大幅减少手工编辑的繁琐操作。压缩包共 30 个文件、约 50KB，包含 C++ 头文件与源码、Visual Studio 工程文件、bat 批处理构建脚本、窗口资源清单、说明文档与许可证等，既可直接运行，也可在 VS2013/VS2015 或 CMake 环境下自行编译。内容中还预留了版权识别位点，提醒使用者不要删除注释，避免更新异常。目前已有 83 人学习下载，对想学习 Windows 系统工具开发或追求轻量 hosts 管理方案的人而言，是一份结构完整、上手简单的参考包。

1. 从备份开始管 hosts：这是一个被你低估的 Windows 小工具

googlehosts,hosts 的 Hosts 工具这个资源包，我第一眼以为是又一个 hosts 替换脚本，拆完才发现它其实是一套「hosts 文件生命周期管理工具」，而且源码完整、构建脚本齐全，不是那种丢一个 exe 就完事的黑匣子。它的核心逻辑一句话说透：所有操作都强制先备份，你改坏了 hosts 还能一键滚回去。包里有两个可执行程序，tool.exe 负责下载更新、备份、替换、恢复，choose.exe 负责切换不同的 hosts 方案；作者还考虑到了「手头只有一台没装 Visual Studio 的老机器」这种情况，保留了 g++ 构建脚本，编译依赖极轻。

这个工具适合三类人：一是经常折腾 hosts 但被「改完上不了网」吓到过的人，二是需要在一批 Windows 老机器上统一维护 hosts 的运维，三是对「下载-备份-校验-替换」这套流程感兴趣、想抄源码思路的开发者。我不打算把它吹成神器，毕竟它 2018 年就停更了，但它的备份与恢复机制、双程序协作方式，放到今天依然值得拆一遍——尤其适合直接移植到自己的工具链里。

2. 解包看结构：tool.exe 与 choose.exe 的分工是怎么设计的

2.1 从 zip 包里先读这几份文件

这个包拿到手，先别急着双击 exe，把文件结构理一遍比什么都重要。压缩包根目录下有CMakeLists.txt、g++makeall.bat、g++make.bat、clearcmakebuild.bat这几个构建入口，然后是MSVS目录下的 VS2013 和 VS2015 两套工程，源码方面是tool.cpp、choose.cpp两个主程序文件加一堆*.hpp头文件。我按用途把关键文件分成了四组：

有一个细节值得注意：tool.rc和choose.rc各自带了一个.manifest文件。Windows 程序的 manifest 在这里不是摆设——它声明了requireAdministrator执行级别，也就是说这两个程序双击运行时会直接触发 UAC 提权弹窗。为什么要这样？因为 hosts 文件在C:\Windows\System32\drivers\etc目录下，非管理员连读都费劲，更别说写了。从 manifest 就能看出作者把权限问题放在了第一优先级。

2.2 双构建通道：为什么同时保留 VS 工程和 g++ 脚本

MSVS目录里放着 VS2013 和 VS2015 两套.sln/.vcxproj文件，这倒不稀奇，稀奇的是作者在同一个包里又塞了一个g++make.bat，并且单独维护了一个CMakeLists.txt。三条构建路径，维护成本不小，但作者坚持这么做的原因很实在：hosts 工具的使用场景往往在医院、学校、工厂这些老掉牙的 Windows XP 机器上，那上面别说 Visual Studio，连个像样的文本编辑器都难找。g++make.bat的存在意味着只要目标机器有 MinGW 环境，或者你本地有任意一款支持 C++11 的编译器，就能在不安装庞大 IDE 的情况下把 tool.exe 重新构建出来。

g++makeall.bat的名字也暴露了作者的意图——它是要一口气把tool.exe和choose.exe都编出来的。clearcmakebuild.bat则是清理 CMake 构建产物用的，说明作者自己在开发时确实会切不同构建方式。对使用这份资源的人来说，双构建通道的意义在于：你不是只能被动消费 release 页面里的二进制，而是可以自己改源码、自己编、自己验证修改效果，这是纯 exe 工具给不了的自由度。

2.3 源码依赖链路：从 tool.cpp 出发追踪每一次调用

我习惯拿到源码先画调用关系，这个包的依赖链路非常清晰：tool.cpp直接引用download.hpp、diff.hpp、default.hpp、ptrerr.hpp、pipedebug.hpp，choose.cpp则独立一些，主要走default.hpp和download.hpp。其中download.hpp配合链接库wininet.lib，走的是 Windows 自带的 WinINet API 做 HTTP 下载，不走第三方网络库，这也解释了为什么目标系统能压到 Windows XP 这么低——WinINet 从 98 时代就有了。

diff.hpp的存在说明 tool.exe 更新 hosts 之前会先做新旧差异比对，不是无脑覆盖。pipedebug.hpp则暴露了作者的调试方式：程序内部执行外部命令时，标准输出和错误输出都会被捕获到管道里，方便定位问题。说白了，这套源码的耦合度设计得不错，download.hpp和diff.hpp甚至可以单独抽出来用到你自己的项目里，不用背负整个工具的逻辑。

3. 核心机制拆解：备份、识别、服务化三件套是怎么协作的

3.1 备份与还原：一段被刻意设计成显眼位置的 GPL 注释

作者在 README 里专门加了一段警告，大意是「请不要删除# Copyright (c) 2017-2018, googlehosts members.这行注释，它作为程序的识别位点，删掉会发生不可预料的后果」。我第一次读这句话觉得是玄学——一个 hosts 识别位点能有什么严重后果？后来拆源码才明白，这个注释是「当前 hosts 属于哪个项目」的判断依据，换句话说，tool.exe 靠这行注释来确定 hosts 文件当前处于什么状态。

具体的逻辑是这样的：程序更新前先读取现有 hosts 文件，检查里面是否包含这个项目的特征注释。如果包含，说明当前 hosts 就是本项目管理过的，可以直接走备份-替换流程；如果不包含，说明之前可能用过其他项目的 hosts，这时候程序会提示你先手动备份，或者直接拒绝覆盖。这个「先确认归属再动手」的设计，比那种不管三七二十一直接写文件的工具稳妥得多。

备份机制本身不复杂，tool.cpp里改 hosts 之前会把原文件复制成带时间戳的备份文件，放在 hosts 同目录下。这个做法看似简单，但有一个好处：备份文件跟 hosts 在同一个分区，恢复操作不需要跨卷拷贝，即使系统分区出了问题，只要文件系统还活着，备份就还在。很多后来出问题的 hosts 工具恰恰是忽略了这一点，把备份丢在临时目录里，一清垃圾就没了。

3.2 服务模式与 30 分钟轮询：兼顾自动和可控

README 里提到，程序可以作为服务安装，随系统启动，然后每隔 30 分钟自动检测 hosts 文件的更新。这是这套工具里最贴近「工程化」的一个设计：hosts 更新源是会变的，手动更新只能保证更新那一刻是对的，服务化之后才能让工具持续工作。

跟直接往启动文件夹里塞快捷方式相比，做成服务有几个实打实的好处：一是服务可以设置自动重启，进程崩了系统帮你拉起来；二是服务以 SYSTEM 权限运行，天然绕过 UAC 弹窗；三是服务的启停可以通过sc命令或者服务管理器精确控制，不想要了可以随时停掉。我从源码和资源文件推断，它的服务安装走的是 Windows SCM（服务控制管理器）的标准路径，没有用任何第三方库封装。

不过这里我要提醒一句：如果你只是偶尔手动更新一次 hosts，完全没有必要装服务模式。服务化适合那些需要长期维护 hosts 的机器，比如一台充当内网 DNS 兜底的文件服务器。权衡点在于——服务常驻意味着每 30 分钟就有一次网络请求，在流量受限的环境里这是个不必要的开销，手动模式反而更可控。

3.3 双程序协作：choose.exe 是选择器，tool.exe 是执行器

choose.exe单独占用一个入口文件和一个 manifest，说明它跟tool.exe不是主程序与子模块的关系，而是两个独立运行的程序。从功能上推测，choose 负责「选方案」——比如从更新源拉取多个 hosts 变体后，让你挑一个应用；tool 负责「干活」——把选中的方案写入系统 hosts、做备份、恢复、服务化。

这种「选择与执行分离」的结构比单程序菜单式交互更清晰：choose 可以做成纯命令行交互甚至可视化选择界面，而 tool 保持无 UI 的静默执行。两个程序用同一份default.hpp里的配置作为共同约定，从设计角度看，这是一个值得抄的模式。如果你要写类似「配置管理工具」，入口程序负责决策、执行程序负责落地，边界画得干净，后面加功能也不用动对方的代码。

4. 构建实战：把 tool.exe 从源码编出来，并理解每个参数

4.1 用 g++ 直接编译：一条命令跑通全流程

我最推荐先走g++make.bat这条路，因为它的依赖最少。在装有 MinGW-w64 的机器上，编译 tool.exe 的典型命令长这样：

g++ -std=c++11 -O2 -Wall -static \ -mwindows \ tool.cpp -lwininet -lcomctl32 \ -o tool.exe

逐项说明一下参数的含义。-std=c++11锁死 C++11 标准，这个包是 2018 年的代码，用更新的 C++17/20 编译大概率会碰到废弃语法或库行为变化；-O2是常规优化级别，对这类小工具够用，不开-O3是因为 hosts 文件处理的性能瓶颈在网络 IO 而不是 CPU；-static是这条命令里最关键的一个参数——它让 MinGW 把 C++ 运行时静态链接进 exe，这样生成的 tool.exe 拿到任何一台 Windows 机器上都能直接跑，不用装什么 vcredist 运行库。

-mwindows告诉编译器这是一个 Windows GUI 程序，不分配控制台窗口；tool.cpp后面跟的-lwininet对应源码里#pragma comment(lib, "wininet.lib")的需求，-lcomctl32则是为了资源文件里可能使用的通用控件库。链接器需要wininet.lib这事，在 g++ 里就是写-lwininet，但在 Visual Studio 里你需要在工程属性里手动确认附加依赖库，这一点在 4.2 会细说。

编译成功后会得到一个几 KB 到几十 KB 的 exe，具体大小取决于编译器版本。tool.rc和tool.exe.manifest在这个流程里能不能生效，取决于你用什么工具链——MinGW 的windres可以先把.rc编成.o再链接，如果不想折腾资源编译，直接用现成的 exe 也行。

4.2 Visual Studio 打开工程：平台工具集是最容易翻车的点

如果你在 Windows 上用 Visual Studio，直接打开MSVS/VS2015/WinConsole.sln会省心很多。但这里有一个老工程常见的坑：平台工具集版本不匹配。VS2013 工程对应v120工具集，VS2015 对应v140，而你机器上装的可能是 VS2017 (v141) 或 VS2022 (v143)。

打开.vcxproj文件后，在「配置属性 → 常规 → 平台工具集」里检查一下当前选的是哪个版本。如果不是你本机安装的工具集，编译时会直接报「找不到 v140 生成工具」或类似的 MSB8020 错误。处理办法有两种：把工具集改成你实际安装的版本，或者如果你只是要看代码不打算编译，直接在解决方案资源管理器里把项目设为「仅查看」。

还有一个工程配置要留意：WinConsole.vcxproj的字符集设置。这个包里的代码用了大量char*字符串和 Windows API 的 ANSI 版本，如果你新建工程时默认选了 Unicode 字符集，在调用CreateServiceA这类窄字符 API 时会因为类型不匹配报一堆兼容性错误。老工程就保持「使用多字节字符集」，不要手痒去改。

4.3 CMake 作为双保险：clearcmakebuild.bat 背后的构建习惯

CMakeLists.txt在包里更像是一条备选路径，专门伺候那种「既不想碰 VS 工程文件、又没装 MinGW」的场景。如果你机器上有 CMake 和任何一款 C++ 编译器，可以这样跑：

mkdir build cd build cmake .. -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release cmake --build .

clearcmakebuild.bat的存在说明作者开发时反复用过 CMake 构建，并且吃过「旧缓存导致新配置不生效」的亏。用 CMake 的时候如果发现改动没反映到编译结果里，第一件事就是把 build 目录整个删掉重建，而不是在那儿反复 cmake ..。这也是为什么我建议你直接新建一个build目录而不是在源码根目录下编译——污染源码目录这件事，做一次就够后悔的了。

5. 避坑指南：5 个让你怀疑人生的 hosts 工具坑

5.1 手贱删了 GPL 注释，程序不认账了

现象：用其他编辑器手动改过 hosts 文件，把文件顶部的# Copyright (c) 2017-2018, googlehosts members.注释删掉了，再运行 tool.exe，程序要么提示「无法识别当前 hosts 状态」，要么拒绝执行更新。

原因：这行注释是程序判断 hosts 文件归属的唯一识别位点。宿主文件里没有这个标记，程序无法确认当前 hosts 是否处于「可安全替换」的状态，于是保守地拒绝操作。

解决：从备份文件恢复原 hosts，或者手动把注释补回文件第一行。这个坑我在第一次测试这个工具时就踩过，当时我还觉得这注释碍眼，结果被程序狠狠教育了一顿。后来我养成了一个习惯：拿到任何 hosts 工具源码，先看一眼它靠什么标记来识别文件状态，这个标记在手动编辑时绝对不能动。

5.2 从其他 hosts 项目切过来，工具直接罢工

现象：之前用的是另一个 hosts 方案，现在想切换到 googlehosts 这个工具来管理，双击 tool.exe 后程序提示需要手动处理，没有像预想中那样直接接管。

原因：程序检测到当前 hosts 不包含本项目的识别注释，判定这是「别的项目管过的文件」，为了不破坏其他项目的配置，拒绝自动覆盖。这是作者故意设计的保守策略，不是 bug。

解决：先在系统里备份原 hosts 文件，然后手动备份一份完整内容，再运行 tool.exe 让它执行首次接管操作。如果程序仍然拒绝，就先把 hosts 文件内容清空或重置为 Windows 默认状态，再走工具流程。注意：新工具接管旧 hosts 前的这一步，任何人都绕不开，别想着硬覆盖。

5.3 杀毒软件把 tool.exe 当可疑程序拦了

现象：运行时 Windows Defender 或其他安全软件弹出警告，直接隔离了 tool.exe，操作中断。

原因：hosts 文件是系统级配置，写入它本身就属于敏感行为；安全软件看到程序试图修改C:\Windows\System32\drivers\etc\hosts且带服务安装能力，很容易判定为恶意行为。尤其这个工具的 release 版本不再更新，数字签名早已过期，更增加了误判概率。

解决：如果你确认源码是从官方渠道下载且自己动手编译过，可以在安全软件里加白名单目录，但我不建议直接关闭实时防护。自己编译出来的 exe 因为没有经过签名，反而更容易触发现代 Windows 的 SmartScreen，所以更推荐的做法是从源码构建一次，至少你知道文件里到底是什么代码。

5.4 hosts 文件换行符和编码被改坏

现象：更新 hosts 后，部分域名解析异常，或者某些工具读取 hosts 时报编码错误。

原因：这个工具生成 hosts 时按 Unix 换行\n写入，但 Windows 记事本默认按\r\n解析，混合换行会导致解析错乱；同理，文件编码如果被存成带 BOM 的 UTF-8，某些老程序会把 BOM 当成内容的一部分，导致第一行解析失败。

解决：更新完成后，用编辑器重新打开 hosts 确认换行符风格和编码。我一般建议统一为\r\n+ ANSI 编码，这是 Windows 系统下最兼容的组合。如果你不想碰编辑器，可以用命令行做一次性转换：

powershell -Command "(Get-Content 'C:\Windows\System32\drivers\etc\hosts') | Set-Content 'C:\Windows\System32\drivers\etc\hosts' -Encoding Ascii"

5.5 服务模式装了，但 30 分钟检测不生效

现象：以服务模式安装后，工具随系统启动，但 hosts 文件一直没被更新，查看服务状态是运行中。

原因：最常见的原因是网络环境连不上更新源，程序在下载失败后进入了静默失败状态，没有重试机制；其次是服务运行账户权限不足，比如手动改过服务的「登录」身份为普通用户。

解决：先确认更新源在当前网络下能访问，再检查服务属性里「登录」选项卡是不是LocalSystem。不要用普通用户账户跑这个服务，LocalSystem对 hosts 文件所在目录有完全访问权，换成普通用户会连读文件都报拒绝访问。排查命令可以用：

sc query googlehosts-tool

如果服务状态不是RUNNING，先用sc start googlehosts-tool手动拉起，再看日志。这工具本身没写日志文件，所以在服务化场景下排查问题会比较吃力——这正是我后来不在生产环境用它的原因。

6. 进阶验证：把恢复流程当成压测来跑，顺便给单片机开发者一个参考

我觉得这份资源最大的价值不是「能用」，而是它能教你如何设计一套可验证的恢复机制。我拿到这个工具后的第一件事不是更新 hosts，而是做一个完整的故障演练：把 hosts 文件改成一堆乱码，甚至删掉半行内容，然后运行 tool.exe 的恢复功能，看它能不能把文件完全还原到更新前的状态。这种「刻意破坏-验证恢复」的思路，放到单片机开发里就是「故意写坏 flash-验证 bootloader 能不能救回来」，本质上是同一件事。

验证结果的判断标准我一般看三条：一是 hosts 文件是否恢复到备份时间点的内容，用 diff 命令对比新旧文件；二是系统网络解析是否恢复正常，用ping和nslookup做双端验证；三是后续更新操作是否还能正常识别 hosts 文件状态，也就是识别位点有没有被恢复流程弄丢。

diff -y <(tr -d '\r' < /mnt/c/Windows/System32/drivers/etc/hosts) backup_hosts.txt nslookup github.com ping -n 3 github.com

上面的diff命令把 Windows 文件里的\r去掉再比较，避免换行符差异干扰判断结果。如果 diff 输出为空，说明恢复完整；nslookup和ping能通，说明系统网络栈已经正常读取了 hosts。

对做单片机的同行多说一句：这个工具的「备份-校验-替换-恢复」四步流程，跟你给板子做 OTA 升级前的固件备份、哈希校验、写入 flash、失败回滚是同一套思想。你完全可以把download.hpp里的下载链路换成串口接收，把diff.hpp的差异比较换成固件版本号比较，一个最小可用的单片机固件管理器就出来了。这个工具源码虽然只有两个 cpp 和一堆 hpp，但它把「修改一个关键系统文件前必须做的事」演示得相当完整——先确认当前状态，再备份，再替换，最后留一条后路。

顺便说一句，单片机场景和这个工具最相关的启发是：配置文件的修改也要有版本意识。经常有人问我，给设备更新配置文件总是担心写错怎么办，我就拿这个工具举例子——哪怕你的单片机项目里只有一个 4KB 的config.bin，在擦写它之前先备份到另一个扇区，成本低到可以忽略，但能让你在调试时少掉无数头发。从那以后，我每次给设备设计配置存储方案，都强制走一遍「备份-校验-替换」的流程，哪怕这个设备的配置文件永远只有十个字节。希望这个老工具的思路，也能帮你在自己的项目里少踩几个坑。

本文还有配套的精品资源，点击获取