OrderedDict 因双向链表保证跨实现顺序性，支持 move_to_end() 和 popitem(last=False)，适用于 LRU 缓存等需稳定保序场景；普通 dict 在 CPython 3.7+ 虽有序但非规范保证，且无上述方法。
Python OrderedDict 为什么比 dict 有序
因为 OrderedDict 在内部用双向链表维护插入顺序，而 Python 3.7+ 的普通 dict 虽然也保持插入顺序，但那是 CPython 实现细节，不是语言规范保证——OrderedDict 的顺序性是明确写进文档的、跨实现可依赖的行为。
这意味着：如果你写的代码要跑在 PyPy、Jython 或未来某个严格遵循标准的 Python 实现上，且逻辑依赖“顺序可预测”，就该用 OrderedDict；如果只是日常开发、只跑 CPython 3.7+，多数场景用 dict 更轻量。
-
OrderedDict的move_to_end()和popitem(last=False)是普通dict没有的关键能力 - 相同 key 重复赋值不会改变位置：
od['a'] = 1; od['a'] = 2后，'a'仍在原位；而dict在 3.7+ 行为一致，但别依赖它 - 内存开销比
dict高约 20%–30%，因为要存前后指针
用 OrderedDict 实现 LRU 缓存的正确姿势
LRU（Least Recently Used）缓存需要两个核心操作：访问时把 key 移到末尾（最新）、容量超限时删最前面的（最旧）。OrderedDict 的 move_to_end() 和 popitem(last=False) 天然匹配这个逻辑。
常见错误是手动遍历或用 list(od.keys()) 取第一个——这会破坏 O(1) 时间复杂度，且每次调用都重建列表，性能崩掉。
立即学习“Python免费学习笔记（深入）”；
- 初始化时设好最大容量：
self.capacity = capacity，不要在每次__setitem__里算len(od)再比较，那没问题；但别用list(od)[0] - 读取（
get）时先检查是否存在，存在就move_to_end(key)，再返回值；不存在直接返回 -1 - 写入（
put）时，如果 key 已存在，先move_to_end(key)，再赋值；如果不存在且满容量，先popitem(last=False)，再插入新项 - 注意：Python 3.2+ 才支持
move_to_end()；3.1 及更早需自己 pop + reinsert，不推荐
from collections import OrderedDict
class LRUCache:
def __init__(self, capacity: int):
self.od = OrderedDict()
self.capacity = capacity
def get(self, key: int) -> int:
if key not in self.od:
return -1
self.od.move_to_end(key)
return self.od[key]
def put(self, key: int, value: int) -> None:
if key in self.od:
self.od.move_to_end(key)
elif len(self.od) >= self.capacity:
self.od.popitem(last=False)
self.od[key] = value
OrderedDict 和 dict 的等价性陷阱
OrderedDict(a=1, b=2) == {'a': 1, 'b': 2} 在 Python 3.7+ 返回 True，但这只是值相等；== 不比较顺序——OrderedDict([('b', 2), ('a', 1)]) == {'a': 1, 'b': 2} 也是 True。真正要判断“顺序也一致”，得用 list(od1.items()) == list(od2.items())。
-
json.dumps(od)输出和dict一样，不保留顺序信息（JSON 标准本身无序） -
pickle序列化能保留顺序，但反序列化后仍是OrderedDict实例，这点安全 - 用
==比较两个OrderedDict实例时，Python 会逐项比对键值对及顺序，所以od1 == od2确实意味着“内容和顺序完全一致” - 别在测试中用
assert od == {'a': 1, 'b': 2}来验证顺序，它过不了，但不代表逻辑错——改用assert list(od.items()) == [('a', 1), ('b', 2)]
什么时候该换回普通 dict
除非你明确需要 move_to_end()、popitem(last=False)，或者必须在非 CPython 解释器上稳定保序，否则大多数“我以为需要有序字典”的场景，其实用 dict 就够了——尤其在数据管道、配置加载、API 响应组装这类一次性读写流程里。
- 做 JSON 序列化输出？
dict插入顺序已足够 - 做配置合并（如多层 YAML 合并）？只要不反复增删 key，
dict更快更省内存 - 需要按插入顺序迭代日志条目？
dict行为稳定，没必要加OrderedDict这层抽象 - 真要用 LRU 缓存，优先考虑
functools.lru_cache，它底层优化更好；自定义实现只在需要细粒度控制（比如带过期、支持删除单个 key）时才动手
最容易被忽略的是：很多人把 OrderedDict 当作“更高级的 dict”来用，结果白扛性能和维护成本。它不是升级版，是特化工具——用对地方才叫合理。
