操作日志的2种实现方式

后台管理和运营系统，一般都会增加操作日志模块，记录用户的操作日志，方便排查问题、监控审计。

在加入br公司之前，一直喜欢用自定义的方式实现。

比如：

void  deleteUser(){
    ...
        删除用户的业务逻辑
    ...
    addOpLog(params,param2,params3);
}

优点：可以准确获得上下文参数，详细记录各种业务执行情况

缺点：辅助代码和业务代码耦合，业务方法执行时间增加，维护麻烦。

另外一种方式，用AOP拦截器的方式。

@OpLog("params1","params2")
void deleteUser(){
    ...
        删除用户的业务逻辑
    ...
}
public class SysOpLogInterceptor{
       void interceptor(){
             invoke();
             addOpLog();
     }
}

优点：标准化，解耦，实现简单，清晰易懂

缺点：不能够准确获得业务执行相关的参数

选择：尽可能用方法1。对业务参数等细节不太需要知道，自己做系统，业务方/客户没要求，就用户方法2简单实现。

被迫用方法2。需要知道业务细节；操作日志由第三方API提供，参数不通用。比如说，在某些大型电商平台，商家的操作日志是由单独的团队实现并提供接口。

需要的参数，可能不方便在注解@OpLog中表示。