背景
我们在做业务系统研发的时候，总会有这种需求，用户做了哪些操作、修改了哪些数据都需要记录下来，有没有一种通用的方式来记录业务日志并且与业务逻辑解耦，今天我们就来讲一种通过切面来记录日志的一种方式，并通过约定对开发流程定一些基本的规范来达到减少硬编码的目的。
原理
1、【客户端】提交的内容都是变更内容的核心参数，非变更内容不提交。所有修改操作 Request Body 需要绑定 提交前的变更内容快照。
2、【服务端】通过自定义注解 + 拦截器方式，解析参数并模板化变更内容。
规范
1、注解 @ApiLog 标记
【服务端】所有修改操作(新增/修改/删除/上线/下线/…)的Controller方法上，都需要标记 @ApiLog 。只有带上 @ApiLog 拦截器才能识别，并保存操作记录。示例如图一：
图一
- ApiLog，包含两个属性，name 表示操作名称，act 表示操作动作。
- 所有返回 Result 都需要 带上 withId 。因为这里离ID最近，因此也最方便。如果要在拦截器中萃取，判断太多。因此，在这里统一加上。
2、新增/修改POST提交
a、【客户端】所有新增/修改操作都必须是POST的提交方式为RequestPayload。Content-Type: application/json
b、【客户端】所有修改操作提交，只需要提交变更参数和对应的主键ID。
c、【服务端】Controller 方法入参只能有1个 RequestBody，且必须继承 BaseDO 基类。
3、修改操作须绑快照
1、【客户端】客户端提交修改操作时，需要在 Request Body 中绑定 snapshot 参数和值。snapshot的值表示修改提交之前的快照。格式和外面保持一致。如图所示：
图二
图三
图四
4、入库结果示例
其中 request_params 为提交入库参数模板化内容。
解析request_params字段，需要根据两个参进行判断：操作类型(日志) 和 参数形式(日志)
当 action_type = 修改 且 param_type = Body 时，内容如：[{“after”:“aiqiyi211”,“before”:“aiqiyi111”,“key”:“apk包名”}]，前后记录都有了。
其他情况，内容如：[{“key”:“ID”,“value”:9}]
