多份配置并存时，怎样知道现在到底在用谁

工作、学习和临时测试各保存一份配置后，最常见的问题不是没有选择，而是忘了当前运行的是哪一份。配置名称、节点选择和本地修改可能分别保存，切换其中一项并不一定改变其他项。要让多配置真正有用，需要给每份配置安排清楚的用途和验证方法。

名称应表达用途而不是私人信息

可以用服务简称、设备用途或维护来源命名，避免出现账户密码、完整订阅或敏感项目名称。为正在测试的配置加上容易辨认的标记，不要让它与日常配置只差一个数字。名称只是帮助识别，不能证明配置已加载，因此还要查看客户端当前活动状态。

保存一份配置、选择它、让内核成功加载它，可能是不同步骤。若加载失败，客户端可能保留旧状态；也可能需要用户明确重载。按当前软件的流程查看错误与运行状态，不能只根据列表中高亮的名称判断全部变更已经生效。发生异常时先确认运行对象，再修改内容。

某些客户端会保存代理组选择或其他本地状态，切换配置后这些状态如何处理，应以实现说明为准。新配置可能没有旧组名称，也可能含同名但用途不同的组。切换后应检查关键组的最终出口，不能假设相同标签意味着相同节点，更不能把之前选择过的地区当作当前连接证明。

如果存在全局覆写、配置专属扩展或外部规则文件，应分别记录它们影响哪些配置。一个针对测试环境的本地规则，若被应用到日常配置，可能改变意料之外的请求。检查时看合并后的运行结果，而不只看远程订阅原文。不要通过复制整份配置制造很多难以同步的副本。

先结束支付、上传、会议或远程操作，再切换配置并发起新的普通请求。记录活动配置、模式、关键代理组和接管方式，验证代表性任务。假设切换后访问失败，先退回已知可用配置确认基础环境，再检查新配置的加载与分流；不要在同一次尝试中连续更换网络和客户端。

清理前确认是否仍被快捷方式、自动更新或其他设备引用，并保留必要私有备份。对长期不用的配置，记录其用途比无限保留多个“最终版”更清楚。最后应能快速回答：日常用哪份、测试用哪份、哪些修改共享、失败时退回哪里。多配置的价值是明确分工，而不是增加无法辨认的选项。