漫阅+ 服务器重新扫描后：检查章节变化与旧书签定位

服务器整理文件后重新扫描，漫阅+ 里可能出现新章节、旧名称或看似重复的条目。处理时先弄清服务器改了什么，再检查应用看到的目录和实际页面。本篇以个人漫画服务器的维护场景为例，重点是确保旧书签与当前文件仍然对应；不会把一次刷新描述成能够自动修复所有身份变化的操作。

维护前留一份目录与位置快照

如果维护由自己安排，先记录目标作品的章节清单、当前卷号、正在读的位置与几个关键书签。截图只要包含必要的目录和作品信息，连接凭据不应出现在分享材料中。说明这次准备做的是补卷、文件改名、换封面还是替换正文，尽量把不同任务分批进行。已经开始维护才发现没有记录，也可以从自己的文件清单和旧笔记补充锚点，但要明确哪些信息是事后推断。先建立可比较的旧状态，才能判断扫描后究竟新增了什么。

先在服务器确认维护结果

文件操作完成后，先以实际阅读账号在服务器自己的界面查看目标作品，确认新目录与页面已经可见。服务器端的文件扫描、内容分析和资料刷新可能负责不同事情；例如 Komga 官方文档分别说明这些任务，不应把它们当成完全相同的按钮。按服务自身说明执行需要的维护，等待对应任务完成，再回到漫阅+。若服务器网页本身仍看不到新卷，应用刷新再多次也不能让尚未入库的文件凭空出现。先把服务器结果确认清楚，可以减少重复操作。

刷新应用列表并对照三项变化

在漫阅+ 对应连接中使用当前可见的刷新或重新加载入口，查看作品名、章节清单和封面三项。逐项对照刚才服务器里的结果，不要只看首页封面数量。旧封面可能还在缓存，而新章节已经可读；名称变了也不代表正文已经替换。若当前版本没有明确刷新按钮，按正常重新进入列表的方式检查，并记录可见状态。不要一上来删除整个连接重建，因为那会同时改变本地缓存与可能的条目身份，让维护前后很难对应。

打开新增与被替换的具体页面

选一章新增内容和一章原本存在的内容，分别打开开头、中段与结尾，确认不仅目录更新，页面请求也对应新结果。若替换了同名文件，要找一处已知改动的画面核对，而不是只看文件名称相同。修改封面与修改正文是不同任务，可能需要不同服务端处理；先依据服务器当前状态确定是哪一层没有更新。不要为了让结果看起来一致就在客户端删页或改章节名，那会掩盖服务器原始对应关系，后续同步也更难理解。

逐个确认旧书签仍指向正确情节

从保留的关键书签返回原位置，核对章节、人物动作与前后页面。即使应用仍能打开某页，内容也可能因为封面新增、拆分跨页或文件替换而偏移。不能只凭书签数字仍存在就认定恢复正确。确认偏移后，先在当前文件找到原情节，再建立新书签并写明维护日期；旧记录留到全部核对完成。若条目身份已经变化，阅读历史可能仍保留旧入口，应将它标为旧来源参照，而不是反复点击期待自动变成新文件。

下载副本与服务器新版本分别核对

设备上的已下载副本可能仍是维护前版本，它能够正常离线阅读，并不说明已经自动替换成服务器新文件。对照副本的代表页面、章节范围和文件来源，决定继续保留旧版还是另行获取新版。先保存需要的旧书签与原件，再按当前下载入口取得新副本，检查两者身份。不要删除唯一可读副本之后才发现服务器下载权限改变。将本地版本写进维护清单，可以避免几周后看到不同画面却忘了这是旧版留档，而误以为同步出现随机错误。

未更新时按层次报告而非连续重建

仍有异常时，分别写下服务器网页结果、漫阅+ 列表结果、正文结果与本地副本结果。四层中只有一层旧，排查范围就比较明确；全部都旧，则应重新确认维护是否真正完成和账号是否连到预期书库。提供作品与章节身份、维护类型及核对时间，足以让维护者检查，没必要发送整个私人目录。不要连续执行扫描、清缓存、删除连接、重新导入所有文件的组合动作，这会让原本可解释的问题变成多个身份和缓存状态同时变化。

常见问题与完成标准

目录刷新后为什么书签仍偏移？书签定位依赖当前文件结构，刷新名称不等于重新理解全部剧情。服务器换文件会自动更新离线副本吗？不能这样假定，需要单独核对下载版本。完成标准是服务器和应用目录能够对应，新增或替换页面实际正确，重要书签已复查，本地副本版本清楚。保留维护前后清单，以后补卷或重新打包时继续使用同一套检查，比只确认封面变了就结束更能发现潜在的位置差异。