日志记录了代码的执行过程，根据目的不同，可以分为系统日志和操作日志。本文作者对操作日志进行了介绍，分析如何用五个步骤设计出用户操作日志，一起来看一下吧。
一、什么是日志
日志记录了代码的执行过程。根据目的不同，可分为系统日志和操作日志。
1）系统日志
记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。开发人员可以通过它来检查错误发生的原因，或者寻找受到攻击时攻击者留下的痕迹。系统日志包括系统日志、应用程序日志和安全日志。由于系统日志主要是为开发人员排查问题提供依据的，因此可读性没那么高。
2）操作日志
记录所有用户在系统中的操作过程和操作结果，如登录记录、修改记录等。操作日志主要是为用户服务，帮助他们查看历史操作记录，因此对可读性要求较高。
二、什么是操作日志
具体而言就是记录“谁在什么时间、什么位置，对什么东西做了什么操作，从而产生了哪些变动”，因此一个完备的操作日志应包含以下信息：
用户（操作人及账号）：谁执行了该操作操作时间：什么时间执行了该操作操作位置（业务菜单）：在哪个模块上执行了该操作，如用户管理、订单管理等操作对象：对哪个对象执行了该操作，如某道题、某份试卷操作类型：具体执行了哪个操作，如登录、浏览、新增、删除等变动值：在执行该操作后产生了哪些变化，主要针对于“编辑”类型的操作，如将题目难度由修改为除了以上内容，还可根据业务场景补充记录其他字段：
操作页面：记录执行操作时调用的接口，如/crowd/system/user/list，当出现异常时，便于技术人员快速定位问题登录IP：记录用户在何地执行的操作，如.71..54四川省成都市武侯区电信设备信息：记录用户通过哪种设备执行的操作，如Chrome、Windows7、PC业务相关字段：为了满足业务需要而记录的字段，如下图所示
拓展1：以上默认只记录操作成功的日志，如果业务需要，还可以增加“操作状态”字段来记录操作失败的日志，同时记录失败原因。
拓展2：若多个项目均要记录用户的操作，不需要为每个项目单独开发一套操作日志功能，而应该设计一个用户操作日志的公共组件（本文只讨论为单一项目设计用户操作日志，组件的设计不在本文讨论范围内，不过设计组件时仍需先理清各项目的用户操作日志，再同开发讨论如何抽离）。
三、五步设计用户操作日志
1.梳理操作列表
梳理操作列表就是罗列出用户的哪些操作要在用户操作日志中记录。具体的方法是：在功能列表的基础上，根据业务需要筛选出要记录的功能。
如上图所示，左边是产品的功能列表，经过产品经理的调研和分析，认为本项目的用户操作日志中不需要记录查看及查询操作，并且也不需要记录公告管理中的所有操作，因此制作了右边的操作列表。
2.梳理记录字段
在本步骤中需要产品经理明确针对每个操作要记录的字段有哪些。至少应包括用户、操作时间、操作位置、操作对象和操作类型，再根据业务的需要增加变动值、IP地址、设备信息、操作页面等其他字段。
3.填充具体规则
搭建好操作列表和记录字段的框架后，接下来就是往里面填充具体的规则了，即如何将操作日志以通俗易懂的方式展现出来。
如上图所示：添加、删除、停用等操作由于只涉及一个对象的一个状态，所以处理起来比较简单，如[-10-9:10:26][小王]在[学院管理]中[添加]了[学院一()]；
批量操作可以被看成是多次对单个对象进行操作，也只涉及一个状态，如[-10-9:10:26][小王]在[学院管理]中[添加]了[学院一()、学院二()、学院三()]；
最复杂的是对编辑操作的处理，因为涉及到两个状态，即编辑前和编辑后，下文会以“编辑”操作为例介绍如何记录两个状态的操作内容。
注：需要根据业务需求决定日志记录的颗粒度，可只记录到操作类型，也可记录到每次操作的详细内容。
1）有限值
针对有限内容（如下拉框、多选框、复选框等）可直接记录前后变化，如题目难度：将[难度一]修改为[难度二]。
2）短文本
由于文本内容较短，也可以直接记录编辑前和编辑后的内容，如学院名称：将[学院一]修改为[学院二]。
3）长文本
由于文字较多，若像短文本那样将全部内容都展示出来，则不利于用户看出变化。这时就可先按“行”梳理长文本内容，编辑后只给用户展示出变动行的内容，如下图所示，可以很清晰地看出用户删除了第-行，新增了-行。
4）图片和音视频
图片和音视频是以地址的形式存储的，因此也应该以地址的形式进行记录，如附件：将[
联系电话：