uni-app本身不处理限流，需后端在Spring Boot、Node.js或Nginx层实现IP限流、令牌桶等策略；前端仅能配合响应429状态码、禁用按钮、弹出验证码并缓存请求时间戳防连点。
uni-app 本身不处理限流，得靠后端配合
uni-app 是前端框架，所有接口请求最终发到你的后端服务。它没法自己做 IP 限流、令牌桶或滑动窗口——这些必须在 Spring Boot、Node.js 或 Nginx 层实现。前端能做的只有配合：比如检测到 429 Too Many Requests 时友好提示、自动加验证码、拦截重复提交按钮。如果你发现 uni-app 里“刷接口”现象严重，第一反应不该是改前端代码，而是检查后端有没有对 /api/send-code、/api/login 这类敏感接口加限流逻辑。
后端限流 key 怎么设计才防住 uni-app 多端场景
uni-app 编译成微信小程序、H5、App 后，同一个用户可能有多个身份标识：
- 微信小程序：用
openId或unionId（推荐）作为限流 key - H5：依赖登录态的
userId或token解析出的 subject，不能只靠ip（同一校园网下全是相同 IP） - App：可用设备 ID（如
plus.device.getInfo().uuid）+ 登录态组合，避免单台手机多账号轮刷
错误做法："limit:ip:" + ip —— H5 场景下完全失效；正确写法示例："limit:login:" + userId 或 "limit:openid:" + openId。Spring Boot 中建议用 Redis + Lua 脚本保证原子性，尤其在高并发选课扣减这类场景下，固定窗口计数器容易被跨窗口绕过。
uni-app 前端怎么配合防刷不露馅
后端返回 429 或自定义码（如 { code: 429, msg: "请求太频繁，请稍后再试" }）后，uni-app 要做三件事：
- 禁用触发按钮（如“获取验证码”），并倒计时恢复，避免用户狂点
- 若后端返回需验证码（如
needCaptcha: true），立即弹出uni.showModal或集成极验 SDK，而不是等下一次请求再报错 - 对登录、注册等关键流程，前端缓存最后一次请求时间戳，间隔不足 1.5 秒直接拦截（防手抖连点）
注意：不要在前端做“IP 获取”，uni.getSystemInfoSync().platform 只能判断端类型，真实 IP 必须由后端通过 X-Forwarded-For 或 Nginx $remote_addr 提取。uni-app 里任何“前端限流”都只是掩耳盗铃。
为什么 Nginx 层限流对 uni-app 特别重要
很多团队只在 Spring Boot 里做限流，结果恶意请求早就在到达应用前就打爆了连接池。Nginx 是第一道闸口，对 uni-app 尤其关键：
- H5 页面走公网域名，Nginx 可基于
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s控制单 IP 频率 - 微信小程序调用后端 API 时，若走的是统一网关域名，Nginx 还能结合
Referer头过滤非微信域名的非法请求 - 配置
limit_req时记得加burst和nodelay，否则 burst 请求会排队，导致 uni-app 请求超时（默认 timeout 是 10s）
真正容易被忽略的点：Nginx 的限流 key 如果只用 $binary_remote_addr，在企业内网或运营商 NAT 环境下会误杀正常用户。更稳妥的是结合 $http_x_forwarded_for（需后端信任该头）或要求 uni-app 在 header 里带上轻量设备指纹（如 X-Device-Sign: md5(ua + model)），后端校验后透传给 Nginx。
