1. 字典到底是什么先搞懂 dict 的设计哲学1.1 从员工工号查姓名说起为什么需要字典做 Python 基础教程这么久每次讲到字典dict的时候我都觉得这是一个特别适合用“员工信息”来打比方的数据结构。为什么因为它和现实世界里的人事登记表几乎一模一样工号对应姓名姓名对应部门部门对应薪资档位。这种一对一的映射关系翻译成 Python 的术语就是“键值对”。很多初学者一开始会用列表存员工信息比如 names [张三, 李四, 王五]然后靠下标 0、1、2 去取。问题来了如果公司有一千个员工你怎么知道“工号 89757”对应的是列表里的第几个你只能从头遍历一遍运气好第一个就是运气不好得跑完一整圈。这个操作的时间复杂度是 O(n)数据量一大程序就肉眼可见地“卡”。字典就是专门来解决这个问题的。它的底层实现是哈希表你给它一个键它直接通过哈希计算定位到值所在的位置平均时间复杂度是 O(1)。说白了字典就是 Python 内置的“按名字找东西”的神器不需要遍历不需要排序直接给键秒出值。这也是几乎所有编程语言都会提供映射结构的原因——C 叫 mapJava 叫 HashMapPython 里就叫 dict。1.2 字典 vs 列表两种数据组织方式的本质区别我见过不少同学学了列表就想着“一招鲜吃遍天”但列表和字典的适用场景是完全不同的搞混了写出来的代码要么绕远路要么直接踩坑。列表是有序的序列它强调的是“位置关系”。你要取第三个元素list[2] 直接取你要知道某个元素在第几个位置用 index() 从头到尾扫描。字典强调的是“映射关系”键和值之间建立一条直接通道它不关心谁排在谁前面只关心“你给我这个键我还你那个值”。举个例子拿员工花名册来说如果数据是“按入职顺序排的名单”用列表合适如果数据是“根据工号查员工详细信息”那就必须用字典。一个员工的所有属性比如姓名、部门、职位其实又是一个小的映射集合所以现实中更常见的做法是“字典里套字典”工号作为外层键内层再放一个包含姓名、部门、职位的字典。从内存和性能的角度看列表的底层是连续内存块或者说动态数组遍历友好字典的底层是哈希表查找友好但会占用更多内存来维护哈希桶。所以在数据量很小、只需要顺序处理的时候列表更轻快但在“频繁按键取数”的场景下字典的优势是碾压级的。记住一句话查得频繁用字典排得频繁用列表。1.3 键值对的约束不可变键与哈希使用字典之前有一个基本约束必须刻在脑子里键必须是不可变类型。字符串、整数、元组都可以当键但列表、字典这类可变类型不行。原因其实不复杂。哈希表在存键的时候会先计算键的哈希值然后根据哈希值决定存在哪个“桶”里。如果键是可变的比如列表你往里面加了一个元素哈希值就变了那这个键之前存在哪个桶的位置就对不上了再查的时候要么找不到要么找到错误的数据。这就像你进图书馆把书放在某个书架上记录“书在第 3 排”结果书自己长脚跑到第 5 排去了那你的索引就失效了整个图书馆的检索系统都会被搞乱。所以 Python 干脆从语言层面禁止可变类型不能作为字典的键。你要是硬写 {[1, 2]: test}解释器直接给你抛 TypeError: unhashable type: list。这个报错新手经常遇到看到“unhashable”这个词别慌翻译过来就是“你给了个没法算哈希的东西当键”换回字符串或者元组就行。2. 字典的常规操作创建、增删改查全过一遍2.1 创建字典的五种姿势创建字典这事看着简单其实有不少细节尤其是从已有数据批量构建的时候方法选得好能省一大半代码。最直白的方式当然是大括号加冒号employee {name: 张三, department: 技术部}。这是最常用的方式可读性最高绝大多数场景都推荐这么写。第二种是用 dict() 构造函数配合关键字参数employee dict(name张三, department技术部)。这种写法在键名是合法的 Python 标识符不含空格、不以数字开头时非常简洁但键名如果带特殊字符就没办法了比如 dict(employee-name...) 直接语法报错。第三种是从成对的可迭代对象转换pairs [(name, 张三), (department, 技术部)]然后 employee dict(pairs)。这种适合数据已经以“成对列表”的形式存在的情况比如从 Excel 或数据库导出的键值对批量构建字典。zip 函数在这里特别有用dict(zip(keys, values))一行代码把两个列表合并成字典我经常在数据处理脚本里这么干。第四种是 dict.fromkeys()这个很适合初始化一批键并设置同一个默认值。比如要给所有部门建一个初始人数统计counter dict.fromkeys([技术部, 市场部, 财务部], 0)得到 {技术部: 0, 市场部: 0, 财务部: 0}。注意这里默认值如果是可变对象会有大坑后面我专门讲 setdefault 的时候再说。最后一种是字典推导式{key: value for key in ...}。比如把员工列表变成工号到姓名的映射一行搞定name_by_id {emp[id]: emp[name] for emp in employees}。推导式的好处是直接在创建过程中做过滤和转换代码非常紧凑。2.2 新增、修改、删除别小看这几个 API字典的新增和修改用的是同一个语法d[key] value。键不存在就是新增键存在就是覆盖。很多新手会纠结“怎么判断是新增还是覆盖”其实大多数场景根本不用判断直接赋值就行Python 帮你处理好了。取值稍微讲究一点。最原始的方式是 d[key]但这有个隐患键不存在的时候会直接抛 KeyError程序当场崩掉。所以在拿“可能不存在的键”时我一般用两种方式。第一种是 d.get(key, default)键不存在返回默认值不报错第二种是 d.setdefault(key, default)键不存在时不仅返回默认值还会把这个键值对写进字典里。setdefault 这个 API 我在工作中用得非常多典型场景就是“给一个词频统计表累加次数”。常规写法是if word in counter: counter[word] 1 else: counter[word] 1用 setdefault 可以压成一行counter[word] counter.setdefault(word, 0) 1虽然性能上差别不大但代码简洁度提升明显读起来也顺畅很多。删除的话有两种主流的做法。del d[key] 是硬删键不存在会抛 KeyErrord.pop(key, default) 是“弹出式删除”删除的同时把值返回出来键不存在时返回你给的默认值而不是报错。如果你需要“删完之后还要用这个值”那 pop 就是最佳选择因为它一次性完成了“取出来”和“删掉”两件事。Python 3.9 之后还引入了合并操作符 |可以把两个字典合并成新的字典merged dict1 | dict2。还有个类似的更新方法 d.update(other)区别是 update 会直接原地修改 d而不是返回新字典。批量更新员工数据的时候update 非常方便employee.update({phone: 138xxxx, email: zhangsanexample.com})一次塞好几个键值。2.3 判断元素在不在字典里这是被问得最多的问题搜索热词里那句“python 判断一个元素在不在dict里”几乎是每个 Python 初学者都会搜的问题。原因是很多人习惯了列表里的 in 判断到了字典里一下子懵了这个 in 到底是判断键还是判断值我直接给结论字典的 in 判断的是“键”不是值。这是 Python 设计上非常符合直觉的一点因为对字典来说“查有没有某个键”是最高频的操作而“查有没有某个值”比较少见需要的话用 value in d.values()。所以标准写法就是if 1001 in employee_dict: print(工号存在)这个 in 的底层也是走哈希查找时间复杂度和 d[key] 一样是 O(1)比遍历列表快得多。如果键不在字典里千万不要用 d[key] 去试——那会抛异常。安全的做法有两种风格一是用 in 先判断再取值二是直接用 d.get(key, default) 一步到位。我个人在实际项目里更推荐 get 风格因为“判断”和“取值”在业务上常常是连续发生的分开写还容易漏判。比如写查询工具的时候用户输入的工号可能不在表里下面这种写法就比 if 判断再取值要干净employee employees.get(emp_id) if employee is None: print(查无此人) else: print(employee)这里有一个经典陷阱如果值本身可能是 None那用 is None 判断“不存在”就会误判。更稳妥的做法是定义一个哨兵值比如 sentinel object()然后 result d.get(key, sentinel)判断 result is sentinel。这个技巧在键对应的值可能为 None 或空字符串时非常有用但很多人没意识到。还有一个容易忽略的坑in 判断键用的是“相等性哈希”所以整数 1 和布尔值 True 在字典里会被当作同一个键。因为 True 的哈希值和 1 一样且 True 1。{1: a}[True] 能取到 a反过来也是。这种边角情况平时不遇到就算了遇到的时候排查会非常痛苦知道这个原理能省不少时间。3. 员工信息查询工具完整实现3.1 需求拆解与数据结构设计光说 API 没意思咱直接上手做个完整的东西。目标很清晰做一个命令行下的员工信息查询工具用户输入工号程序立刻返回这个员工的姓名、部门、职位、联系方式等信息。输入 “exit” 退出程序。这个工具麻雀虽小五脏俱全至少用到了字典的创建、嵌套、查找、遍历、默认值处理这些核心知识点用来巩固 dict 基础再合适不过。先设计数据结构。工号是唯一的适合当外层字典的键每个工号对应的员工信息有多个属性适合用内层字典来存employees { 1001: {name: 张三, department: 技术部, position: 后端工程师, phone: 13800000001}, 1002: {name: 李四, department: 市场部, position: 市场专员, phone: 13800000002}, 1003: {name: 王五, department: 财务部, position: 会计, phone: 13800000003}, }为什么要用两层嵌套而不是平铺一层因为平铺一层的话键只能是工号姓名、部门、职位都得存到值里值就得是字符串拼接查出来还要自己 split 拆开非常脆弱。嵌套字典让每个员工的信息保持结构化想取哪个字段就取哪个字段后续加字段也不用改已有数据的结构。3.2 查询逻辑从用户输入到结果输出主循环的核心逻辑其实就三步接收输入、查字典、输出结果。但正因为逻辑简单才能把 dict 的用法展示得清清楚楚。def query_employee(emp_id): employee employees.get(emp_id) if employee is None: return 查无此员工 return f姓名{employee[name]}部门{employee[department]}职位{employee[position]}电话{employee[phone]} def main(): print(员工信息查询工具已启动输入 exit 退出) while True: emp_id input(请输入工号).strip() if emp_id.lower() exit: print(再见) break if not emp_id: print(工号不能为空) continue print(query_employee(emp_id)) if __name__ __main__: main()这段代码里集合了前面提到的几个关键点。第一用 get 而不是直接用中括号取值避免工号不存在时抛 KeyError第二用 strip() 去掉用户输入的前后空格防止用户多打个空格查不到人第三判断退出用 emp_id.lower() exit这样用户输入 EXIT 或者 Exit 都能正常退出体验更友好。你可能注意到我没在输入阶段判断“这个工号是否存在”而是把判断放到了 query_employee 里返回一个“查无此员工”的提示。这是故意的——把“查字典”的逻辑封装成一个函数主循环只负责输入输出职责分离代码结构更清晰。以后想加模糊查询、批量查询只需要在函数层面扩展不用动主循环。不过 get 方案有个隐藏问题如果字典里某个员工的值不小心变成了 None那“员工存在但返回 None”和“员工不存在返回 None”就混在一起了。为了严谨可以把哨兵方案用上_NOT_FOUND object() def query_employee(emp_id): employee employees.get(emp_id, _NOT_FOUND) if employee is _NOT_FOUND: return 查无此员工 ...这个写法在真实项目中很常见尤其是当字典的值本身就可能是 None、0、空字符串这些“假值”时用 is 判断哨兵对象是最可靠的。3.3 功能扩展批量导入、模糊查询、按部门统计基础版跑通之后可以顺手加几个非常实用的扩展顺便把 dict 的更多特性串起来。第一个扩展是批量导入员工数据。现实中数据不会手写在代码里更常见的是从 Excel 或数据库拉出来。比如从 CSV 读进来然后构建成字典import csv def load_employees_from_csv(filepath): result {} with open(filepath, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: emp_id row[emp_id] result[emp_id] { name: row[name], department: row[department], position: row[position], phone: row[phone], } return resultcsv.DictReader 本身就把每一行变成一个字典键是表头值是单元格内容配合外层工号字典正好是“字典套字典”的经典嵌套结构。这里有个实际经验从文件读数据时一定要确认 emp_id 列不会重复。如果不小心重复了后读进来的行会覆盖前面的数据直接丢失。保险的做法是加个判断if emp_id in result: print(f警告工号 {emp_id} 重复已覆盖)第二个扩展是模糊查询。给用户一个选择输入完整工号精确查或者输入姓氏、部门名做模糊搜索。模糊搜索自然要遍历字典正好把 items() 用上def search_by_keyword(keyword): results [] for emp_id, info in employees.items(): if keyword in info[name] or keyword in info[department] or keyword in info[position]: results.append((emp_id, info)) return results这里 in 操作符在字符串上表示“子串包含”跟在字典上判断键是两码事。同一行代码里有多个 in语义不同初学者容易混淆但其实只要记住“in 就是‘检查左边是否存在于右边’”放到字符串里就是包含关系放到字典里就是键存在逻辑就通了。第三个扩展是按部门统计人数。这是 dict 在数据聚合上的典型应用把“部门名”当作键把“人数”当作值def count_by_department(): stats {} for info in employees.values(): dept info[department] stats[dept] stats.get(dept, 0) 1 return stats我每次讲这段都要强调一下 stats.get(dept, 0) 1 这个写法读旧值加一写回去一步到位。很多人第一次看到会愣一下但它是 dict 统计类代码里最经典的惯用法理解了它后面做词频统计、流量统计、投票计数全都能用。4. 实战中的坑遍历、修改、默认值4.1 遍历字典的三种姿势keys、values、items遍历字典是高频操作但很多新手不清楚该用哪个方法写出来的代码也不够 Pythonic。三个方法分别是 d.keys()、d.values()、d.items()分别用于拿键、拿值、同时拿键和值。如果只需要键for key in d.keys() 和 for key in d 是等价的后者更简洁。只需要值用 for value in d.values()。键和值都要用必须用 items()for emp_id, info in employees.items(): print(emp_id, info[name])这里有个小细节在 Python 2 时代keys()、values()、items() 返回的是列表会一次性把数据全部复制出来Python 3 改成了视图对象是动态的字典变了视图也跟着变而且不会额外占用大量内存。所以在 Python 3 里放心大胆地用这三个方法不用担心大字典遍历时内存暴涨。遍历的时候还有一个常见需求按某种顺序遍历。dict 在 Python 3.7 之后是保持插入顺序的所以直接遍历就是“按插入顺序”。如果希望按键排序就用 sorted(d)比如按工号升序输出写成 for emp_id in sorted(employees): 就行。sorted 默认按升序排字符串工号如果都是纯数字且位数相同效果没问题如果工号有字母有数字排序规则就要仔细确认了否则排出来的顺序可能和你想的不一样。4.2 遍历时修改字典RuntimeError 的经典陷阱这个坑我踩过不止一次几乎每个写 Python 的人都会遇到。场景是这样你想把员工表里所有电话为空的员工删掉于是写了for emp_id, info in employees.items(): if not info.get(phone): del employees[emp_id]跑起来Python 直接甩给你一个 RuntimeError: dictionary changed size during iteration。意思很明确你正在遍历字典同时又改了它的大小Python 不允许这种操作。原因在于字典的迭代器是基于“当前哈希表状态”工作的删除或新增键会改变哈希表的大小迭代器的内部指针就乱了继续迭代下去要么跳过数据要么死循环。解决办法有三种我按推荐程度排个序。第一种是收集要删除的键遍历完之后再统一删to_remove [] for emp_id, info in employees.items(): if not info.get(phone): to_remove.append(emp_id) for emp_id in to_remove: del employees[emp_id]这种“先收集、后处理”的模式最安全因为它把“遍历”和“修改”拆成了两个阶段不会互相干扰。第二种是用字典推导式重建字典employees { emp_id: info for emp_id, info in employees.items() if info.get(phone) }这段代码的好处是函数式风格一行完成过滤可读性其实比 for 循环加 del 更好。缺点是原来的字典对象被替换成了新对象如果有其他变量引用着原字典那些引用拿到的还是旧数据。在脚本里无所谓在复杂系统里就要小心。第三种是用 Python 3 引入的“迭代时删除”特例for key in list(d): 然后删 d[key]。因为 list(d) 先把键快照到列表里迭代的是列表删除的是字典二者互不干扰。这其实和第一种思路一样只是写法更紧凑。我个人的习惯是过滤逻辑简单就用推导式逻辑复杂就用先收集后删除。推荐每个项目里统一一种风格别一会儿这样一会儿那样代码维护起来轻松得多。4.3 get、setdefault 和 defaultdict默认值的三种姿势处理“键不存在”的问题除了 get 和 setdefault还有一个非常顺手的工具collections.defaultdict。它是在创建字典时就指定“当键不存在时自动生成默认值”的工厂函数。比如按部门统计人数的功能用普通 dict 写是stats {} for info in employees.values(): stats[info[department]] stats.get(info[department], 0) 1用 defaultdict 写from collections import defaultdict stats defaultdict(int) for info in employees.values(): stats[info[department]] 1区别大了去了。defaultdict(int) 的意思是访问不存在的键时自动调用 int() 生成一个 0然后把这个键值对插入字典。所以你在 for 循环里直接 stats[dept] 1第一次遇到某个部门时它已经是 0 了加一变成 1完全不用手动判断键是否存在。这里有一个很多教程没讲透的坑defaultdict 的默认值工厂函数只会被调用一次而且是在“访问不存在的键”时自动调用。如果你想把默认值设置成列表然后直接 append那正常的写法是 defaultdict(list)。但如果写成 defaultdict( [] )也就是把空列表当成默认值传入那所有新键会共享同一个列表对象一个键 append 了数据其他键也能看到数据全串了。这是我在实际代码评审里见过的新手错误必须强调一下defaultdict 接收的是“工厂函数”不是“默认值本身”。对照一下三个工具的使用场景想取一个值取不到就拉倒用 get想取一个值取不到时还要把这个默认值写进字典用 setdefault想批量做计数、分组、收集这类聚合操作直接在缺失键上做加法或 append用 defaultdict。5. 员工查询工具的进阶优化嵌套、序列化和容错5.1 KeyError 的排查思路先分清“键不存在”还是“结构不对”实际写查询工具超过 300 行之后你一定会遇到 KeyError这是字典最常见的报错。但别急着甩锅给“用户输入了不存在的工号”KeyError 至少有三种完全不同的成因排查思路完全不同。第一种是键真的不存在。这种最简单用 in 判断或 get 兜底就能解决。第二种是键名拼写不对最常见的是中英文字符混用、下划线和短横线混用比如代码里写的是 employee[deparment]实际键是 department少了一个 t程序报 KeyError 你半天看不出来。我的习惯是字典的键尽量用常量或者统一的变量名不要散落在各个函数里手写字符串。可以定义一组常量class EmployeeFields: NAME name DEPARTMENT department POSITION position PHONE phone然后访问统一用 info[EmployeeFields.NAME]这样拼写错误在代码评审阶段就能被发现。第三种是数据结构本身和你预期不符。比如你以为 employees[emp_id] 返回的是一个字典结果实际值是一个字符串或者 None你再取 [name] 就会报 TypeError: string indices must be integers。这种报错比 KeyError 更隐蔽因为它说明问题不在“键”而在“值”。排查这类问题我一般先打印出实际的数据结构或者用 type() 确认一下类型不要凭记忆推断数据长什么样。5.2 字典与 JSON导入导出员工数据的桥梁做了一个查询工具你肯定想把数据保存下来下次启动还能接着用。最自然的格式就是 JSON因为它和 Python 字典的语法几乎一一对应互转也就两行代码的事。import json # 写入文件 with open(employees.json, w, encodingutf-8) as f: json.dump(employees, f, ensure_asciiFalse, indent2) # 读取文件 with open(employees.json, r, encodingutf-8) as f: employees json.load(f)有几个细节必须注意。第一ensure_asciiFalse 一定要加否则中文会被转成 \uXXXX 的转义序列存进文件里看着像天书虽然读回来没问题但中间如果你想打开文件人工检查体验极差。第二indent2 让 JSON 文件有缩进可读性大幅提升调试起来方便。第三json.dump 不能直接序列化自定义对象只能序列化 dict、list、str、int、float、bool、None 这些基础类型。如果 employees 的值里有 datetime 之类的东西就得自己先转成字符串再存。这里我还想多提醒一句json.load 读回来的键一定是字符串。如果你之前用整数当键比如 {1001: 张三}dump 的时候 Python 会自动把整数键转成字符串 1001load 回来就变成字符串键了。如果程序里还按整数键去查那就真的“查无此人”了。我建议在项目一开始就统一约定字典的键要么全用字符串要么全用整数不要混着来否则序列化一次之后你就会发现数据类型全变了排查起来极其痛苦。5.3 嵌套字典的结构设计部门、职位、联系人三层怎么组织再往深一层说真实公司的员工数据不会只有一层字典通常会有部门表、职位表、联系人表它们之间存在关联关系。这时数据结构的设计就非常考验功底了。一种常见的设计是“工号作为全局唯一键值里再通过部门编号关联部门表”employees { 1001: { name: 张三, dept_id: D01, position: 后端工程师, phone: 13800000001, } } departments { D01: {name: 技术部, manager: 赵六}, D02: {name: 市场部, manager: 钱七}, }查询员工所在部门的负责人时需要先从员工字典里拿到 dept_id再拿 dept_id 去部门字典里查。这种“通过外键关联”的设计和关系型数据库的思路一脉相承好处是部门名称只存一份不会因为部门改名而要批量更新每个员工的数据。这种嵌套查询虽然只是两级查找但初学者往往会写出一长串不安全的代码dept_name departments[employees[emp_id][dept_id]][name]这一行里只要任何一个键不存在就是 KeyError。要多进行防御性编程把每一步都兜底emp_info employees.get(emp_id) if not emp_info: return 查无此人 dept_info departments.get(emp_info.get(dept_id)) if not dept_info: return 部门信息缺失 return dept_info.get(name, 未知部门)代码是长了点但每一条路径都不会让程序崩掉。我见过很多线上的事故都是“假设数据一定存在”造成的写工具的时候多写几行判断运行时就能少接几通报警电话。5.4 查询工具的最终版加入容错与日志把上面这些优化汇总一下给员工查询工具加上“从 JSON 加载数据”和“兜底容错”最终版的结构大概是这样的import json from collections import defaultdict _NOT_FOUND object() def load_data(pathemployees.json): try: with open(path, encodingutf-8) as f: return json.load(f) except FileNotFoundError: return {} except json.JSONDecodeError: print(数据文件损坏请检查 JSON 格式) return {} def query_employee(employees, emp_id): info employees.get(emp_id, _NOT_FOUND) if info is _NOT_FOUND: return 查无此员工 return f{info[name]} | {info[department]} | {info[position]} | {info[phone]} def main(): employees load_data() if not employees: print(暂无员工数据请先导入) return print(员工信息查询工具已启动输入 exit 退出) while True: emp_id input(请输入工号).strip() if emp_id.lower() exit: break if not emp_id: continue print(query_employee(employees, emp_id)) if __name__ __main__: main()load_data 函数里我加了两层异常处理文件不存在返回空字典文件损坏提示错误信息。这是真实项目中非常基础的健壮性设计你在教程里可能看不到但实际运行中几乎一定会遇到。用户不会乖乖按你的预期操作文件也可能因为各种原因损坏代码里多一个 try就少一次线上崩溃。这段代码里还有一个值得推敲的细节query_employee 接收的是 employees 字典而不是在函数内部去读全局变量。把数据作为参数传进去函数就变成了纯函数——同样的输入永远得到同样的输出测试起来非常方便以后想接图形界面或者 Web 接口这段查询逻辑可以直接复用连改都不用改。6. 常见问题与排查技巧速查6.1 典型报错与解决方案对照干活阶段的经验值到这里攒得差不多了我把新手和实际开发中最常踩的坑整理成一张速查表遇到问题直接对号入座。报错或现象原因解决方案KeyError: xxx键不存在直接用 d[key] 取值改用 d.get(key, default) 或先 in 判断TypeError: unhashable type: list用可变类型当键换字符串、元组等不可变类型当键RuntimeError: dictionary changed size during iteration遍历字典时增删了键先收集键遍历完再删或改用字典推导式字典遍历顺序和预期不符误以为 dict 无序或混淆了 Python 版本行为Python 3.7 中 dict 保持插入顺序确认版本json 转存后键类型变了JSON 规定键只能是字符串转存前统一键为字符串或自定义转换逻辑值明明存在in 判断返回 False对 dict 用 in 会判断键不是值判断值用 value in d.values()defaultdict 所有键共享同一个列表传入了默认值对象而非工厂函数写成 defaultdict(list)而不是 defaultdict([])这张表里的每一条我都在真实代码里见过前三条出现的频率最高。尤其是 RuntimeError一旦遇到别慌记住核心原则不要在迭代过程中修改容器的结构。6.2 字典性能的认知什么时候该换数据结构字典的 O(1) 查找在绝大多数场景下够用了但也有一些注意事项。如果字典里存了十万个以上的键内存占用会比列表明显高因为哈希表有额外的桶和负载因子。虽然每个键值对本身的存储开销不大但哈希表的“空桶”会浪费内存这是底层实现的固有代价。如果数据的量级到了百万级以上且你需要频繁做范围查询、前缀查询字典就不一定是最优方案了。这时候可以考虑用数据库或者专门的数据结构比如键值数据库 Redis或者 Python 的 sqlite3 模块。判断标准很简单只做“精确按键查找”字典无敌要做排序、范围扫描、分组聚合就得换个思路。还有一点是关于键的设计。字典查找快前提是哈希函数分布均匀。Python 自带的字符串和整数哈希都做得很好但你如果用自定义对象当键务必实现好hash和eq否则哈希冲突太多O(1) 会退化到 O(n)。这一点初学者基本不用碰但如果哪一天你开始用元组或者自定义类当键就要把这条捡起来。6.3 我用 dict 的一些小习惯最后分享几个我个人的编码习惯不算什么高深技巧但对代码质量和排查效率帮助很大。第一个习惯是能不用“中括号直接访问”就不用尤其是在函数参数、接口返回这些外部数据上。所有外部来的字典我都用 get 或 setdefault 兜底。这看起来只是少了几行代码的事但长期下来线上能少一大半 KeyError。第二个习惯是打印调试信息时用 pprint 而不是 print。pprint.pprint(employee_dict) 会把嵌套字典排版得非常整齐一眼就能看出数据结构长什么样。数据嵌套很深的时候这个习惯能救你很多时间。第三个习惯是写“字典套字典”的多级访问时每一级都用中间变量拆开不要写一长串连环取值。比如上面提到过的那种 employees[emp_id][dept_id] 套 departments 的写法拆成多行之后每行都能单独判断、单独加日志排查问题的定位成本低得多。第四个习惯是把字典的键当作“数据库字段”一样对待。字典看起来是没有固定的结构的但你的业务逻辑一定隐含着结构。一旦某个层级的数据缺少字段程序就会在你不注意的地方报错。我的做法是在入口处做一次数据校验把必填字段检查一遍缺失的直接打印警告或者抛弃避免脏数据流到后面的逻辑里。这几条习惯不是从教程里抄来的是我自己在写爬虫、写 Web 接口、写数据处理脚本的过程中被各种莫名其妙的字典问题折腾之后总结出来的。把这几个习惯刻进肌肉记忆里你在 dict 上踩的坑大概率能减少一半以上。说到底字典是 Python 里最“反直觉但最强大”的内置结构。它不像列表那样直观但只要你理解了“键值映射”和“哈希查找”这两个核心概念再配合今天这套员工查询工具的实操练习你会发现它其实是日常开发中最高频、最好用的数据结构之一。以后写任何“按某个唯一标识找对应信息”的功能先想到字典大概率不会错。