配置与数据格式

这页是对原 常见的配置文件和数据交换格式 的压缩版，目标是保留选型判断，而不是把每种格式都讲成教程。

先想清用途

• 做配置文件：优先考虑人能不能直接看懂、改起来会不会出错、层级够不够表达。
• 做数据交换：优先考虑大小、解析成本、调试便利性和跨语言支持。
• 不要先问“哪个格式更高级”，先问“我要解决的是配置问题还是传输问题”。

常见选择

INI

• 优点：简单、直观、编辑门槛低。
• 缺点：层级能力弱，不适合复杂嵌套和数组。
• 适合：简单配置、桌面工具、小型程序参数。

XML

• 优点：层级强、表达能力足、属性和重复节点都能表示。
• 缺点：冗长，写起来和看起来都更重。
• 适合：结构复杂、需要明确层级和属性的配置或交换格式。

JSON

• 优点：现代生态最好，数组和对象都自然，跨语言支持强。
• 缺点：不适合写注释，人工维护大型配置时可读性一般。
• 适合：接口交换、前后端通信、通用配置。

二进制序列化

• 优点：小、快、适合带宽和性能敏感场景。
• 缺点：不直观，调试门槛高。
• 适合：高频通信、设备协议、明确版本管理的内部数据交换。

用 Boost.PropertyTree 时该记什么

• 它能把 INI、XML 这类树结构格式统一成相似的读写方式。
• put 更像“没有就建，有了就改”。
• add 更像“继续追加同名节点”，常用于表达重复项。
• 真正要小心的不是 API 本身，而是你设计出来的层级是否稳定、是否容易被误解。

实际判断规则

• 配置给人改：优先简单和直观。
• 数据给程序传：优先稳定和易解析。
• 结构一旦需要数组和嵌套，INI 往往就开始吃力。
• 当你已经在解释“这个文件虽然难看但是很灵活”时，通常说明该重新审视格式选型了。