lost+found目录是fsck修复文件系统时存放孤儿文件的预置收容所，用于保存inode完好但目录项丢失的文件，文件以#inode号命名，需人工识别内容恢复。
lost+found 目录本身不“找回”文件，它是 fsck 修复过程中被动接收孤儿文件的地方。所谓“找回”，实际是 fsck 在检查并确认某些 inode 无法归属任何目录后，把它们以编号形式放进这个预置目录——你后续靠人工识别内容来恢复。
它不是搜索工具，也不是恢复界面，而是一个被预留的“收容所”。真正起作用的是 fsck（或 e2fsck），不是目录本身。
为什么修复后孤儿文件会出现在 lost+found
当系统异常断电，ext2/ext3/ext4 文件系统可能处于中间状态：文件数据块和 inode 还在磁盘上，但目录项（即文件名和路径）丢失或损坏。fsck 启动时会：
- 扫描所有 inode，找出链接计数为 0 且无任何目录项指向的 inode；
- 确认这些 inode 的数据块未被覆盖、仍可读；
- 将对应内容以 #inode号 的形式（如 #123456）写入 lost+found 目录；
- 不尝试还原原名或路径——因为元数据已不可信。
进入 lost+found 查看和识别文件
修复完成后重新挂载分区，再进入该目录操作：
- 用 cd /mount/point/lost+found 进入（例如
cd /data/lost+found）； - 运行 ls -i 查看每个文件的 inode 编号（文件名就是编号，如
#245789）； - 用 file #245789 判断类型（文本、ELF、PNG、PDF 等）；
- 对文本类用 head -n 20 #245789 或 strings #245789 | head 快速浏览内容；
- 对二进制文件，可复制出来用对应软件打开验证（如图片用 eog，文档用 libreoffice）。
如何提高恢复成功率
孤儿文件没有扩展名、没有时间戳、也没有原始路径，恢复依赖内容判断：
- 优先检查最近修改过的文件——结合系统日志（
dmesg、/var/log/messages）或应用日志缩小范围； - 若知道原文件大致大小，可用 ls -lS 按大小倒序排列，快速定位大文件；
- 多个编号连续的文件（如 #123450 ~ #123455）可能是同一文档的不同碎片，需合并分析；
- 重要数据建议先 cp -a *.#* /backup/ 整体备份，再逐个处理，避免误删。
注意：lost+found 不是万能保险箱
它只收容那些 inode 和数据块都完好的“逻辑孤儿”。以下情况它帮不上忙：
- 物理坏道导致数据块读取失败——fsck 会标记为损坏，不会放入 lost+found；
- 文件已被覆盖或 inode 被复用——原数据早已消失；
- 文件系统使用 XFS/Btrfs/ZFS 等——它们不用 lost+found，机制完全不同；
- 用户主动 rm 删除后断电——只要 unlink 完成，就不算孤儿，也不会出现。
