结构化配置：改值，而不是改标点

为什么专用工具有时更简单

如果一个很大的配置文件里只需要修改 application.debug，直接指出逻辑路径，通常比搜索正确位置并小心维护逗号、括号或分隔符更明确。

多个格式，共用一种节奏

这些模块刻意保持相似语法：打开、读取键、搜索、用 : 写入、删除、用 -c 验证，或用 dump 输出序列化文本。打开后，$ 还可以代表活动文件。

INI：分区和简单值

INI 用分区组织键值对。点路径可以直接访问逻辑值，不必在整个文件里滚动寻找。

JSON：对象、数组和类型

在这个练习里，先用 code -n 打开 project/config/app.json，粘贴下面的 {} 初始内容并保存，然后再运行 json 命令。结构化编辑器需要先拿到有效的 JSON。

JSON 广泛用于 API、元数据和应用配置。按路径修改可以减少逗号或括号错误，-c 则提供显式验证。

{}

YAML、TOML、XML、conf 和 properties

YAML 依赖缩进，TOML 强调表与类型，XML 使用元素和属性，conf/properties 常见于键值配置。lil 让常用操作保持相似，但不会假装这些格式完全相同。

先验证；需要源码时再 `dump`

-c 验证文档，dump 返回序列化的源码表示。结构化写入可能规范化空白、顺序或注释；如果精确文本布局本身很重要，请用 edit 或 code。

什么时候回到 `code`

格式模块适合定点值、搜索和验证；注释、精确排版或高级格式特性很重要时，code 更合适。两者没有高低之分，只是在回答不同问题。

配置修改非常适合保存成脚本

一组已经验证过的配置动作，可以成为“能执行的文档”。到另一个项目时先读一遍，调整必要的值，再复现同样的环境。