truncate -s 0 filename 是最安全高效的清空方式，不改变 inode、权限、属主，兼容已打开文件；> filename 是 shell 内置重定向，最快但不适用于 append-only 文件；sudo truncate 或 sudo tee 才能解决权限问题；禁用 rm && touch 以防丢失硬链接、ACL 等元数据。
用 truncate 最安全高效地清空文件
直接覆盖原文件内容，不改变 inode、权限、属主，也不触发重命名或重建，适合日志轮转、临时清空等场景。
-
truncate -s 0 filename是首选命令，秒级完成，无论文件多大 - 如果文件被其他进程打开写入（比如
tail -f或服务日志），truncate仍能生效——因为只截断文件逻辑长度，已打开的 fd 还能继续追加 - 别用
truncate -s 0清空正在被mmap映射的文件，可能引发未定义行为；这类情况优先用echo -n > filename
> filename 和 echo > filename 的区别在哪
两者都重定向空内容，但底层行为不同：前者是 shell 重定向清空，后者是执行命令写入换行符。
-
> filename不调用任何外部程序，纯 shell 内置操作，最快最轻量 -
echo > filename会写入一个换行符（\n），实际文件大小变成 1 字节，不是真正“空” - 如果文件有 append-only 属性（
chattr +a），> filename会失败，而truncate依然可用
清空时遇到 “Permission denied” 怎么办
常见于日志文件属主是 root 或服务用户，但当前用户只有写权限（如 /var/log/syslog）。
- 不能靠
sudo > filename—— 重定向由当前 shell 执行，sudo只作用于命令本身，无效 - 正确写法：
sudo truncate -s 0 filename或echo | sudo tee filename >/dev/null - 若目标文件在只读挂载点（如
mount | grep ro），所有清空操作都会失败，得先 remount 或换路径
别用 rm && touch 清空文件
看似等效，实则破坏性极大：删除再新建会丢失硬链接、ACL、扩展属性（xattr）、SELinux 上下文，还可能被监控工具误判为文件重建。
- 硬链接指向原 inode，
rm后新touch创建的是全新 inode，所有硬链接失效 - systemd-journald、rsyslog 等守护进程依赖文件 inode 稳定性做状态跟踪，删重建可能丢日志或卡住
- 即使只是测试环境，也建议养成用
truncate或>的习惯，避免上线后踩坑
真正要注意的不是“怎么清空”，而是“清空后文件是否还被原有上下文信任”——inode、权限、打开态，三者缺一不可。多数人只盯内容，却忘了文件在系统里是个有身份的实体。
