你真的会打印日志吗?基于 Spring Boot 的全方位日志指南

你真的会打印日志吗?基于 Spring Boot 的全方位日志指南
—JavaEE专栏—

目录

一、日志概述:为什么它比 System.out.println 更重要?

在 Java 开发早期,我们习惯使用 System.out.println() 来调试代码 。但随着项目复杂度提升,简单的打印语句已无法满足生产环境的需求 。

1.1 日志的核心用途

  • 系统监控:记录系统运行状态、方法响应时间及状态,设置阈值报警 。
  • 数据采集:统计 PV/UV、用户留存,为推荐算法提供原始数据 。
  • 日志审计:记录用户操作记录,追踪非法攻击或信息泄露(如谁删除了关键数据) 。

1.2 为什么弃用标准输出?

通过 System.out.print 打印的日志相比 Spring Boot 默认日志缺少了时间戳、日志级别、进程 ID、线程名等关键排查信息。


二、日志框架体系:门面模式的深度解析

Spring Boot 默认集成了 SLF4J 作为日志门面,并使用 Logback 作为具体实现。

2.1 门面模式 (Facade Pattern)

SLF4J 是门面模式的典型应用 。它为子系统(如 Log4j、JUL、Logback)提供统一接口,使得客户端无需关心底层实现。

  • 优点:减少系统依赖,提高灵活性,简化客户端使用难度。

2.2 常见框架对比

角色框架名称说明
日志门面SLF4J, commons-logging统一 API 接口,不含逻辑实现
日志实现Logback, Log4j 1/2, JUL负责具体的日志记录逻辑

|


三、实战:Spring Boot 日志的基本使用

3.1 传统方式获取日志对象

需要使用 LoggerFactory 获取,并指定当前类的 Class 对象 。

importorg.slf4j.Logger;importorg.slf4j.LoggerFactory;importorg.springframework.web.bind.annotation.RestController;@RestControllerpublicclassLoggerController{// 注意:Logger 对象必须属于 org.slf4j 包 privatestaticfinalLogger logger =LoggerFactory.getLogger(LoggerController.class);publicStringlogTest(){ logger.info("这是一条 INFO 级别的日志");return"Log Success";}}

千万不要导错包!!!

在这里插入图片描述

3.2 进阶方式:使用 Lombok (@Slf4j)

引入 Lombok 依赖后,只需一个注解即可自动生成 log 对象。

importlombok.extern.slf4j.Slf4j;importorg.springframework.web.bind.annotation.RestController;@Slf4j// 自动提供 log 对象@RestControllerpublicclassLogController{publicvoidlog(){ log.info("使用 Lombok 快速打印日志");}}

四、深入理解日志级别

日志级别按严重程度从高到低排列为:FATAL > ERROR > WARN > INFO > DEBUG > TRACE

  • ERROR:记录较高等级的错误,但不影响系统运行 。
  • WARN:警告信息,需引起注意 。
  • INFO:默认级别,记录系统运行的关键节点。
  • DEBUG:调试阶段的关键信息 。
注意:Spring Boot 默认级别为 INFO,因此默认情况下不会打印 DEBUGTRACE 级别的日志 。

五、日志的高级配置 (application.yml)

5.1 修改日志级别

logging:level:root: debug # 将全局日志级别设为 debug [cite: 39]

5.2 日志持久化

在线上环境中,必须将日志保存到文件。

logging:file:name: logger/springboot.log # 指定文件名(推荐使用) path: D:/temp # 仅指定目录,文件名为默认的 spring.log 

5.3 日志文件分割

为防止单个日志文件过大(默认超过 10MB 分割),可进行如下配置:

logging:logback:rollingpolicy:max-file-size: 1KB # 达到 1KB 自动分割(实际生产常用 200MB)file-name-pattern: ${LOG_FILE}.%d{yyyy-MM-dd}.%i # 分割后的命名格式

六、自定义日志格式说明

通过 logging.pattern.consolelogging.pattern.file 可以自定义输出格式。

占位符说明
%d日期和时间(精确到毫秒)
%5p日志级别
%c类的全限定名
%m日志消息内容

七、总结

  1. 日志的重要性:它是程序运行的“黑匣子”,是定位问题、审计安全、分析数据的核心依据 。
  2. 最佳实践:推荐使用 Lombok 的 @Slf4j 注解,并通过 YAML 配置文件实现日志的级别控制、持久化及滚动拆分。

参考链接:

Read more

[架构之美]若依框架前后端分离版部署全流程详解(本地+服务器+高级配置)

[架构之美]若依框架前后端分离版部署全流程详解(本地+服务器+高级配置)

若依框架前后端分离版部署全流程详解(本地+服务器+高级配置) 若依(RuoYi)作为一款基于SpringBoot和Vue的权限管理系统,凭借其模块化设计和开箱即用的特性广受开发者欢迎。本文将从本地部署、服务器部署、高级配置三个维度,结合常见问题解决方案,详细讲解若依框架前后端分离版的完整部署流程,助力开发者快速上手。 一、本地部署(开发环境) #下载地址 https://www.ruoyi.vip/ #环境准备 JDK >=1.8(推荐1.8版本) Mysql >=5.7.0 (推荐5.7版本) Redis >=3.0 Maven >=3.0 Node >=12 1. 环境准备 * 后端依赖:

By Ne0inhk
Flutter 组件 aws_lambda_dart_runtime_ns 的鸿蒙化适配实战 - 实现 OpenHarmony 分布式端高性能云端协同、冷启动指纹预检与工业级边缘计算核方案

Flutter 组件 aws_lambda_dart_runtime_ns 的鸿蒙化适配实战 - 实现 OpenHarmony 分布式端高性能云端协同、冷启动指纹预检与工业级边缘计算核方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 aws_lambda_dart_runtime_ns 的鸿蒙化适配实战 - 实现 OpenHarmony 分布式端高性能云端协同、冷启动指纹预检与工业级边缘计算核方案 前言 在鸿蒙(OpenHarmony)生态的分布式边缘计算、强云端一体化架构或者是对冷启动耗时有极其严苛要求的 0308 批次企业级应用中。“云原生函数的执行效率与边缘执行环境的指纹预检维度”是衡量整个系统算力调度稳定性的最终质量门禁。面对包含每秒数百万次调用的 Lambda 函数集群、动态变化的 AWS 环境变量、甚至是由于跨域转发产生的 0308 批次请求转发波次。如果仅仅依靠简单的“HTTP 转发”或者是干瘪的裸进程运行。不仅会导致在处理高并发云请求时让系统如同在逻辑废墟中盲人摸象。更会因为运行时环境不兼容。令应用在关键业务触发时瞬间陷入无响应盲区。 我们需要一种“逻辑严密、运行时自适应”的算子调度艺术。 aws_lambda_dart_

By Ne0inhk
Flutter 组件 dio_logging_interceptor 适配鸿蒙 HarmonyOS 实战:全链路网络观测,构建高性能日志拦截与流量审计架构

Flutter 组件 dio_logging_interceptor 适配鸿蒙 HarmonyOS 实战:全链路网络观测,构建高性能日志拦截与流量审计架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 dio_logging_interceptor 适配鸿蒙 HarmonyOS 实战:全链路网络观测,构建高性能日志拦截与流量审计架构 前言 在鸿蒙(OpenHarmony)生态迈向大型分布式应用、涉及复杂微服务调用及严苛线上环境调试的背景下,如何实现网络请求的长效“透明化”治理,已成为决定应用研发效率与故障定位能力的基石。在鸿蒙设备这类强调 AOT 极致性能与低能耗前台驻留的环境下,如果应用依然依赖零散的 print 语句或基础的控制台输出,由于由于网络并发频率高、报文体积大,极易由于由于“日志阻塞”或“关键信息淹没”导致开发者无法在海量日志中捕捉到致命的 401 或 500 异常原因。 我们需要一种能够深度集成于网络管线(Dio)、支持多级日志过滤且具备美理化输出格式的拦截器方案。 dio_logging_interceptor 为 Flutter 开发者引入了“

By Ne0inhk
企业级部署升级:Nginx 反向代理 + ELK 日志监控,让成绩预测平台稳定可追溯

企业级部署升级:Nginx 反向代理 + ELK 日志监控,让成绩预测平台稳定可追溯

⭐️个人主页:秋邱-ZEEKLOG博客 📚所属栏目:python 前言 上一期的 Docker+Linux 部署,让成绩预测平台实现了局域网共享,但真正落地到团队 / 学校使用,还缺两个关键支撑:访问体验不够专业(IP + 端口难记、无加密),运维排查全靠 “猜”(日志分散、无监控)。 这一期,我们跳出 “步骤式部署” 的框架,以 “问题驱动 + 场景落地” 为核心,先拆解企业级部署的核心诉求,再分模块实现 Nginx 域名化改造和 ELK 日志监控,最后通过实战验收和运维手册,让你既能搞定部署,又能轻松应对后续运维问题,全程聚焦 “实用、稳定、可追溯”。 一、企业级部署的 3 个核心诉求(先明确目标再动手) 为什么互联网公司都在用 “Nginx+ELK”

By Ne0inhk