配置越来越长以后，最难的往往不是添加一个字段，而是想起当初为什么加它。尤其是订阅、规则集和个人覆写来自不同地方时，没人能仅靠文件名恢复全部背景。
先记录来源和边界
写下客户端与内核版本、订阅来自哪里、规则集处理什么内容，以及哪些字段由本地覆写管理。记录来源不需要抄下完整账户链接，可以保存服务商名称与获取路径，把实际凭据放在受控位置。
每条个人特例最好有一个简短原因，例如“本地存储管理页使用直连”。不要只写“优化”。当原来的问题已消失或业务域名变更时，明确的原因能帮助你判断是否仍应保留。
一次只改变一个行为
准备修改 DNS 时，先固定节点与规则；准备调整规则时，先维持网络与解析设置。每次记录修改前的症状、修改项与验收方式，避免把一连串碰运气的操作保留成长期配置。
不要无目的地堆叠多个同类规则集。重叠越多，越难从一次命中推断配置目的。保留足够覆盖自己场景、又能解释顺序的规则，比追求文件行数更利于维护。
回退路径也属于配置的一部分
保存一份已知可用的配置与相应版本信息。新配置失败时，先退回最近的正常状态，而不是继续添加更多修补项。远程规则更新也可能影响行为，因此必要时记录当时加载的资源版本或更新时间。
每次客户端大版本升级后，重新做启动、订阅刷新与一条真实请求测试。能够重复得到结果，才说明维护流程可靠。配置的价值在于让你知道流量为什么这样走，而不是让文件看起来比别人更复杂。