日志模块

1、关于记录用户操作日志的几个认知

（1）日志记录内容的设计，应方便后续查询、统计以及日志可视化等，因此可能跨页面、跨接口记录同一日志。
（2）由于是用户操作日志，所以只能由前端触发日志记录。
（3）由前端判断日志的同一性，即哪些操作属于同一条日志的应记录内容，哪些操作需要新建一条日志。

例如，若查询获取结果并记录日志之后，将对该查询结果的导出、打印等视为同一条日志的记录内容（记录是否导出、是否打印），则用户未导出、打印，又重新查询，就需要新建一条日志。或多开页面查询相同条件，就记录多条日志。

• 后端提供接口前端调用时，尽量不交流额外的信息。例如，若由后端判断日志的同一性，则后端需要返回查询结果的标识码，并持续跟踪这个标识码，则可能干扰业务代码（去update旧日志）。前后端传递过多与查询业务无关的参数，不利于代码维护（一个接口干了的活多了）。
• 由前端判断日志的同一性，可方便跨页面、跨接口记录同一日志内容。

（4）为减少请求压力，前端可批量上报日志，或在指定时间内无新日志产生时再上报日志。
（5）区分其他类型的日志，例如，用户登录日志，后端错误日志。这类日志不存在跨页面、跨接口，直接记录即可。

2、关于日志的几个认知

（1）日志完整性：包含 “谁 - 何时 - 何地 - 做了什么 - 结果如何” 核心要素。
（2）应方便后续查询、统计以及日志可视化等。
（3）性能优先，避免阻塞；
（4）可扩展性：支持后续新增操作类型、扩展日志字段；
（5）安全性：敏感数据脱敏（如用户 ID、查询参数中的隐私信息），防止日志泄露。

3、设计

对操作进行分类，并且可扩展操作类型。

（1）日志表的字段：
id，日志编号，生成日志的时间，用户Id，登录ip，日志类型，日志名称，日志内容（存为json）
注：

• 日志类型：一般就是固定的几类，如登录日志、错误日志、操作日志等。
• 日志名称：可以是“日志类型”的补充（子类），或是与功能、业务等相关，例如：“进行用户信息查询”。
• 日志内容：日志名称满足需求时，可以无该字段或不记录日志的内容。存为json，方便前端呈现。

（2）操作类型表的字段
id，名称，显示名称，描述
注：若系统有扩展需求，可对操作进行分类并单独建表。若扩展需求不大，有相应的字典即可。

（3）操作表的字段：
id，日志Id，操作发生的时间，操作类型的名称，是否成功，操作结果内容（存为json）
注：如有必要，前端依据操作类型，使用对应的界面呈现操作结果内容。

4、例子

对每次查询结果进行导出跟踪，并只记录一条记录

后端维护日志同一性

（1）前端发起查询；
（2）后端查询同时记录日志，并返回结果与日志Id；
（2）前端获取查询结果，并记录返回的日志Id；
（3）前端点击导出按钮，请求后端生成excel文件，请求参数携带日志Id；
（4）后端生成excel文件，并提供文件流，同时根据日志Id以更新日志；
（5）前端下载excel文件。

前端维护日志同一性

（1）前端发起查询；
（2）后端查询并返回结果；
（2）前端获取查询结果，并生成日志；
（3）前端点击导出按钮，请求后端生成excel文件；
（4）后端生成excel文件，并提供文件流；
（5）前端下载excel文件，更新日志；
（6）前端上传/批量上传日志，或定时触发上传/批量上传日志。