File.listFiles() 返回 null 是因权限不足、路径不存在或 I/O 异常，非空目录；须先判空避免 NPE；Files.walk() 更安全但需限深防 OOM，且须及时关闭流。
File.listFiles() 返回 null 的原因和应对
它不是“没找到文件”，而是遇到权限问题、路径不存在或 I/O 异常时直接返回 null，不抛异常。很多代码直接对返回值调用 .length 或遍历，结果触发 NullPointerException。
- 永远先判空：
if (files == null) { /* 处理失败 */ } -
listFiles()不处理符号链接，也不过滤隐藏文件（如.git），需要手动判断file.isHidden() - 在 Windows 上访问网络驱动器、Linux 上访问挂载点失败时也常返回
null，不能只当成“空目录”处理
递归遍历时怎么避免 StackOverflowError
深层嵌套目录（比如日志归档生成的 200 层子目录）会让纯递归快速耗尽栈空间。JDK 7+ 推荐用 Files.walk() 替代手写递归，但要注意它的默认行为。
-
Files.walk(path)默认不限制深度，同样可能 OOM；应显式加限制：Files.walk(path, 16) - 如果必须手写递归，改用栈模拟（
Deque<path></path>）而非方法调用栈，控制内存占用更稳 - 注意软链接循环：A → B → A，
Files.walk()默认会检测并跳过，但自定义递归不会，得用Set<string> visited</string>记录已展开的toRealPath().toString()
Files.walk() 和 listFiles() 的性能与语义差异
两者根本不是同一类工具：listFiles() 是即时、一次性、无状态的数组快照；Files.walk() 是延迟求值的流，打开后才真正读目录，且持有文件系统句柄。
- 遍历大目录时，
Files.walk()内存更省（流式），但若中途不.close()或不用 try-with-resources，会泄漏DirectoryStream -
listFiles()返回的是File[]，路径是相对父目录的；Files.walk()返回的是Path，全是绝对路径，拼接子路径时别混用File.separator和Path.resolve() - Android（API Files.walk()，得降级用
FileUtils.iterateFiles()（Apache Commons IO）或自己兜底
过滤文件类型时常见的类型误判
靠文件名后缀判断类型（比如 name.endsWith(".txt")）在真实环境里极不可靠——没有后缀、后缀被改、大小写混用、多点名（archive.tar.gz）都会翻车。
立即学习“Java免费学习笔记（深入）”；
- 用
Files.probeContentType(path)检查 MIME 类型更准，但它依赖系统命令（Linux/macOS 用file命令），Windows 上常返回null - 真正健壮的做法是组合：先按后缀粗筛，再对关键文件用
Files.isRegularFile()+Files.size()判空/大小，最后按需读头几个字节验证魔数（如 PNG 的89 50 4E 47） - 注意
listFiles()不区分文件/目录，Files.walk()默认包含所有类型，过滤时务必加上.filter(Files::isRegularFile)或.filter(Files::isDirectory)
事情说清了就结束。实际项目里最常出问题的，不是“怎么写”，而是忘了 listFiles() 会返回 null，以及把 Files.walk() 当成普通集合用完不关流。
