必须用字节流，因多媒体文件是二进制数据，字符流解码会损坏文件；分块宜选8KB–64KB，本地磁盘推荐32KB、网络上传16KB；须用缓冲流、try-with-resources和flush；接收端应以RandomAccessFile配合seek写入指定位置。
处理大文件分块传输，必须用字节流，字符流完全不适用。
为什么只能用字节流
多媒体文件（MP4、AVI、JPEG、WAV等）本质是二进制数据，含大量非文本字节（如帧头、编码标记、元数据）。字符流（FileReader/FileWriter）会尝试按指定编码（如UTF-8）解码字节，遇到非法序列就抛异常或静默替换，导致文件损坏——视频打不开、图片花屏、音频爆音。字节流（FileInputStream/FileOutputStream）原样搬运每个byte，零转换、零丢失，是唯一安全选择。
分块大小怎么定：8KB–64KB最稳妥
这不是经验值，而是I/O效率与内存占用的平衡点：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 小于8KB（如1KB）：系统read()调用太频繁，上下文切换开销大，吞吐量反而下降
- 大于64KB（如1MB）：单次分配大数组，易触发GC或OOM，尤其在多线程上传或低配服务器上
- 实测推荐值：本地磁盘用32KB，网络上传用16KB；SSD可上探至64KB，HDD建议8–16KB
关键操作不能省：缓冲+自动关流+显式flush
光用FileInputStream/OutputStream还不够，得加两层保障：
立即学习“Java免费学习笔记（深入）”；
- 套一层BufferedInputStream/BufferedOutputStream，减少底层系统调用次数
- 必须用try-with-resources语法，确保流异常时也关闭，避免句柄泄漏
- 写入完成后调用fos.flush()，强制刷出缓冲区剩余数据，防止末尾字节丢失
- 绝对不要用fis.available()预估长度——它返回的是“当前可读字节数”，不是文件总长，对网络流或管道流常返回0或错误值
接收端拼接要靠RandomAccessFile
分块上传后，各块需按序写入同一目标文件。普通FileOutputStream每次打开都是覆盖或追加模式，无法精确定位写入位置。正确做法是：
- 用RandomAccessFile以"rw"模式打开目标文件
- 调用seek(offset)跳转到该块应写入的起始字节位置
- 再用write(byte[])写入当前块数据
- 这样即使块乱序到达，也能准确落盘，天然支持断点续传
