truncate() 是清空文件最直接的方式，通过将文件长度截为0字节实现毫秒级清空，保留权限、硬链接和打开句柄，但需先 seek(0) 且以 'r+' 或 'w+' 模式打开。
truncate() 是清空文件最直接的方式
用 truncate() 清空文件，本质是把文件长度截为 0 字节，不重写内容、不移动数据块，系统级操作，毫秒级完成。比打开再写空字符串快得多，也比删了重建更安全（权限、硬链接、打开句柄都保留）。
常见错误是只调用 f.truncate() 却没先 f.seek(0) —— 如果文件指针不在开头，truncate() 只会从当前指针位置往后截断，前面内容还在。
- 必须以读写模式（
'r+'或'w+'）打开文件；'w'模式本身就会清空，但会丢失原有权限和 inode 信息 - 推荐做法：
f.seek(0)→f.truncate(0) - 注意：Windows 下对已映射（mmap）或正在被其他进程独占打开的文件，
truncate()可能抛PermissionError
os.truncate() 直接操作路径，绕过 Python 文件对象
当文件没被 Python 打开，或者你只想改大小不碰内容时，os.truncate() 更轻量。它接受路径和目标字节数，不需要维护文件句柄。
典型误用是传错单位：第二个参数是字节长度，不是“清空”开关。写成 os.truncate('a.txt', True) 会报错，必须写 0。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 示例：
import os; os.truncate('log.txt', 0) - 兼容性好，Python 3.3+ 都支持；但在 NFS 或某些容器挂载卷上可能不生效（取决于底层文件系统）
- 不会改变文件 mtime（修改时间），如果监控脚本依赖 mtime 判断更新，这点要留意
用 'w' 模式打开文件的隐式清空行为
open('x.txt', 'w') 一执行，文件立刻变为空，这是 Python 的标准语义。但它不是“清空”，而是“重建”：原文件内容被丢弃，新文件获得默认权限（受 umask 影响），硬链接断开，原 inode 被释放。
容易踩坑的是在多进程场景下：一个进程用 'w' 打开，另一个正用 tail -f 监听该文件，此时 tail 会失去跟踪（因为 inode 变了）。
- 适合一次性写入新内容的场景，比如生成配置、导出报表
- 不适合日志轮转、实时管道类需求
- 若需保留权限，得手动
os.chmod()，且无法恢复原属主/属组
清空大文件时 truncate() 和 rm + touch 的性能差异
对 GB 级文件，truncate() 几乎不耗时；而 rm file && touch file 要删除旧 inode、分配新 inode、更新目录项，IO 开销明显更高，且可能触发磁盘碎片整理逻辑。
但要注意：某些 NAS 或云存储（如 S3 兼容接口）根本不支持 truncate()，调用会直接失败。这时候只能退到写空字符串或重命名备份再新建。
- Linux ext4/xfs、macOS APFS 均原生支持
truncate() - 检查是否可用：
os.access(path, os.W_OK) and os.stat(path).st_size > 0不代表truncate()一定成功 - 生产环境建议加 try/except 捕获
OSError，fallback 到with open(...) as f: f.write('')
真正关键的不是选哪个函数，而是想清楚：你到底需要“擦除内容但保持文件身份”，还是“换一张新白纸”。前者用 truncate()，后者用 'w'；中间态（比如保留部分头信息）就得自己 seek + write。
