一个每天定时跑的批处理，里面有两步 python。你手动双击运行过，一切正常。可到了定时执行的时候，第一步跑得好好的，第二步却持续失败，日志里就一句"无法打开文件"。更麻烦的是没人及时发现——数据就这么静默地断了 5 天。这种"跑了一半"的故障，比彻底不跑更隐蔽。
现象
具体表现：
- 定时批处理里有两个
python调用，第一步正常，第二步持续失败； - 失败时的报错是"无法打开文件"，而它去找脚本的位置，是系统目录（比如
C:\Windows\System32），而不是脚本所在的目录； - 手动双击运行同一个批处理，却正常；
- 因为失败是静默的（没告警、没上抛），问题拖了 5 天才被发现。
根因
关键在于：计划任务启动批处理时，工作目录是"系统目录"，不是脚本所在目录。
要理解这点，先分清两个概念：
- 脚本的位置：批处理文件和它引用的 python 脚本，实际放在某个目录里；
- 工作目录（当前目录）：进程启动时所在的目录。相对路径是相对于这个目录去解析的。
当你手动双击一个批处理时，系统默认把批处理所在的目录设为工作目录。于是脚本里写的相对路径（比如 scripts\etl.py）会相对于批处理目录解析——找得到，一切正常。
但当计划任务来启动这个批处理时，如果没有显式设置"起始位置"，工作目录默认是系统目录。这时脚本里的相对路径就变成了相对于系统目录去解析，于是去 C:\Windows\System32\scripts\etl.py 这种地方找文件——当然找不到，报"无法打开文件"。
为什么是"第二步"失败而不是第一步？因为第一步恰好用了能正常解析的路径（比如相对路径碰巧对上了，或者用的是绝对路径），而第二步用了相对路径，就踩中了这个坑。这也解释了"手动正常、定时失败"的诡异现象：区别不在脚本，在谁启动它、在什么工作目录下启动。
解决
原则：定时任务里，所有解释器与脚本一律写绝对路径，并显式设置起始位置。
一、把脚本里的相对路径全部改成绝对路径。
@echo off
REM 用绝对路径，别用相对路径
"C:\Python311\python.exe" "C:\data\etl\step1_fetch.py"
"C:\Python311\python.exe" "C:\data\etl\step2_load.py"
解释器（python.exe）也用绝对路径，避免依赖 PATH 环境变量——因为计划任务的环境和交互式登录的环境也可能不一样。
二、在批处理开头显式切换到脚本所在目录。 用批处理自己的路径变量，让"当前目录"变成"批处理所在目录"：
@echo off
REM %~dp0 是"当前批处理文件所在目录"，cd /d 带盘符切换
cd /d "%~dp0"
REM 之后相对路径就相对批处理目录了
python step1_fetch.py
python step2_load.py
%~dp0 是批处理的一个内置变量，展开成"当前脚本所在目录（含尾部反斜杠）"；cd /d 带上 /d 才能跨盘符切换。这样即便工作目录被设成了系统目录，脚本也会先切回自己的地盘，相对路径就稳了。
三、在计划任务的配置里显式设置"起始位置"。 不管用 GUI 还是命令行，都指定一个明确的起始目录：
REM 用 schtasks 创建/修改时指定 /tr（要运行的程序）和显式的工作目录
schtasks /create /tn "每日ETL" /tr "C:\data\etl\run.bat" /sc daily /st 02:00 /ru SYSTEM
在"任务属性 → 操作 → 编辑"里，也有"起始位置（可选）"这一栏，填上脚本所在目录。显式设置它，别留空——留空就是那个坑的开始。
四、让失败可见。 这条事故拖了 5 天，根本问题是失败没被上抛。给脚本加上结束状态的记录与告警：
REM 检查上一步是否成功，失败就记日志/发提醒
"C:\Python311\python.exe" "C:\data\etl\step2_load.py"
if errorlevel 1 (
echo [%date% %time%] step2 FAILED >> "C:\data\etl\error.log"
REM 这里可以接一个发邮件/发消息的动作
)
关键是别让脚本"安静地失败"——有错误就记、有错误就通知，这样断一天就能发现，而不是断五天。
延伸与预防
这条坑的通用价值，就是那句话：定时任务里永远用绝对路径。
更抽象一点，是**"手动跑得好"不等于"自动跑得好"**。手动执行和定时调度，环境差异比想象中大得多：
- 工作目录不同（本例）；
- 环境变量不同：计划任务（尤其以系统账户运行时）不一定有你登录时的 PATH，命令找不到；
- 用户身份不同：以 SYSTEM 或其它账户跑，可能没有网络盘、没有用户级配置、没有权限访问某些资源；
- 交互能力不同：没有桌面会话，涉及 GUI、弹窗、需要交互的操作会失败；
- 启动时机不同：可能在上一次还没跑完时又启动，造成并发冲突。
所以把"手动能跑"当成"自动没问题"，是危险的。正确做法是按最保守的假设来写：路径全绝对、需要的东西自己设（环境变量、目录）、运行身份明确、失败要可见。写完先在计划任务里手动触发一次验证，看它在这个环境下是否真的跑通，再让它进入每日调度。
最后一条经验值得单独记：静默失败是最贵的故障。一个每天跑的任务，失败了没人知道，损失是按下限累计的（本例是 5 天的数据）。所以任何定时任务，都该配上"跑完/失败"的可见信号。能自己喊出来的自动化，才是可靠的自动化。