框架级日志

实现方式：通过配置文件（如 application.yml/properties）全局或局部配置 logging.level

职责：

• 监控 Spring MVC 及其容器对 HTTP 请求的封装与分发。
• 监控 MyBatis/JPA 生成的原始 SQL 语句、参数绑定及连接池状态。
• 记录 Filter、Interceptor 及 AOP 切面对请求的预处理动作。

应用场景： 主要用于定位网络握手失败、404/405 路由映射错误、数据库索引失效、或者框架配置冲突等系统级故障。

业务逻辑日志

实现方式：利用 Lombok 的@Slf4j注解，在.java源码中手动埋点。

职责：

• 记录核心业务流转的关键状态（如：支付回调后的订单状态更新）。
• 输出关键业务参数（用户 ID、订单号、金额），用于逻辑审计。
• 记录业务预期的或非预期的逻辑异常堆栈

应用场景： 主要用于排查业务逻辑漏洞、计算逻辑错误、API 返回数据不符合预期、以及特定业务流程的中断

区别

这两者的分界线建立在 “自定义业务代码” 与 “第三方框架组件” 之间。

维度	基础设施层 (logging.level)	业务逻辑层 (@Slf4j)
所属层级	框架/中间件/容器层 (Infrastructure)	应用/服务/领域层 (Application)
颗粒度	全局统一，关注请求/响应流	局部精确，关注变量/逻辑分支
数据源	org.springframework, com.zaxxer, org.hibernate	com.example.project.service
性能损耗	Debug 级别下损耗极高，生产环境需调至 Info	生产环境核心埋点，损耗相对可控

在生产环境中，处理BUG遵循一下流程：

1. 优先查看“业务日志” (@Slf4j)：确定请求是否进入业务处理流程。若有日志但报错，则是逻辑问题；若无日志，则请求未达业务层。
2. 按需开启“框架日志” (logging.level: debug)：若业务层无感，则通过配置降低 Spring 或 Nginx 的日志级别，观察请求是否在过滤器（Filter）或拦截器（Interceptor）中被丢弃，或因 SQL 语法错误在持久层崩塌。