UniApp不能实现分布式锁，因其运行在隔离的用户端设备上，无法满足跨进程互斥要求；正确做法是前端调用已由后端（如SpringBoot/PHP+Redis）加锁保护的接口，并通过禁用按钮、校验token、不自行重试等方式配合锁机制。
Uni-app 本身是前端框架，不直接实现分布式锁；真正的分布式锁必须由后端服务（如 SpringBoot、PHP）基于 Redis 等中间件完成。你在 uni-app 里能做的，只是「正确调用带锁保护的接口」，并配合合理的前端行为防止重复提交。
为什么 uni-app 不能自己实现分布式锁
分布式锁的核心要求是「跨进程/跨机器的互斥性」，而 uni-app 运行在用户设备上（小程序、H5、App），每个实例彼此隔离，无法共享状态。你本地 setStorageSync 或 uni.setStorage 只对当前设备有效，对其他用户完全无效——这根本不是分布式，连“单机锁”都算不上。
常见误操作包括：
- 在 uni-app 里用
setTimeout+ 全局变量模拟“加锁”，结果多人同时点“下单”仍触发多次请求 - 把 Redis 的
SETNX命令直接写在 uni-app 的uni.request里，但前端根本没权限直连 Redis（且暴露连接信息极其危险） - 以为用
uni.showLoading挡住 UI 就等于防并发，其实 loading 只影响视觉，网络请求照发
uni-app 正确配合后端分布式锁的姿势
重点不是“怎么写锁”，而是“怎么不破坏锁”——前端要避免绕过或削弱后端已设好的锁机制。
- 按钮点击后立即置为禁用：
disabled属性 +button组件的loading状态，防止手抖连点 - 关键操作前校验 token 有效性，避免因登录态过期导致重复刷新页面后重发请求
- 不要自行重试失败请求（比如网络超时后自动再调一次
/api/seat/select），应由后端返回明确错误码（如423 Locked或自定义{"code": 409, "msg": "座位已被占用"}），前端只做提示，不重放 - 若后端用的是带过期时间的 Redis 锁（如
SET lock:seat:123 "1" NX PX 30000），前端不要假设锁一定长期存在，需接受“抢座失败”为正常业务分支
后端锁逻辑对 uni-app 接口设计的影响
后端是否用了分布式锁，会直接决定你调用接口时的参数、错误处理和用户体验设计。
- 接口响应时间可能变长（比如锁等待 1–2 秒），需调整
uni.request的timeout（建议 ≥5000） - 后端若用 Redisson，可能返回
RedissonBusyException并映射为 HTTP 423，uni-app 要专门捕获该状态码并提示“正在处理中，请稍候” - 锁粒度影响参数设计：例如选座接口必须传
seatId，后端据此生成lock:seat:{seatId}；如果前端传错或漏传，锁就失效 - 若后端锁 key 包含用户维度（如
lock:order:create:uid_456），则同一用户短时间内重复提交会被拦截，但不同用户仍可并发——这点需在 UI 上说明（如“每人限抢 1 单”）
真正容易被忽略的点是：前端日志里几乎看不到锁失败的痕迹，所有异常都被后端吞掉或转成业务错误。如果你发现“明明加了锁，还是出现超卖”，第一反应不该是改 uni-app，而是查后端锁 key 是否拼错、过期时间是否太短、释放锁逻辑是否遗漏（比如没 unlock() 或异常未兜底）。
