网站建设工作情况公司建网
数据类型使用不当
——钱相关的计算，数据类型必须用BigDecimal
1.很多开发在做金额计算时会使用double数据类型，自测一些常用场景认为double是满足需求的因而图省事直接使用此数据类型。使用double类型存在金额精度丢失的风险，涉及到钱的数据类型必须使用BigDecimal
缺少必要的校验，默认调用方会参照约定进行调用
——必传参数，重要参数逻辑，涉及权限逻辑必须有拦截校验
1.必传参数未做空校验以及字段值未做正确性校验，开发会以与上游约定好的应该怎么传参为理由不做校验。需求和人员一直是变动的，不能保证传参不出错，所以重要参数需要做校验
2.与权限相关的场景，所有接口都需要做权限校验的接口。 比如新用户可以选择领取礼品的场景，一般分为两个接口实现，1）用户是否为新用户，若为新用户则返回可以领取礼品；2）用户选择礼品后给用户发放礼品。有些开发会只在查询接口中做用户是否是新用户的校验，而在真正的发奖接口中不做校验。这样会有资损的风险，用户可以抓包直接获取到发奖接口给用户领取新用户礼品，所以在与权限相关的场景中，所有的接口都需要做权限的校验
RPC接口jar包升级影响了调用方
1.新增字段等操作不当，导致调用方序列化失败
并发场景无法正确限制
1.依赖client服务的并发限制，使用client加锁保证调用接口串行，服务端并没有加锁，接口超时等异常场景client重试，服务端产生了并发问题
事务的使用
1.虽然使用了事务，还是出现了数据被覆盖的问题
举例：银行取钱业务
##事务开始##
1.查询用户A的账户信息：select * from account where user = A；
2.计算用户A的账户余额
3.更新用户A的账户余额：update acount set money=? where user = A;
##事务提交##用户连续取钱两次，如下图所示，后面运行的事务的值会将前面修改的值覆盖掉
| 事务A1 | 事务A2 |
| 启动事务 | |
| 查询得到值10 | 启动事务 |
| 查询得到值10 | |
| 将10改成8 | |
| 将10改成7 | |
| 提交事务 | |
| 提交事务 |
正确做法：
查询数据的SQL添加写锁
小知识：
1.锁在事务commit后才会释放
2.在同一个事务中，锁被同一个事务的SQL语句共享
持续更新中。。。