字符流缓冲区未满时数据“静默丢失”本质是数据滞留内存未落盘，仅在缓冲区满、显式flush()或close()时才写出；忘记调用后两者，程序异常退出即永久丢失。
字符流底层的字节转换缓冲区未满时数据“静默丢失”，本质不是真的丢，而是数据还留在内存里没落盘——它卡在缓冲区中，既没写到文件，也没报错，程序结束或异常退出后就彻底消失。
缓冲区的设计本意是提升效率，不是为了暂存待命
字符流（如 BufferedWriter、OutputStreamWriter）内部都维护一个固定大小的字节数组（常见 8192 字节）。它只在三种明确时机把缓冲区内容真正写出：
- 缓冲区被填满（自动 flush）
- 显式调用
flush()方法 - 调用
close()（会自动触发一次 flush）
除此之外，哪怕你写了 1 个字符，只要缓冲区不满、也没手动刷新或关闭，那这个字符就一直停在内存缓冲区里。一旦 JVM 退出、线程中断、或发生未捕获异常导致流未关闭，这部分数据就再无机会写出——用户看到的就是“空文件”或“少内容”，却没有任何错误提示。
常见静默丢失场景
这些情况都不会抛异常，但数据就是不落地：
- 写完数据后忘记
close()或flush()，直接让方法返回或程序退出 - 在 try-with-resources 外写逻辑，资源提前释放但后续还有写操作
- 多线程环境下，一个线程写入后未同步通知另一线程 flush，后者误以为数据已就绪
- 日志类工具封装了 BufferedWriter，但没暴露 flush 接口，上层调用后无法确保落盘
为什么叫“静默”？因为没有失败反馈
写入方法（如 write(String)、write(int)）只负责把数据塞进缓冲区，返回 void 或仅校验参数，完全不检查底层是否已持久化。即使磁盘已满、权限不足、路径不存在，只要缓冲区还能存，这些方法照样成功返回——真正的 I/O 错误往往要等到 flush() 或 close() 时才爆发。所以不调用它们，错误就永远埋着，数据就永远悬着。
怎么避免？关键在生命周期管理
不是“少写点”，而是“管到底”：
- 优先用 try-with-resources 自动关闭：它能确保
close()执行，从而触发最终 flush - 若需中间确认（如实时日志），每次关键写入后加
flush() - 避免跨方法传递未关闭的流对象；不要在 finally 块里只 close 而忽略 flush 的前置必要性
- 测试时可临时把缓冲区设极小（如
new BufferedWriter(writer, 1)），强制频繁刷盘，快速暴露遗漏
缓冲区不是保险箱，它是高速路的临时车道——车开上去不等于抵达终点，不下高速，永远不算到达。
