配套的删除提示放在前端做删除对话框里前端自己调 GET /v1/applications?resume_id… 数一下显示「这份简历关联了 3 条投递记录删除后这些记录仍会保留简历名称但无法再查看原文件」。前端本来就同时持有两个服务的调用权限这是标准的 BFF 式聚合后端两个服务依旧互不认识。BFF式聚合是什么?文章目录BFF 式聚合BFF 是什么核心思想你这段场景的特殊之处原文场景拆解一句话总结BFF 式聚合BFF 是什么BFFBackend For Frontend是一种架构模式意思是为前端服务的后端层。它位于前端和底层微服务之间专门负责为特定的前端界面做数据聚合和格式适配。┌──────────┐ ┌──────────┐ ┌──────────────┐ │ 前端 │ ──→ │ BFF 层 │ ──→ │ 微服务 A │ │ (App/Web)│ │ (聚合层) │ │ (简历服务) │ └──────────┘ └──────────┘ └──────────────┘ │ ┌──────────────┐ └───────→ │ 微服务 B │ │ (投递服务) │ └──────────────┘核心思想底层微服务之间互不认识、互不依赖简历服务不知道投递服务的存在BFF 层负责跨服务编排和聚合把多个微服务的数据拼成前端需要的样子前端只跟 BFF 打交道不用关心底层有多少个服务你这段场景的特殊之处原文说的其实是一种变体——前端自己充当了 BFF 的角色维度传统做法后端聚合原文做法前端 BFF 聚合聚合位置后端 BFF 层前端自己调用关系前端 → BFF → 微服务A B前端 → 微服务A B后端耦合后端需要写聚合逻辑后端两个服务完全解耦实现成本后端要加接口前端多调一次请求原文场景拆解前端要做的事 1. 调简历服务DELETE /v1/resumes/{id} ← 删简历 2. 调投递服务GET /v1/applications?resume_id... ← 查关联投递数 3. 前端自己拼结果「关联了 3 条投递记录...」前端同时持有两个服务的调用权限自己编排两次请求、自己聚合展示。后端两个服务简历服务、投递服务依然互不认识各自只管自己的事。一句话总结BFF 式聚合 把跨服务数据拼装这件事从后端挪到前端或专门的中间层来做让底层微服务保持纯粹的单一职责互不耦合。