推荐接口熔断后走 fallback，直接返回 new ArrayList()，前端拿到 code 0 和空 data，页面显示「暂无推荐」。当天客服收到 47 条反馈说内容被清空了，实际是下游超时。乍看像缓存或者权限的锅，追下去往往不是。
curl -s 'localhost:8080/api/recommend?uid=10086' | jq '{code,degraded,size:(.data|length)}'
curl -s 'localhost:8080/api/recommend?uid=10086' | jq '.data'
追下去是这么回事：降级分支只保证了结构不报错，没有告诉调用方这是兜底结果。前端按 length 判断有无数据，空数组和真的没有数据长得一模一样。
「降级返回空数据」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
具体做法是，fallback 里带上 degraded 标记或者单独的 code 让调用方能区分；前端在 degraded 为 true 时显示重试入口 不要显示暂无数据；兜底内容改成上一次成功结果的缓存 而不是空集合；补一条降级计数 统计每个接口每天走兜底的次数。
验收就看一点，把下游打挂后接口返回 degraded=true，页面显示重试提示，不再出现「暂无推荐」。