不丢字符的关键是解码准、缓冲稳、边界清：必须显式指定UTF-8编码（禁用FileReader/FileWriter默认编码），配用BufferedReader/BufferedWriter，读取用readLine()，写入前flush，关闭用try-with-resources。
用字符流读写文本时，不丢字符的关键不是“读得快”，而是“解码准、缓冲稳、边界清”。FileReader 和 FileWriter 默认依赖系统编码，一旦和文件真实编码不一致，中文就容易被截断或跳过——这不是丢数据，是根本没正确识别字符边界。
明确指定字符编码，别信默认值
FileReader/FileWriter 构造时不支持传入编码参数，它们内部硬编码使用 系统默认编码（Windows 常是 GBK，Linux/macOS 多为 UTF-8）。如果文件是 UTF-8 编码，但在 Windows 上用 FileReader 直接读，一个中文字符的三个字节会被错误拆成两段处理，导致部分字符无法还原。
- 改用 InputStreamReader + FileInputStream 组合，显式指定编码： new InputStreamReader(new FileInputStream("a.txt"), "UTF-8")
- 同理，写入时用 OutputStreamWriter + FileOutputStream： new OutputStreamWriter(new FileOutputStream("b.txt"), "UTF-8")
- 开发中建议统一约定文件编码为 UTF-8，并在所有字符操作处强制声明，避免环境差异引发隐性丢失
用带缓冲的字符流，避免单字符读写
FileReader.read() 每次只返回一个 int（对应一个 char），看似简单，但实际底层仍需按字节块解码。若手动循环调用 read() 且未配合缓冲，容易在边界处因缓冲区未填满而提前结束，尤其遇到换行符或文件末尾的不完整字符序列时。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 优先使用 BufferedReader 和 BufferedWriter，它们自带 8KB 缓冲区，能自动对齐字符边界
- 读取推荐按行：readLine() 内部会完整解析一行，不会在中文中间切断
- 写入时用 newLine() 而非 "\n"，确保换行符符合当前平台规范，避免后续读取错位
关闭前务必 flush，尤其写入场景
FileWriter 和 BufferedWriter 都有内部缓冲区。如果只 close() 不 flush()，最后一批尚未写出的字符可能滞留在内存中，随着 JVM 退出而丢失——这不是编码问题，是资源释放顺序导致的静默丢数据。
立即学习“Java免费学习笔记（深入）”；
- 使用 try-with-resources 时，close() 会自动触发 flush()，相对安全
- 若手动管理流，必须在 close() 前显式调用 flush()
- 注意：FileWriter 的构造方法若传入 true（追加模式），flush 后内容会追加到文件末尾，不会覆盖，但依然要保证 flush 成功
检查文件末尾是否含 BOM 或非法字节
有些编辑器（如 Windows 记事本）保存 UTF-8 文件时会添加 BOM（EF BB BF），而 FileReader 不识别 BOM，可能把前三个字节当乱码跳过，造成首字符“消失”的假象；另外，文件若被异常中断写入，末尾残留半截 UTF-8 字节序列（如只剩两个字节的“汉”），解码器会静默跳过该字符。
- 用十六进制编辑器确认文件真实编码和结尾字节
- 读取时可先用字节流检查前几个字节是否为 BOM，再决定是否跳过
- 生产环境建议用 Apache Commons IO 的 FileUtils.readFileToString(file, "UTF-8")，它内置 BOM 处理逻辑
