光靠前端拦截没用，必须服务端限流+前端配合防自动化调用；攻击者可抓包重放timestamp/nonce，uni-app前端逻辑完全暴露，真正有效的是服务端基于IP/设备指纹/token的频控与行为识别。
直接结论：光靠前端拦截没用，必须服务端限流 + 前端配合防自动化调用
为什么 uni.request 里加个时间戳或随机数根本防不住刷
有人在请求头塞 timestamp 或 nonce，以为能防刷——但攻击者抓包一次就全明白了，脚本照搬重放，连解密都不用。uni-app 打包后 JS 是可反编译的，所有前端校验逻辑（比如 sign 签名算法）都暴露在外。
真正起作用的只有服务端行为识别：
- 同一 IP / 设备指纹 / 用户 token 在单位时间内的请求数阈值（如 60 次/分钟）
- 请求参数模式异常（如连续 10 次
phone=138****1234只改末四位） - 无 referer、user-agent 极简、headers 缺失关键字段（如
X-Requested-With）
uni-app 能做的有效配合手段
不是“防住”，而是提高攻击成本、辅助服务端识别、避免被当成肉鸡滥用：
- 登录态必须用
refresh_token+access_token双机制，access_token有效期严格控制在 15–30 分钟，且每次使用都触发服务端刷新策略 - 敏感操作（注册、登录、短信发送）必须走图形验证码或滑动验证，uni-app 调用
uni.showModal或集成第三方 SDK（如极验），不要自己画个“拼图”糊弄 - 所有请求统一走封装层（比如
request.js），在请求拦截器中自动注入设备标识：plus.device.uuid（App）、uni.getSystemInfoSync().deviceId（小程序/H5），服务端用它做设备级频控 - 禁止在 H5 环境下暴露真实接口地址——开发时用
devServer.proxy，上线时通过 Nginx 反向代理隐藏后端域名，避免被爬虫扫出/api/v1/login这类路径
别踩的坑：token 存 localStorage 就等于白给
很多项目把 access_token 存 uni.setStorageSync('token', ...)，看似加密了，其实 App 端可被 root 后读取，H5 更是打开开发者工具就能看到。正确做法：
- App 端优先存
plus.storage.setItem（比 localStorage 更底层，仍需配合加固） - 小程序端用
uni.setStorage即可，微信已做沙箱隔离 - H5 必须配合 HttpOnly Cookie + SameSite=Strict，前端只管发请求，不碰 token 字符串
- 任何 token 都要绑定设备指纹和服务端 session，退出登录时主动调用服务端
/auth/logout作废该 token
最常被忽略的一点：刷接口往往不是冲着业务来的，而是试探你的鉴权逻辑是否松散。一个没校验 Content-Type: application/json 的登录接口，可能被用 application/x-www-form-urlencoded 绕过字段白名单。服务端每个接口的入参校验粒度，远比前端加几个 loading 更关键。
