01 低效的字典键存在性检查方式
在 Python 中，字典（dict）是一种极其高效的数据结构，常用于存储键值对。然而，许多开发者在使用字典时，往往会采用一些看似合理但实际上不够优雅的方式来判断键是否存在并获取对应的值。
假设我们有一个字典 my_dict，存储了用户的信息：
python
my_dict = {"name": "Kiran", "age": 24}如果我们想要安全地获取 "name" 的值，并在键不存在时返回一个默认值，许多开发者会这样写：
python
if "name" in my_dict:
print(my_dict["name"])
else:
print("No name found")虽然这段代码能够正常工作，但它存在两个问题：
-
"name" in my_dict 会先检查键是否存在，而 my_dict["name"] 又会再次访问字典，导致两次查找操作。
-
if-else 结构增加了代码的嵌套层级，降低了可读性。
Python 字典提供了 .get(key, default) 方法，可以在键不存在时返回指定的默认值，而不会抛出 KeyError。我们可以将上面的代码简化为：
python
print(my_dict.get("name", "No name found"))虽然 .get() 方法非常方便，但在某些情况下，直接使用 in 检查可能更合适，例如：1）当我们需要在键不存在时执行更复杂的逻辑（而不仅仅是返回默认值）;2）默认值的计算成本较高时，.get() 会无条件计算默认值（即使键存在）。
02 遍历字典的低效方式
字典的遍历是 Python 编程中的高频操作，但许多开发者仍然沿用一些不够高效的写法。这些写法虽然能完成任务，却在性能和可读性上存在一些问题。
假设我们有一个简单的字典：
python
my_dict = {"a": 1, "b": 2, "c": 3}最常见的一种低效遍历方式是先获取键，再通过键查找值：
python
for key in my_dict:
print(key, my_dict[key])这种写法存在两个明显的缺陷：
-
每次 my_dict[key]都会重新计算键的哈希值并查找对应值，在较大型的字典中会产生不必要的性能开销。
-
键和值的关联关系被拆解，需要读者在脑海中重新建立映射。
Python 提供了.items()方法，可以直接返回键值对元组：
python
for key, value in my_dict.items():
print(key, value)通过 timeit 模块测试两种方式的性能差异（百万级字典）：
python
import timeit
large_dict = {i: i*2 for i in range(1_000_000)}
def method1():
for k in large_dict:
_ = k, large_dict[k]
def method2():
for k, v in large_dict.items():
_ = k, v
print("键查找式：", timeit.timeit(method1, number=100))
print("items式：", timeit.timeit(method2, number=100))测试结果显示 .items() 方式通常有 15-20% 的性能提升，这个差距随着字典规模的扩大而更加明显。
03 原地合并字典的风险
在 Python 中合并字典是常见操作，但许多开发者习惯使用 update()方法而未意识到其副作用。这种看似便捷的操作，可能在复杂程序中埋下难以排查的隐患。
python
user_profile = {"name": "Alice", "age": 30}
update_data = {"age": 31, "city": "New York"}
user_profile.update(update_data)虽然这段代码成功将 age 更新为 31 并添加了新字段，但它也带来了两个问题：1）update()会直接修改 user_profile，原始 age 值 30 被永久覆盖；2）任何引用 user_profile 的代码都会立即产生变更，可能破坏其他业务逻辑。
Python 3.5+引入的字典解包操作符能创建新字典，完美解决这个问题：
python
merged_profile = {**user_profile, **update_data}
python
# 危险方式（破坏性的修改）
history = []
current = {"status": "active"}
history.append(current.copy())
current.update({"status": "inactive"})
history.append(current.copy())
# 安全方式（非破坏性的修改）
history = []
current = {"status": "active"}
history.append(current)
current = {**current, "status": "inactive"}
history.append(current)第一种方式必须谨慎处理数据拷贝，否则 history 中的所有记录都会指向同一个字典；第二种方式则保证了每次修改都生成独立的副本。
python
危险方式：
current → {内存地址A}
history → [地址A, 地址A] # 所有元素共享同一对象
安全方式：
current → 地址A → {"status":"active"}
↓ 修改后
current → 地址B → {"status":"inactive"}
history → [地址A, 地址B] # 每个状态独立存储04 过度使用 defaultdict
在 Python 的日常开发中，collections.defaultdict 经常被视为处理缺失键的万能解决方案。然而，这种看似便利的工具如果使用不当，反而会让代码变得难以理解和维护。
面对简单的词频统计需求，许多开发者会这样实现：
python
from collections import defaultdict
word_counts = defaultdict(int)
for word in ["apple", "banana", "apple"]:
word_counts[word] += 1完全可以用更基础的方式实现：
python
word_counts = {}
for word in ["apple", "banana", "apple"]:
word_counts[word] = word_counts.get(word, 0) + 1在简单场景下，defaultdict 的性能优势并不明显。通过 timeit 模块测试可以发现，对于小规模数据处理，普通字典配合 get()方法的性能与 defaultdict 相差无几。真正的性能差异只有在处理超大规模数据（千万级键值）时才会显现，而这种场景在实际开发中并不常见。
主要是可读性方面的考量。defaultdict 的初始化需要指定默认值工厂函数，这会让简单的计数逻辑变得复杂。相比之下，get(key, default)方法直接表达了"获取值，如果不存在则返回默认值"的意图，更符合代码即文档的原则。
当然，defaultdict 并非完全无用武之地。
例如，当需要将单词按首字母分组时：
python
from collections import defaultdict
words = ["apple", "banana", "avocado", "cherry"]
grouped = defaultdict(list)
for word in words:
grouped[word[0]].append(word)在长期维护的项目中，过度使用 defaultdict 可能带来隐患。当默认值工厂函数比较复杂时，后续开发者可能需要深入理解工厂函数的实现细节才能预测字典行为。相比之下，显式的 get()方法让字典的行为更加透明可控。
在接口设计中返回 defaultdict 也可能造成问题。因为 defaultdict 是 dict 的子类，接口使用者可能会意外依赖自动创建默认值的特性，导致后续难以重构。更好的做法是在接口内部使用 defaultdict 处理逻辑，但返回普通字典。
05 忽视大字典的性能问题
字典因其 O(1)的时间复杂度常被视为"永远高效"的数据结构，这种认知导致许多开发者习惯性地创建大字典。
如果需要存储一千万个数字及其平方值，许多开发者可能会这样写：
python
square_dict = {i: i**2 for i in range(10_000_000)}这个看似优雅的表达式实际上会立即消耗约 1.2GB 内存（基于 Python 3.8 实测）。问题在于它一次性生成所有键值对并存储在内存中，即使后续程序可能只访问其中一小部分数据。
更聪明的做法是采用惰性求值策略。通过生成器表达式，我们可以建立计算规则而非立即存储结果：
python
def generate_squares():
for i in range(10_000_000):
yield (i, i**2)
square_dict = dict(generate_squares())这种实现方式的内存消耗峰值能降低约 30%，如果我们只需要前 1000 个平方数，可以进一步优化为：
python
from itertools import islice
first_1000_squares = dict(islice(generate_squares(), 1000))06 setdefault()的误用
在 Python 字典操作中，setdefault()方法经常被开发者当作一把万能的瑞士军刀，用来处理键不存在时的默认值设置。然而，这把看似万能的瑞士军刀在实际使用中却隐藏着不少陷阱。
许多初学者在遇到字典键的初始化问题时，会写出这样的代码：
python
user_data = {}
if "preferences" not in user_data:
user_data["preferences"] = initialize_default_prefs()当发现使用 setdefault() 可以进一步简化代码的编写方式时，便会高兴地这样写：
python
user_data.setdefault("preferences", initialize_default_prefs())这种改写看似优雅，却带来了一个严重问题：无论"preferences"键是否存在，initialize_default_prefs()这个函数都会被立即执行。当初始化函数涉及复杂计算或 IO 操作时，会造成严重的性能浪费。
setdefault()的设计机制决定了它的行为特点：该方法总是先计算第二个参数的值，然后再检查键是否存在。
有这样一个从数据库加载用户配置的场景：
python
# 错误用法：每次都会连接数据库
user_data.setdefault("config", fetch_config_from_db(user_id))
# 正确做法：先检查再获取
if "config" not in user_data:
user_data["config"] = fetch_config_from_db(user_id)对于不需要较为复杂的初始化的场景时，.get()方法提供了更安全的选择：
python
# 简单默认值场景
theme = user_data.get("theme", "light")当确实需要较为复杂的初始化时，Python 3.8 引入的海象运算符（:=）可以提供更清晰的表达：
python
if (config := user_data.get("config")) is None:
user_data["config"] = config = load_config()