Windows 计划任务不执行：账号、目录与返回码排查
本文适用于 Windows Server 2022、2025。计划任务是否可靠，需要同时检查“按时触发、进程启动、脚本完成、业务结果有效”四个阶段。任务显示运行成功，只能说明调度器观察到对应状态，不能代替对备份文件、导出结果或数据同步的检查。
先确认触发记录与实际结果
在任务计划程序中查看任务是否启用、最近运行时间、下次运行时间和上次运行结果，核对触发器日期、时区解释及重复周期。若任务历史未启用，不能期待找回此前没有记录的详细执行过程。
# 服务器：替换为实际任务名称与任务路径，只读检查
Get-ScheduledTask -TaskName 'DemoDaily' -TaskPath '\Ops\' |
Select-Object TaskName, State, Principal,
Actions, Triggers, Settings
Get-ScheduledTaskInfo -TaskName 'DemoDaily' -TaskPath '\Ops\'
任务路径必须与实际保存位置一致。返回结果中的运行时间和错误码可作为调查起点，参数见 Get-ScheduledTaskInfo 文档。若启动时间根本没有更新，优先查触发器、禁用状态与条件；若进程已启动，则继续查动作和脚本日志。
使用完整路径和明确的工作目录
交互终端里运行脚本时，你通常已处于正确目录。计划任务未必如此：未指定动作工作目录时，常见默认工作目录是 %windir%\system32。依赖相对路径读取配置或写结果的脚本，因此可能找不到文件，或写到了意料之外的位置。
在“操作”中把程序、参数和“起始于”分别填写。使用实际解释器完整路径，参数可以采用 -NoProfile -NonInteractive -File "C:\Ops\Job.ps1"，工作目录设为已确认的 C:\Ops。不要把整条命令塞进程序路径，也不要把执行策略绕过参数当成常规故障修复方式。
动作字段的用途见 New-ScheduledTaskAction 文档。修改前导出任务定义并记录原动作；验证时使用任务实际指定的解释器版本，避免手动测试与调度执行不同版本的 PowerShell。
以任务账号核查权限和环境
“仅在用户登录时运行”与“不管用户是否登录都运行”会影响执行环境。核查任务配置的身份、凭据是否过期、账号是否被锁定，以及访问目标文件和网络资源所需权限。提高到最高权限并不会自动解决网络身份或文件路径错误。
后台任务通常不应依赖交互会话映射的盘符。需要访问共享时，使用明确的 UNC 路径，并确认任务身份具备访问条件。脚本依赖的环境变量、代理设置、证书和用户配置，也应按任务身份检查。
不要把密码直接写进脚本、参数或日志。遇到凭据问题，应使用组织允许的身份管理方式修正。为了排障临时提升权限时，应有明确范围并及时恢复，避免让一个普通导出任务长期获得整台服务器的管理权限。
让脚本正确报告失败
脚本应使用绝对输出路径，记录开始、结束、关键阶段和错误信息，并在失败时返回非零退出码。PowerShell 中部分错误默认不会终止脚本，通常需要在合适范围内设置 $ErrorActionPreference = 'Stop'，再通过 try/catch 记录错误和返回失败。
调用外部程序时还应检查它的退出码，不能假定 PowerShell 的错误处理自动覆盖全部失败。记录日志时避免输出令牌、连接密码或完整敏感数据。对日志目录设置大小与留存策略，防止可靠性日志最终填满磁盘。
返回码为零仍应结合业务产物验证。例如备份任务需要检查文件属于本次运行、大小合理且可恢复；只创建一个空文件也可能让脚本“成功”。
重试与错过运行需要业务规则
在任务设置中检查运行超时、失败重试和已有实例时的处理方式。长任务若允许重叠执行，可能同时写同一个文件或重复处理订单。应根据业务选择等待、跳过或拒绝并发，并让脚本具有必要的锁或幂等机制。
“错过计划时间后尽快运行”也不适合所有任务。补做一次报表与补发一批通知的影响不同，需要先明确业务期望。修改触发和恢复策略后，通过受控测试验证一次成功、一次失败及对应告警，再观察自然触发是否按预期执行。用于备份时，可结合备份恢复指南制定最终验收条件。