优先选 defaultdict(list)，仅当顶点 ID 空间极大且存在大量无效查询时改用 dict + setdefault()；边存储按需去重或排序；超大图用 NumPy 数组分段管理或 mmap 二进制格式替代纯 Python 容器。
邻接表用 dict 还是 defaultdict？
超大图的邻接表若用普通 dict，每次添加边前都得手动检查节点是否存在，代码冗长且易漏判；用 defaultdict(list) 能自动初始化空列表，写法简洁，但要注意它会隐式创建键——哪怕只是查询不存在的节点（如 graph["missing"]），也会触发插入，导致内存意外增长。真实场景中，如果图稀疏但顶点 ID 分布极广（比如 ID 是 64 位随机整数），这种“访问即创建”可能快速吃光内存。
- 优先选
defaultdict(list)，仅当顶点 ID 空间极大且存在大量无效查询时，改用普通dict+setdefault()：graph = {} graph.setdefault(u, []).append(v) - 避免直接索引：
graph[u].append(v)在u未初始化时会抛KeyError - 若需支持双向边且去重，考虑用
defaultdict(set)，但注意set不保持插入顺序，且内存开销略高
边存储要不要去重或排序？
超大图中重复边很常见（比如日志批量导入、爬虫多次发现同一条链接），不做处理会导致遍历变慢、统计失真。但实时去重有代价：用 set 存邻接关系，插入是 O(1)，但无法按序遍历；用 list + 后续 dedupe，则浪费内存和时间。
- 如果业务允许（如 PageRank、BFS/DFS），先不强制去重，等构建完成再用
graph[u] = list(set(graph[u]))批量清理 - 若需保持邻接点有序（如按权重升序选邻居），用
list构建后调sorted()，别在插入时反复排序 - 千万别在循环里对每个
graph[u]调list(set(...))—— 时间爆炸，O(N²)
内存爆了怎么办？用什么替代纯 Python dict？
当顶点数超千万、边数超亿级，纯 Python 的 dict 和 list 会因对象头开销和指针间接寻址，占用数倍于原始数据的内存。实测 1 亿条边用 defaultdict(list) 可能占 20+ GB。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 用
collections.namedtuple或dataclasses封装边信息？没用——单个对象仍带 Python 头 - 更可行的是：只存目标节点 ID，且用 NumPy 数组分段管理，例如为每个源节点分配一个
np.array(dtype=np.uint32)存邻居 ID，再用主dict映射节点 ID → 数组索引或内存视图 - 或直接上
networkx的Graph(adjlist=None)模式配合自定义迭代器，但前提是你的算法能接受流式遍历而非随机查邻接表 - 真到瓶颈时，考虑 mmap 文件 + 自定义二进制邻接块格式，Python 层只做轻量索引
遍历时为什么突然卡住？小心 __iter__ 和 keys() 的陷阱
用 for u in graph: 遍历节点没问题，但若写成 for u in graph.keys():，在 CPython 3.7+ 虽然 key 视图是动态的，可一旦在循环中修改 graph（如删节点、加新节点），就会触发 RuntimeError: dictionary changed size during iteration。更隐蔽的是，某些库（如旧版 igraph 绑定）内部会把 dict.keys() 转成 list 再遍历，看似安全，实则多占一倍内存。
立即学习“Python免费学习笔记（深入）”；
- 遍历前明确是否要修改图结构：要改，就先取
list(graph.keys())快照；不改，直接for u in graph: - 别依赖
graph.keys()返回顺序——即使 CPython 当前保持插入序，也不代表跨版本或 PyPy 下一致 - 如果图结构固定后只读，可提前调
graph = dict(graph)强制转成不可变形态（虽不能真不可变，但能减少意外突变）
邻接表本身简单，但超大图下每一步选择都会被放大成性能拐点。最常被忽略的是：顶点 ID 的数据类型和分布，比选用什么容器更能决定内存和速度上限。uint32 范围内 ID 和全范围字符串 ID，对应的优化路径完全不同。
