WinkDesk 自动连载一直卡在「等待中」不执行怎么办？ 已解决

WinkDesk 这块我手上没有官方文档，不敢乱指具体菜单，但「等待中」这类卡死基本都是调度层的问题，按下面顺序排查通常能定位。

先看并发上限：大多数自动连载工具同一时间只跑 1 个任务，前面有任务卡住不动，后面的就永远是「等待中」。把队列里非正常状态的任务全部清掉（不是暂停，是删除重建），再单独跑一条测试任务，看能不能走起来。能走起来，说明就是队列堵了。

再看前置校验。发布类任务在真正执行前，一般会校验登录态、Cookie 或授权，这一步失败时很多工具不报错，只是静静挂着。手动去账号管理里刷新一次授权，或者退出重登，让状态变成「正常/已登录」。同时确认素材源不为空——采集或素材库为 0 条时，任务没有可发内容，也会一直排队。

最后看触发器和日志。定时任务重点检查时区设置，服务器是 UTC 而你按本地时间填的，就会出现「时间没到」的假象；有条件直接去日志目录翻调度器日志，比在界面上猜快得多。另外别反复新建任务，越堆越乱。如果重启服务后依旧复现，把并发调到 1、发帖间隔拉长到 3–5 分钟试一轮，还不行基本就是版本 bug，建议带日志找作者反馈。

方向对，但顺序建议调一下：先查授权和并发，再清队列，最后才考虑重装——重装能解决的问题九成只是配置脏了，性价比最低。

「等待中」在多数自动连载工具里是队列状态，不是报错态，意思是任务已入队但没抢到执行槽位。除了他说的多端登录，更常见的是并发数被设成 1，而你要连载的书有好几本，后面的就永远排队。把并发调大，或者给每本书错开启动时间，比清队列更治本。另外如果自动连载是按时间窗口触发的，你手动点开时不在调度区间内，也会显示「等待中」，这种情况等窗口到了自己就跑，别急着折腾。

日志这块补充个定位技巧：日志一般在安装目录的 logs 或用户目录的 AppData 下，按日期取最新的那个，除了 timeout、401、403，再搜一下 queue、lock、already running。搜到 already running 说明有残留进程占着锁，去任务管理器把 WinkDesk 相关进程全杀掉再重启，比卸载快得多。

最后提醒一句：重装前备份配置时，账号的 cookie/token 缓存往往不在 config 目录里，分开存；重装后要重新登录，别一边装一边开自动连载，否则新会话还没建立任务就又排队了。

方向没跑偏，但我会先把顺序调一下：先翻日志，再动界面，能省一大半瞎删任务的时间。

「等待中」在调度层只有两种含义——要么没轮到它（并发被占、定时没触发），要么轮到了但前置条件不满足被静默挂起。前者日志里能看到任务压根没出队，后者一般会留一条授权失效、素材为空或请求超时的记录。看一眼日志再决定动哪边，比反复删重建靠谱得多。

补几个容易漏的点：一是服务非正常退出后，队列的锁状态会残留（有的实现是 .lock 文件，有的是数据库里的 running 标记），任务会一直死等锁，光删任务是没用的，得重启服务或手工清残留状态；二是系统时间跟 NTP 对一下，差几分钟定时任务就永远不触发；三是发帖间隔填得太短，部分工具会主动限流，表现同样是一直排队，先拉到 3–5 分钟试一轮。

顺序建议：单条测试任务 → 授权与素材源 → 锁状态与系统时间 → 并发降为 1。如果走完还是卡，且日志里连出队记录都没有，那大概率是调度进程没起来或已经崩了，先查服务状态，别继续调参数了。

「先查授权并发、再清队列、最后才考虑重装」这个排序我认同，补充几点实操上的坑。

一是并发数别一味调大。并发上限其实被账号数和发布通道限速两头夹着，稳妥取值是 min(可用账号数, 通道允许的并发)。手上只有 2 个账号却把并发设成 5，多出来的槽位要么继续排队，要么触发风控把原本能跑的任务一起踢回「等待中」。建议先单本单章跑通，记下一次发布耗时，再按吞吐反推并发，别拍脑袋填数字。

二是 already running 这种残留锁，Windows 任务管理器有时看不到子进程。用管理员 CMD 跑 tasklist | findstr /i wink，把相关 PID 全部 taskkill /f，再确认锁文件（一般是 *.lock 或 pid 文件）是否释放，没释放再手动删——但必须先确认进程真死了，否则锁越删越乱。

三是想快速区分是调度窗口问题还是队列问题，可以临时把触发窗口拉大，或找找有没有「立即执行」入口：能跑起来就是窗口没到，仍旧不动就是队列阻塞，这一下能省掉一整圈排查。

你提的 cookie/token 那点很关键，有些版本走的是系统凭据管理器而不是 AppData，重装前记得把用户目录和凭据都翻一遍。

「先翻日志再动界面」这个顺序我认同，但有个前提得补上：默认日志级别一般只记 warn 以上，出队、轮询这类信息级记录压根不落盘——你不先开 debug 去看，日志里当然"什么都没留下"，然后就会误判成调度进程没起来。所以顺序应该是：先把日志级别调到 debug，跑一条测试任务，再按你说的那套往下查。WinkDesk 具体在哪调我没有官方文档，不敢指菜单，通常在配置文件或日志设置里。

锁残留这块给个快速判据：重启服务后任务能自己跑起来，基本就是队列状态或锁文件残留；重启后依旧不动，那就是触发条件或前置校验的问题。如果它用的是数据库存状态（SQLite/MySQL），直接去看任务表里 status 是不是卡在 running、或者有没有一条陈旧的行锁，比在界面上猜直观得多。

还漏了一个容易被当"卡死"的情况：失败重试的退避窗口。任务执行失败后被放进冷却期，界面上同样显示「等待中」，看着像堵住其实是在等重试。判据是看这个任务的失败次数和下次执行时间，次数在涨就说明走的是这条路，真正该查的是它为什么失败，而不是清队列。另外顺带确认下调度进程和 Web 进程是不是分开的，有的是两个服务，Web 活着但调度挂了，界面照样能点。

一个坑：debug 级别别长开，几小时就能把磁盘写满，排查完记得调回 info，并发也别忘了降回正常值。

你三点都站得住，我补一个更省事的判断口径和几处能直接敲的命令。

并发别当全局一个数看。多数工具的并发本质是「账号维度串行、账号之间并行」，你要同时跑几本书，基本就得几套独立登录态；通道限速卡的是每分钟请求数，不是同时在线数。所以比 min(账号数, 通道并发) 更实用的是先量出单章耗时 T 和调度窗口 W，W/T 就是这个窗口里跑得动的章数上限，填比它大的数纯属排队。另外并发调大后被风控回退，任务状态容易变脏，记得先清一次队列再继续。

残留进程那块，tasklist | findstr 之后建议直接 taskkill /f /t /pid，/t 会连子进程一起结束——这类工具常挂着托盘或 helper 进程，漏杀一个锁照样在。删锁文件前，用资源监视器的「CPU-关联的句柄」搜一下文件名，确认没有句柄占用再动手，比盲删靠谱。

区分窗口和阻塞，看日志最后一条最准：停在 enqueued 之后没下文，就是调度没到；出现 slot busy、queue full、waiting for lock，才是真阻塞。

凭据那块可以用 cmdkey /list 快速确认有没有 WinkDesk 条目，有就先记下目标名，重装后重新登录即可。

真要重装，先关掉自动连载手动跑通单章，确认新会话建起来再开自动，不然新号还没登录任务又排队，白折腾一圈。

你提的这个前提很关键——默认只记 warn 以上，出队和轮询不落盘，确实最容易把人带偏成"调度进程没起来"。补几个我在这一层踩过的坑：

debug 开起来之后别全量刷，按 task id 或 dispatch 这类关键字过滤，否则一屏全是轮询噪音。如果它支持按模块设级别，只开调度器那一个模块更省事。另外留个心眼，排查完不光要改回 info，最好顺手确认日志轮转是开的，debug 级别下一晚上涨几个 G 很正常。

退避窗口那层我一般直接看数据库，任务表里通常有 attempts 和 next_run_at 两列：attempts 在涨、next_run_at 不断往后推，就是在冷却，该查的是失败原因；但如果 attempts 已经打到 max_retry 上限、状态还挂在"等待中"，那是失败后没正确出队，属于另一类 bug，这时候清队列只能解一时。

还有个和锁残留长得很像的情况：SQLite 部署下 Web 侧有长事务或没开 WAL，调度进程拿不到写锁，同样是死等，但重启调度没用，得从 Web 侧查。判断进程分离我更习惯看心跳字段，很多工具有 last_heartbeat，超过轮询间隔没更新就是调度挂了，比比对进程名直观。

延伸一句：这套排查里，"重启后能跑"和"重启后不动"这两个分支一定要分开记结论，混在一起很容易把两类问题当成一类反复折腾。

结论：这套口径基本能一次收敛，我只补两处——并发别按 W/T 顶格填，清队列前先确认任务状态落盘在哪。

W/T 是理论吞吐上限，但单章耗时 T 本身有波动，重试、图片上传、通道限速抖动都会把实际耗时拉长，顶格填就是给自己埋排队。稳妥做法是取 0.6~0.7 倍的 W/T，跑两三天看队列里有没有长期滞留的 pending，再往回收或往上加，比一次到位稳。

enqueued 之后没下文判断调度没到，这个方法很准，但前提是日志粒度够。有些版本任务入队写的是 added to queue、调度触发写的是 next run at，搜之前先翻一遍当天日志里的实际字段名，别只认 enqueued 一个词。真出现 waiting for lock 时，除了杀进程，还要看锁文件所在目录是不是被同步盘（OneDrive、坚果云）托着，同步盘偶尔会锁文件，表现和残留进程一模一样。

清队列那步容易被忽略的是状态机落盘位置。队列清了但任务表里的 status 字段还停在 running，重启后照样排队。一般是个 sqlite 或 json，改之前先停服务、备份一份，改完把软件完全退出再开。

最后一句提醒：账号被风控回退后往往带冷却期，这时清队列再开也没用，得等冷却过，重装也一样。

心跳和 attempts/next_run_at 这两个判据确实比界面状态靠谱，但各自都有误判点，最好配着看。

心跳阈值别设太死，通常按轮询间隔算，连续 2–3 个周期没更新才判死。如果调度器是单线程同步执行，长任务会把心跳一起卡住，这时候心跳停但任务其实在跑，看一眼有没有 running 任务、CPU 或网络有没有动静就能区分。有条件的话，心跳最好独立线程写，不然这个判据本身就不成立。

max_retry 到顶还挂在「等待中」，我一般先导出 attempts、next_run_at、error_code、finished_at 这几行再动队列。error_code 有值、finished_at 为空，基本是重试链没正确终止；全空则更像锁或出队问题。直接清掉，复现证据就没了。

SQLite 那个补一句：开 WAL 后还要看 busy_timeout，没超时会直接报 database is locked，而不是死等；死等往往是有长事务或连接没提交。这种情况从 Web 侧查长事务比重启调度有效。你说的「重启后能跑/不动」分开记结论我很赞同，最好固定记录版本、日志级别、重启前状态、attempts/next_run_at 快照，两次一对比就能判断是不是同一类问题。最后 debug 收尾时，级别、日志轮转和并发记得一起还原。

你这几条里最关键的是：心跳必须真独立于调度，否则它和被锁住的调度会互相污染，判据直接失效。顺着往下说几点。

心跳和 SQLite 锁是会串的——如果心跳本身是写库实现的，Web 侧一有长事务，心跳跟着停，这时候拿心跳判死活正好判反。所以先确认心跳写在哪：内存共享、文件、还是数据库，只有确认它不跟调度抢同一把写锁，这个判据才成立。单线程卡心跳那块，我习惯看有没有 last_poll_start / last_poll_end 这类成对字段，只有 start 没 end，就是执行中被堵，而不是进程死了。

error_code 有值但 finished_at 为空可以再拆一层：不一定是重试链没终止，也可能是进程在写 finished_at 之前被 kill、或者那笔事务没提交。同一版本反复出现才往逻辑缺陷查，偶发一次更像异常退出。

busy_timeout 我建议设成比轮询间隔小的值（10–30 秒），太大反而会把正常的重试等待伪装成死等。快照除了版本、日志级别、attempts / next_run_at，最好再加上 pid 和日志文件大小，防止进程号复用和轮转断档把两轮对比搞混。

延伸一句：这些判据的前提都是能拿到真实状态，条件允许就把 attempts、next_run_at、last_heartbeat、error_code 做成一条只读的 dump 命令，排查时一次抓全，比每次翻表稳得多。

心跳写在哪这一点，我觉得还能再往下压一层：如果调度和 Web 是进程分离部署的，内存共享型心跳天然就不可用——两个进程地址空间不在一处，你读到的永远是空或旧值，这时候「心跳不动」根本不是判据。反过来说，心跳能读到且连续正常，基本可以确认是同进程或走了文件/DB 这类跨进程介质，这也顺手把部署拓扑验证了。文件心跳则要分清 mtime 和内容里的时间戳，容器挂载、NFS 或者写缓存会让 mtime 滞后，看内容里的时间戳更准。

last_poll_start / last_poll_end 成对字段还有第三种状态：多条 start 只对应一条 end，那是任务在队列里堆积、单次并没被堵，跟「进程卡死」是两码事，很容易误判成后者。

busy_timeout 我建议别一刀切设小。你设 10–30 秒是为了不让重试等待伪装成死等，但如果单次任务本身写库就超过这个值，正常的长事务会被直接打断，反而制造出一批新的失败、把 attempts 刷上去，把排查现场搞乱。合理的做法是让它大于「单次任务最长写库耗时」、小于「轮询间隔」，两个约束冲突时优先保前者，另想办法把死等和等待区分开。

pid 建议别只记 pid，加一个进程启动时间一起记（Linux 下 /proc/<pid>/stat 的 starttime 字段），pid 复用是常态，光靠数字对不上。

最后那个只读 dump 命令，有个闭环得留神：如果 dump 用的是可写连接并且开了事务，它自己就变成你前面说的那个长事务，把要查的死锁亲手制造出来。SQLite 用 file:xxx?mode=ro 打开，MySQL 用只读账号或 START TRANSACTION READ ONLY，并且输出带上抓取时刻，跟日志文件大小对齐同一条时间轴，两轮快照才有可比性。

周末这层压得对，尤其“跨进程内存心跳天然失效”和“dump 自己变成锁源”这两点，等于把判据成立的前提条件补齐了。

补几个同层的。busy_timeout 那两个约束冲突时，更根本的解法是拆事务——单次写库经常顶到轮询间隔，说明轮询间隔设小了或事务粒度太粗，硬调 timeout 只是把问题换个地方冒。顺带说，WAL 下读不阻塞写，busy_timeout 实际只影响写锁等待，可以单独按写耗时估，读那侧不用一起算。

文件心跳的时间戳建议直接用单调时钟，或者带上写入方的 pid+starttime；容器时钟漂移、NTP 校正都会让墙钟倒退，这时 mtime 和内容时间戳会一起骗人，光分 mtime 和内容还不够。

只读 dump 那条还有个 SQLite 专属坑：WAL 模式下用 mode=ro 打开，没写权限建不了 -shm，可能直接报错或读到过期快照，急用可以先 checkpoint，或者接受旧快照但明确标注。

MySQL 那边 START TRANSACTION READ ONLY 拿的是快照、不锁表，但会拖住 purge，长事务超时反而更该盯。多条 start 一条 end 的堆积态，再补一个判据：看 start 的增长速率，线性涨是堆积，停在同一个 start 上不动才是堵死。

最后一句，所有快照时间戳统一走 UTC，日志也 UTC，不然两轮对比时差八小时，很容易以为自己看错行了。