一个备份需求往往出现在最不方便的时候：手机准备重置、设备要换、误改了一条路由规则想让配置回到从前。此时需要的不是“大概记得怎么设置”，而是能落地的文件与可回看的日志。围绕 Hey 日志与备份导出，本文按“先看清导出什么，再谈恢复前后，最后处理分享与无法恢复的情况”的顺序展开。
Hey 日志页面说明：先知道日志能提供什么
Hey 的日志页面用于呈现应用运行过程中产生的记录，帮助定位问题发生在哪一层：是隧道建立、规则匹配、分应用分流，还是外部入口调用。日志的价值在于顺序与上下文，单条记录通常不足以说明问题，连续多条的先后关系才是关键。
日志阅读的基本方法
- 先确定时间范围，把无关时段排除，缩小到出现问题的那一段。
- 按从上到下的顺序读，先看第一条异常，再看后续连锁反应。
- 记录涉及的页面与操作：是编辑路由规则、导入配置，还是切换分应用隧道模式。
- 把日志内容与当前配置对照，判断是配置本身的问题还是运行环境的问题。
需要明确的是，日志反映的是已经发生的动作，不预测结果。它不能替代配置备份，也不能把错误配置变成正确配置。日志与备份是两件事：日志用于回溯，备份用于还原。
把日志当成“事后记录”，把备份当成“事前保险”。两者都做，才有回退空间。
Hey 配置备份导出：实际能导出的三类内容
Hey 支持导出的内容有三类，边界清晰，用途不同。
一、节点分享链接
节点分享链接是把节点信息编码成可传递的文本形式。它便于在设备之间搬运单个节点，也便于把节点交给其他人使用。导出后得到的是一段链接文本，可以复制、粘贴或通过系统分享发送。
二、路由规则 JSON
路由规则 JSON 描述规则的匹配条件与动作。应用内包含路由规则编辑页面，也提供导入与导出入口。导出这份 JSON 的意义在于：规则是配置中最容易被改坏、也最难凭记忆复原的部分。把它单独导出保存，恢复时可以只回滚规则，不影响其他设置。
三、本地备份 JSON
本地备份 JSON 是范围更大的整体备份，用于把当前配置保存成文件。它与路由规则 JSON 的区别在于覆盖范围：前者面向整体，后者面向规则。日常建议两份都留，整体备份用于换机与重置，规则备份用于局部回滚。
导出时需要注意的事实
- 应用不内置服务器地址、配置源地址、规则集或地区预设。导出文件里不会包含这些内容，导入后也不会有“默认配置”被自动补上。
- 仓库仅提供源代码，不提供预编译安装包。获取应用的方式与备份文件无关，备份文件只对已安装并可运行的应用有意义。
- 应用面向 HarmonyOS NEXT。备份文件的适用环境以此为准，跨平台搬运不具备可预期性。
恢复前后：顺序决定成败
恢复不是“导入就完事”。导入之前与导入之后各有一组动作，顺序错了会白费一次备份。
恢复之前
- 先导出当前配置，哪怕它已经出问题。保留现场，才能在回滚失败时继续排查。
- 确认要导入的是哪一份文件：整体备份还是规则 JSON。两者用途不同，不要混用。
- 把文件放在应用可访问的位置，避免导入过程中因路径不可读而中断。
- 记录当前的关键设置，尤其是分应用隧道的模式与包名列表。导入未必覆盖全部项目。
恢复之后
- 打开路由规则编辑页面，逐条确认规则是否按预期出现，顺序是否变化。
- 检查分应用隧道页面：隧道/直出模式是否符合预期，持久化包名列表是否完整。
- 回到日志页面，观察导入后的运行记录，确认没有新的异常连续出现。
- 若结果不符，先保留日志，再用恢复之前导出的那份文件回退。
恢复的正确姿势是“双向留底”：导入前留一份现状，导入后留一份日志。
分享风险：链接一旦发出就不受控
节点分享链接的本质是可传递的凭据性文本。它便于协作，也意味着一旦发出，接收方可以继续转发，发送方无法收回。分享前应做三件事。
- 明确分享对象与用途，只发送必要的那一条，不整批转发。
- 避免在公开场合粘贴，包括群聊、论坛与截图。截图同样会泄露完整链接。
- 分享后如不再需要该节点对外可用，应及时在节点详情编辑页面调整节点信息，使旧链接失去意义。
节点详情编辑页面是处理这类问题的入口：节点名称、连接参数等内容在此维护。修改后重新导出，旧链接不应继续沿用。分享与备份要分开看待：备份文件用于自己恢复，分享链接用于他人使用，两者的保管要求不同。
分应用隧道设置整理：先定模式，再定名单
分应用隧道相关页面用于控制哪些应用走隧道、哪些直出。它支持隧道与直出两种模式，并维护一份持久化的包名列表。整理这部分设置时，按以下顺序推进。
第一步：确定模式
先决定默认行为是“全部走隧道再挑出直出”还是“全部直出再挑出走隧道”。模式决定名单的含义，颠倒顺序会让同一份名单产生完全相反的效果。
第二步：整理包名列表
- 只保留确实需要区别对待的应用，名单越长越难维护。
- 包名要与应用实际标识一致，凭应用显示名称猜测容易出错。
- 列表是持久化的，改动会被保存；改动前先做一次整体备份。
- 应用更新后包名可能变化，定期回看名单。
第三步：与路由规则配合
分应用隧道决定“哪个应用走哪条路”，路由规则决定“流量匹配到什么动作”。两者叠加时，先确认分流结果，再看规则命中情况，否则容易把分流问题误判为规则问题。
外部入口：先展示，再确认
Hey 的外部深链、系统分享与扫码入口有一个共同行为：会先展示目标内容，等待用户确认后才继续。这个设计的意义在于把“被动接受配置”变成“主动确认配置”。
- 从深链打开时，先看清目标指向的是节点、规则还是其他内容。
- 通过系统分享导入时，确认来源与内容，再决定是否接受。
- 扫码得到的内容同样先展示，确认后再落地。
这条机制值得在备份与恢复流程中利用：不确定的配置先让它展示，确认无误再接受，比事后回滚成本低。
无法恢复时的记录方式
有些情况确实无法靠备份恢复：备份文件损坏、文件被覆盖、误删且无副本、或改动发生在导出之前。此时的目标从“还原”转为“重建”，记录方式决定重建效率。
建立一个最小的记录集
- 日志片段：截取问题发生时段的连续记录，标注对应的操作。
- 规则清单：把路由规则编辑页面中的规则按顺序抄录或截图，注明每条规则的作用。
- 分应用设置：记录当前模式与包名列表，注明每项为何这样设置。
- 节点信息：记录节点在详情编辑页面中的关键字段，便于重新建立。
- 时间线与现象：按顺序写下做了什么、看到什么，不写推测。
重建时的顺序
- 先恢复节点，再恢复规则，最后处理分应用隧道。前者是基础，后者依赖前者的结果。
- 每完成一步就查看日志，确认没有新增异常，再进入下一步。
- 全部完成后立即导出整体备份与规则 JSON，把这次重建的结果固化下来。
无法恢复时，最值钱的不是记忆，而是当时留下的日志与清单。记录得越具体，重建越快。
把流程固定下来
Hey 日志与备份导出的核心是三个动作的循环：改动前导出，改动后看日志，分享前想清楚。节点分享链接面向传递，路由规则 JSON 面向局部回滚，本地备份 JSON 面向整体还原；三者各司其职。节点详情编辑页面负责节点信息的维护，分应用隧道页面负责模式与包名列表的持久化，路由规则编辑与导入导出页面负责规则的落地。外部入口先展示再确认，为这套流程提供了一道低成本的前置检查。应用不内置服务器地址、配置源地址、规则集或地区预设，因此备份文件的价值完全取决于使用者是否认真导出并妥善保存。仓库仅提供源代码，不提供预编译安装包，应用面向 HarmonyOS NEXT，这些事实决定了备份与恢复只能在既有环境中闭环完成。
下一步：打开日志页面确认记录正常产生，随即导出一次本地备份 JSON 与路由规则 JSON，把文件放到与设备分离的位置。
