sys.modules 是 import 机制的缓存字典，非模块列表；键为模块名，值为已初始化模块对象，但存在不等于可用，可能残留半初始化或失效模块。
sys.modules 是模块加载器的缓存字典，不是“模块列表”
很多人误以为 sys.modules 是 Python 当前“已导入模块的清单”，其实它只是 import 机制内部用的缓存映射：键是模块名（如 'json'），值是已成功初始化的模块对象。模块没进 sys.modules，就等于没被真正导入过；但进了也不代表你“能用”——比如被删了 __dict__ 或清空了属性，它还在缓存里，只是内容无效。
常见错误现象：ImportError: cannot import name 'xxx' from partially initialized module，往往是因为循环导入时，模块刚塞进 sys.modules 就被其他代码提前引用，但还没执行完顶层代码。
- 模块首次
import时，Python 先查sys.modules，命中则直接返回，跳过查找和执行 - 模块执行失败（抛异常）时，Python 通常会把它从
sys.modules中移除——但except里手动塞进去、或__import__异常后未清理，就会留下“半残模块” -
sys.modules不包含子模块别名，比如import pkg.sub as s，缓存里存的是'pkg.sub'，不是's'
手动修改 sys.modules 的典型场景和风险
真要用到改 sys.modules，基本就两类：热重载调试、或绕过 import 系统做模块注入（比如插件系统）。但绝大多数情况，这是在替 Python 解释器“擦屁股”，而不是正经设计手段。
使用场景举例：你想 reload 一个模块，但 importlib.reload() 失败，因为依赖链里有 C 扩展或被其他模块强引用——有人会 try 清掉 sys.modules['xxx'] 再重新 import。这看似有效，实则危险。
立即学习“Python免费学习笔记（深入）”；
- 删掉
sys.modules['xxx']后再import xxx，会触发完整重加载，但所有已存在的该模块对象（比如类实例、函数闭包引用）仍指向旧模块，容易引发静默错乱 - 如果模块里用了
atexit、threading.local或注册了 signal handler，重载不会自动清理这些副作用 - 某些打包工具（如 PyInstaller）会预填充
sys.modules，手动删可能破坏运行时环境
判断模块是否“真正可用”，别只看 sys.modules 有没有
'mymodule' in sys.modules 只说明它被 import 过一次，不说明它现在能用。尤其在测试或动态加载场景下，这个检查非常误导人。
常见错误现象：单元测试里 patch 某个模块后，断言 'mymodule' in sys.modules 为 True，结果后续调用却报 AttributeError——因为 patch 把模块对象替换了，但名字还在缓存里。
- 更可靠的检查是：
hasattr(sys.modules.get('mymodule'), 'some_function')，或者直接尝试访问关键属性（加try/except） - 想确认模块是否“干净重载”，得比对
id(sys.modules['mymodule'])和上次的值，而不是只查存在性 - 注意相对导入：包内
from . import utils注入的是'mypackage.utils'，不是'utils'，查错 key 会导致误判
sys.modules 和 importlib.util.find_spec 的关系容易混淆
importlib.util.find_spec('xxx') 查的是“能不能找到并加载”，而 sys.modules.get('xxx') 查的是“之前有没有成功加载过”。两者完全不互斥：spec 可能返回 None（找不到路径），但 sys.modules 里还有残留；反之，spec 找到了，但模块因语法错误卡在初始化，也不会进 sys.modules。
- 开发 loader 或自定义 import hook 时，必须同时处理 spec 查找 +
sys.modules缓存逻辑，漏掉任一环节都会导致 import 行为不一致 -
find_spec不触发实际加载，所以不会写入sys.modules；只有importlib._bootstrap._load_backward_compatible（或等价流程）才会最终把模块对象塞进去 - 在 frozen 模块（如 PyInstaller 打包后）中，
find_spec可能返回非 None，但模块对象是硬编码进解释器的，sys.modules里对应项可能是占位符
最麻烦的点在于：模块缓存行为跨 Python 版本有细微差异，比如 3.12 对部分内置模块的缓存时机做了调整，而 sys.modules 本身又允许任意写入——这意味着靠它做状态判断的代码，极易在升级后出现边缘 case 失效。
