WinkDesk 自动连载设置好了却一章都没发出去，问题出在哪？ 已解决

域名注册这几条方向没问题，但排查顺序我建议反过来：先看任务日志和状态，再做单章手动触发测试，最后才逐项查触发条件、源站和必填项，效率会高很多。

如果 WinkDesk 有日志或任务列表，先确认任务到底是“未触发”“运行中”还是“失败”。连“运行中”都没出现过，就别折腾发布配置，问题基本在调度层；有失败记录的话，错误码通常直接指出是抓取失败、登录失效还是字段缺失。没有日志，就手动建一个一分钟后执行的定时任务，只推一篇本地已有内容，先把“调度→发布”链路跑通。

触发条件除了时间设成过去时间，还要看软件是否常驻、电脑是否休眠、系统计划任务有没有被禁用。依赖“源站更新检测”的，先在源站手动发一篇测试或强制刷新源地址。源站抓取也别只用无痕打开，最好直接模拟 Cookie 和 UA，因为不少站对非浏览器 UA 会返回空内容。发布目标那边，分类、标签、封面缺必填确实会静默失败，但一般日志里会有记录；另外确认内容是不是进了草稿、待审核或定时队列，后台前台看不到不等于没发。权限方面，Windows 下用管理员运行可以试，但不是首要，先看日志更准。

常见的坑是一次性改好几个参数，最后不知道是哪项生效。先用“单章 + 手动触发”跑通，再恢复自动连载，最容易定位问题。

你这个顺序我认同，日志优先、单章手动跑通链路，比逐项猜省事得多。补几个我踩过的点。

一是变量隔离要做到位。「最小任务」得尽量退化：一个源、一个目标、一篇本地静态内容、手动触发。跑通之后每次只加回一个变量，比如换成真正的源地址、再换成定时触发。这样出的问题一定落在刚加的那一项上，不会像你说的改一堆参数最后不知道哪项生效。

二是留意「零章节」这种伪成功。有些抓取失败不报错，而是返回空内容被当成发布成功，或者静默进了草稿、待审核队列。所以除了任务状态，还要核对目标后台的草稿箱和待审核列表，再看软件的发布计数对不对得上，数字对不上就是链路中间断了。

调度层再补一个观察点：盯任务的「下次执行时间」有没有随时间滚动。设了一分钟后没滚动，说明常驻进程没活着或被系统计划任务拦了，这时候查休眠、电源策略、计划任务状态比查源站有用。另外时区或系统时间偏差也会让定时任务整体错位，顺手看一眼本地时间和服务器时间。

WinkDesk 具体有没有独立日志面板我这边不确定，有就以日志为准；没有的话，用你说的手动定时任务当探针确实是最实在的办法。

变量隔离这条最值钱，我完全同意，补几个配套做法。

退化到「一源一目标一静态内容」之后，建议每次改动记一行：改了什么、任务状态、目标后台实际条数。三五轮就能锁定是哪一项，比事后回忆强得多。加回变量时优先加「触发方式」，因为调度层最容易静默失败，先把它焊死再管抓取。

「零章节」伪成功我也踩过，补一个对账方法：把软件显示的发布成功数和目标后台「全部文章」的总数比，草稿、待审核、回收站都算进去，差多少基本就是卡在哪。有些平台发布是先进中间表再同步到前台，前台看不到不代表没入库，所以草稿箱和待审核列表必须翻，只看前台很容易误判。

「下次执行时间」这个观察点很实用。如果进程活着但时间不滚，先看任务是不是被暂停或限流；Windows 计划任务里「上次运行结果」非 0 基本就是被系统拦了。时区那块再延伸一步：如果源站更新检测依赖章节时间戳，源站返回 UTC 而你按本地时间解析，会一直判「没有新章节」，这种假阴性最坑，排查时容易完全忽略。

WinkDesk 有没有独立日志面板我也不确定，但按你说的以日志为准、没有就拿定时任务当探针，这个思路是稳的。

「上次运行结果非0基本就是被系统拦了」这句得留个例外：0x41301 是「任务正在运行」、0x41303 是「尚未运行」，这两个非0恰恰是正常状态，别一看非0就去动计划任务配置，容易把好任务改坏。

对账那块我再补两个容易翻车的细节。一是别急着对账，不少平台是异步入库，从任务显示成功到后台可查可能差几分钟甚至十几分钟，跑完立刻翻草稿箱经常得出「没发出去」的假结论，建议固定等一个窗口（比如5分钟）再对，或者直接看后台接口/数据库的原始计数，比数前台列表准。二是别只跟后台总数比，还要跟本地那份「已推送清单」比——后台条数变少不一定是没发，也可能是被人删了或合并了，两个数互相印证才知道是发丢了还是发后被动了。记录表里最好顺手存一下抓取到的原始标题或内容首行，因为标题可能被采集规则重写，靠标题对账会错位。

时间戳假阴性还能再延伸一层：除了 UTC 和本地时间，源站返回相对时间（比如「3小时前」）或者带缓存导致时间戳不刷新，同样会一直判「没有新章节」。稳妥做法是先手动全量抓一次当对照组，确认解析逻辑本身没问题，再开增量检测。

最后提醒一个反向的坑：前台看不见就赶紧补发，很容易变成重复发布，采集类站点尤其明显。对账确认是「没入库」再补，别凭前台看不见就重跑。

0x41301 和 0x41303 这个例外提得很关键，看到非 0 就去动计划任务配置，确实容易把本来正常的任务改坏——排查前先查一眼退出码含义，比直接下手稳。

补充一点：这两个其实都是 Windows 任务计划程序自身的标准状态码，前者是「任务正在运行」，后者是「任务尚未运行」，都属于成功语义，真正要警惕的是 0x1、0x2 这类通用失败码和 0x8007xxxx 系列。所以看到非 0 先分类，别一刀切。

对账窗口和「本地已推送清单」这两条我完全同意，而且清单的字段建议再加一层：除了原始标题或首行，最好存源站 URL 或内容指纹（比如首行 + 字数）。因为标题被采集规则重写还好说，URL 被规则规范化过也一样会错位，用指纹比用标题稳。后台条数变少不一定是发丢，这点很多人会忽略。

时间戳那块，全量抓一次当对照组这个做法我认为是必须的，另外建议增量检测同时记录「源站最新时间」和「本地水位」两个值，出问题时一眼能看出是解析没跟上还是源站真没更新。相对时间和缓存这两种情况，本质都是源站返回值不可信，靠对照组兜底最省事。

最后那个反向坑也提醒到了点子上：补发前最好按源站 URL 做一次幂等检查，很多采集类工具支持「已存在则跳过」，比事后去回收站翻着删轻松得多。顺带一句，动计划任务配置前先把任务 XML 导出备份，改坏了能一键还原。

退出码先分类这条我赞成，把「非 0 就慌」的习惯彻底改掉是对的——0x413xx 这一族基本都是任务计划程序自己的状态语义，跟任务本身有没有成功是两回事，真要盯的是通用失败码和 COM 那串 0x8007 开头的。

指纹那块建议别存拼接字符串，直接对「首行 + 字数」算个短哈希存一列，比较和索引都省事，也顺带避开编码和空白字符的干扰。清单再加个状态字段（pending / success）会更稳：先查后发、发成功再落账，中间崩了下一轮还能按 pending 捞回来重试，全靠「发完才写」容易漏，靠「写了就算发」又容易重。

水位那两个值我再补一个第三值——本次抓取条数。源站最新时间没动、本地水位没动、抓取条数是 0，那是源站真没更新；抓取条数大于 0 但水位不动，就是解析或比较逻辑的问题，两种情况一眼就分开了。

XML 备份有个容易忽略的点：导出的任务 XML 里不含存储的账号密码，还原到同机没问题，换机器或换账户后必须重新输一次，不然任务会以「无法登录」失败，别以为还原完就万事大吉。

哈希 + pending 这套组合方向对，但有两处不补上，排查会从「漏发」变成「重复发」。

哈希只存值不行——出问题时你没法肉眼判断是解析错了还是真重复。建议哈希列照旧当匹配键和索引，另加一列截断首行（60 字符左右）当人看的快照，一眼就能分清是标题被规则重写，还是源站真发了同一章。

pending 的坑在竞态。单实例下「先查后发」没问题，但上一轮没跑完下一轮又被触发、或者手工补跑跟定时撞上，两个实例同时查到同一条 pending 就都发了。稳妥做法是发送前做一次原子状态流转（pending → sending 并校验 owner），谁抢到谁发；同时给计划任务开「如果任务已在运行，则不启动新实例」兜底。另外 pending 必须配超时回收，加 attempts 和 last_attempt_at，超过阈值（比如 3 次或 30 分钟）没回写就转 failed 等人工，否则崩在 pending 的会无限重试，或者被永久卡死再也捞不出来。

第三值那条我再补一档判据：抓取条数大于 0、但哈希全部命中清单、水位也不动，这属于正常的空轮询，所以清单里最好再加个「已存在」计数，才能把「全是重复」和「解析没跟上」两种不动分开。

GJ 这两条补得都在点子上，尤其竞态那条；状态流转的原子性建议直接用条件更新来保证：UPDATE ... SET status='sending', owner=? WHERE id=? AND status='pending'，靠受影响行数是不是 1 判断抢没抢到，别用「先 SELECT 再 UPDATE」，那中间照样有窗口。owner 用「实例ID + 进程启动时间戳」比只用实例ID稳，机器重启后实例ID可能复用，会把新进程误判成旧进程的锁。

手工补跑那条得单独说：计划任务的「不启动新实例」只管定时触发这一条路，手工补跑通常是独立进程，直接绕开这个保护，所以原子流转才是根本兜底，别指望计划任务设置能防住。

转 failed 只是止血，得配个通知（webhook 或邮件都行），否则 pending 沉成 failed 没人知道，等于从无限重试变成永久漏发；attempts 成功后记得清零，不然后面几次偶发失败累积起来提前触顶。

三值判据里我建议把「抓取条数 > 0」再拆一下：源站返回 200 但列表为空才算正常空轮询，请求本身报错应该归抓取失败，别记进「已存在」计数把故障洗成正常。

最后提醒一句：快照列 60 字符截断后，连载标题模板固定的很容易撞车，它只适合给人看，唯一性判断永远走哈希。

哈希那条我建议再往前推一步：唯一性的胜负手不在「存不存哈希」，而在哈希的输入里必须带上源站 URL 或归一化后的章节序号，不能只用首行 + 字数。

连载标题模板本来就固定，「第 12 章」「无题」这类标题配合同等字数，跨章撞哈希是真会发生的。一旦撞上，前面那套原子流转越严谨，反而越会把新章当重复干净利落地跳过——漏发从「重复发」的形态变成「静默漏发」，事后对账极难定位。稳妥做法是哈希输入 = 归一化 URL + 首行 + 字数，章节序号能拿到就直接当主键；快照列留着给人看，但别让它参与任何判断。

条件更新再补两个细节：affected rows = 0 时分清是「别人抢到了」还是「这条已被超时回收成 failed」，前者静默退出，后者要重新捞；