Windows下INI文件读写实战：配置管理最佳实践

1. INI 文件到底是什么：一种不该被遗忘的轻量配置方案

提起 Windows 开发里的配置文件，很多朋友第一反应是注册表、XML、JSON，甚至现在流行的 YAML。但我在实际项目里折腾一圈之后发现，INI 文件在特定场景下仍然是最省心的选择，尤其适合工具类软件、便携程序、老系统维护和老项目改造。这次分享的是我整理的四种 Windows 文件操作中的第三种——INI 文件读写，内容偏实战，代码都能直接抄走改改用。

INI 文件的全称是 Initialization File，结构上就是纯粹的文本，用节（Section）、键（Key）和值（Value）组织数据。一个典型的 INI 长这样：

[config] width=1920 height=1080 fullscreen=0 [user] name=Admin language=zh-CN

它的核心优势在于“人类可读”：记事本打开就能改，git diff 时能看清楚改了什么，出错时也容易排查。相比之下，注册表里键值改错了要小心备份和恢复，XML 写起来标签一大堆，JSON 虽然简洁但要求严格的双引号，手写时一个逗号漏了整份文件报废。INI 的容错度反而更高，很多解析器都能容忍一定程度的格式问题。

Windows 系统本身也一直保留着对 INI 的原生支持，早期系统的 system.ini、win.ini 都是这种结构。虽然微软后来主推注册表，但 INI 文件在配置文件这个细分领域里从来没有真正退出过。市面上各种 INI 解析库也很多，从 C++ 到 C# 到 Python 都有成熟方案。

我为什么要在 2024 年还专门整理 INI 读写？因为我最近在做一个跨平台的工具软件，需要同时兼容 Windows 和 Linux 环境下的便携运行。软件本身不需要安装，解压即用，配置项也不多，就十来个键值对。这时候如果引入 JSON 或 XML，我得多写不少序列化代码；如果用注册表，Linux 上根本没法用。INI 文件摆在程序同目录下，读写都走文本操作，两个系统之间无缝切换。这种场景下，INI 几乎是唯一不需要额外依赖就能统一处理的方案。

还有一类场景也让 INI 有长期的生存空间：工业设备、嵌入式上位机、老旧的业务系统。这类系统的特点是生命周期特别长，协议和配置格式已经固化，即使新项目也不得不延续这种格式才能对接旧设备。前阵子我帮某实验室维护一个仪器控制程序，上位机通讯参数就是存在 INI 里的，界面文本框、配置文件、设备参数三者的对应关系一清二楚。想换成 JSON 反而会破坏原有生态。

总之，INI 文件适合这类场景：配置项少（几十个以内）、需要人工直接编辑、希望零依赖、要求跨语言跨平台互通。如果你遇到的是这几类需求，优先考虑 INI 没有问题。反之如果需要存储复杂嵌套结构、数组、对象，那 INI 就不够用了，还是选 JSON 或 XML 吧。

2. 四种 Windows 文件操作的定位区分

标题里提到了“四种文件操作”，这里顺便把我整理的四个方向理清楚，因为很多人对它们的边界模糊。我在项目里把它们分成了四类，各自解决不同层次的问题，INI 只是其中之一。

2.1 文本文件读写：最基础的字节流操作

文本文件操作是最底层的技能。用 C 标准库里的 fopen/fread/fwrite，或者 C++ 的 ifstream/ofstream，把整个文件当字符串数组读入内存、处理、再写回。这类操作适合处理日志文件、数据导出、简单的数据交换。

文本文件操作的核心问题是编码处理。Windows 下常遇到 GBK 和 UTF-8 混用的情况，稍不注意读出来就是乱码。我一般在读文件时先检测 BOM，没有 BOM 就尝试用 UTF-8 严格模式解析，失败再回退到 GBK。这套策略在绝大多数场景下都能正确处理。

2.2 二进制文件读写：结构体直接落盘

二进制读写讲究的是内存结构和磁盘数据结构一一对应。在 C++ 里可以直接把结构体指针 cast 成 char 指针，然后写进文件；读取时反过来。这种方式的优点是速度快、占用空间小，缺点是文件不透明、不能跨平台跨编译器（字节序和结构体对齐都会影响）。

我实践中更推荐的做法是：把二进制文件的结构设计得显式一些，比如自定义文件头、字段偏移表、显式写入整数大小端标记。不要完全依赖编译器的内存布局，否则换一个编译器或换一个平台，读出来的数据可能全乱了。

2.3 INI 配置文件读写：本节核心

INI 文件正好介于文本和二进制之间：它本质是文本，但带有结构。INI 的解析逻辑不复杂，但处理起来有不少隐藏的坑，比如中文字符编码、键值对前后的空格、注释在不同解析器中的规则差异、重复键名的策略等，这些我会在后面的章节逐一展开。

2.4 注册表操作：系统级配置存储

注册表是 Windows 特有的配置数据库，适合保存需要系统级管理的配置，例如开机启动项、文件关联、服务配置、深层系统参数等。注册表按 Hive、Key、Value 分层次存储，访问时路径形式类似文件系统路径。

注册表的优点是集中管理、权限控制好、支持事务，适合系统集成场景；缺点是强依赖 Windows 环境，程序换到其他系统就无法运行，而且注册表臃肿后系统维护会很难受，修改错误还可能影响整个系统稳定性。可移植性要求高、想做成绿色软件的时候，还是优先考虑 INI。

3. Windows 下 INI 文件读写的两种主流技术路线

实际开发中，Windows 平台读写 INI 文件有两种主流路线：系统原生 API 和开源解析库。两种我都用过，它们各有明确的适用场景，提前搞清楚能省下不少返工时间。

3.1 路线一：调用系统自带的 INI 操作函数

在 Win32 环境下，微软原生提供了一组 INI 操作函数：GetPrivateProfileString、GetPrivateProfileInt、WritePrivateProfileString，还有操作 ini 文件内各节（Section）的GetPrivateProfileSection。它们位于 kernel32.dll，在 C/C++/Delphi 程序中都可以直接调用，无需额外引入任何库。

使用这套 API 的好处是零依赖、系统级兼容、解析逻辑微软自己维护。特别适合老项目改造、维护老设备配套程序，因为很多十多年前写的程序就是用这套 API 读写 INI，沿用下来最稳妥。

#include <windows.h> #include <stdio.h> int main() { // 读取字符串 char buffer[256] = {0}; GetPrivateProfileStringA( "config", // Section 名 "width", // Key 名 "1920", // 默认值 buffer, // 接收缓冲 sizeof(buffer),// 缓冲大小 ".\\app.ini" // INI 文件路径 ); printf("width = %s\n", buffer); // 写入字符串 WritePrivateProfileStringA( "config", "width", "2560", ".\\app.ini" ); return 0; }

上面代码里的A后缀代表使用 ANSI 编码的版本，对应还有W后缀的宽字符版本。在 Windows 上默认的 ini 文件编码是 ANSI（在简体中文系统上就是 GBK），所以读写中文推荐直接用 A 版本，按系统 ANSI 编码处理。如果你用 UTF-8 编码保存 ini 文件，这些 API 识别会出问题，这一点我在第 4 章会详细展开。

GetPrivateProfileInt专门用来读整数值。它默认值设在第三个参数，比如GetPrivateProfileIntA("config", "port", 8080, ".\\app.ini")，如果 ini 里没有这个键或者键值不是合法数字，就返回默认值 8080。函数返回类型是 UINT，只支持无符号整数；如果你需要负数或者大数，建议读字符串再手动转换。

这套 API 内部实现了很多细节，例如自动处理文本解码、大小写不敏感的节名和键名、自动创建文件等，所以用起来比自己解析稳很多，但它的问题在于：过度依赖于操作系统实现，跨平台无法使用，而且不支持 UTF-8 编码的 ini 文件，这两个限制在使用时要记住。

3.2 路线二：使用跨平台开源 INI 解析库

如果你需要写跨平台代码，或者需要支持 UTF-8 编码的 INI 文件（现在很多项目配置文件统一用 UTF-8 以方便协作），那系统 API 就不够了，得引入开源库。

我常用的库有两个：

• inih（INI Not Invented Here）：一个 C 语言写的极简解析库，核心只有一个 C 文件和一个头文件，支持注释、行继续符、自定义回调，而且非常轻量，很适合嵌入式或需要打包进工具链的场景。
• SimpleIni：C++ 写的，封装更人性化，支持按节遍历、类型转换、注释保留、多行值，适合 C++ 项目中直接 include 头文件使用。

以 inih 为例，它接收一个回调函数指针来处理每个键值对。这种设计把“解析”和“处理”分开，灵活性极高，比如你可以只提取指定节的数据，也可以逐行记录所有键。使用 inih 读取刚才那份 ini 文件，主要代码如下：

#include "ini.h" #include <stdio.h> #include <string.h> static int handler(void* user, const char* section, const char* name, const char* value) { if (strcmp(section, "config") == 0) { if (strcmp(name, "width") == 0) { printf("width = %s\n", value); } } return 1; // 返回 1 表示继续解析，返回 0 则中止 } int main() { if (ini_parse("app.ini", handler, NULL) < 0) { printf("文件解析失败\n"); return 1; } return 0; }

SimpleIni 用起来更直接一点：

#include "SimpleIni.h" CSimpleIniA ini; ini.LoadFile("app.ini"); const char* width = ini.GetValue("config", "width", "1920"); ini.SetValue("user", "name", "Admin"); ini.SaveFile("app.ini");

两种路线用表格对比如下：

对比项	Win32 API (GetPrivateProfileString)	开源库 (inih / SimpleIni)
跨平台支持	仅 Windows	全部主流平台
UTF-8 支持	不支持（需 ANSI）	支持
外部依赖	无（系统自带）	需引入源码或头文件
使用复杂度	简单，接口固定	需理解回调或类封装
key 大小写	不敏感	默认敏感，可配置
注释保留	自动忽略	可读取或保留
适合场景	Win32 传统程序、老系统维护	新跨平台项目、需 UTF-8 的项目

我的建议是：做纯 Windows 小程序、老系统配套工具、快速原型验证，直接用 Win32 API 最省事；做跨平台应用、需要统一 UTF-8 编码、需要灵活控制解析行为时，选开源库。两者都在生产环境验证过，没有谁更优，只有是否适合当前项目。

4. 从零手写一个 INI 读写器：核心逻辑与编码处理

如果你不想依赖第三方库，或者你的开发环境引入外部代码比较麻烦，手写一个精简的 INI 解析器也是可行的。这里我以 C++ 为例，从零实现一个支持读写的基础 INI 工具，重点是讲清楚内部逻辑，方便你改成其他语言版本。

4.1 解析核心：按行拆解、按分隔符切分

INI 文件的格式规则不算严格，但基本逻辑是一致的：

• 文件由若干节组成，节以[节名]开头，直到下一个节标记结束。
• 节内包含若干键值对，形式为键=值或键:值，等号最常见。
• 注释行以;或#开头，解析器应跳过。
• 空行可以忽略。

因此解析过程可以拆成三步：

1. 逐行读取文件内容；
2. 判断当前行类型：节标记、键值对、注释、空行；
3. 维护一个“当前节名”的状态变量，直到遇到新的节标记时更新它。

这个思路用 C++ 标准库的文件流就能实现，不需要依赖任何第三方库，核心代码也不长。参考实现如下：

#include <iostream> #include <fstream> #include <map> #include <string> #include <algorithm> class IniFile { public: // 键名使用 "section.key" 的形式存储，方便快速查找 std::map<std::string, std::string> values; bool load(const std::string& filename) { std::ifstream file(filename); if (!file.is_open()) return false; std::string line, current_section; while (std::getline(file, line)) { // 去除首尾空白 trim(line); if (line.empty()) continue; if (line[0] == ';' || line[0] == '#') continue; if (line.front() == '[' && line.back() == ']') { current_section = line.substr(1, line.size() - 2); trim(current_section); } else { auto pos = line.find('='); if (pos == std::string::npos) continue; std::string key = line.substr(0, pos); std::string value = line.substr(pos + 1); trim(key); trim(value); values[current_section + "." + key] = value; } } return true; } std::string get(const std::string& section, const std::string& key, const std::string& default_value = "") { auto it = values.find(section + "." + key); return it != values.end() ? it->second : default_value; } void set(const std::string& section, const std::string& key, const std::string& value) { values[section + "." + key] = value; } void save(const std::string& filename) { std::ofstream file(filename); if (!file.is_open()) return; std::string last_section; for (const auto& [k, v] : values) { auto dot_pos = k.find('.'); std::string section = k.substr(0, dot_pos); std::string key = k.substr(dot_pos + 1); if (section != last_section) { file << "\n[" << section << "]\n"; last_section = section; } file << key << "=" << v << "\n"; } } private: static void trim(std::string& s) { s.erase(s.begin(), std::find_if(s.begin(), s.end(), [](unsigned char ch) { return !std::isspace(ch); })); s.erase(std::find_if(s.rbegin(), s.rend(), [](unsigned char ch) { return !std::isspace(ch); }).base(), s.end()); } };

这个实现没有做重复键名的合并策略——后出现的覆盖先出现的；也没有保留注释和空行，保存时会丢失原始排版。如果你的场景需要保留注释（比如配置文件需要给人看），就需要额外设计一个结构体来保存每一行的原始内容，同时记录它属于哪个节。虽然复杂度会上升一些，但原理还是上面这几步。

4.2 编码处理：GBK 与 UTF-8 的取舍

手写解析器绕不过去的一个问题是编码。Windows 简体中文环境下，记事本默认以 ANSI（GBK）保存文本，而各种开发工具和团队协作时又普遍推荐 UTF-8。这两者混用，就会出现读出来中文乱码的情况。

我的处理策略分两种情况：

• 如果程序只在 Windows 简体中文环境运行，且配置文件可能被用户用记事本编辑，尽量保持 GBK 编码。读写时直接用系统 ANSI 编码，最不容易出错。Win32 API 的 A 版本本质就是这么处理的。
• 如果程序需要跨平台，或者配置文件会被 Git 等团队工具共享，统一使用带 BOM 的 UTF-8。带 BOM 的 UTF-8 文件在 Windows 记事本里打开时能够正确识别，同时 Git 也能正常追踪内容。

BOM（Byte Order Mark）是位于文件开头的一串特殊字节，UTF-8 的 BOM 是EF BB BF。在读取时，如果发现文件以这三个字节开头，就跳过它们；在写入时，如果确定要兼容 Windows 记事本，就主动写入这三个字节。很多开源库默认不写入 BOM，所以直接用它们生成的 UTF-8 文件在记事本里打开可能会乱码，这一点要特别留意。

我自己实际摸索出来的实用编码检测流程如下：

1. 读取文件前三个字节，如果等于EF BB BF，认定为 UTF-8，跳过 BOM 解析。
2. 如果没有 BOM，就把整个文件内容按 UTF-8 严格模式解码；解码失败则回退到 GBK/ANSI。
3. 写入时根据项目约定决定：跨平台项目写带 BOM 的 UTF-8；Windows-only 的简易工具按系统 ANSI 写。

这个策略在绝大多数场景下都能避免乱码问题，代价是读文件时多了一次解码尝试。对 INI 这种小文件来说，性能损失可以忽略不计。

4.3 键值对处理细节：分隔符、空格与行尾符

手写解析器时容易忽略的小坑，我列举几个实战中真实遇到的：

第一个坑是分行符。Windows 下文本文件换行是\r\n，Linux 下是\n。如果你在 Windows 上把一份在 Linux 下生成的 INI 文件直接读进来，std::getline默认按\n分割，读出来的字符串末尾会带着\r，然后键名就变成"width\r"，匹配不上。解决办法是在 trim 时把\r也当作空白字符处理，或者读入后统一移除末尾的\r。

第二个坑是行内注释。有些 INI 文件支持key=value ; 注释这种形式，但什么时候分号算注释、什么时候算值的一部分，不同解析器规则不同。我自己定的规则是：只有当分号或井号在行首时才视为注释，行内注释一律不处理。这样可以避免键值里本来就带分号（比如 URL 参数、分隔符）时被错误切断。如果你确实需要支持行内注释，建议约定注释标记前面必须有空格，比如key=value ; 注释，解析时先找=，再从值部分的末尾向前查找空格+分号。这种做法仍有可能误伤，所以默认关掉更安全。

第三个坑是值的两端空格。有些配置文件里人会写width = 1920，如果不做 trim，读出来的值是"1920 "，转成整数时可能报错。上面的实现已经在解析时做了 trim，但注意保存时不要再把值重新 trim 掉，因为有些场景下空格本身是有意义的（比如分割多个路径的字符串）。

第四个坑是节名和键名的大小写。Windows 自带的 API 对节名和键名不区分大小写，但你手写的std::map默认区分。如果项目里有人把[Config]和[config]混写，就会产生两个不同的节，很容易排查半天。我的建议是统一约定：加载时全部转小写存储，写入时保持原始大小写。这样可以避免大小写不一致导致的查找失败。

5. 实战：一个系统托盘工具如何用 INI 保存用户偏好

理论说完了，来看一个完整的实战案例。我用 C++ 写过一个带系统托盘的小工具，功能是监控某个文件夹的大小变化，并在超过阈值时弹出通知。用户的可配置项包括：监控路径、轮询间隔、提醒阈值、开机是否自启、窗口位置记录。这些配置如果每次退出都写注册表，那这个工具就没法做绿色便携版了，所以我选择全部存到程序目录下的settings.ini。

5.1 用 Win32 API 完成读写与遍历

在这类纯 Windows 小程序里，我直接用最传统也最稳定的 Win32 API。整体交互逻辑如下：

程序启动时，检查同目录下有没有settings.ini，不存在就创建并写入默认值；存在就读取各项配置并加载到内存中的全局变量里。用户修改配置并确认后，调用WritePrivateProfileStringA立即写回文件。

读取配置的代码大致是这样的：

char path[MAX_PATH] = {0}; char interval[16] = {0}; char threshold[16] = {0}; char autostart[8] = {0}; GetPrivateProfileStringA("monitor", "path", "C:\\", path, MAX_PATH, ".\\settings.ini"); GetPrivateProfileStringA("monitor", "interval_sec", "30", interval, 16, ".\\settings.ini"); GetPrivateProfileStringA("alert", "threshold_mb", "500", threshold, 16, ".\\settings.ini"); GetPrivateProfileStringA("misc", "autostart", "0", autostart, 8, ".\\settings.ini");

写入时注意路径的写法。INI 文件路径里如果出现反斜杠，需要特别注意：WritePrivateProfileStringA对 ini 文件路径的反斜杠处理是常规的 Windows 路径方式，但写在配置值里的路径（例如C:\monitor\target）在保存时没有特殊转义需求，直接写入即可。反而是路径含中文时，要确保使用 A 版本并按系统 ANSI 保存，否则记事本打开是乱码。

这里有个实用技巧：如果你希望在配置里保存带反斜杠的路径，而程序又使用 Win32 API 读写，注意反斜杠在绝大多数实现里没有特殊含义，不要把它当 C 字符串的转义符处理。上面代码里我已经用"C:\\"的形式表达了 C 语言层面的字符串，实际写到 ini 里的内容是C:\。

5.2 配置热更新与默认值兜底策略

配置文件的价值不仅在于保存，还在于“允许用户随时改动且程序能感知”。我的做法是：每次配置窗口打开时，重新从文件读取并刷新界面显示，而不是用内存缓存；这样用户在窗口打开期间用记事本修改了文件，窗口也能在刷新时看到新值。不过更常见的做法是：程序启动时只读一次，之后用户在窗口里修改并通过按钮保存。两种模式各有取舍，我倾向于后者，简单且避免文件被并发写入。

默认值兜底策略也很重要。一个成熟的程序至少要保证：即使settings.ini被用户删了一半内容、甚至完全删掉，程序也要能带着默认配置正常运行，而不是崩溃。Win32 API 的默认值参数在这里就是兜底：GetPrivateProfileStringA的第三个参数lpDefault在键不存在时返回，GetPrivateProfileIntA也一样。我的写法是，代码里的默认值和文档中描述的出厂值保持一致，同时只在启动时做一次检查性写入，把缺失的键补上默认值，不覆盖用户已经设置过的键。这样用户改了部分配置后，程序不会把没改的键复位成出厂值。

关于路径扩容问题，我再提一句：GetPrivateProfileStringA的lpReturnedString缓冲区大小固定为MAX_PATH（260 字节）时，如果配置的监控路径很长，可能被截断。这时候要么把缓冲区设大一些，要么使用GetPrivateProfileSection配合动态内存。我习惯的做法是常量给到 1024，同时判断返回值小于缓冲区大小，如果返回值接近缓冲区大小，说明可能有截断，界面里给出提示。

5.3 配置管理模块的容错设计

我在这里再加一些工程化的思考。INI 作为配置载体，本身解析就简单，真正容易出问题的是程序对配置内容的校验。我的建议是：把所有的 INI 读取操作收敛到一个SettingsManager类里，统一完成读取、校验、类型转换、默认值兜底、写回。不要散落在窗体事件处理函数里。这样以后想从 INI 迁移到 JSON 时，只需要替换这一个类，其他代码不必改动。

SettingsManager大致这样组织：

class SettingsManager { public: void load(); void save(); int getMonitorInterval() const { return m_interval; } std::string getMonitorPath() const { return m_path; } void setMonitorPath(const std::string& p) { m_path = p; } private: void loadFromIni(); void validateAndFix(); std::string m_path; int m_interval; int m_threshold; bool m_autostart; };

validateAndFix()的作用是检查数值范围。比如轮询间隔必须是 5 到 3600 秒，如果配置里写的是-1或者99999，就回退到默认值 30 秒，并打印一条日志。这个检查非常必要，因为配置文件是文本，用户随手改错一个数字，代码直接拿去用，可能造成死循环或异常高频轮询。

顺带说一句：如果你做的是 C# 项目，可以考虑 NuGet 上的第三方 INI 库，也可以直接用 Microsoft.VisualBasic.FileIO 里的 TextFieldParser 写简单解析；如果你用 Python，标准库configparser几乎就是为 ini 量身定做的，处理注释和大小写也提供了选项。跨语言场景下，INI 的互通性远比你想象的好，这也是它至今还能在自动化脚本里频繁露面的原因。

6. 踩坑实录：我使用 INI 配置时遇到的 5 个典型问题

几乎每次带 INI 的项目都会有人踩到下面这些坑，我干脆把它们集中写出来，方便你排雷。

6.1 UTF-8 无 BOM 的 ini 在 Windows 记事本打开乱码

这个问题我最早是在用 inih 的时候遇到的。inih 按 UTF-8 解析文件，而我用代码创建的 ini 文件没有写 BOM。用记事本打开时，Windows 默认按 ANSI 解码，所有中文直接变成乱码。用户以为程序把配置写坏了，实际只是编码标记缺失。

解决方式在前文提过：只要需要兼容 Windows 记事本，写 UTF-8 文件时主动在文件头写入EF BB BF。在 C++ 里可以这样实现：

std::ofstream file(filename, std::ios::binary); char bom[] = {(char)0xEF, (char)0xBB, (char)0xBF}; file.write(bom, 3); // 然后写入 UTF-8 编码的正文

另外如果你用的是 Win32 API 的 W 版本（宽字符版）读写 INI，它内部走的编码是 UTF-16，而不是 UTF-8，和记事本默认 ANSI 也不一样。所以不要以为用了 W 后缀就万事大吉，中文环境下文本存储还是绕不开 ANSI 这个前提。

6.2 配置值中包含分号时被错误截断

我有一次在配置里保存通知标题，内容包含了分号，结果用某个解析库读出来，后半段被当成了注释丢掉。排查了很久才发现是库对行内注释的处理规则和文档描述不一致。

此后我给自己定下规矩：只要使用第三方解析库，先写一个针对特殊字符的单元测试，验证;、#、=、前后空格这些字符在值中的表现是否符合预期。不要轻信文档，直接将库的解析规则写进测试用例里。

目前我用 inih 时，会提前约定配置值里不出现分号和井号，如果确实需要，就用 URL 编码或自定义转义符；而用 SimpleIni 时，它默认不做行内注释解析，所以值里的分号是安全的。每换一种解析库，都要重新确认一遍。

6.3 系统 API 的 65535 字节限制

GetPrivateProfileString有一个让我猝不及防的限制：如果写入的单个值超过 65535 字节，该函数会失败，WritePrivateProfileStringA则根本不能写入这么长的值。我最早给监控工具加“历史通知消息”功能时，把一大段 JSON 塞进了 INI 的某个键里，结果写入接口直接返回 FALSE，折腾半天才查出来。

从那以后，凡是超过几 KB 的数据我从不放 INI，只放小键值对。需要存储较大数据（比如日志、缓存、历史记录）时，就另建一个单独的数据文件，INI 里只保存该数据文件的路径和元信息。这也符合 INI 作为“轻量配置载体”的定位。

6.4 相对路径和反斜杠的依赖

早期的时候我把监控目录配置写成相对路径.\target_folder，结果程序从不同工作目录启动时，读取到的路径不一致，行为变得特别诡异。后来规定：INI 中的路径字段必须保存绝对路径，程序启动时先GetCurrentDirectory或者以可执行文件路径为基准转成绝对路径再写入配置。

还有一个相关细节是路径分隔符。在 Windows 上读写 INI 时，内部用\分隔路径没问题，但是如果这配置文件要导出给其他系统使用，反斜杠可能无法被对方解析。统一使用双反斜杠会让文件在 Windows 的记事本里看起来别扭，所以如果是跨平台工具，建议使用正斜杠/，Windows 的 API 基本都兼容正斜杠路径。比如C:/data/target在很多场景下都能正常工作，而且无需转义。

6.5 多线程并发写入导致配置丢失

当你的程序里有多个线程同时修改配置，或者用户开着配置窗口同时程序又在自动保存配置时，两个线程同时WritePrivateProfileStringA到同一个文件，可能出现互相覆盖、配置丢失的诡异情况。INI 解析简单，但没有内置并发控制。

我的解决方案是给所有配置写入操作加一个全局互斥锁，并且只在程序退出或者用户显式点击“保存”时才写文件。同时应用“先写临时文件、再替换原文件”的策略：先把新内容写到settings.ini.tmp，写完关闭流后，再通过MoveFile/rename覆盖原文件。这样即使某个写入中途崩溃，原文件也不至于被截断成半份。

7. INI 之外的自然延伸：何时升级到 JSON / XML / 注册表

虽然我在很多场景下力挺 INI，但它确实有天花板。了解什么时候该替换，也是实践的一部分。

如果你发现配置文件里出现了下述信号，就该考虑升级到更复杂的格式了：

• 配置项开始有嵌套结构：比如用户界面里要保存“最近打开的 10 个文件列表”，每个文件还有时间戳和目录标签，INI 只能靠recent.1.path、recent.1.time这样的命名勉强模拟，维护起来很痛苦；
• 配置项数量超过一两百个：INI 文件会膨胀得难以人工维护，查找和修改不如树状结构高效；
• 需要强类型校验和 Schema 校验：比如 JSON Schema 或 XSD，能在加载配置时直接发现类型错误；
• 需要程序生成、备份、版本化管理配置：JSON 和 YAML 在开发工具链里有更多现成支持；
• 配置需要多语言、多用户、多层继承时：注册表和 XML 配置体系更成熟。

以我个人的选型标准，可以这样简单判断：跨平台项目优先 JSON；Windows-only 项目但配置量少用 INI；配置量多且需要系统集成用注册表；团队需要共享和注释时用 YAML 或 XML。没有标准答案，只有权衡。

8. 最后分享几点个人经验

如果你也是要从零开始给项目接入 INI 文件操作，我建议按这个顺序来：

1. 先确认运行环境是否纯 Windows。是，则优先用 Win32 API，因为零依赖最稳。
2. 需要跨平台，直接引入 inih 或 SimpleIni，不要自己重复造轮子。
3. 不管用哪种，先把默认值、边界值、中文编码、特殊字符处理写进单元测试。
4. 配置文件路径尽量放在程序目录或用户目录下，避免权限问题。Windows 下C:\Program Files目录的写权限经常导致配置保存失败，建议放到%APPDATA%\你的程序名下，或者干脆做成绿色版放同目录。
5. 写一个独立配置类管理所有读写，别把配置逻辑散落在各处。

我自己在后续项目中，把 INI 继续用在一个跨平台命令行工具的参数持久化上。这些工具往往只有一个配置文件，但每个参数都涉及默认值和提示信息，用 INI 的节来分组、用键值对存储、用返回值做兜底，效果非常好。写配置文件的代码量很少，运行时开销更是可以忽略不计。这也是我现在仍然愿意在合适的场景里选择它的原因。