1.安全
之前做的一个在校项目，没有用 https 之前是明文传输账号密码的，被校内安全检测部门责令整改......
用了 https 也可能因为用户操作不慎，被中间人攻击，这时候就算是 账号密码被加密，但是加密用的公钥是攻击者的，私钥也在攻击者那里 所以也会被破解。
需要和前端协商好加密的方式 和密钥，如果单纯只用 RSA 这种高消耗的非对称加密的话，性能可能吃不消，如果用户量一大的话，如果用对称加密的话，又要保证密钥交接的过程中不被偷取
最后因为这个项目用户量不多，只有几百人，最后还是用 RSA 非对称加密了......
公私钥写死，公钥写死在前端，后端。虽然有可能被暴力破解，但是可能性不大，另外 还有 https 加持，安全性应该还可以。
如果要求性能的话，就要模拟 https 那样，先非对称，用非对称加密 传输 对称加密的密钥后，再用对称加密。
2.幂等性
类似情景：用户发过来的订单请求包可能在网络的某个节点因为错误，拷贝了两份，这样的话就需要对这两份包而言，只会执行一次真正的业务操作。
具体实现可以用 随机 Token 等 策略
3.防止暴力压测
攻击者可能无法修改 数据包里的数据，也无法实时加密合成出合法的包，但是他可以用合法的包做为请求数据，压测服务器。
这样的话，就要设置包的过期时间，免得同一个包长期有效，这样的话攻击者只用拿一个包就能疯狂压测服务
4.限流：
5.调用方管理
类似微信小程序的 接口，需要调用方提供 appid
并且如果调用发有违法行为，就封禁此 appid
待补充。。。