System.out.println() 立即输出是因为默认启用自动刷新，写入换行符后自动调用 flush()；而 print() 不触发刷新，需手动 flush() 才可见。
System.out.println() 立即输出，是因为它背后绑定了自动刷新的 PrintStream，且每次调用都隐式触发 flush()；但一旦你重定向、关闭自动刷新，或混用 print()，输出就可能“消失”——不是没执行，是卡在缓冲区里了。
为什么 println("hello") 总是立刻看到，而 print("hello") 有时不显示？
关键在 PrintStream 的 autoFlush 开关和方法行为差异：
-
println()、printf()、format()：写完换行符后，自动调用flush()（仅当autoFlush == true时生效） -
print()和write()：只写入内部缓冲区，**从不自动刷出**，必须手动System.out.flush() - 默认情况下
System.out是new PrintStream(out, true)构造的，所以println看似“直出”，实为“写+换行+刷”三步合一
验证方式：
System.out.print("waiting...");
try { Thread.sleep(2000); } catch (InterruptedException e) {}
System.out.flush(); // 不加这句，控制台两秒内可能空着
重定向 System.out 后日志“凭空消失”的真实原因
不是代码没跑，而是三类常见陷阱同时发生：
-
缓冲未刷：重定向到文件时，
PrintStream仍用默认缓冲策略，若程序提前退出或没调flush()，最后一段内容永远留在内存里 -
异常被吞：底层
FileOutputStream写失败（如磁盘满、权限不足），PrintStream默认静默忽略，checkError()才能发现 -
多线程乱序：多个线程共用一个
System.out实例，println()虽有同步锁，但若混合print()+write()+flush()，缓冲区竞争可能导致截断或错行
安全重定向示例：
立即学习“Java免费学习笔记（深入）”；
PrintStream fileOut = new PrintStream(new FileOutputStream("app.log", true), true); // 第二个true=autoFlush
System.setOut(fileOut);
// 后续每句 println 都会落盘，无需手动 flush
System.out.println 输出中文乱码？别只改 JVM 参数
-Dfile.encoding=UTF-8 只影响 String.getBytes() 等 API 的默认编码，**不影响 System.out 的实际字节流编码**。真正起作用的是终端/IDE 的字符集设置：
- Windows CMD 默认是 GBK，即使 JVM 用 UTF-8，输出到 CMD 也会乱码
- IntelliJ IDEA 控制台需单独设置：Settings → Editor → File Encodings → Console Encoding 改为 UTF-8
- Linux/macOS 终端一般没问题，但若用
LANG=C启动 JVM，也会退化成 ASCII
临时绕过办法（不推荐长期用）：
String utf8Str = "你好"; System.out.println(new String(utf8Str.getBytes(StandardCharsets.UTF_8), StandardCharsets.ISO_8859_1));
这行本质是“骗”终端按 Latin-1 解码 UTF-8 字节——仅用于调试，不可用于生产。
上线前必须替换掉 System.out.println 的硬性理由
它不是“不够好”，而是根本没设计成生产工具：
- 无法按级别开关：你不能说“只输出 WARN 以上”，也不能临时关掉 INFO 日志
- 输出目标固化：重定向一次就得改代码，无法运行时切到 Log4j 的 RollingFileAppender 或 SLF4J 的 AsyncAppender
- 无上下文支持：MDC（Mapped Diagnostic Context）这种请求级追踪能力，
println连边角都摸不到 - 性能黑洞：高并发下每条
println都是同步 I/O，比异步日志框架慢 10–100 倍
哪怕只是临时加一句调试输出，也建议统一用 System.err.println()——它和 stdout 是两条独立流，不会被 System.setOut() 影响，关键时刻能救命。
