system.logger 不适合跨类库统一日志门面，因其仅静态绑定 jul、不支持第三方实现、无 mdc/异步/分级配置，且无法桥接或重定向；适合轻量 cli 工具或 jdk 内部打点等弱管控场景。
System.Logger 不能替代 SLF4J 或 JUL 的门面角色，它本身是 JDK 9+ 提供的轻量级日志抽象，但不支持绑定第三方实现（如 Logback、Log4j2），也不具备 MDC、异步日志、分级配置等能力。强行用它做“统一日志门面”会踩坑。
为什么 System.Logger 不适合跨类库统一日志门面
Java 标准库的 System.Logger 是一个只读接口，由 System.getLogger(String) 返回，其底层实现由 JVM 在启动时静态绑定到 java.util.logging.Logger（即 JUL），且不可替换。这意味着：
- 你无法通过 SPI 或系统属性切换为 Log4j2 或 Logback 实现
- 所有依赖
System.Logger的模块，最终都走 JUL 输出，而 JUL 默认配置简陋、性能一般、格式难定制 - 第三方类库（如 Netty、JUnit5）若使用
System.Logger，你无法拦截或重定向其日志——它不参与任何外部日志框架的桥接机制 - 没有
LoggerFactory类似物，无法注入自定义上下文（比如 traceId），System.Logger实例不携带任何可扩展元数据
哪些场景下可以安全用 System.Logger
它适合对日志无强管控需求的轻量场景，比如：
- JDK 自带工具类（如
java.net.http.HttpClient）内部打点，你只需默认看到 INFO 级别调试信息 - 小型 CLI 工具、脚本类应用，不需日志归集、不接入 ELK、不关心 MDC
- 模块间仅需最低限度协作，且所有模块都明确接受 JUL 作为最终输出目标
- 你想避免引入 SLF4J + binding 的 JAR 包（例如在极小体积容器镜像中）
示例用法：
System.Logger logger = System.getLogger("MyComponent");
logger.log(System.Logger.Level.INFO, "Starting up with config: {0}", configPath);
真正可行的“跨类库统一日志门面”方案
如果你的目标是解耦具体日志实现，并让不同类库（包括你自己写的、第三方的）共享同一套日志行为，必须用业界标准方案：
- 所有代码统一使用
org.slf4j.Logger和org.slf4j.LoggerFactory—— 这才是事实上的 Java 日志门面 - 运行时只引入一个 binding：比如
slf4j-simple（开发）、logback-classic（生产）、或slf4j-jdk14（若坚持用 JUL） - 对已使用
System.Logger的 JDK 类（如HttpClient），可通过-Djdk.httpclient.HttpClient.log=ALL开启其 JUL 输出，再用 JUL 的Handler转发到 SLF4J（需自写桥接 Handler，见slf4j-jdk14源码中的JDK14LoggerAdapter思路） - 对使用 JUL 的老代码，可用
slf4j-jdk14的桥接器；对使用 Log4j1 的，用slf4j-log4j12；但注意 Log4j2 需用log4j-to-slf4j（反向桥接）
容易被忽略的关键细节
很多人以为只要自己代码里全用 System.Logger 就“没依赖”，其实隐式绑定了 JUL，而 JUL 的行为受 logging.properties 文件、System.setProperty("java.util.logging.config.file", ...)、甚至容器环境变量影响，极易在不同部署环境表现不一致。更麻烦的是，某些云平台（如 AWS Lambda）会静默覆盖 JUL 配置，导致 System.Logger 日志直接丢失。
如果你正在设计一个要被其他项目复用的 SDK，不要暴露 System.Logger 实例，也不要要求调用方传入它——这会让使用者被迫适配 JUL。正确的做法是只依赖 org.slf4j.Logger，并在文档里写明：“需用户提供 SLF4J binding”。
