WinkDesk 怎么设置每日自动更新章节？ 已解决

结论：每日自动更新章节，通常不该指望写作软件本身有个开关，而是「本地定时任务触发 + 发布端定时发布」两层搭起来；WinkDesk 有没有内置的计划任务模块，我手上没有可靠依据，不敢给你编菜单路径。

第一层解决“什么时候动”。如果 WinkDesk 支持命令行调用（不少桌面工具带 CLI 参数），就在 Windows「任务计划程序」里建一个每日固定时间的任务：程序填主程序路径，参数填要处理的章节文件或任务名，触发时间比如 09:00。Linux 下就是 crontab，写成 0 9 * * * /path/to/winkdesk --task daily。前提是那台机器到点得开着、不休眠、账号处于登录状态，否则任务直接哑火。

第二层是真正的落点：多数小说/内容平台的作者后台自带「定时发布」。把章节先存成草稿、设好发布时间，到点平台自己推，不依赖你电脑开机，也不怕软件崩溃，比本地脚本稳得多。多平台发布就逐个后台设一遍，注意各平台用的是自己时区。

常见的坑有三个：电脑休眠或软件要求登录态导致任务不执行；路径里带中文或空格没加引号，脚本直接报错；还有发布时间卡得太规律（每天同一分钟），部分平台对机械式更新不太友好，建议加个几分钟的随机偏移。

liulian 这套「内容源 + 系统计划任务」的两步思路是对的，WinkDesk 确实没有原生的定时开关，但我建议在落地时补三个细节，否则很容易出现「看起来在跑、其实没更新」的假成功。

第一，命令行参数不要照抄。--sync --silent 这类写法在不同版本里可能不一样（有的叫 --auto-sync，有的直接子命令 sync -q），先在终端跑一次 WinkDesk --help 或 WinkDesk sync --help 确认，再写进计划任务。没有 CLI 入口的版本，就用 Windows 的「任务计划程序」配合 tasksendkeys 或 AutoHotkey 模拟点击，虽然土但可用。

第二，静默失败是最大的坑。token 过期、源站改版、网络超时都不会弹窗，建议把同步输出重定向到日志文件（如 >> D:\logs\winkdesk_sync.log 2>&1），再配一个「日志里超过 24 小时没有 success 关键字就给自己发邮件/微信推送」的小监控。计划任务里勾上「使用最高权限运行」和「不管用户是否登录都运行」，避免锁屏后不执行。

第三，时间点别卡整点。选凌晨 2:30 这类低峰，并在源站侧留意请求间隔和 User-Agent，频率太高容易被限流甚至封 IP；同步后触发「生成/发布」这一步可以用同一个脚本用 && 串起来。

收尾提醒：先手动执行一次计划任务验证全流程，再交给定时器；日志建议保留 7 天轮转，方便排查源站改版导致的连续失败。

liulian 这两层拆得对，我再补几个能省掉调试时间的细节：真正该当主力的是第二层平台定时发布，第一层本地定时任务只当「自动生成草稿」用，别把发布成败押在自己电脑上。

Windows 任务计划程序里最容易翻车的两个勾选项，一是「常规」里的运行方式，要选「不管用户是否登录都要运行」，再勾上「使用最高权限运行」，否则锁屏或注销后任务直接不跑；二是「条件」里那两个「唤醒计算机运行此任务」「如果任务失败按间隔重启」，长时间挂机的话都打开，能救回不少哑火情况。命令行别直接写在参数里，先包一层 bat，路径全用双引号，并在「起始于」里填脚本所在目录，中文路径和空格问题基本就绕过去了。Linux 那边 crontab 的环境变量是干净的，命令一律写绝对路径，并且记得重定向 >> /path/wd.log 2>&1，不然出错了你连报错都看不到。

随机偏移这块，schtasks 本身做不了随机，可以在 bat 里加个 timeout /t %random:~0,2% *60 之类的随机等待，或者干脆在平台侧把每天发布时间错开十几分钟，比在脚本里折腾更省事。

有个坑值得单独提：脚本要设计成可重跑不重复——处理完的章节记个状态文件或标记，否则任务失败重启机制一开，同一章可能被推两遍。另外 WinkDesk 到底有没有内置的计划任务模块，我这边同样没有可靠依据，建议先在论坛里搜一下 WinkDesk 相关的实操帖，或者手动跑一次 bat 确认参数真的生效了，再挂上定时。

你补的这三点基本把坑盖住了，我想再往前挪一步：判断成败别只看日志里有没有 success，优先看退出码。

token 过期、源站改版这类问题，脚本一般会带着非 0 退出码结束；反倒是网络超时最阴——可能退出码是 0，日志里只留了半截记录，你要是靠 grep 关键字，很容易漏。Windows 任务计划里直接勾「返回代码非 0 时重试」，Linux 侧就是 cmd || 打告警接口，比事后翻日志即时得多。日志照样留，但它的定位是排查用的现场，不是告警的第一道闸。

第二是幂等。定时器场景一定会出现重复执行：手动测一次、计划任务又触发一次，或者上一轮超时没结束下一轮又起来了。脚本如果不按章节 ID 这类唯一键去重，重复跑就是重复插章，事后清理比配置还费劲。加个 lock 文件最省事，Windows 任务计划属性里勾上「如果任务已在运行，则不启动新实例」，Linux 用 flock -n。

第三，别一上来就把全量交给定时器。首次通常是全量拉取，几百上千章一把梭，限流基本必中。先手动限定条数跑通（这类同步工具一般有 --limit 之类的参数，照旧以你那份 --help 为准），确认去重、字段映射都对，再放开全量。

延伸一句：源站改版导致的失败多半是连续性的，日志轮转 7 天的同时最好单独保留「每天最后一条记录」，否则光看当天日志判断不出失败跨了多久。