该选PrintWriter还是PrintStream取决于数据类型和场景：纯文本/日志用PrintWriter（支持指定编码、自动flush、异常不中断线程）；二进制混合内容或兼容System.out时用PrintStream（需显式指定编码，注意平台默认编码陷阱），二者均非线程安全，多线程需加锁或改用专业日志框架。
PrintWriter 和 PrintStream 什么时候该选哪个？
PrintWriter 是字符流，PrintStream 是字节流——这是最根本的分水岭。你写的是纯文本、日志、配置内容，用 PrintWriter；你要输出二进制混合内容（比如 HTTP 响应头 + 图片数据），或者必须兼容老代码里硬写的 System.out（它本身就是 PrintStream 实例），那就得用 PrintStream。
-
PrintWriter支持指定字符编码（如new PrintWriter(file, "UTF-8")），PrintStream构造时只能传File或OutputStream，编码靠底层OutputStreamWriter隐式处理，容易踩默认平台编码坑 -
PrintWriter的printf()、format()方法抛出的是未检查异常（RuntimeException），PrintStream同名方法也是，但它的write()系列方法可能触发IOException，而PrintWriter默认吞掉异常（除非你显式调用checkError()） - 日志记录场景下，
PrintWriter更安全：能控制编码、不意外中断线程（因异常被吞）、支持自动 flush（autoFlush = true）
PrintWriter.printf() 不生效？检查这三件事
printf() 看似调用了，文件却空着或内容不全——不是语法错，是流没刷出去。
- 没开自动 flush：
new PrintWriter(out, true)第二个参数必须为true，否则换行符不会触发刷盘；只靠println()不够，printf()不带换行 - 输出目标是文件但没 close：
flush()不等于close()，尤其用 try-with-resources 时，别漏掉close()触发的最终 flush - 编码不匹配导致乱码掩盖内容：比如用
GBK打开 UTF-8 写入的文件，看着像“没输出”，其实是字节解码失败
示例：
try (PrintWriter pw = new PrintWriter("log.txt", "UTF-8")) {
pw.printf("User %s logged in at %tF%n", username, System.currentTimeMillis());
// 这里没 println()，也没 flush()，且 autoFlush=false → 内容卡在缓冲区
}
PrintStream.println() 为什么有时中文变问号？
根本原因是 PrintStream 底层用的是平台默认编码（Windows 是 GBK，Linux/macOS 通常是 UTF-8），而你写入的字符串是 UTF-16（Java 字符串内部格式），转换时若没显式指定，就按系统猜。
立即学习“Java免费学习笔记（深入）”；
- 直接传
File构造：new PrintStream("a.txt")→ 完全依赖系统编码，跨平台必出问题 - 正确做法是包装
FileOutputStream+OutputStreamWriter，但那就绕过PrintStream了；更实际的解法是改用PrintWriter，它构造函数明确支持编码字符串 - 如果非用
PrintStream（比如要重定向System.out），必须用new PrintStream(new FileOutputStream(f), true, "UTF-8")，第三个参数才是编码名
日志记录别直接用 PrintWriter/PrintStream 做并发写入
它们都不是线程安全的写操作类。多个线程同时调 println()，可能一行日志被截断、两行粘连、甚至抛 NullPointerException（因内部 lock 字段未初始化）。
- 单线程写文件没问题；多线程必须加锁，或用
java.util.logging.Logger、slf4j+logback这类专为并发设计的日志框架 - 即使加了 synchronized，
PrintWriter的checkError()也不反映其他线程的错误状态，错误检测失效 - 小项目图快用
PrintWriter记日志可以，但只要涉及定时任务、Web 请求、异步回调，就得切到真正线程安全的日志方案
字符编码、自动刷盘、线程安全——这三个点漏掉任何一个，都会让看似简单的输出变成深夜排查现场。
