第一点：
问题
遇到的问题之：在实现后台管理端-账户操作的时候，添加员工的时候如果重复添加同一个员工，会触发一个数据库唯一约束异常，但客户端无法清晰的理解这个错误，所以我们就对新增员工的代码进行try catch，但同时带来一个问题，代码量一旦上来就不可行。
解决：
这里我们使用SpringAop思想实现全局异常拦截处理，从而对异常的统一处理。
当报错信息出现Duplicate entry时，就意味着新增员工异常了 所以，我们对异常类的方法进行一些小改动，让这个异常反馈变得更人性化 这个时候再来客户端试试，就会提供人性化的报错，非常的快乐~，更加人性化，体验更好。
实现代码：
//@RestControllerAdvice包括了下面两行
@ControllerAdvice(annotations = {RestController.class, Controller.class})
@ResponseBody
@Slf4j
public class GlobalExceptionHandler {
/**
* 异常处理方法
* @return
*/
//捕获完整性约束违反异常（其实就是数据库唯一约束异常）SQLIntegrityConstraintViolationException
@ExceptionHandler(SQLIntegrityConstraintViolationException.class)
public R<String> exceptionHandler(SQLIntegrityConstraintViolationException ex){
log.error(ex.getMessage());
if(ex.getMessage().contains("Duplicate entry")){
return R.error("唯一约束异常:"+exception.getMessage().split(" ")[2]+"已存在");
}
return R.error("未知唯一约束错误");
}
}这回再回到Controller，这时就不需要再来try catch这种形式了，不用管他，因为一旦出现错误就会被我们的AOP捕获。所以，不需要再用try catch来抓了
第二点
问题：
启用禁用员工账号，js主键丢失精度问题
只有管理员账号有禁用启用按钮：
前端如何判断当前用户是admin？缓存：local Storage里面
点击禁用后发送请求：
js丢失long精度问题
Long类型id是19位，而js只能处理17位数字，Long类型主键从前端传回后端丢失精度，导致传到后端的id和数据库id不一致：
解决方案：
实体类注解@JsonFormat
实现代码：
在员工的主键上面加上@JsonFormat
@JsonFormat(shape = JsonFormat.Shape.STRING)
private Long id;
