目录里积累大量日志后，执行rm *.log可能直接返回Argument list too long。文件本身并没有损坏，问题发生在命令真正启动之前：Shell把通配符展开成了过长的参数列表。
不要把文件名拼成一个更长的命令，正确做法是让工具分批遍历并执行。
为什么rm还没执行就失败
Shell会先把*.log展开为成千上万个文件名，然后通过execve()启动rm。参数与环境变量的总大小受系统限制，可用getconf ARG_MAX查看参考值；环境变量也会占用这部分空间。
错误来自启动参数过长，不代表rm一次只能删除固定数量的文件。
先预览准确的文件范围
先使用find /目标目录 -maxdepth 1 -type f -name '*.log' -print预览，并确认目录、文件类型和名称规则。需要按时间筛选时再增加-mtime等条件，先统计匹配数量，再决定删除或移动。
不要用ls输出直接拼给xargs。空格、换行、引号和以连字符开头的文件名都可能被错误解释。
用find分批执行命令
GNU find支持-exec 命令 {} +，会在系统允许范围内自动合并参数。例如find /目标目录 -maxdepth 1 -type f -name '*.log' -exec rm -- {} +。若只需删除普通文件，也可在完整预览后使用相同筛选条件配合-delete。
删除前必须先运行不带动作的预览命令。find表达式的路径、深度和条件写错会扩大处理范围。
必须使用xargs时怎样保护文件名
需要把列表交给其他工具时，使用find ... -print0 | xargs -0 -r 命令，让NUL字符分隔文件名。GNU xargs可用--show-limits查看上限，也可用-n或-s限制每批大小。
在其他用户可修改的目录中，遍历与执行之间可能存在竞态，优先考虑-execdir ... +并限制目录权限。单纯加大批量数量不能解决安全边界问题。
处理完成后如何验收
再次运行同一条find筛选命令确认目标已处理，并检查磁盘空间、应用日志和仍在打开的已删除文件。可在萤光云或LightNode的测试VPS复现大目录。验收标准是目标文件数量符合预期、非目标文件未变化、命令无截断且业务继续正常写入。
FAQ
问：提高ulimit能解决Argument list too long吗？答：一般不能。该限制与进程启动参数及环境大小有关，应改为分批处理。
问：rm -rf目录再重建更快吗？答：只有确认整个目录都可删除并能安全停写时才考虑，日志目录、挂载点和权限可能因此受影响。
温馨提示
温馨提示：生产目录批量删除前先做数量统计和小范围演练，必要时改为移动到隔离目录后再异步清理，并保留可回滚的备份或快照。
