"@vendor/ocr-sdk": "3.1.4" npm ls @vendor/ocr-sdk
SDK 升到 3.2 之后，返回多包了一层 data，老代码 resp['result']['lines'] 拿到 None，前端列表直接空白。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，3.x 把公共响应头抽出来统一放在 data 外层，属于不兼容变更，只在 changelog 写了一行。依赖写的是 ^3.0，构建时自动拉到了 3.2。
这次卡住的地方就在「识别结果结构升级」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。
一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
处理上按这个顺序：依赖锁到具体小版本 不用范围符；升级前用十张固定样本跑回归；解析层做兼容 两种结构都尝试；CI 里加一条结构断言。
改完只确认一件事：锁版本后返回结构稳定 CI 的结构断言连续通过。