最轻量清空文件的方法是> file，它不启动新进程、保留inode和权限、直接截断为0字节；truncate -s 0 file语义明确且支持批量安全处理；其余方法或启进程、或改权限、或加载全文，均不推荐。
用 > 重定向清空文件最轻量
这是 shell 内置机制，不启动新进程，开销最小，适合高频、脚本化场景。它直接截断文件到 0 字节，保留 inode 和权限不变。
常见错误是写成 > file.log 后面多加空格或换行，导致命令被拆解失败；也有人误以为要写 > /dev/null，其实不需要——> 本身语义就是“打开文件并截断”，/dev/null 完全多余。
-
> access.log✅ 正确，推荐日常使用 -
: > access.log✅ 等效，但多一次 shell 解析，无实际优势 -
true > access.log❌ 启动外部进程，没必要
truncate -s 0 是唯一能控制稀疏文件行为的方法
当文件是稀疏文件（比如日志轮转后留下的大空洞），> 和 cat /dev/null > 都会真正释放磁盘空间；但 truncate -s 0 可以在某些文件系统上保留稀疏属性（取决于挂载选项和内核版本），不过多数情况下效果和 > 一致。
它的优势在于语义明确、可读性强，且支持 -c 参数跳过不存在的文件报错（truncate -sc 0 missing.log 不报错）。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
truncate -s 0 error.log✅ 安全、清晰、兼容性好 -
truncate -c -s 0 *.log✅ 批量处理时避免因某文件不存在而中断 - 注意：不支持 NFS v3 挂载点上的原子截断，可能返回
Operation not permitted
cat /dev/null > file 兼容性最好但有隐含风险
几乎所有 POSIX shell 和老系统都支持，适合写跨平台脚本。但它本质是 fork + exec cat + 重定向，比 > 多一次进程创建，对极大量小文件批量清空时延迟更明显。
真正要注意的是权限继承问题：如果目标文件由其他用户创建且设置了 setgid，cat /dev/null > file 会重置 group 为当前用户 primary group；而 > 和 truncate 保持原有权限位不变。
-
cat /dev/null > audit.log✅ 老系统稳妥选择 - 别用
echo > file—— 它写入一个换行符，文件大小变成 1 字节 - 也别用
echo -n "" > file—— 多余，不如直接>
别用 vim 或 sed -i 清空大文件
对百 MB 以上文件，vim file :%d :wq 会尝试把整个文件读进内存，极易触发 OOM killer；sed -i 'd' file 同样需要加载全文再写回，还额外生成临时文件，I/O 放大两倍。
哪怕只是想“确认后再清空”，也不该交互式编辑——先 ls -lh file 看大小，再用 > 一行搞定。真要审计内容，用 tail -n 20 file 或 head -c 1M file | strings | head 更靠谱。
- 大文件清空必须绕过内存加载路径
-
dd if=/dev/null of=file理论可行，但dd默认块大小 512 字节，效率远低于>或truncate -
cp /dev/null file行为等价于cat /dev/null > file，没额外好处
> 和 truncate -s 0 是仅有的两个不碰内容、不占内存、不改权限的选择；其余方法要么慢，要么危险，要么悄悄改了你没意识到的东西。 
