truncate清空文件最安全，不改变权限、属主、硬链接和inode号；对符号链接无效，不支持FIFO、socket、/proc、/sys文件及只读文件系统。
用 truncate 清空文件最安全
直接覆盖文件内容而不删重建，是运维中最稳妥的做法。truncate 不改变文件权限、属主、硬链接和 inode 号，也不会触发某些监控工具对“文件删除+新建”的误报。
- 清空单个文件：
truncate -s 0 filename - 批量清空日志（保留文件本身）：
truncate -s 0 /var/log/*.log - 如果文件正被进程写入（如
tail -f或服务日志），truncate仍有效——内核会重置文件偏移，后续写入从头开始 - 注意：
truncate对符号链接无效，它操作的是目标文件；若想清空链接指向的文件，得先readlink解析路径
> filename 重定向清空的副作用
看似最简，但隐含风险：它依赖 shell 的重定向机制，且会重置部分文件元数据。
- 执行
> filename后，文件 mtime（修改时间）更新，但 atime（访问时间）不一定变（取决于挂载选项） - 如果文件有 SELinux 上下文，重定向可能丢失或重置上下文（尤其在 enforcing 模式下），而
truncate不动扩展属性 - 当
filename是 FIFO 或设备文件时，> filename会报错：bash: filename: No such device or address；truncate则直接失败并提示不支持操作 - 别写成
cat /dev/null > filename—— 多余调用cat进程，无实际增益
哪些情况不能用 truncate？
不是所有“文件”都支持截断。Linux 中的特殊文件类型会拒绝 truncate 请求。
- 对管道（FIFO）、socket、/proc 下多数文件、/sys 下节点执行
truncate -s 0，会报错：truncate: cannot open 'xxx' for writing: Operation not permitted或Invalid argument - 只读文件系统上的文件，即使你有 root 权限，
truncate也会失败：Read-only file system - 如果文件正被 mmap 映射且映射为 MAP_SHARED，某些内核版本下
truncate可能导致 SIGBUS，但极少见；普通日志场景无需担心
清空前要不要检查文件状态？
线上清空前多看一眼，能避开很多“为什么日志又满了”的回头路。
- 先确认是不是真要清空：
ls -lh filename看大小，file filename看类型（避免清空二进制配置或数据库文件） - 查谁在写它：
lsof +D /path/to/dir 2>/dev/null | grep filename或fuser -v filename - 如果文件属于某个服务（如 nginx 日志），清空后建议
kill -USR1通知其重新打开日志文件，否则旧 fd 仍指向已截断的文件，磁盘空间不会释放 - 别依赖
rm && touch：会丢权限、SELinux 上下文、ACL、硬链接，且新文件的 inode 号变了，rsync 或 inotify 可能出问题
