根本原因是IOUtils.copy()字节级拷贝不处理编码，文本需显式指定UTF-8；FileUtils.readFileToByteArray()易OOM，大文件应分块读；forceDelete()无法绕过Windows文件占用锁；getExtension()按最后一个点截取，.tar.gz返回gz合理。
用 IOUtils.copy() 读写流时为什么文件内容变空或乱码？
根本原因不是函数本身有问题，而是默认用 InputStream/OutputStream 的字节级拷贝，不处理字符编码。如果源是 UTF-8 文本但没指定编码，IOUtils.copy() 就原样搬字节，下游按平台默认编码（比如 Windows 的 GBK）解，必然乱码。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 文本场景优先用
IOUtils.toString(inputStream, "UTF-8")或IOUtils.write(string, outputStream, "UTF-8")，显式传编码 - 二进制文件（图片、ZIP）才用
IOUtils.copy(input, output)，此时编码参数无效，也不该传 - 别把
FileInputStream直接塞给toString()——它会尝试按编码解析二进制，结果不可控
FileUtils.readFileToByteArray() 内存爆了怎么办？
这个方法会把整个文件一次性加载进堆内存，读一个 500MB 的日志文件，JVM 很可能直接 OutOfMemoryError。它适合小配置文件、模板文件这类 KB 级数据，不是为大文件设计的。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 文件大于 10MB 就放弃
readFileToByteArray()，改用FileInputStream+BufferedInputStream分块读 - 想用 Commons IO 又要控内存，选
IOUtils.readLines(inputStream, "UTF-8")，逐行读，适合日志分析 - 注意
readLines()返回的是List<string></string>，如果文件有千万行，List 本身也吃内存，得配合流式处理（如传LineIterator）
为什么 FileUtils.forceDelete() 在 Windows 上删不掉正在被占用的文件？
Java 的 File.delete() 和 Commons IO 的 forceDelete() 都依赖底层 OS 的文件系统权限。Windows 下只要文件被任意进程（包括记事本、IDE、杀毒软件）打开着，删除就会失败，抛 IOException: Unable to delete file。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
forceDelete()只是多试几次 + 清只读属性，并不能绕过 OS 锁，别指望它“强制”到能删被占用的文件 - 真要删，先确保无进程持有句柄：关 IDE、停服务、检查资源管理器是否预览了该文件
- 生产环境避免在运行时删活跃日志文件；改用
FileUtils.moveFile()归档再删更安全
用 FilenameUtils.getExtension() 提取后缀时，.tar.gz 返回 gz 合理吗？
合理。这个函数定义就是“最后一个点之后的部分”，不是“逻辑后缀”。对 archive.tar.gz，它只看字符串结构，不识别复合压缩格式。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 需要识别
.tar.gz这类双后缀，别依赖getExtension()，改用正则匹配或FilenameUtils.getName()后手动切分 - 如果只是做简单类型判断（比如只区分
.jpg和.pdf），getExtension()完全够用，性能比正则好 - 注意它对
noext返回空字符串，对.hidden返回hidden，边界情况要判空
真正麻烦的是混合场景：一边要流式处理大文件防止 OOM，一边又要准确识别复杂后缀，还要求跨平台删文件不报错——这些事 Commons IO 不打算包圆，得自己搭积木。
