directory.createdirectory实战：3步搞定性能优化，告别空目录报错
刚学完 os 模块，对着 mkdir 敲代码，结果项目一跑就崩？别慌，这是90%新手的通病。你背下了语法，却不知道怎么在真实工程里搭出稳如泰山的目录结构。更扎心的是，一旦目录创建失败，整个部署流程就断在半路，排查起来头大。今天咱们不聊虚的，直接拆解 directory.createdirectory 这个高频报错背后的坑，顺便讲讲如何通过合理的目录策略实现性能优化。记住，在工程化开发中，文件系统操作不是简单的增删改查，它直接关联到 I/O 瓶颈和并发安全。很多人忽略了一点：RFC 规范里对文件路径长度和字符集的限制（如 RFC 8089 对 HTTP URL 的编码规则），在跨平台部署时，如果你没处理好目录命名和层级，轻则报错，重则导致容器挂载失败。下面咱们用真实场景，一步步把这块硬骨头啃下来。
为什么你的目录创建总出错？定位不同方案的痛点
在深入代码前，先搞清楚你现在的痛点到底在哪。是手动创建太麻烦？还是用库创建不安全？亦或是并发环境下目录冲突？
很多开发者习惯用 os.mkdir，这没错，但它在多层级目录创建时是个“弱鸡”。比如你想创建 /data/logs/app/2023/10，os.mkdir 只能创建最后一级，前面的层级必须已经存在。一旦缺失，直接抛 FileNotFoundError。这时候你可能想：“那我加个 exist_ok=True 不就行了？” 行，但如果是多级，你还是得一层层套，或者递归判断，代码写得跟面条一样。
另一种常见做法是用 os.makedirs，它支持一次性创建多级目录，也支持 exist_ok。但问题出在并发场景。假设你的 Web 服务有 10 个线程同时启动，都试图创建同一个日志目录。os.makedirs 在检查“目录是否存在”和“创建目录”这两个步骤之间，存在时间窗口（Time-of-check to time-of-use, TOCTOU）。线程 A 检查目录不存在，线程 B 也检查不存在，然后 A 创建成功，B 创建时抛出 FileExistsError。虽然加了 exist_ok=True 能吞掉这个异常，但如果你后续还有依赖目录创建成功的其他操作，这种“假成功”可能会掩盖真正的逻辑错误。
再来看 Python 3.2 引入的 pathlib.Path.mkdir。它封装了 os 模块，接口更面向对象。但它的底层实现依然依赖系统调用，对于复杂的权限控制或特殊文件系统（如 NFS、CIFS），它的容错能力并不比 os 强多少。
最后，很多人忽略了第三方库 pyfilesystem 或 shutil。shutil 提供了 make_archive 等高级功能，但在纯目录创建上，它并没有提供比 os 或 pathlib 更本质的优势，反而增加了依赖。
核心结论：没有银弹，只有最适合你场景的工具。单机脚本、Web 服务、容器化部署，三种场景下的最佳实践完全不同。
核心差异对比：os、pathlib 与并发安全
为了让你一眼看清区别，咱们用一张表格来硬核对比这三种主流方案在关键维度上的表现。注意，这里的“性能”不仅指执行速度，更指在高并发下的稳定性和资源开销。特性/维度
os.mkdir / os.makedirs
pathlib.Path.mkdir
并发安全锁方案 (fcntl/mutex)API 风格
函数式，参数扁平
面向对象，链式调用
混合模式，需手动加锁多级创建支持
makedirs 支持，需 exist_ok
mkdir(parents=True) 支持
支持，但需自行处理逻辑异常处理
原生异常，需 try-except
原生异常，需 try-except
可自定义，屏蔽竞争异常跨平台一致性
高，但路径分隔符需处理
高，自动处理路径分隔符
中，锁机制在 Windows/Linux 不同并发安全性
低 (TOCTOU 风险)
低 (TOCTOU 风险)
高 (原子性保证)性能开销
极低，直接系统调用
低，少量对象封装开销
高，涉及系统级锁或原子操作适用场景
简单脚本、单线程
现代 Python 项目、重构代码
高并发 Web 服务、分布式任务解读关键点：TOCTOU 陷阱：在 os 和 pathlib 中，检查与操作是非原子的。在 Linux 下，mkdir 系统调用本身是原子的，但 Python 层的 exist_ok 逻辑是先 stat 再 mkdir，这就引入了竞争。
性能优化视角：对于单线程脚本，os.makedirs 的性能略优于 pathlib，因为后者有对象创建开销。但对于 Web 服务，稳定性优于速度。一个因为并发创建目录导致的 500 错误，其修复成本远超那几微秒的性能损失。
RFC 规范关联：在构建目录结构时，文件名往往来源于用户输入或 HTTP 请求。根据 RFC 3986 对 URI 的规范，路径中的某些字符（如 #, ?）是保留字符。如果你的目录创建逻辑直接拼接 URL 路径而不做解码或清洗，不仅会报错，还可能导致路径遍历漏洞（Path Traversal）。这是安全与性能的双重隐患。代码写法对比：从入门到生产级
光说理论没用，咱们直接上代码。以下代码块均基于 Python 3.10+ 环境，确保兼容性和现代特性。
方案一：基础版 - os.makedirs (适用于简单脚本)
这是大多数教程里的写法，简单直接，但请注意异常处理的粒度。
import os
import logginglogging.basicConfig(level=logging.INFO)def create_dirs_os(target_dir: str) - bool:使用 os 模块创建多级目录:param target_dir: 目标目录路径:return: 是否创建成功try:# exist_ok=True 忽略目录已存在的错误# mode=0o755 设置权限，但受 umask 影响os.makedirs(target_dir, mode=0o755, exist_ok=True)logging.info(fDirectory created: {target_dir})return Trueexcept FileExistsError:# 虽然 exist_ok 处理了大部分情况，但极端竞争下仍可能触发# 这里为了健壮性，显式捕获logging.warning(fDirectory already exists: {target_dir})return Trueexcept PermissionError:logging.error(fPermission denied to create: {target_dir})return Falseexcept OSError as e:# 捕获其他 OS 层错误，如磁盘满、路径无效logging.error(fOS error while creating dir: {e})return False# 测试
create_dirs_os(/tmp/test_logs/2023/10/01)代码解析：mode=0o755：指定目录权限。但在生产环境中，权限通常由部署脚本或 Dockerfile 控制，代码中硬编码权限是不好的习惯，建议仅保留 exist_ok。
缺陷：在多线程环境下，两个线程同时执行 os.makedirs，即使加了 exist_ok，日志中可能会出现混乱的警告，且无法保证创建动作的原子性（即无法保证“要么完全创建，要么完全未创建”的中间状态一致性，尽管目录本身是原子的，但后续操作可能受影响）。方案二：进阶版 - pathlib.Path (适用于现代项目)
pathlib 提供了更优雅的接口，且能更好地处理路径拼接。
from pathlib import Path
import logginglogging.basicConfig(level=logging.INFO)def create_dirs_pathlib(target_dir: str) - bool:使用 pathlib 创建多级目录:param target_dir: 目标目录路径:return: 是否创建成功path = Path(target_dir)try:# parents=True 相当于 os.makedirs# exist_ok=True 忽略已存在path.mkdir(parents=True, exist_ok=True)# 额外步骤：验证路径是否为目录if not path.is_dir():raise ValueError(fPath is not a directory: {path})logging.info(fDirectory verified: {path})return Trueexcept FileExistsError:# pathlib 的 mkdir 在 exist_ok=True 时通常不抛此异常# 但如果路径是一个文件，会抛 FileExistsErrorlogging.error(fPath exists but is not a directory: {path})return Falseexcept PermissionError:logging.error(fPermission denied: {path})return Falseexcept OSError as e:logging.error(fOSError: {e})return False# 测试
create_dirs_pathlib(/tmp/test_logs/2023/10/02)代码解析：Path(target_dir)：将字符串转换为 Path 对象，支持 / 运算符进行路径拼接，例如 base_dir / sub / file.txt，代码可读性大幅提升。
is_dir() 验证：这是一个好习惯。确保创建后路径确实是目录，防止因竞态条件导致路径被替换为文件的情况（虽然罕见，但在高并发下可能发生）。
性能：pathlib 的调用栈略深，但差异在微秒级，对于目录创建这种低频操作（通常在应用启动时执行一次），可以忽略不计。方案三：生产级 - 并发安全 + 原子性 (适用于 Web 服务)
这是解决 directory.createdirectory 类报错的终极方案。核心思想：不要依赖 exist_ok，而是利用系统调用的原子性或显式锁。
import os
import threading
import logging
from pathlib import Pathlogging.basicConfig(level=logging.INFO)# 简单的全局锁，适用于单进程多线程序
_dir_lock = threading.Lock()def create_dirs_concurrent_safe(target_dir: str) - bool:线程安全的目录创建:param target_dir: 目标目录路径:return: 是否创建成功with _dir_lock:path = Path(target_dir)try:# 在锁内执行，确保 check 和 create 的原子性# 注意：os.makedirs 在 Linux 下底层是多次 mkdir 系统调用# 锁保证了整个过程的互斥if not path.exists():path.mkdir(parents=True, exist_ok=False)logging.info(fCreated: {path})else:# 检查是否存在，但确保是目录if not path.is_dir():raise FileExistsError(fPath exists as file: {path})logging.debug(fAlready exists: {path})return Trueexcept FileExistsError:# 在锁内，如果还抛出 FileExistsError，说明路径被占用为文件logging.error(fConflict: {path} is not a directory)return Falseexcept Exception as e:logging.exception(fUnexpected error: {e})return False# 模拟高并发测试
def worker(thread_id: int):success = create_dirs_concurrent_safe(f/tmp/concurrent_test_{thread_id})if success:print(fThread {thread_id}: OK)if __name__ == __main__:threads = []for i in range(10):t = threading.Thread(target=worker, args=(i,))threads.append(t)t.start()for t in threads:t.join()代码解析：threading.Lock()：在单进程多线程序（如 Flask/Gunicorn 的 sync 模式）中，使用锁是最简单有效的并发控制手段。
exist_ok=False：在锁保护下，我们可以更严格地检查。如果目录不存在，则创建；如果存在，则验证。这避免了 exist_ok=True 可能掩盖的“路径被文件占用”的严重错误。
局限：threading.Lock 只在单进程内有效。如果你的服务是多进程部署（如 Gunicorn 多 worker、Celery 多进程），这个锁不起作用。多进程场景怎么办？
在多进程环境下，你需要使用系统级文件锁（如 fcntl.flock on Linux, msvcrt.locking on Windows）或数据库行锁。但更推荐的做法是：将目录创建逻辑移出应用启动流程。
最佳实践建议：初始化阶段：在 Dockerfile 的 RUN mkdir -p /app/logs 或 K8s 的 initContainer 中创建静态目录。
运行时：应用只负责写入文件，不负责创建目录。如果必须动态创建，使用 mkdir 系统调用的原子性（在 C 扩展或 Rust 侧实现），或者接受 FileExistsError 并忽略（前提是确保路径是目录）。
性能优化：对于高频动态目录（如按日期分区的日志），使用 os.stat 缓存目录存在性，避免频繁的系统调用。适用场景与选型建议
别被代码吓到，根据你的实际场景选就行：单机脚本 / 一次性任务：推荐：os.makedirs 或 pathlib.Path.mkdir。
理由：简单、无依赖、性能足够。不用考虑并发，exist_ok=True 完全够用。Web 应用 (单进程/多线程)：推荐：pathlib + threading.Lock (如果必须动态创建)。
理由：pathlib 代码更清晰，锁解决线程竞争。但更推荐在应用启动时统一创建所有必要目录，运行时只写文件。容器化 / 微服务 (多进程)：推荐：Dockerfile / K8s 初始化。
理由：不要在 Python 代码里处理多进程并发创建目录的痛点，那是架构层面的问题。将目录创建交给编排系统或镜像构建过程，代码保持无状态和轻量。这是真正的性能优化——把 I/O 开销前置，避免运行时抖动。高性能 / 高并发场景：推荐：预创建 + 内存缓存。
理由：在应用启动时，扫描配置，创建所有可能用到的目录，并将路径对象缓存到内存。运行时直接 open 文件，避免 mkdir 系统调用。这能显著降低 CPU 占用和上下文切换开销。避坑指南：不要硬编码权限：让操作系统或容器运行时管理权限。
注意路径长度：Linux 默认路径长度限制 4096 字节，Windows 260 字符。超过这个长度会报错。在生成动态目录名时，务必控制长度。
字符集问题：避免使用非 ASCII 字符作为目录名，除非你确定整个链路（代码、文件系统、日志系统）都支持 UTF-8。还有这些细节容易踩坑
除了并发，还有一个常被忽略的点：目录删除与重建。
在清理旧日志时，你可能想“删掉旧目录，创建新目录”。但 os.rmdir 只能删空目录，shutil.rmtree 可以删非空目录，但它是非原子的。如果在删除过程中，另一个线程还在写文件，会导致数据丢失或文件句柄错误。
正确做法：不要删除正在使用的目录。
使用“原子重命名”策略：创建新目录 - 将旧目录重命名为 .old - 删除 .old。
或者，使用 rotating log handler 等库，让库来处理文件轮转，而不是手动管理目录。性能优化小贴士：批量创建：如果你需要创建 100 个目录，不要循环调用 100 次 mkdir。可以考虑使用 os.system(mkdir -p ...)（不推荐，有安全风险）或编写 C 扩展批量调用。但在 Python 层面，循环调用的开销主要在于 Python 解释器，而非系统调用。对于 100 次以内的创建，直接循环即可。
异步 I/O：在 asyncio 应用中，使用 asyncio.to_thread 将阻塞的 mkdir 操作放到线程池执行，避免阻塞事件循环。import asyncio
from pathlib import Pathasync def async_create_dir(target_dir: str):在 asyncio 中创建目录path = Path(target_dir)# 将阻塞操作放入线程池await asyncio.to_thread(path.mkdir, parents=True, exist_ok=True)最后，关于 RFC 规范的再次强调：
如果你的目录名来源于 URL 参数，务必参考 RFC 3986 进行百分号解码（urllib.parse.unquote），并过滤掉非法字符（如 /, \, :, *, ?, , , , |）。这不仅是为了避免 directory.createdirectory 报错，更是为了防止路径遍历攻击。安全，永远是性能优化的前提。
技术选型没有绝对的对错，只有适合的与不适合的。os 模块经典可靠，pathlib 现代优雅，并发锁保障稳定，容器化前置高效。根据你的项目规模、部署环境和团队熟悉度，选择最让你睡得着觉的方案。
在实战中，你是否也遇到过因为目录创建导致的诡异 Bug？比如文件找不到、权限不足、或者并发冲突？还有什么不懂的？评论区留言挨个回。 directory.createdirectory实战：3步搞定性能优化，告别空目录报错
directory.createdirectory实战：3步搞定性能优化，告别空目录报错
刚学完 os 模块，对着 mkdir 敲代码，结果项目一跑就崩？别慌，这是90%新手的通病。你背下了语法，却不知道怎么在真实工程里搭出稳如泰山的目录结构。更扎心的是，一旦目录创建失败，整个部署流程就断在半路，排查起来头大。今天咱们不聊虚的，直接拆解 directory.createdirectory 这个高频报错背后的坑，顺便讲讲如何通过合理的目录策略实现性能优化。记住，在工程化开发中，文件系统操作不是简单的增删改查，它直接关联到 I/O 瓶颈和并发安全。很多人忽略了一点：RFC 规范里对文件路径长度和字符集的限制（如 RFC 8089 对 HTTP URL 的编码规则），在跨平台部署时，如果你没处理好目录命名和层级，轻则报错，重则导致容器挂载失败。下面咱们用真实场景，一步步把这块硬骨头啃下来。
为什么你的目录创建总出错？定位不同方案的痛点
在深入代码前，先搞清楚你现在的痛点到底在哪。是手动创建太麻烦？还是用库创建不安全？亦或是并发环境下目录冲突？
很多开发者习惯用 os.mkdir，这没错，但它在多层级目录创建时是个“弱鸡”。比如你想创建 /data/logs/app/2023/10，os.mkdir 只能创建最后一级，前面的层级必须已经存在。一旦缺失，直接抛 FileNotFoundError。这时候你可能想：“那我加个 exist_ok=True 不就行了？” 行，但如果是多级，你还是得一层层套，或者递归判断，代码写得跟面条一样。
另一种常见做法是用 os.makedirs，它支持一次性创建多级目录，也支持 exist_ok。但问题出在并发场景。假设你的 Web 服务有 10 个线程同时启动，都试图创建同一个日志目录。os.makedirs 在检查“目录是否存在”和“创建目录”这两个步骤之间，存在时间窗口（Time-of-check to time-of-use, TOCTOU）。线程 A 检查目录不存在，线程 B 也检查不存在，然后 A 创建成功，B 创建时抛出 FileExistsError。虽然加了 exist_ok=True 能吞掉这个异常，但如果你后续还有依赖目录创建成功的其他操作，这种“假成功”可能会掩盖真正的逻辑错误。
再来看 Python 3.2 引入的 pathlib.Path.mkdir。它封装了 os 模块，接口更面向对象。但它的底层实现依然依赖系统调用，对于复杂的权限控制或特殊文件系统（如 NFS、CIFS），它的容错能力并不比 os 强多少。
最后，很多人忽略了第三方库 pyfilesystem 或 shutil。shutil 提供了 make_archive 等高级功能，但在纯目录创建上，它并没有提供比 os 或 pathlib 更本质的优势，反而增加了依赖。
核心结论：没有银弹，只有最适合你场景的工具。单机脚本、Web 服务、容器化部署，三种场景下的最佳实践完全不同。
核心差异对比：os、pathlib 与并发安全
为了让你一眼看清区别，咱们用一张表格来硬核对比这三种主流方案在关键维度上的表现。注意，这里的“性能”不仅指执行速度，更指在高并发下的稳定性和资源开销。特性/维度
os.mkdir / os.makedirs
pathlib.Path.mkdir
并发安全锁方案 (fcntl/mutex)API 风格
函数式，参数扁平
面向对象，链式调用
混合模式，需手动加锁多级创建支持
makedirs 支持，需 exist_ok
mkdir(parents=True) 支持
支持，但需自行处理逻辑异常处理
原生异常，需 try-except
原生异常，需 try-except
可自定义，屏蔽竞争异常跨平台一致性
高，但路径分隔符需处理
高，自动处理路径分隔符
中，锁机制在 Windows/Linux 不同并发安全性
低 (TOCTOU 风险)
低 (TOCTOU 风险)
高 (原子性保证)性能开销
极低，直接系统调用
低，少量对象封装开销
高，涉及系统级锁或原子操作适用场景
简单脚本、单线程
现代 Python 项目、重构代码
高并发 Web 服务、分布式任务解读关键点：TOCTOU 陷阱：在 os 和 pathlib 中，检查与操作是非原子的。在 Linux 下，mkdir 系统调用本身是原子的，但 Python 层的 exist_ok 逻辑是先 stat 再 mkdir，这就引入了竞争。
性能优化视角：对于单线程脚本，os.makedirs 的性能略优于 pathlib，因为后者有对象创建开销。但对于 Web 服务，稳定性优于速度。一个因为并发创建目录导致的 500 错误，其修复成本远超那几微秒的性能损失。
RFC 规范关联：在构建目录结构时，文件名往往来源于用户输入或 HTTP 请求。根据 RFC 3986 对 URI 的规范，路径中的某些字符（如 #, ?）是保留字符。如果你的目录创建逻辑直接拼接 URL 路径而不做解码或清洗，不仅会报错，还可能导致路径遍历漏洞（Path Traversal）。这是安全与性能的双重隐患。代码写法对比：从入门到生产级
光说理论没用，咱们直接上代码。以下代码块均基于 Python 3.10+ 环境，确保兼容性和现代特性。
方案一：基础版 - os.makedirs (适用于简单脚本)
这是大多数教程里的写法，简单直接，但请注意异常处理的粒度。
import os
import logginglogging.basicConfig(level=logging.INFO)def create_dirs_os(target_dir: str) - bool:使用 os 模块创建多级目录:param target_dir: 目标目录路径:return: 是否创建成功try:# exist_ok=True 忽略目录已存在的错误# mode=0o755 设置权限，但受 umask 影响os.makedirs(target_dir, mode=0o755, exist_ok=True)logging.info(fDirectory created: {target_dir})return Trueexcept FileExistsError:# 虽然 exist_ok 处理了大部分情况，但极端竞争下仍可能触发# 这里为了健壮性，显式捕获logging.warning(fDirectory already exists: {target_dir})return Trueexcept PermissionError:logging.error(fPermission denied to create: {target_dir})return Falseexcept OSError as e:# 捕获其他 OS 层错误，如磁盘满、路径无效logging.error(fOS error while creating dir: {e})return False# 测试
create_dirs_os(/tmp/test_logs/2023/10/01)代码解析：mode=0o755：指定目录权限。但在生产环境中，权限通常由部署脚本或 Dockerfile 控制，代码中硬编码权限是不好的习惯，建议仅保留 exist_ok。
缺陷：在多线程环境下，两个线程同时执行 os.makedirs，即使加了 exist_ok，日志中可能会出现混乱的警告，且无法保证创建动作的原子性（即无法保证“要么完全创建，要么完全未创建”的中间状态一致性，尽管目录本身是原子的，但后续操作可能受影响）。方案二：进阶版 - pathlib.Path (适用于现代项目)
pathlib 提供了更优雅的接口，且能更好地处理路径拼接。
from pathlib import Path
import logginglogging.basicConfig(level=logging.INFO)def create_dirs_pathlib(target_dir: str) - bool:使用 pathlib 创建多级目录:param target_dir: 目标目录路径:return: 是否创建成功path = Path(target_dir)try:# parents=True 相当于 os.makedirs# exist_ok=True 忽略已存在path.mkdir(parents=True, exist_ok=True)# 额外步骤：验证路径是否为目录if not path.is_dir():raise ValueError(fPath is not a directory: {path})logging.info(fDirectory verified: {path})return Trueexcept FileExistsError:# pathlib 的 mkdir 在 exist_ok=True 时通常不抛此异常# 但如果路径是一个文件，会抛 FileExistsErrorlogging.error(fPath exists but is not a directory: {path})return Falseexcept PermissionError:logging.error(fPermission denied: {path})return Falseexcept OSError as e:logging.error(fOSError: {e})return False# 测试
create_dirs_pathlib(/tmp/test_logs/2023/10/02)代码解析：Path(target_dir)：将字符串转换为 Path 对象，支持 / 运算符进行路径拼接，例如 base_dir / sub / file.txt，代码可读性大幅提升。
is_dir() 验证：这是一个好习惯。确保创建后路径确实是目录，防止因竞态条件导致路径被替换为文件的情况（虽然罕见，但在高并发下可能发生）。
性能：pathlib 的调用栈略深，但差异在微秒级，对于目录创建这种低频操作（通常在应用启动时执行一次），可以忽略不计。方案三：生产级 - 并发安全 + 原子性 (适用于 Web 服务)
这是解决 directory.createdirectory 类报错的终极方案。核心思想：不要依赖 exist_ok，而是利用系统调用的原子性或显式锁。
import os
import threading
import logging
from pathlib import Pathlogging.basicConfig(level=logging.INFO)# 简单的全局锁，适用于单进程多线程序
_dir_lock = threading.Lock()def create_dirs_concurrent_safe(target_dir: str) - bool:线程安全的目录创建:param target_dir: 目标目录路径:return: 是否创建成功with _dir_lock:path = Path(target_dir)try:# 在锁内执行，确保 check 和 create 的原子性# 注意：os.makedirs 在 Linux 下底层是多次 mkdir 系统调用# 锁保证了整个过程的互斥if not path.exists():path.mkdir(parents=True, exist_ok=False)logging.info(fCreated: {path})else:# 检查是否存在，但确保是目录if not path.is_dir():raise FileExistsError(fPath exists as file: {path})logging.debug(fAlready exists: {path})return Trueexcept FileExistsError:# 在锁内，如果还抛出 FileExistsError，说明路径被占用为文件logging.error(fConflict: {path} is not a directory)return Falseexcept Exception as e:logging.exception(fUnexpected error: {e})return False# 模拟高并发测试
def worker(thread_id: int):success = create_dirs_concurrent_safe(f/tmp/concurrent_test_{thread_id})if success:print(fThread {thread_id}: OK)if __name__ == __main__:threads = []for i in range(10):t = threading.Thread(target=worker, args=(i,))threads.append(t)t.start()for t in threads:t.join()代码解析：threading.Lock()：在单进程多线程序（如 Flask/Gunicorn 的 sync 模式）中，使用锁是最简单有效的并发控制手段。
exist_ok=False：在锁保护下，我们可以更严格地检查。如果目录不存在，则创建；如果存在，则验证。这避免了 exist_ok=True 可能掩盖的“路径被文件占用”的严重错误。
局限：threading.Lock 只在单进程内有效。如果你的服务是多进程部署（如 Gunicorn 多 worker、Celery 多进程），这个锁不起作用。多进程场景怎么办？
在多进程环境下，你需要使用系统级文件锁（如 fcntl.flock on Linux, msvcrt.locking on Windows）或数据库行锁。但更推荐的做法是：将目录创建逻辑移出应用启动流程。
最佳实践建议：初始化阶段：在 Dockerfile 的 RUN mkdir -p /app/logs 或 K8s 的 initContainer 中创建静态目录。
运行时：应用只负责写入文件，不负责创建目录。如果必须动态创建，使用 mkdir 系统调用的原子性（在 C 扩展或 Rust 侧实现），或者接受 FileExistsError 并忽略（前提是确保路径是目录）。
性能优化：对于高频动态目录（如按日期分区的日志），使用 os.stat 缓存目录存在性，避免频繁的系统调用。适用场景与选型建议
别被代码吓到，根据你的实际场景选就行：单机脚本 / 一次性任务：推荐：os.makedirs 或 pathlib.Path.mkdir。
理由：简单、无依赖、性能足够。不用考虑并发，exist_ok=True 完全够用。Web 应用 (单进程/多线程)：推荐：pathlib + threading.Lock (如果必须动态创建)。
理由：pathlib 代码更清晰，锁解决线程竞争。但更推荐在应用启动时统一创建所有必要目录，运行时只写文件。容器化 / 微服务 (多进程)：推荐：Dockerfile / K8s 初始化。
理由：不要在 Python 代码里处理多进程并发创建目录的痛点，那是架构层面的问题。将目录创建交给编排系统或镜像构建过程，代码保持无状态和轻量。这是真正的性能优化——把 I/O 开销前置，避免运行时抖动。高性能 / 高并发场景：推荐：预创建 + 内存缓存。
理由：在应用启动时，扫描配置，创建所有可能用到的目录，并将路径对象缓存到内存。运行时直接 open 文件，避免 mkdir 系统调用。这能显著降低 CPU 占用和上下文切换开销。避坑指南：不要硬编码权限：让操作系统或容器运行时管理权限。
注意路径长度：Linux 默认路径长度限制 4096 字节，Windows 260 字符。超过这个长度会报错。在生成动态目录名时，务必控制长度。
字符集问题：避免使用非 ASCII 字符作为目录名，除非你确定整个链路（代码、文件系统、日志系统）都支持 UTF-8。还有这些细节容易踩坑
除了并发，还有一个常被忽略的点：目录删除与重建。
在清理旧日志时，你可能想“删掉旧目录，创建新目录”。但 os.rmdir 只能删空目录，shutil.rmtree 可以删非空目录，但它是非原子的。如果在删除过程中，另一个线程还在写文件，会导致数据丢失或文件句柄错误。
正确做法：不要删除正在使用的目录。
使用“原子重命名”策略：创建新目录 - 将旧目录重命名为 .old - 删除 .old。
或者，使用 rotating log handler 等库，让库来处理文件轮转，而不是手动管理目录。性能优化小贴士：批量创建：如果你需要创建 100 个目录，不要循环调用 100 次 mkdir。可以考虑使用 os.system(mkdir -p ...)（不推荐，有安全风险）或编写 C 扩展批量调用。但在 Python 层面，循环调用的开销主要在于 Python 解释器，而非系统调用。对于 100 次以内的创建，直接循环即可。
异步 I/O：在 asyncio 应用中，使用 asyncio.to_thread 将阻塞的 mkdir 操作放到线程池执行，避免阻塞事件循环。import asyncio
from pathlib import Pathasync def async_create_dir(target_dir: str):在 asyncio 中创建目录path = Path(target_dir)# 将阻塞操作放入线程池await asyncio.to_thread(path.mkdir, parents=True, exist_ok=True)最后，关于 RFC 规范的再次强调：
如果你的目录名来源于 URL 参数，务必参考 RFC 3986 进行百分号解码（urllib.parse.unquote），并过滤掉非法字符（如 /, \, :, *, ?, , , , |）。这不仅是为了避免 directory.createdirectory 报错，更是为了防止路径遍历攻击。安全，永远是性能优化的前提。
技术选型没有绝对的对错，只有适合的与不适合的。os 模块经典可靠，pathlib 现代优雅，并发锁保障稳定，容器化前置高效。根据你的项目规模、部署环境和团队熟悉度，选择最让你睡得着觉的方案。
在实战中，你是否也遇到过因为目录创建导致的诡异 Bug？比如文件找不到、权限不足、或者并发冲突？还有什么不懂的？评论区留言挨个回。