必须使用inode号删除，因shell无法解析乱码文件名；先在文件所在目录执行ls -i获取第一列inode号，再用find . -inum n -exec rm -rf {} \;删除，非空目录需用-exec而非-delete。
乱码文件名删不掉，不是权限问题，是 shell 根本没法把那串字符当合法文件名解析——键盘打不出、复制粘贴失效、ls 显示为 ???.log 或一堆 \345\273\201，这时候必须绕过文件名，直击 inode。
用 ls -i 查 inode 号，别信 ll 或 ls -li 的排版
必须在乱码文件所在目录执行 ls -i，输出第一列数字才是 inode；不要误读权限列或时间列。比如：
43012 "\345\273\201.txt" 134217793 etc
这里 43012 是目标文件 inode，引号里全是干扰项，不用管。某些 busybox 环境不支持 ll，ls -i 更可靠。
-
stat也能看 inode，但前提是能正确引用文件名——这恰恰是难点，所以别优先试 - 如果目录文件太多，
ls -i | head -20比ls -i | grep ""更稳妥，后者在部分终端下会漏掉乱码行 - 别在别的目录跑
ls -i再 cd 过来删——inode 号只在原路径下有效
find . -inum N -delete 只对文件和空目录生效
-delete 行为很严格：遇到非空目录直接报 Directory not empty 并跳过，不会递归删内容。常见误操作：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 用
find / -inum N -delete全盘扫——慢、跨挂载点可能匹配到同 inode 号的其他文件（NFS 尤其危险） - 没加
.起点，find -inum N默认从当前目录开始，但容易因路径变更导致误删 - 普通用户执行时，
sudo find . -inum N -delete有时静默失败；更稳的是sudo find . -inum N -exec rm -rf {} \;
非空目录必须用 -exec rm -rf {} \;，哪怕提示 No such file or directory，其实已经删了——这是内核返回的旧路径残留信息，不是命令失败。
当 ls -b 显示 report\ntotal.txt，就用 $'' 语法
ls -b 把换行、制表符转成 \n\t 形式，这是唯一能肉眼确认不可见字符的方式。此时不能手动复制粘贴，因为终端渲染后换行已断开成两行字符串。
- 安全写法：
rm $'report\ntotal.txt'——$''让 shell 解析转义序列为真实字节 - 脚本中动态构造更通用：
rm "$(printf 'report\ntotal.txt')" - 别用
rm "report\ntotal.txt"：双引号不解析\n，它就真当字面量\n两个字符去删，肯定找不到 - 含空格+换行混合？
$''仍可用，比如$'file name\nwith tab.txt'
删完还在？先看是不是 overlayfs、NFS 或进程占用
命令返回成功但文件“还在”，大概率不是删错了，而是底层限制：
- 该分区是只读挂载（如容器
overlay、tmpfs），inode 存在但不允许 unlink - 有进程正打开该文件：
lsof +D /path查占用，删完只是释放 inode，磁盘空间要等进程退出才回收 - NFS 客户端查到的 inode 号，服务端根本不认——必须在服务端操作，或改用服务端可识别的路径方式删
最隐蔽的是：你以为在原目录执行 find，其实中途 cd 过，. 已指向别处。每次执行前，用 pwd 确认当前路径是否仍是乱码文件所在目录。
