find 报 Argument list too long：不要把海量文件展开成搜索起点

清理图片缓存时，命令写成 find /mnt/data/cache/*.jpg -maxdepth 0 -mtime +100 -type f ...，终端却报 bash: /usr/bin/find: Argument list too long。即使目录没有子目录，继续调小 -maxdepth 也无效。

这个报错位置说明 Bash 在启动外部程序时就遇到了参数长度限制。应把目录作为搜索起点，让 GNU find 自己遍历并匹配文件名。下面的命令适用于 Linux 上的 GNU find；删除前先确认缓存可以重建，或已有可恢复的备份。

-maxdepth 0 为什么管不到这次错误

未加引号的 *.jpg 会先由 shell 展开。目录里有大量匹配文件时，交给 find 的参数实际上是一个个完整路径。Linux 启动程序时对参数及环境字符串的总大小有限制，文件名足够多或足够长就可能超过它。此时 find 还没有机会读取 -maxdepth。

-maxdepth 0 控制的是 find 启动后是否向下遍历。以前每个文件本身就是起点，这个深度尚可用于处理这些文件；改成目录起点以后，深度 0 只检查目录本身，会漏掉目录中的图片。只给整个 /mnt/data/cache/*.jpg 加引号也不够：那会把含星号的路径原样交给 find，而不会让它变成文件名筛选条件。

先核对清理范围，再列出候选

以下示例只查看指定目录第一层的普通 .jpg 文件，不进入子目录、不跟随符号链接，并排除以点开头的文件名：

find /mnt/data/cache -depth -mindepth 1 -maxdepth 1 \
  -type f -name '*.jpg' ! -name '.*' -mtime +100 -print

把示例目录换成实际缓存目录。这里的 -name '*.jpg' 保留了引号，匹配工作交给 find，命令行不会随着文件数量膨胀。-type f 保留了普通文件限制，不能因为当前没有子目录就省掉它。

! -name '.*' 明确排除了隐藏文件。GNU find 的 -name '*.jpg' 本身可以匹配 .cache.jpg；普通 Bash 文件名展开默认不匹配这类名字。若缓存策略需要包含隐藏文件，可以去掉这个排除条件，但要重新检查候选范围。

-mtime +100 按已经过去的完整 24 小时段计算，忽略不足一天的部分，再判断是否大于 100。因此它通常要到至少 101 个完整日龄才匹配，并不是超过 100 小时，也不是按日历日期直接比较。修改阈值前，应确认保留策略指的是修改时间以及这种日龄计算方式。

如果没有输出，先核对目录、后缀大小写和修改时间条件。没有输出不能证明目录为空。权限报错或非零退出状态则说明遍历未完整完成，先处理这些错误，再考虑删除。

确认候选后才执行删除

确认备份可恢复、候选均可移除且没有应用正在依赖这些缓存后，才将末尾动作换成 -delete：

find /mnt/data/cache -depth -mindepth 1 -maxdepth 1 \
  -type f -name '*.jpg' ! -name '.*' -mtime +100 -delete

这一步会直接删除匹配文件，不能靠把命令改回来恢复。需要恢复时，使用此前备份或应用的缓存重建机制。预览和删除是两次遍历，期间文件可能新增、更新或消失；不要把预览列表当作删除操作的固定快照。对持续变化的目录，应在应用允许的维护窗口内处理，或采用应用自己的缓存清理功能。

GNU find 的 -delete 会启用深度优先遍历，所以预览也显式使用 -depth。不要把 -delete 放到筛选条件前，更不要未经核对再拼接 -prune；两者的遍历要求会冲突。

完成后，按同一筛选条件重新列出候选，并检查退出状态与错误输出。目标是符合保留策略的文件已清理、其他文件仍在，应用能继续正常读取或重建缓存。命令能够启动，只解决了参数过长的问题；删除范围正确还需要这一步确认。