KeyError发生时不能直接用dict[key]，因为该操作在键不存在时立即抛出异常，而实际场景（如解析API响应、读取配置）中键常不确定；推荐用dict.get(key, default)安全访问，它返回默认值而非报错，但需注意嵌套调用陷阱及可变默认值风险。
KeyError发生时，为什么不能直接用dict[key]访问
因为dict[key]在键不存在时会立即抛出KeyError，而很多场景下你并不确定某个键一定存在——比如解析用户输入、读取配置文件、处理API返回的JSON数据。一旦上游数据结构稍有变化（例如字段缺失或拼写错误），程序就中断了。
常见错误现象：KeyError: 'user_id'、KeyError: 'data'，尤其在嵌套字典中层层['a']['b']['c']访问时，错一个就崩。
- 使用
dict.get()是防御性编程的第一步，它不抛异常，而是返回None（或你指定的默认值） -
.get()只检查当前层级，对嵌套键无效；想安全取data['user']['profile']['email']，得逐层调用.get()或改用dict.get('user', {}).get('profile', {}).get('email') - 注意：如果键存在但值为
None，.get(key)也会返回None，无法区分“键不存在”和“键存在但值为None”。需要明确语义时，建议显式传入哨兵对象，比如sentinel = object(); val = d.get('x', sentinel)再判断val is not sentinel
如何用dict.get()设置合理的默认值
默认值不是随便填None或0就行，得匹配后续逻辑的数据类型和业务含义。
- 字符串字段（如
'name'）建议用空字符串''，避免后续name.upper()报AttributeError - 数值字段（如
'count'）建议用0，而不是None，否则total += d.get('count')会触发TypeError - 列表字段（如
'tags'）建议用空列表[]，方便直接调用.append()或for item in d.get('tags', []) - 避免用可变对象作默认值，比如
d.get('items', [])是安全的，但d.get('items', some_list)若some_list被多处复用，可能引发意外修改
什么时候.get()还不够，得换方案
.get()适合单层、轻量、低风险的键访问。但它解决不了所有问题：
立即学习“Python免费学习笔记（深入）”；
- 需要多次访问同一字典的多个键，且都依赖默认值？考虑用
collections.defaultdict，但注意它会自动插入新键，可能污染原始数据 - 要安全提取深层嵌套字段（如
config['db']['host']['port']）？推荐dict.get('db', {}).get('host', {}).get('port')，或引入pydantic做结构化校验，或用glom库：glom(data, 'user.profile.email', default='') - 必须保证键存在、缺失即属严重错误？那就别防御，让
KeyError暴露出来，并配合try/except做有针对性的日志或降级处理，比如except KeyError as e: log.error("Missing required field: %s", e) - 从JSON加载后立刻校验结构？用
jsonschema或pydantic.BaseModel.parse_obj()比一堆.get()更可靠
容易忽略的细节：.get()的返回值类型和链式调用陷阱
.get()返回的是字典中存储的原值，不会做类型转换。如果你默认返回0，但实际值是字符串"42"，后续做算术运算就会出错。
- 链式调用如
d.get('a').get('b')风险很高：如果d.get('a')返回None，再调用.get('b')会触发AttributeError: 'NoneType' object has no attribute 'get'，这比KeyError更难排查 - 正确写法是每层都带默认空字典：
d.get('a', {}).get('b', {}).get('c', '') - Python 3.8+ 可用海象运算符简化重复调用：
if (val := d.get('x')) is not None: process(val)，但别为了省一行牺牲可读性 - 静态类型检查（如
mypy）对.get()推断较弱，建议配合类型注解：name: str = data.get('name', '')
.get()，而是默认值选什么、嵌套怎么写才既安全又不啰嗦、以及什么时候该放弃防御直接报错。这些得结合数据来源稳定性、下游消费逻辑、错误容忍度来权衡。 
