第一道门是能不能解析文本

YAML 与 JSON 都用于表达结构化数据，但语法规则不同。缩进、括号、引号和逗号等细节，可能决定解析器能否读取内容。文件看起来像配置，并不能证明格式正确；改名也不会把一种格式自动变成另一种。遇到导入错误时，先保存原文件并阅读具体位置提示，不要在不理解结构的情况下大量删除符号，以免让问题变得更难恢复。

YAML 重点看层级关系

阅读 YAML 时，注意缩进表达的层级，以及列表项属于哪个字段。把一个配置片段粘贴到错误层级，即使词语都拼对，也可能改变含义。字符串中有特殊字符时，应遵循相应语法要求，不能仅按视觉排版理解。不同实现可能支持特定字段和写法，所以公开示例应与当前客户端说明对照，而不是把任何 YAML 文件都视为可互换的订阅。

JSON 重点看结构与类型

JSON 的对象、数组、字符串、数字和其他值有明确表示方式。括号配对、逗号位置与引号都需要正确，但语法通过仍只是第一步。例如一个字段期待数组，却得到字符串，业务校验仍可能失败。不要把所有数字都改成文本来追求表面一致，也不要随意复制某个字段到另一位置。理解值的类型，有助于读懂错误信息所指向的真正差异。

第二道门是字段是否被支持

不同客户端和内核可以采用不同配置结构，即使都使用 YAML 或 JSON，也未必理解同样的字段。版本变化也可能影响支持范围。检查时区分未知字段、缺少必填项和引用目标不存在等问题。格式转换通常只能处理它明确支持的内容，不能假设所有规则、策略与高级设置都会完整保留。敏感配置更不宜随意交给陌生的在线转换入口。

第三道门是运行时是否符合预期

导入成功后，查看软件真正启用的配置、节点、策略和规则。编辑磁盘上的文件，不一定等于运行中的配置已经重载；自动更新也可能覆盖部分手工更改。选择一个普通任务验证路径，并检查关键设置是否存在。不要用“没有报错”代替行为验收，因为程序可能忽略某些内容，或者当前任务根本没有经过你刚修改的部分。

让每次修改都能回到上一版

调整配置前保存受保护的副本，记录修改目标与最小差异。一次只解决一类问题：先语法，再结构，最后行为。求助时可提供去掉令牌和密码的片段，保留必要上下文，不必公开完整订阅。成功后将有效修改写进自己的维护说明，避免下一次更新又从头尝试。配置管理的目标不是制造越来越长的文件，而是让每项设置都有清楚用途。

延伸阅读：拿到订阅之后：做一次能验证结果的首次导入 · 换电脑之前，先做一次配置恢复演练。