事由
上午手动触发供应商风险巡检任务，运行 3 秒即失败。界面上给出的提示被概括成一句话：「数据库没连接上」。
如果顺着这句话去查数据库，方向从一开始就是错的。这个问题本可以用 20 秒避免，而它暴露的认知盲区，比故障本身更值得记录。
第一步：先证明「是好的」，而不是去证明「是坏的」
排查故障时最容易犯的错误，是接受别人（或系统）对错误的转述，然后顺着转述去验证。证据链一旦从二手描述开始，后面所有动作都在给一个假命题找解释。
所以第一步不是问「数据库为什么连不上」，而是直接跑一次取数，看它到底能不能跑通。
让取批脚本原样执行一次，结果很干脆：库里 596 家供应商，按名称升序正常取出了今天的 5 家名单，序号、轮次、排除测试占位，全部符合预期。
能做完整的数据往返------连库、读表、筛选、排序、输出------这条链路就是通的。数据库无罪，一案撤销。
第二步：去找报错的原文，而不是听它被怎么讲
数据库被排除后，问题回到那句提示本身。关键动作只有一个：去日志里找原始报错，而不是继续接受转述。
翻了运行日志，原文长这样：
定时任务依赖的数据源（连接器）均未连接成功：tyc-mcp。该任务为无人值守运行，已终止以避免产出无效结果；请检查连接器授权状态（可能需要重新登录授权）后重试。
真相在这里：是连接器，不是数据库。 界面把这一长串收敛成「未连接成功」，转述过程中又丢掉了主语，最终变成「数据库没连上」------一个听起来精确、实际完全错误的结论。
顺带还发现一条经验：这次失败的运行记录，只在主进程日志里有完整留痕，任务自己的日志里几乎没有。排查时只盯一个日志文件，等于自己蒙住一只眼。
第三步：状态正常 ≠ 运行正常
连接器的体检结果很反直觉：
- 状态文件里，凭据
bound: true、启用位enabled: true------文件层面一切正常
- 但体检脚本判定的结论是：OAuth 凭据已失效，需要重新授权
- 工具检索也确认：连接器的工具根本挂载不上
这就是最容易被骗过去的地方。「配置显示已启用」和「运行时真的连得上」是两件事。 前者是磁盘上的一个布尔值，后者是运行时握手的结果。只看配置文件，你会得到 100% 的安全感，和 0% 的可用性。
而且这类故障有个硬边界：改状态文件没用，重启客户端也没用。 它只能由人走一次重新授权。如果不区分「凭据失效」和「被停用」这两类故障，就会把时间浪费在无效的自愈手段上------反复重启、反复改文件，然后怀疑人生。
三条可复用的结论
- 验证输入别验证结论。 先用一个最小可执行动作证明某条链路是好的，比讨论它为什么坏高效得多。
- 只认原始报错。 任何转述都是信息损耗，主语、对象、原因都可能在中途掉队。
- 区分「配置态」和「运行态」。 配置文件说正常，只是说明它没被改坏，不代表服务真的在跑。
故障排查真正的成本，往往不在修，而在一开始找错了要修的东西。