日志到底应该怎么打

日志内容

不讨论针对用户行为的埋点日志，仅讨论业务日志。

待过两家公司，完全不同的日志策略：前者是内容平台（也是创业公司），基本上能不打日志就不打，只打一些异常日志；后者是交易平台，基本上所有用户请求都要 trace，每个请求参数，返回值的关键信息，除了集合类型的数据，其他数据都是尽量落日志了。

我总结了下，前者因为是内容平台，内容多寡、精不精确，对用户其实没有承诺（当然用户会用脚投票），真有问题就让用户重新操作下就可以了；而后者因为涉及到交易，需要对交易链条上的每个环节负责到底，无论是因为用户操作不当还是系统问题都需要给出合理的解释。前者没有一个客服，后者一大帮客服。前者平台跟用户是互利的（流量换内容），后者用户是平台爸爸。

思考：用户对产品的认知有差异，产品越简单，这种差异越小，就越不需要客服，也就越不需要日志。减少日志的办法可能还是简化产品逻辑，使之符合更多人的预期。

日志级别

正常业务流程 info，业务异常 warn （可能是参数不对或者不能满足一些业务条件之类的），这两种都属于正常情况，ret=0,表示结果是可用的，前端可以直接展示给用户。业务异常不能打 error，否则会有大量报警。

只有系统异常（如超时）才打 error，ret 不等于 0，表示结果不可用，前端可以根据 errorcode 判断是要重试还是怎么处理。这种异常会报警，可以标识服务的状态。

errorcode 也是一个值得讨论的话题，不过这贴先不讨论了。

不知道 XDM 在项目中是如何实践的，欢迎分享讨论