2026年iStoreOS与OpenWrt升级回滚完全指南：保留配置到底能不能勾，哪些东西一定会丢

「升级固件的时候那个『保留配置』要不要勾？」——这个问题在软路由群里每周都有人问，答案却很少有人说清。因为它其实不是一个是非题：「保留配置」这四个字在不同固件里保留的东西根本不是一回事，OpenWrt 原生 sysupgrade 保留的是一部分配置文件，而 iStoreOS 的「保留配置」把你装过的插件也一起留下来。同一个勾选框，两种完全不同的行为。

更麻烦的是，2026 年的 iStoreOS 走到了一个大版本换包管理器的节点，官方直接把「跨版本保留配置升级」这条路封掉了。所以我们不打算只给一句「建议备份」，而要把三件事讲透：源码层面保留配置到底打包了哪些文件、五种版本边界分别该不该勾、勾错之后怎么用最小代价退回去。顺带说一句，升级失败的真正代价往往不是固件本身，而是你在升级那半小时里没有第二条能出网的路——所以升级前先确认手机热点能开、或者手里有一份能直接用的订阅（比如瑶瑶领先这类入门档 ¥9.9/384GB 的，够撑完整个升级和回滚过程），比任何技巧都实在。

一、先把「保留配置」拆成三件事：配置、软件包、数据

绝大多数「升级后怎么变这样了」的事故，根源是把三件不相干的东西当成了一件：

你要保住的东西	实际存在哪	「保留配置」管不管
配置	/etc/config 下的 UCI 文件、插件自己的配置目录	管，但只保留「你改过的」那一部分，不是整个 /etc
软件包	/usr、/lib 里被包管理器接管的那部分文件	OpenWrt 原生不管；iStoreOS 因为 overlay 独立分区，会一起保留
数据	/mnt 下挂载的硬盘、U 盘、NAS 共享	不管，但「不保留配置」时的整盘写入有可能波及分区表

这三行的差别决定了一切。你勾了保留配置，以为「插件还在」，在纯 OpenWrt 上会发现插件全没了、但插件的配置文件还在原地——重新装上插件，配置自动回来了；而在 iStoreOS 上勾了保留配置，插件和配置都还在，但可能因为新固件换了内核、换了包管理器，这些「留下来的插件」反而成了升级失败的元凶。

记住一句话作为后面所有判断的锚点：保留配置保的是「文本」，不是「二进制」。而 iStoreOS 是个例外，它把二进制也保了。

二、OpenWrt 原生 sysupgrade 保留的到底是什么

OpenWrt 官方文档站这几天正好在维护（文档站返回 503），所以下面所有结论都直接来自源码，不走二手教程。核对对象是 openwrt/openwrt 的 openwrt-25.12 分支，两个文件：package/base-files/files/sbin/sysupgrade 和 package/base-files/files/lib/upgrade/keep.d/base-files-essential，核对日期 2026-10-22。你可以在自己机器上用 ls /lib/upgrade/keep.d/ 对照，内容一致就说明版本语义相同。

2.1 keep.d 白名单只有 10 个文件

「保留配置」时最优先被保住的是 /lib/upgrade/keep.d/* 里列出的路径。base-files 这个包只提供了一个文件，里面正好 10 条：

/etc/hosts
/etc/inittab
/etc/group
/etc/passwd
/etc/profile
/etc/shadow
/etc/shells
/etc/shinit
/etc/sysctl.conf
/etc/rc.local

看出来了吗：这 10 个是「系统能不能启动、root 还能不能登录」的地基，不含任何 /etc/config 下的业务配置。而 /etc/sysupgrade.conf 出厂状态只有三行注释，没有任何生效条目。所以「保留配置 = 把 /etc 整个搬过去」这个理解从一开始就是错的——第三方固件（比如 iStoreOS、ImmortalWrt）之所以感觉「保得更多」，是因为它们的 keep.d 目录更厚，而且下面 2.2 的机制会额外捞一批文件。

2.2 只有「你改过」的配置文件才进备份

sysupgrade 的备份清单由两部分拼起来：list_static_conffiles（就是上面那些白名单）加上 list_changed_conffiles。后者的逻辑很朴素：从包管理器的数据库里读出每个包的 conffile 和它安装时的校验和，逐个重新算一遍，对不上就是「你改过」，进备份；对得上说明还是默认值，没必要备份，新固件自己会带一份。

# sbin/sysupgrade 里的核心判断（节选）
list_conffiles | while read file csum; do
    [ -r "$file" ] || continue
    echo "${csum}  ${file}" | busybox sha256sum -sc - || echo "$file"
done

这条机制解释了一堆玄学问题：为什么你手动 vi 改过的配置文件升级后还在、而某个插件的默认配置被重置了；为什么两个人都勾了保留配置，一个人丢了设置一个人没丢。备份清单是按你本机的修改痕迹算出来的，不是固定清单，所以你机器上到底是什么，只有跑一次 sysupgrade -l 才知道。

2.3 已装软件包默认不保留

这一点最容易踩。备份归档（/tmp/sysupgrade.tgz）里只有文件列表，没有「重新安装这些包」的动作。想让新系统知道「原来装过哪些包」，得额外加 -k 参数，它只是把 opkg list-installed 的结果写进备份文件里当一张纸条，安装仍然要你自己来。-u 则更省空间：和 /rom 里一模一样的文件直接跳过，只打包真正变过的。

2.4 各个开关分别改变什么

LuCI 里那个勾选框，在命令行上等价于「有没有 -n」。但命令行还给了你更细的颗粒度，这也是排查问题的关键：

参数	它做的事	什么时候用
（默认，对应勾选保留）	白名单 + 改过的配置文件进备份	同大版本补丁升级
`-c`	把 /etc 下所有改过的文件都保住（不止包声明的 conffile）	你手写过 /etc 下的自建脚本、证书
`-o`	把根目录下所有改过的文件都保住（包自带的除外）	改过 /usr/lib 下别人的脚本，极少用
`-n`	不保配置，全新装一遍	跨大版本、跨发行版、配置已经乱了
`-u`	和 /rom 相同的文件不进备份	备份文件太大、flash 快满了
`-k`	把已装包清单写进备份	你打算升级完照着单子重装
`-p`	刷完不恢复分区表	分区布局是你自己改过的
`-F`	镜像校验失败也硬刷	几乎没有正当理由，别用

另外 -b / -r / -l 是备份 / 恢复 / 预览清单，不刷固件。它们和升级是两条独立的路：先 -b 出一份 tar.gz，升级出任何问题都能用 -r 盖回去。这个动作十秒钟，能省掉后面两小时。

三、iStoreOS 的差异：为什么它的「保留配置」连软件包一起保留

这是本文最值得记住的一节，因为绝大部分「为什么我的情况和网上教程不一样」都出在这里。

3.1 overlay 被从 ROM 分区里拆了出来

iStoreOS 官方开发者文档写得很清楚：它把 Overlay 从 ROM（Squashfs）分区里分离出来，所以比常规 OpenWrt 多一个独立分区；这个改动就是用来支持「固件升级时保留用户安装的软件」以及沙箱模式。Overlay 分区不需要预先格式化，只要在分区开头写入 RESET，第一次启动时会自动格式化。

而目标板的升级脚本（target/linux/*/base-files/lib/upgrade/platform.sh）相应地在保留配置升级时跳过 Overlay 分区。x86 的 platform.sh 开头那行注释写得更直白：1. keep overlay partition when upgrade。

3.2 升级时到底写了哪几个分区

把 x86 的 platform_do_upgrade 拆开看，逻辑是这样的（节选，变量名保留原文）：

if [ -n "$UPGRADE_BACKUP" ]; then
    diff=                      # 有备份 = 保留配置，跳过分区表比较
else
    diff="$(grep -F -x -v -f /tmp/partmap.bootdisk /tmp/partmap.image)"
fi
...
while read part start size; do
    if [ -n "$UPGRADE_BACKUP" -a "$part" -ge 3 ]; then
        v "Skip partition $part >= 3 when upgrading"
        continue
    fi
    if [ "$part" -eq 3 ]; then
        echo "RESET000" | dd of="/dev/$partdev" bs=512 count=1
    fi
done < /tmp/partmap.image

翻成白话就是三条：

勾了保留配置：只写 boot 和 ROM 分区，part >= 3 的 Overlay 分区直接跳过——所以插件、pip 装的库、Docker 镜像全在。
没勾保留配置：往 3 号分区头部写 RESET000，下次启动自动格式化，overlay 清空。
分区表和镜像对不上（比如你以前手动扩过分区，或者从别的发行版刷过来）：diff 非空，走整盘写入 get_image_dd ... of=/dev/diskdev，整块盘连同分区表一起重写。

第三条必须单独提醒：整盘写入会按镜像里的分区表重建磁盘，如果你的数据盘分区不在新表里，它可能就没了。升级前把挂载的硬盘拔掉，或者至少确认数据有别的副本——这一步比备份配置重要得多，因为配置丢了能重配，硬盘分区表被重写就只能上恢复工具了。

3.3 升级后第一次启动做了什么

保留 overlay 会带来副作用：overlayfs 的 origin 标记在新系统里失效、新固件的软件包版本变了导致包管理器报错。iStoreOS 的修法是在升级后首次启动时跑一个补丁脚本（/etc/init.d/isos_upgrade），它做三件事：重建包管理器状态（把 ROM 里的包清单和 overlay 里的合并，内核包以 ROM 为准）、清掉已经失效的 LuCI 主题、把软件源地址换成新固件对应的 releases 路径。

# /etc/init.d/isos_upgrade 的 boot() 节选
if [ -f /usr/lib/opkg/.upgrading ]; then
    rm -f /usr/lib/opkg/.upgrading
    is_overlayed /usr/lib/opkg/status && { split_both_status; rebuild_opkg_status > /usr/lib/opkg/status; }
    is_overlayed /etc/opkg/distfeeds.conf && { upgrade_opkg_distfeeds; }
fi

这解释了一个常见现象：升级后 opkg update 报一堆 404、或者某些包「明明装了却显示没装」，通常不是固件坏了，是这个补丁没跑完或被打断。等它跑完（首次启动会明显慢一点）再判断。

四、能不能勾：五种版本边界一张表

把前面两节的机制合起来，判断只需要问两个问题：跨的是一条什么边界、这条边界上被换掉的是配置格式还是运行环境。

你正在跨的边界	能不能勾保留配置	判断依据
同一大版本的补丁升级（例如 24.10.7 → 24.10.8）	✅ 可以	包管理器、内核 ABI、插件依赖都没动，overlay 里的东西仍然可用
跨大版本（21.02 / 22.03 → 24.10）	⚠️ 官方不建议	内核、库、插件依赖全换代，旧配置项可能已改名或废弃
跨大版本且换了包管理器（24.10 → 25.12）	❌ 官方明确不支持	opkg 换成 apk，已装软件包无法迁移，见第五节
跨发行版（OpenWrt ↔ iStoreOS ↔ ImmortalWrt）	❌ 不要	分区布局、包仓库、默认配置体系都不同，属于「换系统」不是「升级」
同版本但引导方式变了（EFI ↔ legacy）	刷不进去	platform_check_image 会直接拒绝，见下

最后一行值得单独说：x86 的 platform_check_image 会先判断当前磁盘是不是 EFI 分区，再判断镜像是不是 EFI 镜像，两者不一致就返回失败并打印「Flashing a non EFI image to EFI system!」或反向的提示。也就是说 UEFI / legacy 不匹配时，正常流程根本刷不进去——如果你看到一个「刷完起不来」的案例，要么是强行 -F 刷了，要么是绕过了 Web 界面用 dd 直接写盘。

跨大版本时最容易被低估的成本不是刷机那十分钟，而是「重装一遍插件栈」：代理插件、规则集、DNS 分流、可能的 Docker。如果你不想每换一次大版本就把这套东西重搭一遍，那么把「出口」这件事和「软路由固件」解耦是更稳的做法——固件只负责分流和转发，真正出网的那一段交给机场订阅，换固件时只要把订阅粘回去。SS-ID 这类官方明确支持 OpenWrt（含梅林）的纯 IEPL 机场，优势就在这里：标准订阅链接，重装插件后粘一次就好，不用跟着固件版本折腾客户端。站内这套「订阅与固件的生命周期分开管理」的思路，在机场订阅链接应急手册里还有更细的分层处理。

五、25.12 这一关：包管理器换了，官方直接说不支持

iStoreOS 在 2026-09-11 发布了 25.12.5，维护者在公告里写得很直接，这里原文照录关键三句（后两句是我按原文意思转述，避免断章取义）：

「OpenWRT 版本升级到 25.12.5。」
「由于 25.12 切换了包管理器（opkg → apk），不支持从 24.10 保留配置升级（因为 iStoreOS 的保留配置升级实际上也保留软件包）。」
因为这条限制，25.12 的更新通知不会推送给老版本（含 24.10），老版本只能手动升级。

这段话说清了前面所有机制的最终后果：正因为 iStoreOS 的「保留配置」连软件包一起留，而 25.12 换了包管理器，留下来的那批包在新系统里根本没有对应的数据库条目——所以官方干脆不支持，而不是「可能有问题，你自己试」。

同一份公告里给了两条正统路线，选哪条取决于你想保留什么：

路线	做什么	保留了什么	代价
A. 整包系统备份	iStore → 维护 → 系统备份，把当前系统（配置 + 已装软件包）完整备份到 U 盘	全部，但是只能同大版本恢复（24.10.8 的备份能恢复到 24.10.x，不能恢复到 25.12.x）	升级后回不去旧版本时，这份备份就只是「同版本内的后悔药」
B. 真·仅保留配置	① 在 iStore 维护页下载「已安装列表」→ ② 在 24.10 后台「系统 → 备份与更新」备份配置文件 → ③ 恢复出厂设置（这一步是为了把软件包清掉，只留配置；恢复后不要再装任何软件）→ ④ 保留配置升级到 25.12	只有配置，软件全丢	自己装的软件都要重装；从 iStore 装的可按「已安装列表」一键恢复，手动装的不行

路线 B 反直觉的地方在第三步：要先「恢复出厂设置」把包清干净，再保留配置升级。因为只有 overlay 里干净了，升级后的包状态才不会被旧包污染。顺序反了（先升级再恢复出厂）就等于什么都没留住。

公告还专门点了 nginx 用户：恢复备份以后可能没有 Web 服务、后台打不开。这时可以走 7681 端口的 ttyd 终端（形如 http://istoreos.lan:7681/），登录后执行 /etc/init.d/uhttpd start 临时起一个 Web 服务进后台，再把 nginx 插件装回来。同一思路也适用于 25.12 升级完之后——先临时起 uhttpd，再装插件。

顺带把 25.12 的其他变化记一下，它们会影响你升级后的判断：内核从 6.6 升到 6.12；Docker 挪到「服务」菜单下的 Dockerman JS；x86 新增 i915-sriov 与 xe-sriov 驱动选项（两个都勾时 xe 生效，且 xe 默认不支持 HuC 固件，Jellyfin 转码相关的低功耗设置要关掉）。这些都不是配置迁移问题，是「新系统本来就长这样」，别误判成升级失败。

也正因为每次大版本都要重搭一遍环境，出口侧的东西越简单越好：软路由上只留订阅，出口属性交给机场。对做跨境多账号、需要稳定登录环境的人，这一点尤其关键——升级软路由不该导致你的出口 IP 归属跟着变。仙路湾这类提供原生 IP / 住宅 IP 档位的机场（¥9.9/50GB 原生、¥30/100GB 住宅起），价值就在「换设备、换固件都不换出口属性」，避免每次折腾软路由都换来一轮重新养账号。

六、升级前 15 分钟：按这个清单走

下面每一项都能在你自己的机器上复现，命令不依赖任何第三方工具。前提是先 SSH 上去（ssh root@192.168.1.1，iStoreOS 默认也是 root）。

#	检查项	命令	不合格怎么办
1	当前版本与目标版本	`cat /etc/openwrt_release`	确认跨的是不是大版本边界，回到第四节查表
2	overlay 剩余空间	`df -h /overlay`	不足 200MB 先清包或清日志，否则备份可能写不下
3	已装包数量（基线）	`opkg list-installed \| wc -l`	记下这个数字，升级后对比，就知道丢了几个
4	会被备份的文件清单	`sysupgrade -l`	关键配置不在清单里 → 把它加进 /etc/sysupgrade.conf
5	真的导出一次配置	`sysupgrade -b /tmp/cfg-$(date +%F).tar.gz`，然后把文件拉到电脑	只生成在路由上等于没备份，重启就没了
6	旧固件留在手里	把当前版本的 .img / .img.gz 存到电脑	没有旧固件 = 回滚只能靠 iStore 整包备份，见第七节
7	引导方式对不对	`[ -d /sys/firmware/efi ] && echo UEFI \|\| echo legacy`	和你要刷的镜像类型对不上就别刷
8	数据盘是否在挂载	`mount \| grep /mnt`	有就记下来，升级前拔掉或确认已有副本

第 5 项容易被偷懒跳过，但它是最划算的一步：备份文件只有几十 KB 到几 MB，而它能在「升级完发现全乱」时把配置一键盖回来。备份这件事本身有一套方法论（什么该备、备到哪、多久验一次），站内自建节点备份与迁移完全指南里讲的「三份副本 + 定期试恢复」同样适用于软路由。

如果你还没进过这套流程、甚至连固件和刷机的关系都没理清，建议先看软路由刷机完全指南——刷机（换系统）和升级（同系统换版本）是两件事，混着做最容易出事故，那篇里「factory 与 sysupgrade 不能混用」这一条，也正好解释为什么有人升级时会刷错文件。

七、回滚：四种「退回去」的代价完全不同

「回滚」这个词被用得太宽，实际上有四条完全不同的路，能退回的东西和前提都不一样。选错路，就是白折腾。

回滚方式	能退回什么	前提	实际代价
恢复配置备份（`sysupgrade -r` 或 LuCI 备份/恢复）	只回配置文件	同版本或同大版本；备份文件在手	几分钟，但插件不会被装回来
重刷上一版固件	系统回到旧版本	手里有旧 .img；引导方式一致	20–40 分钟，之后要么恢复配置、要么重配一遍
iStore 系统备份整包恢复	配置 + 已装软件包	只能同大版本	最快，十几分钟回到升级前状态
整盘镜像写回（x86 dd）	整机原样，连分区表一起	升级前做过盘级镜像	最彻底，但要求盘容量不变

关键在第二列和第三列的搭配上。举个最常见的错配：从 24.10 刷到 25.12 之后不满意，想做「iStore 系统备份整包恢复」退回 24.10——做不到，因为整包备份按大版本绑定，跨大版本恢复会带着 25.12 的包管理器状态一起炸。这时候唯一的路是第三条走不通就走第二条：刷回 24.10 固件，再 -r 恢复当时那份配置备份。也就是说，升级跨大版本时，「旧固件文件」和「配置备份」这俩必须同时留着，只留一个都回不去。

回滚完还有一件事：验证出口确实恢复成你期望的样子，而不是「能上网就算好了」。用 curl -s https://ifconfig.me/ip 看出口地址、ip route 看默认路由、在代理插件里刷新一次订阅看节点数是否回到升级前。跨境业务场景尤其要认真核这一步，因为位置或 IP 归属变了，账号风控会立刻感知到——站内软路由科学上网故障排查完全指南里的分层排查顺序（先出口、再分流、最后插件）在这里可以直接套用。

如果不幸刷到一半断电、连 LuCI 都进不去，那就不是回滚问题了，是救砖问题：能进 Breed / U-Boot 的重刷固件，x86 用 U 盘重新引导写盘，具体程度分级和对应救法在上面提到的刷机篇里已有完整流程，这里不重复。

八、升级后必须复验的五项

升级完能打开后台，只说明「系统起来了」，不说明「你的网络还是原来那个网络」。按这个顺序复验，五分钟能定位 90% 的问题：

后台自身能不能进。用 nginx 的机器在恢复备份后可能没有 Web 服务，走 7681 端口的 ttyd 执行 /etc/init.d/uhttpd start 临时救一下，再装回 nginx 插件。
包数量对不对。opkg list-installed | wc -l（25.12 系换成了 apk，对应 apk list --installed），和升级前记下的基线数字比，差多少心里有数。
插件配置还在不在。保留配置升级后，配置文件通常还在原地，但插件本体若没保留（原生 OpenWrt 就是这种情况），表现为「菜单没了但配置还在」——重装插件即可自动读回配置。
订阅还能不能更新。在插件里手动更新一次订阅，看节点数量是否正常。升级后节点列表变空，八成是订阅链接里的 UA 或域名指纹变了，或者 DNS 解析还没恢复。
DNS 与 IPv6 的行为。新版本对 dhcpv6 选项做过调整，二级路由场景下 IPv6 前缀获取行为可能和旧版不同；SmartDNS 这类插件在部分版本上「勾选与取消都显示运行中」，属于版本自身问题，不是你的配置错。

第 4、5 项是最容易被误判成「升级失败」的。它们的共同点是：系统没问题，是你的网络参数在新版本里换了默认值。判断方法很简单——把插件停掉，用软路由本身直连出网（curl -s https://ifconfig.me/ip）能不能通；能通就说明固件和物理链路都正常，问题在插件或订阅层。这一层怎么逐段定位，站内软路由首次配置清单里那 8 步顺序可以直接当复验顺序用：拨号 → 网段 → DHCP → DNS → IPv6 → 时间 → SSH → 备份。

九、常见问题

Q1：勾了保留配置，为什么插件菜单不见了，但配置还在？

因为「保留配置保文本不保二进制」。在原生 OpenWrt 上，插件本体属于软件包，升级后不会自动装回；但它的配置文件被你改过、进了备份，所以文件还在。重新 opkg install 装上，配置自动生效。iStoreOS 因为 overlay 独立分区，通常不会出现这个现象。

Q2：不勾保留配置，会不会把我挂在 /mnt 的硬盘也清掉？

正常情况不会，因为清的是 overlay 分区（3 号），数据盘不在里面。但要注意一个例外：如果镜像的分区表和当前磁盘对不上，走的是整盘写入，分区表会被重写，数据盘分区可能消失。所以升级前 mount | grep /mnt 看一眼，有数据盘就拔掉或先备份。

Q3：从 25.12 还能退回 24.10 吗？

能，但要按「刷旧固件 + 恢复配置备份」这条路走，不能靠 iStore 整包备份（它只支持同大版本恢复到同一大版本）。而且旧固件文件必须是你升级前就留好的，官方不提供「降级包」这种说法。

Q4：家里只有一台软路由，升级失败全家断网，怎么降低风险？

三个动作：① 挑家人不用网的时间段升级；② 升级期间用手机热点顶上；③ 手里留一份能在手机或电脑上直接用的订阅，这样即使软路由完全趴了，你至少还能查资料、下载固件。第三条常被忽略，但它决定了你是「十分钟修好」还是「断网两小时边查边修」。

Q5：iStore 的「系统备份」和 OpenWrt 的「备份配置」有什么区别？

前者是整包（配置 + 已安装软件包），文件大、按大版本绑定；后者是 sysupgrade -b 生成的配置文件归档（几十 KB 到几 MB），跨版本也能用，但插件要自己重装。两个都做，成本很低，作用完全不同。

Q6：在线升级按钮点了没反应 / 检查不到更新？

两个常见原因：部分设备本来就不支持在线升级（官方教程里明确写了）；以及 25.12 之后官方不会把更新推送给 24.10 老版本，必须手动下载固件、走「系统 → 备份与升级 → 刷写固件」。

Q7：升级后 `opkg update` 一堆 404？

软件源地址还指向旧版本的 releases 路径。iStoreOS 的 isos_upgrade 补丁会在首次启动时替换 distfeeds，但如果那次启动被打断，就得手动改回新版本的源，或者干脆重刷一次让它跑完。

Q8：双固件设备上的 `-s` 是干什么的？

「stay on current partition」，刷到分区表里指定的那个分区而不切换。只有双固件（A/B）设备才有意义，普通 x86 软路由不用管这个参数。

Q9：升级过程中能断电吗？

不能。刷写阶段由 RAM 里的临时系统接管（stage2 会 pivot 到 ramfs），任何中断都可能留下半写状态。这也是为什么升级必须接 UPS 或至少确认供电稳定——软路由通常和光猫、交换机插在同一个排插上，家里人一拔插头就是事故。

Q10：跨大版本又想少重配，有没有折中方案？

有，就是第五节那条「真·仅保留配置」路线：先下载已安装列表 → 备份配置 → 恢复出厂清包 → 再保留配置升级。配置全保住，软件按单子重装。它比「硬勾保留配置」多花二十分钟，但成功率完全是两个级别。

十、一页纸决策流程

把全文压成一张判断流程，升级前照着走一遍就行：

先看版本号（cat /etc/openwrt_release）。同大版本补丁升级 → 勾。
跨大版本？先查这一版有没有换包管理器或内核大版本。换了（如 24.10 → 25.12）→ 绝对不勾，走官方两条路线之一。
没换包管理器但跨大版本（21.02/22.03 → 24.10）→ 不勾，或用「仅保留配置」的迂回法；先把插件清单存下来。
跨发行版（OpenWrt ↔ iStoreOS）→ 当换系统处理：备份配置、不勾、刷完重配。
不管哪种情况，先做三件事：sysupgrade -b 导出配置、把旧固件存到电脑、确认引导方式匹配。
刷完按第八节五项复验，任何一项不对先判断是「系统问题」还是「插件/订阅问题」，再决定要不要回滚。

最后补一句判断标准：如果你为了省二十分钟而勾了不该勾的保留配置，代价通常是花两小时排查一个「看起来像插件坏了、其实是版本边界」的问题。反过来，如果你老老实实不勾、重配一遍，得到的是一个干净的、你知道每一层是什么状态的环境——对天天靠这条线吃饭的人来说，后者才是省时间。