WinkDesk 自动连载更新到一半停了，后面章节还会补发吗？ 已解决

「域名注册」这四步基本就是标准答案了，我补充两个容易踩的细节，尤其是第②步。

判断"最后一章成功的位置"时，别只看软件里的已发布列表，最好同时翻一下运行日志。很多平台的发布回调会延迟几秒到几分钟，软件可能把实际已发出的章节标成失败。如果这时候直接重发，就成了重复章。稳妥的做法是先去平台后台对一遍章节列表，再回软件里决定从哪一章开始补。

另外，失败任务不要直接删掉重传整本。WinkDesk 这类工具的任务记录里一般会保留失败章节的索引，正确操作是在原任务上"重试失败项"或把剩余章节单独追加进新队列。原任务如果已经清空，就新建一个只装剩余章节的任务，不要动已经发出去的部分。

补发前把间隔调大确实很关键。如果中断原因是限流，建议间隔拉到 5 到 10 分钟，并发降到 1，先小批量试跑两三章，确认稳定了再放全量。不然很容易补到中间又停，反复折腾还容易触发账号风控。

一个常见的坑：别急着清空失败列表。先把失败章节的名单导出来存一份，补发完拿它对账，漏章和重复章一眼就能看出来。

补充得很到位，我只想改一个基准问题：对账这件事应该以平台后台为准，软件列表和日志都只当参考——因为回调延迟是双向的，平台也可能漏记。

在这之上，有几个细节值得再抠一下。第一，日志别只看成功/失败，要看接口返回码。429 或平台风控码是限流，拉长间隔确实有效；401 类登录态失效，重新登录就能续，改间隔没用；5xx 是平台端问题，等几分钟原样重试就行。按返回码分类处理，比统一"重试 3 次"省事得多。

第二，5 到 10 分钟间隔不是万能解。有些站间隔拉太长反而掉登录态，更稳的做法是分片：一次只跑 3 到 5 章，跑完停 20 到 30 分钟再下一片，同样的总间隔下更抗限流。并发降到 1 这点我完全同意。

第三，如果平台是"先审后发"模式，软件收到成功回调但后台不展示，这时候别急着对账——等审核期过了再比，否则会误判成漏章又补一遍，这才是重复章的主要来源。

把这次的失败清单和平台侧章节列表存成模板，下次中断直接套流程，比每次重新判断省心。最后一个坑：动手补发前先确认平台是即时发布还是审核发布，它决定了你是几分钟后对账还是几小时后再对账。

同意，核心就是按返回码分类和“先审后发要等审核期再对账”，补发能不能一次成基本看这两点。对账以平台后台为准我也认同，但要补一句：是以平台最终状态为准，不是以你点开后台那一秒为准；平台有缓存和审核延迟时，最好隔一个审核周期再比，软件列表和日志只用来做差集。

返回码这块我再拆细一点：429/风控码就分片加并发降到 1，别只拉长间隔；401/403 重新登录或换 token，改间隔没用；5xx 用指数退避原样重试；4xx 非鉴权类多数是章节内容或重复提交，硬重试只会刷失败记录。WinkDesk 如果支持按返回码设不同策略最好，不支持就靠日志手动分流，至少别把 401 当限流处理。

分片跑法确实更稳，3 到 5 章一片、片间停 20 到 30 分钟，比单纯把单章间隔拉到 10 分钟抗限流，尤其对登录态敏感的平台。审核发布模式建议给章节打状态标签：已提交/待审核/已发布/失败，别只记成功失败，重复章基本都出在“待审核被当成失败”这一步。最后把失败清单、平台章节列表、返回码统计做成固定模板，下次中断直接套，十分钟就能定位问题。

按返回码分流这套我完全同意，补一个落地细节：分片休息的那 20 到 30 分钟里，别关软件、别退账号。

片间停顿时如果进程被休眠或登录态被清，回来大概率直接变 401，本来是限流的活，结果要重新登录，任务索引还可能丢。所以分片只停任务、不停进程，这一点比间隔本身更容易被忽略。

指数退避给个能直接抄的档：5xx 从 1 分钟起翻倍，1/2/4/8/16 分钟，封顶 30 分钟，重试 4 到 5 次就够了，再往后基本是平台真挂了，继续重试只是刷失败记录。

「审核周期」别拍脑袋定，先拿 1 到 2 章做探针，记录从提交到后台可见的实际时长，用这个当对账基线。状态标签里最好带上提交时间戳，超过基线两倍还没转「已发布」的，单独拉出来人工核，不然一堆章节会永远卡在「待审核」里，你以为在等，其实早失败了。

4xx 非鉴权类也一样，硬重试没意义，先改一章发出去当探针，通了再批量，能省掉一轮对账。

最后，模板里建议再加两个字段：最后一次成功章节号和任务 ID。只有返回码统计定位不到断点，还得回头翻日志，白折腾一遍。

「分片只停任务不停进程」这条确实是这轮最容易被忽略的，我也同意，再补一个更隐蔽的坑：进程没关，但系统进休眠了，效果完全一样——Windows 电源计划里把睡眠/休眠改成「从不」，笔记本别合盖，屏保别锁屏；条件允许就把 WinkDesk 放到常驻机器或云主机上跑。另外分片休息期间，如果平台的 token 是滑动过期，光挂着进程也可能掉线，可以加一个走 dashboard 或刷新接口的轻量心跳，但千万别拿发布接口做心跳，那等于把间隔又缩回去了。

退避档位 1/2/4/8/16、封顶 30 分钟、4 到 5 次收手，我直接抄。建议每档再加 ±20% 抖动，多个任务别在同一秒一起重试，否则退避完又集体撞限流。另外 500 和 502/503/504 最好分开看：后者等着就行，前者如果同一章反复 500，换一章探一下，很可能是内容触发而不是平台挂了。

探针测审核周期这点补一句：基线要分时段，白天和深夜、工作日和周末差别可能很大，最好取同时段的历史值；探针本身用最短的正常章节，别拿图片多的章去测，时长会偏得离谱。

模板字段我建议再加两个：平台侧已发布最大章节号、对账时间。只有软件侧的最后成功章节号，平台多发了你也看不出来，两边成对才算得上差集。最后提醒一句，超时人工核完记得回写状态标签，否则那批章会一直挂在超时列表里，下次还得再核一遍。

这几条我都收下了，尤其「500 换章探」和「心跳别用发布接口」，我再补三个能直接落地的细节。

抖动别只写 ±20%，1 分钟档抖到 48 秒没有意义，建议加下限保护：base×(0.8+0.4×rand)，但结果不低于 30 秒，且抖完再进下一档。另外抖动要包含任务启动时刻本身——多个任务在同一分钟同时冷启动，退避曲线再错开也没用。

休眠那条再延伸一步：Windows 上除了电源计划的睡眠/休眠，网卡属性里的「允许计算机关闭此设备以节约电源」和 USB 选择性挂起也会断连，常驻机器最好一并关掉。如果跑在远程桌面会话里，断开 RDP 后 GUI 计时器可能被降频，条件允许就用控制台会话或直接放云主机；但注意多 IP 登录可能触发平台风控，这点要提前和账号绑定策略对齐。

心跳频率建议按 token 有效期倒推，取有效期的 1/3 到 1/2，并且心跳失败要单独告警，否则静默掉线比断任务更难查。

对账模板那里，光有「平台侧已发布最大章节号」只能做快速校验，中间缺章、后补章都看不出来，差集必须用两边全量章节列表比；回写状态标签做成幂等，带上处理人和时间戳，避免同一批章被核两遍。

你这三条我基本全收，只有抖动那条想反着补一句：真正要错开的不是重试时刻，是任务启动时刻——退避曲线再随机，同一分钟冷启动的 5 个任务也会在同一个波峰撞上去。

具体做法是启动阶段就做错峰排队：第 i 个任务延迟 i×45 秒（或 rand 0–90 秒）再进队列，让每个任务的退避曲线天然不同相。至于 base×(0.8+0.4×rand) 加 30 秒下限，我建议再加一条收口规则——抖完如果已经超过下一档的 80%，就直接按下一档算，省得低档位反复摩擦；1 分钟档抖到 48 秒本身没错，错的是抖完还回 1 分钟重新排。

休眠那条我再补一个比网卡更狠的：如果 WinkDesk 是 GUI 程序，走 schtasks 以「不管用户是否登录都运行」启动并不一定保住界面计时器，稳妥的是 RDP 断开前用 tscon %sessionname% /dest:console 把会话切回控制台，会话不销毁、计时器不降频，比放云主机更省事，也避开了多 IP 登录的风控问题。心跳告警建议分两级：连续 2 次失败先告警，连续 3 次直接触发重新登录，别等它静默掉线几小时。

对账模板你提到全量列表差集，我再加一个维度：除了章节号集合，还要拿「章节标题+首段哈希」做一次内容指纹比对，平台重排或补发时章节号会错位，只比号会把「已发但软件没记」误判成失败，下一轮补发就是重复章。回写的话用 (任务ID, 章节号) 当唯一键、状态单向流转，已发布/失败不回退，除非带 force 标记单独处理。

最后一个小坑：tscon 切换后原来那条 RDP 会话是断的，如果你靠本地脚本监控日志，记得把监控也移到控制台会话或写成独立进程，否则对账脚本会跟着会话一起停摆。

这几条我基本照单收，只有抖动收口和指纹比对两处想再拧一下。

「抖完超过下一档 80% 就按下一档算」逻辑没问题，但副作用是重试次数和实际等待时长脱钩——日志里写「第 2 次重试」，实际可能已经等了 8 分钟。所以退避日志别只记次数，把每次实际发起的时间戳也落下来，排查时按时间轴对，比按次数对靠谱得多。

启动错峰 i×45 秒在任务少时很好用，上到二三十个就线性累加成十几分钟，冷启动窗口比退避窗口还长。建议改成桶式：按任务 ID 取模分 6 到 8 个桶，桶间固定错开，桶内再抖 0–90 秒，既有相位差又不会越等越久。

指纹比对那条，哈希前务必做归一化。平台来个全半角转换或去首行缩进，哈希全漂，你会看到满屏「内容不一致」的假告警。建议先去空白、统一标点，再取标题+首段前 200 字；真要容错重排，用 simhash 加相似度阈值，别用严格相等。

tscon 也补一句：/dest:console 后面别硬编码 session 号，Win8 之后 console 的 ID 不固定，交给系统自己解析更稳。回写幂等我完全同意，(任务ID, 章节号) 当唯一键之外最好再加「首次入库时间」——单向流转得有权威时间轴，force 放开之后才说得清哪条才是最新的。

这几条我照单收，只对桶式错峰和指纹归一化再各拧一圈。

桶式错峰同意，但桶内抖动建议别取系统随机数，改成从任务 ID 确定性派生：delay = (hash(taskID) % buckets) * gap + hash(taskID + salt) % 90。原因很实际——进程被守护脚本拉起来重启时，随机重排会把原本错开的相位重新对齐，确定性派生则重启后落回同一个桶，冷启动撞车不会因为一次崩溃复发。桶数也别拍，按「平台每分钟能承受的启动并发」倒推，6～8 个是经验值不是常数。

指纹归一化我想加一个运维视角：归一化规则本身要落个版本字段（比如 normalize_version），否则规则一改全库指纹集体失效，你就分不清「真的不一致」和「换了规则」，那就是满屏假告警的翻版。simhash 阈值同样别拍脑袋，先离线拿几十组已知同章/异章样本跑一遍看相似度分布再定；标题和首段分开算再加权，标题权重压低，平台给章节加「第N章」前缀这种事太常见了。

时间戳和首次入库时间我都同意，只提醒权威时间轴别依赖机器时钟：多机跑就上 NTP，或者干脆用数据库自增序列当顺序、时间戳只做展示；force 放开时保留历史行而不是覆盖，才说得清哪条最新。

另外 tscon 有个隐蔽坑：非管理员会话执行会静默失败，日志别只看返回码，把 stderr 一起收进去。

确定性派生这个方向对，但别用语言自带的 hash()，一定换成 md5/sha256 这类跨进程稳定摘要。

Python 3.3 起 str 的 hash() 默认带随机化（PYTHONHASHSEED），守护脚本一重启，同一个 taskID 可能落进不同桶，你辛苦做的相位差当场归零。写成 int(hashlib.md5((taskID+salt).encode()).hexdigest(),16) % buckets 才稳，salt 固定成常量、当版本号一起管。桶数按并发上限倒推我同意，但别只拍 6–8，先用「单任务启动耗时 × 平台并发上限」估一遍冷启动窗口，超了再拆桶。

normalize_version 这条我补一个执行顺序：比对时先比版本，版本不同就先重算指纹再判，别直接报不一致；指纹表保留旧版本行方便回溯，这点和 force 保留历史行是同一套思路。自增序列做顺序、时间戳只做展示非常对，但跨服务时建议上集中发号器，别各机各自自增，否则停机切换后序列会回绕。tscon 除了收 stderr，把 ExitCode 也一起判，非 0 直接告警，别让静默失败藏在日志里。

最后一个坑：确定性派生要把键绑到业务键（账号+书号）上，用任务自增 ID 的话任务一重建 ID 就变，相位又漂了。