python 3.7+ dict 保序靠 entries 数组追加实现，插入顺序即内存布局顺序；dict_keys 不支持下标访问，需用 next(iter(d.keys())) 取首键；json 保序依赖 dict 构造顺序；ordereddict 仍必要于顺序敏感相等、键位置移动等场景。
Python 3.7+ dict 保序不是靠排序，而是靠 entries 数组追加
字典保持插入顺序，根本不需要运行时做任何排序或链表维护——每次 d[key] = value，CPython 就把 (hash, key, value) 三元组直接 append 到 entries 数组末尾。遍历时只顺序读这个数组，顺序自然就稳了。
这和旧版（≤3.5）完全不同：那时所有数据挤在一个稀疏二维数组里，扩容重哈希会打乱物理位置，遍历必须跳空槽，结果不可预测。
- entries 是紧凑、线性、只增不移的存储区，插入顺序 = 内存布局顺序
- indices 数组只负责哈希查找，它大小约是 entries 的 2–4 倍，每个元素是
int8，只存偏移量 - 查键走 indices 定位，遍历绕过 indices 直接扫 entries，两者互不干扰
为什么 d.keys()[0] 会报 TypeError？
dict_keys 视图对象不是序列类型，它没有 __getitem__ 方法，所以 d.keys()[0] 或 d[0] 都会触发 TypeError: 'dict_keys' object is not subscriptable。
这不是 bug，是设计使然：字典本质仍是哈希映射，不是 list 或 tuple。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 想取第一个键？用
next(iter(d.keys()))，O(1) 开销，不建新列表 - 想按位置弹出？
d.popitem(last=False)弹最老项，last=True弹最新项（3.7+ 已支持） - 别写
list(d.keys())[0]——它强制全量转 list，O(n) 时间 + O(n) 内存，热路径慎用
JSON 序列化保序的关键前提是什么？
json.dumps() 本身不排序，它只是忠实按 dict 的迭代顺序输出。所以保序的真正前提是：dict 构造方式必须反映你想要的字段顺序。
- 直接字面量
{'a': 1, 'b': 2}→ CPython 解析器按书写顺序插入，没问题 - 解包
{**d1, **d2}→ 顺序由d1和d2的插入顺序拼接，不是语法顺序 -
json.loads('{ "b": 2, "a": 1 }')→ 返回的dict在 3.7+ 中确实是{'b': 2, 'a': 1}，不是按键排序 -
json.dumps(d, sort_keys=True)会覆盖插入顺序，强制字典序，这是显式干预
OrderedDict 还有必要用吗？
普通 dict 在 3.7+ 已覆盖绝大多数“要顺序”的场景，但 collections.OrderedDict 仍有不可替代的用途：
- 两个对象顺序敏感相等：
OrderedDict(a=1, b=2) == OrderedDict(b=2, a=1)返回False；普通dict返回True - 移动键位置：
od.move_to_end('key', last=False)把某个键挪到开头 - 需要稳定、可预测的
popitem行为（尤其在旧版本兼容场景） - 别用
OrderedDict(dict(...))初始化——传入的dict在旧解释器中可能已乱序，原始顺序丢失
真正容易被忽略的是：有序 ≠ 可索引，也 ≠ 自动排序。你依赖顺序，就得确保构造逻辑本身是确定性的——比如用 dict.fromkeys(iterable) 去重时，结果顺序取决于 iterable 的首次出现顺序，而不是值大小。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
