用 dict 存路径+stat 会爆内存，因每个 os.stat_result 占约 200 字节，叠加字典哈希开销和重复路径字符串，10 万文件超 200MB；且 NFS 等场景下 os.stat() 可能阻塞。应改用 namedtuple 存必要字段（如 size/mtime/ino），内存仅约 25MB，并结合路径复用、相对化、字符串驻留等优化。
为什么用 dict 存路径+stat 会爆内存？
直接 os.stat() 每个小文件再塞进 dict，看似合理，实则灾难：每个 os.stat_result 对象在 CPython 中占约 200 字节，加上字典哈希表开销、字符串路径对象（每个路径字符串本身又是独立对象），10 万个小文件轻松吃掉 200MB+ 内存——这还没算引用计数和 GC 堆碎片。
更糟的是，os.stat() 在 NFS 或某些云存储上可能触发远程调用，阻塞且不可缓存；而你真正需要的往往只是 st_size、st_mtime、st_ino 这几个字段，没必要扛完整结构。
- 只取必要字段：用
os.lstat(path).st_size替代全量os.stat() - 路径复用：用
pathlib.Path实例统一管理路径，避免重复字符串对象 - 避免嵌套 dict：不用
{path: {'size': ..., 'mtime': ...}}，改用元组或命名元组
用 namedtuple 替代 dict 存元数据
namedtuple 是零拷贝、不可变、内存紧凑的替代方案。它底层是 tuple，没有字典哈希表开销，字段访问仍是 O(1)，且能语义化命名。
对比：dict 存 10 万个条目 ≈ 80MB；namedtuple 同样数量 ≈ 25MB —— 差距主要来自哈希桶和键字符串的重复存储。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
from collections import namedtuple
FileMeta = namedtuple('FileMeta', ['size', 'mtime', 'ino'])
meta_map = {}
for p in files:
try:
st = p.lstat()
meta_map[p] = FileMeta(st.st_size, st.st_mtime, st.st_ino)
except OSError:
continue
- 字段顺序按访问频次排：最常查的放前面（如
size用于跳过空文件） - 别用
dataclass：默认带__dict__，内存开销接近dict - 若需修改字段，用
_replace()返回新实例，保持不可变性
何时该用 mmap + 自定义二进制布局？
当小文件数量超 50 万、且你频繁做范围查询（如“找出 size 在 1KB~10KB 之间的所有文件”），纯 Python 结构已成瓶颈。这时应放弃对象模型，转向内存映射的紧凑二进制索引。
核心思路：把所有元数据序列化为固定长度记录（例如每条 24 字节：8 字节 size + 8 字节 mtime + 8 字节 ino），写入一个二进制文件，再用 mmap 映射到内存——此时整个索引就是一块连续 buffer，CPU 缓存友好，struct.unpack_from() 随机访问极快。
- 记录长度必须固定，否则无法 O(1) 定位第 N 条
- 用
struct.pack('QQQ', size, mtime, ino)打包，避免浮点精度丢失 - 排序后再写入：按常用查询字段（如
mtime）预排序，后续二分查找才有效 - 别忘了
mmap.ACCESS_READ，写时用单独临时文件，原子替换
路径字符串怎么省内存？
路径字符串是内存大头之一。10 万个 /var/log/app/2024-01-01/trace_0001.log 这种长路径，光字符串对象就占上百 MB。
解法不是压缩，而是去重 + 相对化：
- 提取公共前缀：用
os.path.commonpath(files)得到根目录，所有路径转为相对路径 - 字符串驻留：
sys.intern(str(p.relative_to(root)))强制复用相同路径字符串 - 极端情况用
bytes：若路径不含 Unicode，p.as_posix().encode()比str少一半内存 - 别用
pathlib.Path当 key：它本身是对象，比字符串还重；key 只用str或bytes
真正海量时，索引结构本身就得和业务耦合：比如日志场景，按日期分桶，每个桶内只存文件名+偏移，主索引只管桶定位——而不是幻想一个全局 flat dict 能 hold 住一切。
