uni-app本身不支持分布式锁，死锁异常必由后端引发；前端只能识别拦截错误码、设置请求超时、清理加载态、禁用重复提交并上报日志，无法解决死锁本身。
uni-app 本身不支持分布式锁，死锁异常一定是后端引发的
uni-app 是前端框架，所有锁逻辑（Redis 分布式锁、数据库行锁、Redisson 可重入锁等）都运行在 SpringBoot 或其他服务端。你在 uni-app 里看到的“死锁异常”，实际是前端收到了后端返回的 500、503 或自定义错误码（比如 "LOCK_TIMEOUT"、"DEADLOCK_DETECTED"），或是请求长时间卡在 pending 状态后超时失败。
真正发生死锁的环节永远在服务端：比如两个事务按不同顺序更新 seat 和 order 表，或 Redis 锁未设置过期时间 + 客户端崩溃导致锁残留。uni-app 能做的只有识别、拦截、降级，而非“解决”死锁本身。
前端如何识别并规避死锁导致的 UI 异常
用户连续点击选座/下单按钮后页面卡住、按钮变灰无响应、loading 一直转——这往往是后端因死锁重试失败后返回了异常，但前端没做状态清理。关键不是“防死锁”，而是“不让用户感知到死锁”。
- 所有涉及锁的操作接口（如
selectSeat、acceptOrder）必须配置明确的超时时间，uni-app 中用timeout字段，建议 ≤8000ms（避免用户等待超过 8 秒） - 请求发起前立即置
isSubmitting = true，并在finally块中重置，哪怕请求失败或超时也必须执行 - 对后端返回的特定错误码做显式拦截：
"DEADLOCK_DETECTED"、"LOCK_ACQUIRE_FAILED"、"DB_TRANSACTION_ROLLBACK"，统一提示“操作太拥挤，请稍后再试”，而不是静默失败 - 禁用按钮的同时加 UI 遮罩（
uni.showLoading({ mask: true })），防止用户误以为卡死而反复退出重进
为什么在 uni-app 封装层加“重复请求拦截”反而加剧死锁感知
你可能在请求封装里写了类似下面的逻辑：
const pendingSet = new Set();
const request = (config) => {
const key = `${config.url}_${JSON.stringify(config.data)}`;
if (pendingSet.has(key)) return; // ❌ 卡死根源
pendingSet.add(key);
wx.request({ /* ... */ complete: () => pendingSet.delete(key) });
};
这个写法在弱网+重复点击场景下会直接导致页面“点不动”：第 1 次请求 pending，第 2 次被拦截且没返回 Promise，第 3 次同样被拦截……最终所有后续点击都石沉大海，因为没有 resolve/reject，Promise 链彻底断裂。这不是死锁，但用户体感一模一样。
正确做法是：拦截后仍返回一个被 reject 的 Promise，让调用方能 catch 并做 UI 恢复：
if (pendingSet.has(key)) {
return Promise.reject(new Error('request_already_pending'));
}
最容易被忽略的调试盲区：App 端看不到后端真实错误栈
你在微信开发者工具里能看到完整的 500 Internal Server Error 响应体，但在 iOS/Android App 中，uni.request 的 fail 回调往往只返回 err.errMsg = "request:fail timeout" 或空对象——因为原生 WebView 层做了错误裁剪。你根本不知道后端是不是抛了 PessimisticLockingFailureException 或 MySQL 的 Deadlock found when trying to get lock。
必须在后端日志中确认死锁发生点，前端只能配合：在 App 端对所有锁相关接口启用强制日志上报（带 traceId），并在 uni.onUnhandledRejection 中捕获未处理的请求拒绝，把 url、data、timestamp、networkType 打包上报，否则问题永远定位不到。
