java日志命名规范要求统一使用private static final logger logger = loggerfactory.getlogger(当前类.class);，以全限定类名自动标识日志来源，避免硬编码字符串、冗余前缀或动态生成名称，确保可追溯、可配置、可监控。
Java 日志命名规范的核心是让日志名称能准确反映类的职责，而不是随意用类名或“Logger”结尾。最推荐的方式是：每个类使用 private static final Logger logger = LoggerFactory.getLogger(当前类.class);，即日志器名称统一为 logger，而日志器的归属由其所属类的全限定名自动标识。
用类名作为日志来源，而非自定义字符串
错误做法是写成 getLogger("UserService") 或 getLogger("biz.user")，这会丢失类路径信息、难以溯源、且与实际代码脱节。正确方式是传入 UserService.class —— 日志框架（如 Logback、Log4j2）会自动提取全限定类名（如 com.example.user.UserService）作为 logger name。
- 调试时可通过日志中的
[com.example.user.UserService]精确定位到具体类 - 便于在 logback-spring.xml 中按包或类名做精细化配置（如单独调高某个服务的日志级别）
- 重构类名或移动包路径时，日志来源自动同步，无需人工维护字符串
避免在日志名中加入环境、模块等冗余前缀
不要写成 getLogger("prod-user-UserService") 或 getLogger("auth.UserService")。环境信息应由日志系统通过 context property（如 %X{env}）或 appender 路由规则 统一注入；模块划分应靠包结构（如 com.example.auth.service）自然体现。
- 日志名膨胀会导致配置复杂、搜索困难、MDC 冗余
- 同一类在不同模块复用时，名字反而产生歧义
- 真正需要区分场景的行为（如异步任务、定时任务），应通过独立类封装，而非拼接名字
工具类和静态上下文的特殊处理
对于无状态工具类（如 DateUtils），仍应使用 getLogger(DateUtils.class)。若确需跨类共享上下文（如全局请求 ID），应通过 MDC（Mapped Diagnostic Context） 注入字段，而不是把 MDC 内容塞进 logger name。
- 例如：
MDC.put("traceId", id);，再在 pattern 中用%X{traceId}输出 - 日志名保持干净，语义聚焦在“谁打的日志”，而非“当时在什么上下文中”
- 避免出现
getLogger("UserService-" + traceId)这类动态生成 logger name 的反模式（会造成 logger 实例爆炸、内存泄漏）
团队协作中的最小约定
无需定义复杂的命名层级（如 “system.db.dao”、“system.web.controller”），只需统一执行两条规则：
- 所有类内声明 logger 变量名均为
private static final Logger logger - 初始化一律使用
LoggerFactory.getLogger(本类.class)
这样既保持代码简洁，又确保日志可追溯、可配置、可监控。日志的价值不在名字多花哨，而在它能否在出问题时，让你 3 秒内打开对应类、看清上下文、找到关键变量值。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
