用seek()和write()创建空文件最轻量，因不写入实际数据，仅移动指针并写1字节，由系统以稀疏块填充中间区域，不占磁盘空间但os.stat().st_size显示指定大小。
为什么用 seek() 和 write() 创建空文件最轻量？
因为不写入实际数据，只靠移动文件指针并写一个空字节就能撑开文件大小——操作系统会把中间区域用稀疏块（sparse blocks）填充，磁盘不真占空间，但 os.stat().st_size 显示的是你指定的大小。
常见误区是用循环写 '\0' 或重复字符串，既慢又占 I/O 和内存；而 seek(n-1); write(b'\0') 两步搞定，毫秒级完成 GB 级文件占位。
-
seek()必须用os.SEEK_SET模式（默认），避免在文件末尾追加导致大小不对 - 目标位置必须是
size - 1（不是size），否则写入后文件长度为size + 1 - 务必以二进制模式（
'wb'）打开，文本模式下seek()行为不可靠
完整可复用的创建函数怎么写？
封装成函数时要处理边界：0 字节文件直接创建即可；负数或非整数 size 应抛出明确错误；路径父目录不存在需自动创建。
import os <p>def create_empty_file(path, size): if not isinstance(size, int) or size </p>
- 不用
f.truncate(size)——它依赖已有文件内容，对新文件无效 - 不要用
f.seek(size); f.write(b"")——空字节不触发文件扩展，大小仍为 0 - Windows 下若路径含中文或特殊字符，确保 Python 运行环境编码支持（一般 UTF-8 没问题）
创建大文件时遇到 OSError: [Errno 28] No space left on device 怎么办？
这通常不是磁盘真满，而是文件系统不支持稀疏文件（如某些 FAT32 或启用了配额/压缩的 NTFS 卷），导致 seek()+write() 强制分配物理块。
- Linux 上可用
ls -lsh查看实际磁盘占用（第一列）和逻辑大小（第二列），差值大说明稀疏有效 - macOS 默认支持稀疏，但 APFS 卷若开启“优化存储”可能限制行为
- 绕过方法：改用
truncate命令（Linux/macOS）：truncate -s 1G /path/to/file，它更底层且兼容性更好
用 os.posix_fallocate() 是否更可靠？
是，但它有严重限制：仅 Linux 2.6.23+ 支持，且要求文件系统为 ext4/xfs/btrfs 等；Python 3.3+ 才引入该函数，Windows/macOS 完全不可用。
示例：
import os
fd = os.open(path, os.O_CREAT | os.O_WRONLY)
try:
os.posix_fallocate(fd, 0, size) # 直接分配，不稀疏，真占空间
finally:
os.close(fd)
- 它分配的是真实磁盘空间，适合需要预分配防写满的场景，但违背“快速创建空文件”的初衷
- 若调用失败（如系统不支持），会抛
NotImplementedError或OSError，不能当兜底方案 - 普通用户优先坚持
seek()+write()，兼容性、速度、资源消耗都更平衡
真正要注意的是：稀疏文件在某些备份工具或容器镜像构建中会被展开，看似“空”的文件可能突然吃光磁盘。别只看 ls -l，用 du -h 确认实际占用。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
