globals()抛KeyError是因为它返回普通dict，而dict[key]访问不存在键时默认抛该异常；应改用.get()避免崩溃，且不支持点号嵌套访问或反映局部变量。
globals() 查不到变量时为什么抛 KeyError 而不是返回 None
因为 globals() 返回的是一个普通字典（dict），而字典在用方括号 dict[key] 访问不存在的键时，**默认行为就是抛 KeyError**，不是设计缺陷，是字典本身的协议。你写 globals()['missing_var']，和写 {'a': 1}['b'] 是同一类操作。
常见错误现象：
- 想动态读取全局变量，却直接用
globals()['config_path']，结果环境没设这个变量，程序崩了 - 在配置加载逻辑里硬编码查一堆键，没做兜底，上线后某台机器少配一个环境变量就挂
正确做法始终用 .get()：
config_path = globals().get('config_path', '/etc/default.conf')
user_timeout = globals().get('USER_TIMEOUT', 30)
为什么不能用 globals() 查嵌套模块路径（比如 "utils.db.connect"）
globals() 只维护当前模块顶层命名空间的映射，键名是字符串标识符，不支持点号解析。写 globals()['utils.db.connect'] 是在找一个叫 "utils.db.connect" 的全局变量，而不是递归导入并访问属性。
立即学习“Python免费学习笔记（深入）”；
实际场景中容易踩的坑：
- 误以为
globals()['json.loads']能拿到函数——其实它根本不存在于当前全局命名空间，json模块本身才在，loads是它的属性 - 拼接字符串构造键名（如
f"{prefix}_handler"）后直接查globals()，但忘了确保该变量真被定义过
替代方案更可靠：
import importlib
func = getattr(importlib.import_module('utils.db'), 'connect', None)
globals() 在函数内部使用时的隐藏陷阱
如果在函数里调用 globals()，它返回的仍是模块级全局变量字典——这点没问题。但很多人混淆的是：**函数内对同名变量赋值后，再用 globals() 查，查到的还是旧值，不是你刚改的那个局部变量**。
例如：
counter = 100
def inc():
counter = 200 # 这是局部变量
print(globals()['counter']) # 输出 100，不是 200
所以别指望用 globals() 去“反射”函数内部状态。它只反映模块加载完成后的那一份快照，且不包含任何局部作用域内容。
比 globals() 更安全的动态变量访问方式
多数情况下，你要的不是“任意全局变量”，而是“配置项”或“注册的处理器”。这时候硬依赖 globals() 会让代码脆弱且难测试。
推荐组合策略：
- 配置统一收口到
config.py或os.environ.get()，避免散落各处 - 处理器注册用字典显式管理：
HANDLERS = {'csv': csv_handler, 'json': json_handler} - 真要按名调函数，优先走
getattr(module, name)，而非globals()[name]
最常被忽略的一点：globals() 返回的字典可以被修改（比如 globals()['x'] = 999），但这属于危险操作，会破坏可读性和调试体验，生产代码里基本没有正当理由这么做。
