Java创建与读取目录全解析：File与NIO.2实战指南

1. 项目概述：为什么我要专门写一篇“创建与读取目录”的Java博文

如果你也是个写了几年Java的老码农，你大概也会有这种感觉：日常编码里最容易被忽略、但真出问题又最让人头疼的，就是IO这块。尤其是目录的创建和读取——你说它难吧，无非就是mkdir、list这几行代码的事；你说它简单吧，真到了生产环境，权限问题、路径分隔符问题、递归创建失败、目录流没关闭导致文件句柄泄漏……哪一件拎出来都能让你排查半天。

我之所以专门把“Java IO API - 创建与读取目录”这个主题单独拿出来写一篇，是因为我发现很多刚入行的朋友，Java基础面试题背得滚瓜烂熟，什么集合、锁、JVM调优都能扯几句，但真让他在服务器上写一段逻辑：检查目录是否存在、不存在就创建、然后把目录下的文件全部列出来做批量处理——他反而会卡壳。甚至不少工作两三年的同学，还在用File.list()然后手动判断null，完全不知道Java 7之后NIO.2提供了更好用的一套API。

这篇文章我打算用一条完整的主线来讲：从最传统的File体系开始，讲到Java 7引入的Path和Files体系，再深入到目录遍历、递归删除、文件过滤这些实战场景。内容覆盖Java基础到进阶的完整链路，既适合刚学Java的初学者打底，也适合准备Java面试的读者查漏补缺，更希望能给每天跟文件系统打交道的开发同学一些能直接抄走的代码片段。

2. 核心思路与技术选型：File体系与NIO.2体系，到底该怎么选

2.1 目录在Java里到底是个什么东西

很多初学者会有一个误区，觉得“目录”和“文件”是两种完全不同的东西。其实在操作系统的层面，目录就是一种特殊的文件——它里面存的不是业务数据，而是子文件和子目录的条目信息。Java的IO API也沿用了这个思路：无论File还是Path，操作目录和操作文件用的是同一套抽象，只不过在语义上通过isDirectory()等方法加以区分。

这个认知很重要。因为当你理解了“目录本身就是文件”，你就能明白为什么Files.createDirectory()抛出的异常、目录遍历时的权限问题、删除目录时要求目录为空这些规则，本质上都是操作系统文件系统层面的限制，而不是Java故意为难你。Java只是把底层的行为通过API暴露了出来。

在我接触过的项目里，很多奇怪的问题都源于对这个基本认知的偏差。比如有人想判断一个路径是不是目录，结果用path.toString().endsWith("/")去判断——这在Windows下直接失效，因为Windows的路径分隔符是反斜杠。正确做法永远是调用isDirectory()或者Files.isDirectory(Path)，让JDK帮你去跟文件系统确认，而不是自己去做字符串判断。

2.2 File与Path/Files的演进关系，选型时看什么

Java从1.0开始就提供了java.io.File类，这个类承载了Java早期所有的文件和目录操作。但它的设计有几个明显的历史包袱：一是它把路径字符串和操作逻辑耦合在一起，很多方法失败时返回false或null而不是抛出异常，导致错误信息丢失；二是它无法很好地表达符号链接、文件属性、目录流这类现代文件系统概念。

到了Java 7，官方推出了NIO.2，核心就是java.nio.file.Path接口和java.nio.file.Files工具类。Path用更抽象的方式表示路径，Files则提供了静态方法封装了几乎所有文件系统操作，包括我们今天要讲的创建目录和读取目录。这套新API最大的优势是：方法返回时有明确的类型信息，出错时抛出带有具体原因（比如NoSuchFileException、AccessDeniedException）的IOException，而不是默默返回一个false让你自己去猜。

那是不是说File就不能用了？也不是。如果你维护的是历史遗留项目，或者目标JDK版本还是Java 6甚至更老，File依然是唯一选择。但从长远来看，新代码我建议一律用Path + Files。原因很简单：NIO.2的API设计更安全、语义更清晰，而且它是所有现代Java框架（Spring Boot、Netty等）底层实际使用的IO方案。哪怕只是为了读代码不吃力，你也应该把NIO.2熟练起来。我在实际工作中对新代码的要求就一条：不允许再出现new File()去操作目录的情况，除非有特殊兼容需求。

3. 创建目录：从mkdir到createDirectories的完整演进

3.1 File.mkdir与File.mkdirs：老一代的创建方式到底坑在哪

先来看看传统的File方式。假设我要在/home/user/logs/2025/04这个路径下创建一个目录，传统写法是这样：

java复制File dir = new File("/home/user/logs/2025/04");
boolean created = dir.mkdirs();
if (created) {
    System.out.println("目录创建成功");
} else {
    System.out.println("目录创建失败");
}

这里有两个方法容易混淆：mkdir()和mkdirs()。区别只有一个，mkdir()只能创建单层目录，如果父目录不存在就创建失败；mkdirs()会连同所有不存在的父目录一起创建，相当于递归创建。这个区别在Java基础面试题里几乎必考，我面试别人的时候也常拿这个做切入点。

但我要说的是，这个老API最大的问题不是单层还是多层，而是失败时的表现。mkdir/mkdirs失败时只是返回false，不抛异常，也不告诉你为什么失败。是权限不够？是路径中有个文件占用了目录名？是磁盘满了？全都要你自己去猜。而且还有个更隐蔽的坑：如果目录已经存在，mkdirs()也会返回false，这在某些场景下会被误判为“创建失败”，导致业务逻辑走错分支。

我在一个老项目里就踩过这个坑。那段代码判断“目录创建失败就抛异常”，结果目录第二次运行时明明存在，却被当成失败处理，引发了后续一连串逻辑错误。后来排查了半天才发现是mkdirs()的返回值语义问题。所以如果你必须用File体系，记住了：创建前先通过exists()判断，或者干脆忽略返回值，创建后再用isDirectory()做一次确认，都比直接信任返回值要靠谱。

3.2 Files.createDirectory与Files.createDirectories：NIO.2的正确姿势

用NIO.2创建目录，对应的两个方法是Files.createDirectory(Path)和Files.createDirectories(Path)，前者创建单层，后者创建多层。用法如下：

java复制Path path = Paths.get("/home/user/logs/2025/04");
try {
    Files.createDirectories(path);
    System.out.println("目录创建成功：" + path);
} catch (FileAlreadyExistsException e) {
    System.out.println("目录已存在，无需重复创建");
} catch (IOException e) {
    System.err.println("创建目录失败：" + e.getMessage());
}

注意几个关键差异。第一，createDirectories()在目录已存在时不会报错，它的设计目标就是“确保目录存在”，所以你在业务代码里可以直接调用它，不需要先做exists()判断。第二，目录已存在时createDirectory()会抛出FileAlreadyExistsException，这是一个IOException的子类，你可以单独捕获做精确处理。第三，如果父目录的某个层级是已存在的文件而不是目录，系统会抛出FileSystemAlreadyExistsException或者类似的IOException，这种情况属于路径冲突，需要检查路径是否写错。

我在生产环境写初始化逻辑时，最常用的套路就是直接调用Files.createDirectories()，然后在后面跟一条日志记录。因为它天然满足幂等性——多执行几次不会出问题，这在定时任务、应用启动初始化这些场景里非常实用。比如下面这段代码，每次应用启动时确保日志目录存在：

java复制Path logDir = Paths.get(System.getProperty("user.home"), "app-logs");
try {
    Files.createDirectories(logDir);
} catch (IOException e) {
    throw new IllegalStateException("无法创建日志目录: " + logDir, e);
}

这里我用了System.getProperty("user.home")来获取用户主目录，用Paths.get的变参形式拼接路径，避免手动拼字符串时踩到Windows和Linux路径分隔符不一致的坑。这个细节虽然小，但确实是很多线上问题的根源。

3.3 目录权限与符号链接：创建目录时容易被忽略的细节

创建目录并不总是“调用一下就完事”，有几个细节在实际项目里会突然冒出来给你一击。

第一个是权限问题。如果你在Linux服务器上以普通用户身份运行Java程序，而目标目录位置需要root权限，Files.createDirectories会抛出AccessDeniedException。这个问题在任何教程里都不会细讲，但你在部署到服务器时几乎一定会遇到。排查思路很简单：先自己用命令行mkdir试一下，确认操作系统层面有没有权限，如果命令行都不行，Java代码怎么调都没用。

第二个是Posix权限的主动设置。有些场景要求创建出来的目录权限是700或者750，而不是默认的755。在Linux环境下，你可以用Files.setPosixFilePermissions在创建后设置权限：

java复制Path privateDir = Paths.get("/home/user/private");
Files.createDirectories(privateDir);
Set<PosixFilePermission> perms = PosixFilePermissions.fromString("rwx------");
Files.setPosixFilePermissions(privateDir, perms);

注意，这段代码只在支持Posix文件系统的环境（Linux、macOS）上才能运行，Windows上调用会抛出UnsupportedOperationException。所以生产环境做权限设置时，最好先用FileSystems.getDefault().supportedFileAttributeViews().contains("posix")判断一下当前系统是否支持。

第三个是符号链接。当你要创建的路径中某个层级是符号链接时，Files.createDirectories会穿透符号链接进行操作。绝大多数情况下这符合直觉——你想确保的其实是链接指向的那个目录存在。但如果你在写安全敏感的程序，比如文件上传服务，就需要注意符号链接可能把目录指向你预期之外的位置，存在路径穿越的风险。严格的校验做法是先调用toRealPath()解析出真实路径，再判断目标是否在允许的根目录之内。

4. 读取目录：从list到DirectoryStream再到Stream API

4.1 list与listFiles：老办法还值不值得用

创建完目录，下一步自然就是读取目录内容。传统的File体系提供了两个方法：list()返回String[]，只包含子项名称；listFiles()返回File[]，包含完整的File对象。用起来很简单：

java复制File dir = new File("/home/user/docs");
File[] files = dir.listFiles();
if (files != null) {
    for (File f : files) {
        if (f.isDirectory()) {
            System.out.println("[目录] " + f.getName());
        } else {
            System.out.println("[文件] " + f.getName() + "，大小 " + f.length());
        }
    }
}

是不是看起来很简单？但这里有个经典的坑：如果dir不是一个目录，或者发生IO错误，listFiles()返回的不是空数组，而是null。太多人写代码时忽略了null判断，直接遍历数组，结果列表页在特定条件下报出空指针异常——而且这个条件还很难稳定复现，因为只有目录不存在或者没权限时才会触发。

还有一个值得注意的点：list()和listFiles()返回的数组是一次性加载到内存的。如果目录下有几十万个文件，这个数组会占用相当大的内存，而且返回之前会阻塞在IO上。我处理过一个文件数量突破二十万的目录，友商用listFiles遍历导致内存飙升到1个G以上，后来改成NIO的DirectoryStream才把内存降下来。如果你维护的系统里有大目录场景，这一点必须放在心上。

当然，老API也不是一无是处。listFiles(FileFilter)和list(FilenameFilter)提供了过滤器重载，在文件数量不多时写起来非常简洁。我早年做文件批量处理时常用这个特性按扩展名过滤：

java复制File[] logs = dir.listFiles((d, name) -> name.endsWith(".log"));
File[] bigFiles = dir.listFiles(f -> f.isFile() && f.length() > 1024 * 1024);

两个重载的区别，一个是传入文件名，一个是传入File对象，按需选择就行。但注意过滤器里不要做耗时操作，因为它在调用线程里同步执行，每个子项都要过一次过滤器，文件多的时候会影响性能。

4.2 DirectoryStream：更安全的目录遍历方式

Java 7之后推荐的方式是DirectoryStream，它实现了Iterable接口，可以不一次性把所有子项读进内存，而是像流一样边读边处理。但它的正确使用姿势稍微有点讲究——必须用try-with-resources，因为DirectoryStream实现了Closeable接口，需要手动关闭释放底层资源。

下面这段代码是标准的写法：

java复制Path dir = Paths.get("/home/user/docs");
try (DirectoryStream<Path> stream = Files.newDirectoryStream(dir)) {
    for (Path entry : stream) {
        if (Files.isDirectory(entry)) {
            System.out.println("[目录] " + entry.getFileName());
        } else {
            System.out.println("[文件] " + entry.getFileName() + "，大小 " + Files.size(entry));
        }
    }
} catch (IOException e) {
    System.err.println("读取目录失败: " + e.getMessage());
}

这里有个很多新手不知道的细节：DirectoryStream只遍历当前目录一层，不会递归到子目录。另外，遍历过程中如果目录被并发修改（比如别的线程删除了一个文件），DirectoryStream不保证能响应这个变化，有些实现会抛ConcurrentModificationException，有些则不会，你也不能依赖这个行为。所以在做“遍历并删除文件”这类操作时，需要自己处理遍历期间目录内容变化的边界场景。

DirectoryStream还支持一个很实用的重载：传入一个glob模式过滤器，让底层直接替你过滤，比遍历后再判断效率更高。比如我只想读.jpg结尾的图片文件：

java复制try (DirectoryStream<Path> stream = Files.newDirectoryStream(dir, "*.{jpg,jpeg,png}")) {
    for (Path image : stream) {
        System.out.println("图片: " + image);
    }
} catch (IOException e) {
    e.printStackTrace();
}

这个glob模式语法和你在shell里用的通配符是类似的，*匹配任意长度的字符，?匹配单个字符，{jpg,jpeg}表示枚举匹配。在用之前我建议先看一遍官方文档的glob语法说明，不要凭直觉写，容易踩到语法不支持的坑。

4.3 Files.list与Files.walk：函数式风格的目录读取

DirectoryStream虽然省内存，但写起来还是传统迭代风格。Java 8把Stream引入之后，Files类也提供了配套方法，其中最常用的就是Files.list(Path)，它返回一个Stream，同样只遍历一层，但可以用Stream的链式操作做过滤、映射、收集。

java复制try (Stream<Path> stream = Files.list(Paths.get("/home/user/docs"))) {
    List<Path> txtFiles = stream
            .filter(p -> p.toString().endsWith(".txt"))
            .sorted(Comparator.comparing(p -> p.getFileName().toString()))
            .collect(Collectors.toList());
    txtFiles.forEach(System.out::println);
} catch (IOException e) {
    e.printStackTrace();
}

这里最最关键的又双叒是关闭问题。Files.list返回的Stream内部持有底层目录流的句柄，如果你不关闭它，文件句柄就会泄漏。最稳妥的方式就是try-with-resources，这已经是NIO.2目录操作的标准姿势了。在代码审查中，我看到过有人把Files.list返回的Stream存进一个字段里打算“慢慢用”，结果就是那个目录被持续占用，在Windows上甚至会导致目录无法删除或重命名。

Files.walk则更进一步，它可以递归遍历目录树，返回一个包含所有层级子目录和文件的Stream。walk有一个重载可以指定最大深度：Files.walk(path, maxDepth)，这个参数在遍历大型目录树时非常重要，不设上限的话，它会一直递归到最深层，而目录层级深、子项多的时候，这个操作的时间成本和内存开销都不容小觑。

我用Files.walk做过一个小工具，批量找出目录树下所有大于100MB的文件，整个过程可以用三行代码描述：

java复制try (Stream<Path> paths = Files.walk(Paths.get("/data"))) {
    List<Path> bigFiles = paths
            .filter(Files::isRegularFile)
            .filter(p -> {
                try {
                    return Files.size(p) > 100 * 1024 * 1024;
                } catch (IOException e) {
                    return false;
                }
            })
            .collect(Collectors.toList());
    bigFiles.forEach(System.out::println);
}

这个代码在开发环境跑得很欢，拿到生产环境就遇到一个问题：某些深层目录没有权限访问，Files.walk在递归遇到AccessDeniedException时会直接抛出来中断整个遍历。后来我用Files.walkFileTree + SimpleFileVisitor的方案替换了它，因为FileVisitor允许你在遇到无法访问的分支时自行决定是跳过还是终止。walk和walkFileTree的选择，本质上就是“简洁优先”和“健壮优先”的取舍。

5. 目录遍历的进阶玩法：递归删除、按条件查找与FileVisitor实战

5.1 递归删除目录树：三步走实现，但务必谨慎

删除目录和创建目录是配套操作，创建时用createDirectories，删除时却没有一个deleteDirectories让你一把梭。Files.delete只能删除空目录，如果目录下有文件，会抛出DirectoryNotEmptyException。要删除一个整棵目录树，要么自己递归，要么用walkFileTree。

我自己常用的是walkFileTree + SimpleFileVisitor，核心逻辑是：先删除所有文件，再删除所有目录。因为文件没有子级，可以直接删；目录必须等它的子项都删干净了，最后才能删掉自己。代码大概是这个样子：

java复制Path target = Paths.get("/tmp/old-data");
Files.walkFileTree(target, new SimpleFileVisitor<Path>() {
    @Override
    public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
        Files.delete(file);
        return FileVisitResult.CONTINUE;
    }

    @Override
    public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException {
        Files.delete(dir);
        return FileVisitResult.CONTINUE;
    }
});

注意postVisitDirectory是在一个目录的所有子项都访问完之后才回调，所以在这里删除目录是安全的。如果你在preVisitDirectory里就动手删目录，系统会报DirectoryNotEmptyException。另外，生产环境里这种代码要加小心，建议先打印日志再真正执行删除，最好把目标路径放到配置中心或者经过二次确认，避免手一抖删了根目录。我在内部工具里还加了校验，要求父路径必须包含特定的业务目录名，才允许执行删除。

5.2 Files.find：带属性的高级查找

Files.walk和Files.walkFileTree都是遍历，但如果你的需求是“按照文件属性查找”，比如找出所有大于10MB的文件、找出所有修改时间在昨天的文件，那Files.find会比walk更合适。它的签名是Files.find(Path start, int maxDepth, BiPredicate<Path, BasicFileAttributes> matcher)，第三个参数直接给你BasicFileAttributes，不需要再通过Files.size和Files.getLastModifiedTime去额外查询，性能上会好一些。

实战例子，找出/data目录下5天内修改过的所有log文件：

java复制long fiveDaysAgo = System.currentTimeMillis() - 5L * 24 * 60 * 60 * 1000;
try (Stream<Path> results = Files.find(
        Paths.get("/data"),
        Integer.MAX_VALUE,
        (path, attrs) -> attrs.isRegularFile()
                && path.toString().endsWith(".log")
                && attrs.lastModifiedTime().toMillis() > fiveDaysAgo
)) {
    results.forEach(System.out::println);
} catch (IOException e) {
    e.printStackTrace();
}

这里有一个我踩过的坑：maxDepth参数我一开始写的是Integer.MAX_VALUE，意图是“不限深度”，结果在生产环境遍历了一个挂载了网络存储的目录树，整整跑了十几分钟，把性能监控都打爆了。后来我把这个查询加了一个depth限制，并在业务层面明确最多扫描三层。文件遍历这个操作，你真得对目录规模有预估再动手，否则很容易出性能事故。

5.3 glob模式与正则模式：两种过滤方式，何时用哪个

前面提到DirectoryStream支持glob模式过滤，Files类里还有一个PathMatcher机制，可以通过FileSystems.getDefault().getPathMatcher("glob:**.log")来构建。PathMatcher支持两种语法：glob和regex。两者选择很直观——简单的文件名匹配用glob，复杂的条件用regex。

举个例子，我要匹配日志目录下所有以2025开头的.log文件：

java复制PathMatcher matcher = FileSystems.getDefault().getPathMatcher("glob:**/2025*.log");
try (DirectoryStream<Path> stream = Files.newDirectoryStream(Paths.get("/var/log"), "*.log")) {
    for (Path entry : stream) {
        if (matcher.matches(entry)) {
            System.out.println("匹配到日志文件: " + entry);
        }
    }
} catch (IOException e) {
    e.printStackTrace();
}

PathMatcher的glob语法里，**是很重要的一个模式，它表示匹配任意层级的路径。而DirectoryStream里那个简单的glob重载，实际匹配的是文件名部分，不支持跨越目录层级。如果你要用PathMatcher去匹配完整路径，需要把Path转换为绝对路径再调用matches，否则相对路径和绝对路径的比较结果会出乎意料。

6. 常见问题与排查技巧实录：那些坑我都替你踩过了

6.1 高频问题速查表

为了让读者能快速定位问题，我把这些年实战里遇到的高频Bug整理成一个表格，每一行都对应真实的线上场景：

这个表格只是一个索引，很多问题的排查思路不是表面这么简单。比如最后那个中文文件名乱码，当年也是折腾了不少时间。现象是程序在Linux上列出文件名正常，但把文件名写入数据库再读出来展示时变成乱码。后来发现是JDK在读取文件名时用的是系统默认编码，而系统的LANG环境变量没设好，导致文件名以GBK解码出来。解决办法是在启动脚本里明确设置JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8"，并且保证操作系统的locale也统一成UTF-8。

6.2 文件句柄泄漏：一个困扰了一下午的真实案例

想跟你分享一个真实的排查经历。有个内部数据同步任务，每次跑完都会报“打开的文件过多”（Too many open files），一开始大家以为是连接池没释放，后来把连接池调优一遍也没用。最后看了堆栈才发现，是代码里有一段类似这样的逻辑：

java复制Stream<Path> stream = Files.list(Paths.get("/data/inbox"));
List<Path> files = stream.collect(Collectors.toList());
// 后续处理...

Files.list返回的Stream没有被关闭。在Linux上，文件句柄是有限资源，默认单进程1024个，这个任务每次执行会打开几十个目录流而且不关闭，连续跑几十次就把句柄耗尽了。解决办法就是用try-with-resources包裹：

java复制try (Stream<Path> stream = Files.list(Paths.get("/data/inbox"))) {
    List<Path> files = stream.collect(Collectors.toList());
    // 后续处理...
}

这个教训让我之后的代码审查里多了一条铁律：凡是看到Files.list、Files.walk、Files.find、Files.newDirectoryStream这四类调用，必须检查是否处于try-with-resources中，否则一律打回。文件句柄泄漏不像内存泄漏那么容易被GC感知到，它会在你以为一切正常的时候，突然让整个应用崩掉。

6.3 路径分隔符与跨平台兼容性

还有一个非常经典的问题：硬编码路径分隔符。Windows用的是反斜杠\，Linux和macOS用的是正斜杠/。Java在Windows上其实能同时接受/和\，因为Windows系统调用本身就对/做了兼容处理，但如果你把路径写到配置文件里再跨环境使用，就很容易出差错。

我在代码里统一遵守三个原则：第一，代码中不写死分隔符，拼接路径一律用Paths.get的变参形式或者FileSystems.getDefault().getSeparator()；第二，配置文件里的路径统一使用/，因为Java在Windows上解析/没有任何问题，但反之不成立；第三，如果必须从字符串构造Path，优先用Paths.get(pathString)而不是new File(pathString).toPath()，因为前者会做更严格的路径合法性检查。

另外一个容易踩的点是相对路径的基准问题。Paths.get("data/logs")是相对于JVM的工作目录，也就是启动Java进程时所在的目录，而不是项目根目录或classpath目录。如果你用IDE启动应用和用java -jar启动应用，工作目录不一样，相对路径解析出来的绝对位置可能也不同。生产环境我建议要么统一用System.getProperty("user.dir")拼接完整路径，要么强烈要求配置文件里就必须是决定好的绝对路径，千万别在代码里裸写相对路径。

6.4 目录状态判断的冗余防御

最后分享一个我认为非常有价值的小技巧：目录操作前后的状态校验。很多线上问题，根因是对目录的“假设”与实际环境不匹配。写代码时默认“目录应该存在”，结果目录被运维清理了；或者默认“目录不存在”，结果上次运行已经创建过了。针对这种情况，我习惯在关键目录操作前后加上防御性校验，让问题第一时间暴露，而不是等到三个小时后的数据对账才发现。

比如下面这个模式，是我在初始化模块里常用的：

java复制Path workDir = Paths.get("/data/work");
if (!Files.exists(workDir)) {
    Files.createDirectories(workDir);
}
if (!Files.isDirectory(workDir) || !Files.isReadable(workDir) || !Files.isWritable(workDir)) {
    throw new IllegalStateException("工作目录不可用: " + workDir);
}

这段代码先确保目录存在，再确认它真的是目录、可读可写，任何一个条件不满足就立刻抛出异常。代价只是多几个系统调用，但换来的是一启动就能发现环境问题，而不是等到业务跑了一半才在某个角落报错。这种“防御性校验”的风格，在运维严格的团队里是很受认可的。

7. 实操总结：从这次项目中沉淀下来的经验

写到这里，“Java IO API - 创建与读取目录”这个主题的核心内容基本讲完了。回看整篇文章梳理的过程，我自己最大的感受是：文件目录操作看上去是Java IO里最不起眼的角落，但它在面试题里常驻，在线上问题中出现频率也极高，而这恰恰说明了基础知识的重要性。无论是mkdir和mkdirs的区别，还是目录流必须关闭，这些点你提前掌握了，踩坑的概率就能大幅下降。

如果你只记住一句话：新代码请使用Path + Files + try-with-resources来处理目录创建和读取，老代码遇到问题时再检查是否有返回值忽略、空指针、句柄泄漏这三类隐患。按照这个思路去写，目录相关的代码至少能减少一半的线上故障。

我个人在实际操作中的体会是：目录操作代码写得好不好，看的不是你会不会调用API，而是你有没有把“目录可能不存在”“目录可能有权限问题”“目录下的内容可能很大”“目录在遍历期间可能发生变化”这些边界场景都考虑进去。把这些场景想在前面，代码自然就健壮了。以后你写完目录操作代码，不妨问自己一个问题：如果这个目录不见了、满了、没权限了、被人塞了上万个文件，我的代码会怎样？能把这些问题答清楚，你的Java IO基本功就算真正过关了。