关键在于背压责任主体与释放时机：UI或容器线程（如Tomcat工作线程、Android主线程、RN JS线程）绝不可被CallerRunsPolicy拖入耗时任务，否则导致卡死；需通过线程dump验证，并配合限流、有界队列、非阻塞拒绝策略及前端协同防御。
关键不是“要不要背压”，而是“背压压力该由谁承担、何时释放”。界面卡死往往不是因为没背压，而是背压错误地压在了 UI 线程或 Web 容器线程上——比如 Tomcat 的 http-nio-8080-exec 线程被 CallerRunsPolicy 拖住执行耗时任务，导致后续请求排队、前端白屏、超时雪崩。
识别调用者线程的真实身份
很多开发者误以为“调用线程 = 业务线程”，其实不然：
- Spring MVC 接口里
executor.submit()的调用者，是 Tomcat 的工作线程（非守护线程，不可长时间阻塞） - Android 中
Handler.post()后再提交到线程池，调用者是主线程（UI 线程，绝对禁止 IO 或耗时计算） - React Native 的 JS 线程调用原生模块提交任务，调用者是 JS 主线程（同样不可阻塞）
一旦这些线程被 CallerRunsPolicy 拉去同步执行数据库查询、HTTP 调用或序列化，界面立刻无响应。验证方法：线程 dump 中搜索 http-nio 或 MainThread，看其堆栈是否停留在你的业务 run() 方法内。
对外接口层：用 CallerRunsPolicy + 主动限流，不给卡死留机会
API 层允许背压传导，但必须控制传导强度和范围：
- 搭配网关级限流（如 Spring Cloud Gateway 的
RequestRateLimiter），在流量入口就削峰，避免大量请求抵达线程池 - 设置合理的队列长度（按公式
queueSize ≈ (QPS × P95耗时) × 1.5计算），防止队列积压掩盖问题 -
禁用无界队列：Spring Boot 默认
queueCapacity = Integer.MAX_VALUE，等同于关闭背压信号，必须显式覆盖
内部服务调用：拒绝策略只记日志+发指标，绝不阻塞
服务间 RPC 或消息消费场景，调用者通常是业务线程，但它的职责是编排，不是执行：
- 自定义拒绝策略中禁止任何 IO：不写文件、不发 HTTP、不调远程监控接口；日志仅
warn级 + 采样（如 1% 打点） - 触发 Prometheus 告警指标（如
threadpool_rejected_total{service="order",policy="custom"}），让运维感知而非代码等待 - 对非核心任务（如埋点上报、缓存预热），可降级为同步重试一次，但必须设超时（
try-with-resources + Future.get(200, MILLISECONDS)）
前端与移动端的协同防御
后端背压必须有前端配合，否则用户反复点击只会加剧恶化：
- 按钮点击后立即置灰 + 加载态，禁用重复提交（防用户狂点放大压力）
- HTTP 请求配置合理超时（建议 connect=1s、read=3s），避免前端无限等待已卡住的后端线程
- 关键操作（如支付）增加客户端本地熔断：连续 3 次 503/timeout 后，主动降级提示“系统繁忙，请稍后再试”，不重试
