每次重启都要手动点一下，它才肯干活

守望先锋那个查分插件有个怪毛病：服务器重启后一定用不了。

不是报错，是查了没结果——接口返回空，或者干脆超时。但只要你在群里发一条 /重启后端，它立刻恢复正常，之后一直好好的，直到下次重启。

这个现象反复出现过好几次，每次都是同样的流程。我第一次遇到的时候当成偶发问题，查了一轮日志没看出所以然，用手动重启糊过去了。第二次又出现，才意识到它是有规律的。

"手动一下就好"这条线索很值钱

先想清楚这句话说明了什么：

代码逻辑是对的。 手动触发一次后能正常工作，而且能一直工作，说明初始化那套流程本身没写错。

问题只在启动的那一个时刻。 一定是重启后某个东西没就绪，而插件的初始化没等它——或者说，插件的初始化在那一刻做了个错误的判断，然后把自己标记成"未就绪"，之后也不会自己再试一次。

这两条合起来，排查方向就很明确了：别看运行时的业务逻辑，去看启动阶段。

这类问题我看下来主要是两种。

第一种是依赖没就绪就初始化。 插件初始化时要连一个后端服务或者读一个文件，而服务器刚起来的时候那个服务还没监听。连接失败 → 插件把状态设成失败 → 之后不再重试，等着人来手动按一下。

判断方法很简单：重启之后先等两分钟再查，如果等一会儿就好了，那就是时序问题；如果等多久都不行，必须手动触发，那就是"失败后不重试"。

第二种是懒加载的触发条件写死了。 后端不是启动时连的，而是第一次被调用时连的。这个设计本身没问题，但如果初始化那一层缓存了一个"后端不可用"的结果，后续调用就直接返回缓存，永远不会真的去连一次。

/重启后端 干的事就是把这个缓存清掉，强制重新连接——所以一按就好。

我把这个现象记录了好几次，每次修完过一阵又出现。原因是我每次都只处理了症状：让插件在启动失败后能重试，或者调整后端服务的启动顺序。

真正该做的是把依赖关系声明清楚——让插件的启动等待它所依赖的服务真正可用，而不是"启动之后就假定可用"。

一个可以立刻做的检查：重启服务器，然后什么都不做，看插件需要多久自己恢复。 如果答案是"永不恢复"，那它缺的就是启动依赖，不是别的。

这个插件依赖的后端在那台服务器上跑着，状态一直是"存活但上游挂了"——它自己活着，但它去查数据的那个上游接口全挂。等于说这插件有两个独立的失败点：本地的启动时序问题，和外部接口的可用性问题。

排查的时候这两者会混在一起，看着像是同一个毛病。分辨方法是手动触发一次：如果手动之后能用了，那就是本地时序；如果手动之后还是不行，那问题在上游。