工具调用随机失败时，把执行通道挪到后台队列

工具调用随机失败时，把执行通道挪到后台队列

做每日自动化两周，遇到过最诡异的一类故障：同一条命令，第一次跑成功，第二次报 `spawn EPERM`，第三次又好了。连 `Get-Date` 这种纯读命令都会中招。这篇记录定位过程和最后定下来的降级方案。

## 一、现象：失败没有规律，但集中在"前台"

最初以为是权限问题，因为报错字面是 EPERM。但同一会话里，有的命令能跑、有的立刻失败，失败的命令重试一次又可能成功；而且失败不挑命令复杂度，读时间、读文件、调外部程序都会中招。

更关键的一条观察：把完全相同的命令改成后台方式提交，连续几十次没有一次失败。于是基本可以排除"命令本身触发了什么限制"，问题出在调用通道上——前台同步调用某种资源时，偶尔拿不到句柄；后台进程走的是另一条路径，不受影响。

这类问题最难查的地方在于它没有稳定复现条件。如果按"换个写法再试"的思路排查，会被随机成功误导，浪费大量轮次。正确的做法是先统计：同一命令在前台与后台各跑 N 次，看失败率是否呈现 0 与"明显大于 0"的分界。分界一出来，结论就定了。

## 二、前台为什么会卡

前台模式需要父进程创建子进程、接管道、等退出、收输出。中间任何一环被占用或超时，整条链就断。而后台模式把"提交"和"取结果"拆成两次交互：提交只要把任务交出去，取结果时任务早跑完了。拆开之后，等待和管道都不在关键路径上。

顺带一个附带症状：前台失败时错误来自宿主而不是命令本身，命令的退出码、标准输出都拿不到。这意味着任何依赖"看返回值判断下一步"的脚本，在这种环境下都不可靠——它连失败原因都读不到。

## 三、降级方案：后台提交 + 文件交接

改造分三步。

第一步，把动作序列写成独立脚本文件，而不是拼在一条长命令里。长命令既难复用，也容易被引号规则坑：Windows PowerShell 5.1 给原生可执行文件传带双引号的 JSON 参数时，内层引号会被吞掉，解析直接报 `key must be a string`。写成脚本文件后，参数由脚本自己拼装，绕开这一层。

第二步，用后台方式执行脚本，让脚本把结果写进文件，而不是靠标准输出回传。标准输出在后台模式下可能被截断或延迟，文件是确定的：脚本写、另一个工具读，双方只约定路径和格式。

第三步，结果文件里同时落"日志"和"证据"。日志记每一步的返回摘要，证据是页面观察文本、返回的 JSON 片段。这样即使执行端和读取端不在同一进程，也能完整回放当时发生了什么。排查时先看日志定位失败步骤，再看证据确认页面状态，不用重跑。

## 四、脚本化之后必须守住的三条纪律

一是脚本文件保持纯 ASCII。PowerShell 5.1 会把无 BOM 的 UTF-8 脚本当 ANSI 读，中文注释和字符串会变成乱码，导致解析报 `Missing ')' in function parameter list`。需要中文匹配时，用字符码在运行时拼字符串，例如用 `[char]` 数组 join 出目标词，脚本本身不含任何非 ASCII 字节。

二是每次动作前重新取上下文。浏览器自动化里元素引用号会随页面变化重新编号，跨轮次复用旧引用必然失败。所以流程统一是：同步一次 → 观察一次 → 从观察里提取当前引用 → 执行动作。四步写在一个脚本里，不留跨脚本的隐式状态。

三是动作与观测分离。写操作只负责改变状态，状态判断交给独立的观察步骤。曾经把"点击后立即断言文本变化"塞进同一个调用，结果页面异步渲染还没完成，断言读到旧值，白白重试了好几轮。分开之后，等待多久、读什么、怎么判都是显式可控的。

## 五、小结

遇到随机失败，先别改命令，先改通道：把同步前台换成后台提交，把标准输出换成文件交接，把长命令换成可回放的脚本。这三件事做完，故障从"时好时坏"变成"要么成功要么有明确日志"。对长期跑的定时任务来说，可诊断性比单次成功率更重要。