递增matchID抓取LOL对局数据时模块化代码死循环排查

核心根因 #

重构后的脚本存在两个明确的逻辑漏洞，共同触发了无输出挂起：

• 状态码分支存在逻辑缺口：将HTTP状态判断前置后，仅为200/429/503分支编写了完整流转逻辑，404分支缺失「跳出当前请求处理流程」的出口，同时把matchID += 1的步进逻辑写在了特定状态分支内部，而非整个请求流程的最外层。
• 重试逻辑无兜底退出阈值：429触发的等待重试循环没有设置最大重试次数，只要没有命中已编写处理逻辑的状态码，就会一直留在循环里空转。

为什么旧版代码能稳定运行 #

第一版“意大利面代码”是线性执行结构，matchID自增、下一轮请求触发的逻辑写在整个流程的最末尾，不管中间遇到429等待、404无效对局、503服务错误，走完单次请求的所有分支后都会强制执行步进，不会被某个状态分支截断执行流，所以不会卡死。

为什么仅处理49条数据后触发故障 #

前49次请求刚好全部命中200有效返回、或429等待后返回200的场景，没有触发存在缺口的404分支；直到请求到matchID=5995867084时，先触发429限流进入重试循环，多次等待后接口判定该ID不存在返回404，此时执行流落入没有出口的404分支：既不跳出重试循环，也不执行ID步进，也不打印任何日志，就进入了无限空转的挂起状态。

修复方案 #

1. 将matchID += 1的步进逻辑移动到单次请求处理流程的最外层，确保无论返回什么HTTP状态码、无论重试成功还是失败，只要当前ID的处理结束，就一定会进入下一个ID的请求，禁止把步进逻辑写在某个状态码的分支内部。
2. 给429/503的重试逻辑加硬限制：单个matchID最多重试5次，重试次数耗尽后直接标记为处理失败，强制跳出重试循环，禁止无限等待。
3. 补全404分支逻辑：命中404时直接打印「无效对局ID，跳过」的日志，立刻终止当前ID的所有处理流程，不要停留在重试循环内。
4. 增加最低粒度的进度日志：每处理10个ID打印一次当前进度、最新处理的matchID值，避免出现无输出挂起时无法定位卡点的问题。

快速验证方法：单独对故障ID5995867084发起请求打调试断点，观察返回404时的执行流，可直接确认是否卡在重试循环未退出、未执行ID步进。

内容的提问来源于stack exchange，提问作者sutbly