curl -s 'localhost:8080/api/order/123' | jq 'keys' curl -s 'localhost:8080/api/order/123?forceDegrade=1' | jq 'keys'
订单详情接口降级时返回 {code:0, msg:'服务繁忙'}，正常返回里有 data.orderNo。前端直接解构 data 抛 TypeError: Cannot destructure property 'orderNo' of undefined，页面白屏。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：降级分支是后补的，只对齐了 code 和 msg，没有对齐业务字段。前端默认成功响应一定带 data，解构时没做防御。
「降级返回结构」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。同一份配置存在多处的，先确认改的是被加载的那一份。
新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
处理上按这个顺序：降级返回保持和正常响应一样的字段结构 值可以为空；用同一个响应类构造 避免手写 map；前端对 data 做默认值处理 不要直接深层解构；加契约测试 校验正常和降级两种响应字段一致。
确认没问题再收工，两种响应 keys 完全一致，前端在降级时显示服务繁忙提示而不是白屏。