jul测评：这些坑我真踩过
jul测评不能只看“JDK自带、无需依赖”这几个优点。我按实际接入顺序跑了一遍，从默认输出、级别控制、文件落盘到线上可维护性，发现它有些地方很轻巧，有些地方新手特别容易被默认配置带偏。
第1步：先测零依赖启动，确实爽
做 jul测评，我先从最朴素的场景开始：新建一个 Java 类，不加 Maven 依赖，只写 Logger.getLogger(Test.class.getName())。结果很直接，info、warning、severe 都能正常输出。
这一点是 JUL 最大优势。写一次性数据修复脚本、批处理小工具、教学示例时，不用为了打日志去拉一套 Logback。尤其在受限环境里，比如客户机器不能随便联网下载依赖，JUL 很顶。
第2步：测日志级别，第一坑来了
我把 log.fine("debug detail") 加进去，运行后没输出。很多人到这里会以为代码错了，其实不是。JUL 默认控制台 Handler 通常是 INFO 级别，FINE 被挡住了。
正确测法是同时改两层：Logger 本身 setLevel(Level.FINE)，根 Logger 下面的 Handler 也 setLevel(Level.FINE)。这点和一些日志框架的直觉不一样，是 JUL 新手坑榜第一名。
第3步：测格式，能用但不够现代
默认 SimpleFormatter 输出的信息挺全，但观感比较老派。时间、来源类、方法、级别、消息会分行展示，开发时还能忍，一旦日志量大起来，扫日志效率明显下降。
我试过用系统属性改 java.util.logging.SimpleFormatter.format，能压成单行，比如时间 级别 类名 消息。但说实话，这块体验不如 Logback 的 PatternLayout 顺手。如果团队很看重日志可读性，JUL 要多花点配置时间。
第4步：测文件落盘，注意默认XML
FileHandler 是 JUL 自带的文件输出方案，支持大小轮转和文件数量限制。比如 FileHandler("app-%g.log", 10485760, 7, true)，就是 10MB 一个文件，最多 7 个，追加写。
坑点是默认 Formatter 可能不是你想要的纯文本。我第一次打开文件看到一堆 XML 标签，心里咯噔一下。解决办法是 handler.setFormatter(new SimpleFormatter())，否则排查问题时会很难受。
第5步：测线上维护，边界很清楚
这轮 jul测评下来，我给它的定位很明确：轻量、内置、够用，但不适合承包所有复杂日志需求。比如异步写入、JSON 日志、链路追踪字段、按环境灵活切配置，JUL 都不是最舒服的选择。
如果你的项目只有几千行代码，日志只是辅助排查，JUL 很省事。如果是多人协作的后端服务，我会优先选 SLF4J 门面，再接 Logback 或 Log4j2，后面迁移成本低很多。
常见问题
jul测评结果适合新项目使用吗？
适合小型工具、Demo、内部脚本；如果是长期维护的 Web 服务，建议至少用 SLF4J 做门面，避免后期换框架成本太高。
JUL最大的缺点是什么？
默认配置不够直观，Logger 和 Handler 双级别机制容易误判；格式化、异步、结构化日志能力也不如主流日志框架顺手。
JUL文件日志会自动切分吗？
会，但要用 FileHandler 的 limit 和 count 参数配置，比如单文件大小、保留数量。不配置清楚可能导致日志文件不可控。