后端开发常犯的问题（Java版）

数据类型使用不当

——钱相关的计算，数据类型必须用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;
##事务提交##

用户连续取钱两次，如下图所示，后面运行的事务的值会将前面修改的值覆盖掉

正确做法：

查询数据的SQL添加写锁

小知识：

1.锁在事务commit后才会释放

2.在同一个事务中，锁被同一个事务的SQL语句共享

持续更新中。。。