根本原因是ls -l对每个文件执行stat()调用并默认排序：100万次stat耗尽IO与CPU，全量加载文件名排序导致内存暴涨，从而卡死；绕过stat（-f/-U）可秒出结果。
为什么ls -l在百万级目录里会卡死
根本原因不是磁盘慢，而是ls -l对每个文件都调用一次stat()系统调用——要读取权限、大小、修改时间等元数据。100万个文件 = 100万次stat()，再加上默认排序（把全部文件名读进内存再快排），内存暴涨、IO打满、CPU跑满，自然卡住。你看到的“没反应”，其实是它还在拼命stat第999999个文件。
快速列出文件名：绕过stat + 禁排序
只要不看详细信息，就完全没必要stat。用这两个组合能秒出结果：
-
ls -f：禁排序，按目录项原始顺序（d_type + inode顺序）直接输出，不缓存全部文件名 -
ls -U：效果同-f，更明确语义（Unsorted）
例如只看前10个：ls -U | head -n 10；想统计总数：ls -f | wc -l。注意别加-l或--color，它们会悄悄触发stat或额外解析。
删不掉、rm报“Argument list too long”怎么办
这不是ls的问题，是shell展开./*时参数超长（ARG_MAX通常2MB左右）。此时rm -rf ./*根本执行不了。
- 用
find绕过shell展开：find . -maxdepth 1 -type f -delete（安全起见先试-print） - 分批删更稳：
find . -maxdepth 1 -type f -print0 | xargs -0 -n 1000 rm（每次删1000个） - 如果连
find也卡，说明目录结构本身已退化（ext4 dir_index失效），得用debugfs或直接mv整个目录离线处理
目录本身已损坏或挂载异常时的排查路径
如果ls卡在根目录//home这种关键路径，且df -h也卡，大概率不是文件太多，而是某子目录被挂载了NFS/sshfs等远程文件系统，而服务端已不可达。
- 先用
mount | grep ":"找NFS挂点，或findmnt看异常挂载 - 用
strace -e trace=stat,openat,access df -Th 2>&1 | tail定位卡在哪一行挂载 - 确认后强制卸载：
umount -f /path/to/broken/mount；若提示busy，改用umount -l（lazy unmount）
真正棘手的是ext4目录项膨胀到几百万后，即使清空文件，目录inode仍残留大量dir_entry，ls -U也会变慢——这时必须用mv重命名+重建目录，或换XFS（对大目录更友好）。
