手动触发了一个计划任务，想看看跑得怎么样。于是立刻查询任务状态，看到"上次结果"那一栏是一个六位数——267009 之类的。数字这么大，看着就像个严重的错误码。你开始怀疑任务是不是卡死了、是不是又失败了，甚至准备去翻日志排查。
先别急。那个数字不是错误，它说的是"任务此刻还在运行"。
现象
具体表现：
- 手动触发一个计划任务，马上去查询它的状态；
- "上次结果"（Last Result / Last Run Result）显示出一个六位数，看起来像严重错误码；
- 任务"状态"那一栏写着"正在运行"（Running）；
- 过一会儿再查，结果变成 0，任务也显示"就绪"了。
根因
关键在于：那个数字是"任务仍在运行"的状态码，不是失败码。
Windows 计划任务的状态用一组数值表示，常见的几个：
- 0：
SCHED_S_TASK_HAS_NOT_RUN的反面——成功完成的常规结果，你可以把它读成"正常结束，无错误"； - 267009（十六进制 0x41301）：
SCHED_S_TASK_RUNNING，任务正在运行； - 267011（0x41303）：
SCHED_S_TASK_HAS_NOT_RUN，任务从未运行过； - 其它一些以 0x413xx 开头的值，也都是"调度器状态"而不是"任务业务错误"；
- 真正表示失败的，通常是非零的业务退出码（取决于脚本/程序自己返回什么）。
问题就出在这个数字又大又不像 0，直觉上就把它当成了错误码。而实际上，这是一组有含义的枚举值：这个六位数恰好代表"正在跑"。因为你刚触发就立刻查询，任务还没结束，自然报"正在运行"——这不是故障，是时机问题。
换句话说：你在任务还没跑完的时候问"结果如何"，得到的回答是"还在跑"，这完全合理。
解决
判断计划任务成功与否，要等它跑完再看。 具体做法：
一、先看状态列，再看结果列。 查询时用详细模式，同时看"状态"和"上次结果"：
schtasks /query /tn "任务名称" /v /fo LIST
输出的字段里，"状态"（Status） 会明确写"正在运行"还是"就绪"（Ready）。只要状态显示"正在运行"，那个六位数的"上次结果"就该被读成"运行中"，不是失败。
二、等任务结束再判断。 隔一会儿、或等任务该结束的时间点之后，再查一次。状态变回"就绪"、结果变成 0，就是成功。
三、更可靠的办法：看脚本自己的日志。 与其纠结调度器那个状态码，不如让脚本自己输出"开始/结束"的标记。脚本跑完写一行"完成"，报错写一行"失败 + 原因"，这样你一眼就知道到底跑没跑完、成没成。前面就有一条相关的教训：判断任务有没有跑完，看脚本自己的日志里有没有结束行，比看调度器的状态码直观得多。
四、如果结果真的是非零而且不是那几个 0x413xx 状态码，那就是任务真的失败了（脚本返回了非零退出码，或程序崩溃）。这时候再去查脚本的逻辑和它自己的日志——这才是需要修的。
一个小提醒：不同 Windows 版本、不同工具下，"上次结果"的展示形式可能略有不同，但含义是一致的：先分清"状态"和"结果"，再解读数字。
延伸与预防
这条坑的通用价值，是那句很基本的话：状态码要看含义，不要按数字大小猜严重程度。
数字大小和严重程度之间没有关系。一个267009看着吓人，其实是"一切正常，正在运行"；一个1看着不起眼，可能才是真正的失败。类似地：
- HTTP 状态码里，4xx/5xx 是"错误"，但
304 Not Modified是"内容没变，用你的缓存"，完全正常； - 进程退出码里，
0是成功，其它都是失败——但具体含义要看程序自己怎么定义，有的程序用非零表示"有警告但完成了"； - 字符串返回值、枚举值，更是必须查文档。
所以看到任何状态/结果/错误码，先做一件事：查它的定义。别靠数字大小、别靠"看着像"来猜。这能避免一大批"把正常状态当成故障"的虚惊，也能避免反过来"把一个真错误当成正常码"漏掉问题。
预防上，给自己的自动化留好可读的结束标志：任务跑完打印一行明确的结果，比依赖调度器的数字更直观、更不容易误读。毕竟，让运行者自己说清楚"我跑完了、结果是什么"，永远比让外面的人去猜一个数字要可靠。