日常开发调试过程里很多人遇到程序异常习惯反复刷新、重启服务试错却常常忽略日志的价值。工作多年越发觉得养成规范记录、保存日志的习惯能节省大量排障时间在这里分享一点个人经验。一、不要忽视控制台原始输出很多开发者看到报错信息大致扫一眼关键词就开始上网搜索不会完整保存原始报错文本。 线上环境、本地复现偶发 bug 时报错信息转瞬即逝。等到想要再次复现问题有可能环境状态已经变化很难再次触发相同异常。 建议遇到异常第一时间完整复制控制台日志或者截图留存保留堆栈信息、参数上下文。二、区分日志级别不要全部打印新手开发经常喜欢无差别打印大量信息所有内容统一使用普通输出。 上线之后海量冗余日志会带来几个麻烦日志文件体积快速膨胀占用服务器磁盘资源排查问题时有效报错信息被大量无关打印淹没不方便通过日志等级筛选故障内容。合理做法按照业务划分DEBUG、INFO、WARN、ERROR等级开发环境开放调试日志生产环境关闭低级别调试输出。三、日志尽量带上关键上下文单纯打印程序出错了这类文字几乎没有排查价值。 记录日志时尽可能附带关键上下文请求编号、操作账号、入参数据、调用时间。 当系统并发量上涨多条请求同时执行只有上下文信息才能快速定位是哪一条业务流程产生故障。四、本地日志与线上日志分开管理本地开发产生的临时日志建议配置独立目录定期清理。 线上业务日志做好滚动分割策略按照时间或者文件大小切分日志避免单个日志文件体积过大打开、检索困难。同时设置合理保存周期避免长期堆积。五、一个容易踩的误区日志中输出敏感信息调试的时候不少同学会直接打印完整请求参数其中可能包含手机号、身份凭证、私密业务数据。 一旦日志长期留存存在信息泄露风险。上线前务必做一次检查脱敏处理敏感字段禁止明文输出隐私数据。总结日志不只是故障出现之后用来救火的工具。规范的日志体系能够帮助我们还原程序执行流程快速定位偶现 bug。 不管是个人小型项目还是团队协作的大型业务系统尽早建立日志输出规范长期来看能显著提升问题排查效率。
