必须以'r+'或'w'模式打开文件才能用truncate()清空：'r+'需先seek(0)再truncate(0)，'w'打开即清空但丢失元信息；truncate()是系统级截断操作，'w'是Python打开行为，二者触发时机与控制粒度不同。
用 truncate() 清空文件前必须先打开为可写模式
直接调用 f.truncate() 报错 io.UnsupportedOperation: truncate，是因为文件没以写入方式打开。只读打开（'r'）或追加打开（'a'）都不支持 truncate() —— 即使你只是想清空内容。
正确做法是用 'r+' 或 'w' 打开：'r+' 保留文件存在性且允许读写定位，'w' 则直接覆盖重置。若需清空后继续写入（比如日志轮转），优先选 'r+'；若确定要彻底丢弃原内容，'w' 更干脆。
-
'r+'模式下必须先f.seek(0)再f.truncate()，否则可能只截断开头几字节 -
'w'模式打开即清空，无需truncate()，但会丢失原文件权限、mtime 等元信息 - 用
'a+'不行：它强制写入末尾，truncate()被忽略或报错
truncate() 和 'w' 模式的本质区别在哪
truncate() 是系统级文件截断操作，作用于当前文件指针位置；'w' 是 Python 文件打开行为，等价于 open(..., 'w') → os.open(..., os.O_WRONLY | os.O_CREAT | os.O_TRUNC)。两者都能清空，但触发时机和控制粒度不同。
典型差异场景：
立即学习“Python免费学习笔记（深入）”；
- 清空大文件时，
'w'立即释放磁盘空间；truncate()在'r+'下也立即生效，但若忘了seek(0)，可能只截掉后面部分 - 多进程/线程写同一文件时，
'w'打开瞬间就清空，其他进程正在读的内容会突然消失；truncate()需显式调用，可控性略高 -
truncate(0)可在不关闭文件句柄前提下反复使用；'w'每次都新建句柄，旧句柄内容不可恢复
常见错误：清空后文件大小没变或内容残留
现象：调用 f.truncate() 后用 ls -l 看文件大小还是老样子，或者用 cat 还能看到旧内容。这不是 bug，而是缓存或未刷新导致的假象。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 忘记
f.flush()：尤其在'r+'模式下，截断后若没flush()，部分系统（如某些 NFS）可能延迟同步 - 没关闭文件：Python 缓冲区未落盘，
truncate()效果只在内核缓冲中，os.fsync(f.fileno())可强制刷盘 - 用
truncate()后又写了内容但没seek(0)：新内容追加到末尾，前面留了一堆空字节，stat显示大小不变
验证是否真清空？别信 cat，用 hexdump -C filename | head 看前几字节是不是全 00，或直接 python -c "print(open('f.txt').read())"。
一句话选型建议：什么情况下该用哪个
只清空、不关心原文件状态 → 用 open('f.txt', 'w').close()，最简最安全。
清空后立刻写新内容，且需保持文件 inode、权限、atime/mtime → 用 'r+' + seek(0) + truncate(0) + write() + flush()。
脚本里频繁清空小文件（如临时状态文件）→ 直接 'w'，省心；处理 GB 级日志且不能丢数据 → 避免 'w'，改用 truncate() 配合原子重命名更稳妥。
最容易被忽略的一点：Windows 下用 'r+' 清空文本文件时，若原文件含 \r\n，truncate() 后再写入可能因换行符处理出错 —— 此时老实用 'w' 或明确指定 newline=''。
