直接用 importlib.util.spec_from_file_location 会报 ModuleNotFoundError 是因为未执行 spec.loader.exec_module()，该步骤才真正执行模块代码；只创建 spec 或 module 对象并不等同于导入成功。
为什么直接用 importlib.util.spec_from_file_location 会报 ModuleNotFoundError
因为没执行 spec.loader.exec_module() —— 这步才是真把代码跑起来。只创建 spec 或 module 对象，不等于导入成功。常见错误是拿到 module 对象后就以为能直接用函数，结果调用时报 NameError。
典型场景：你想从非当前目录、非 PYTHONPATH 的路径动态加载一个工具脚本，比如 /tmp/utils.py，又不想把它硬塞进 sys.path。
- 必须先用
importlib.util.spec_from_file_location创建 spec，其中第二个参数必须是绝对路径（相对路径容易因工作目录变化失效） - 用
importlib.util.module_from_spec创建空模块对象，这步不执行代码 - 必须显式调用
spec.loader.exec_module(module)，否则模块里的函数、类、变量全都没被定义 - 建议给
file_location起个有意义的模块名（如"my_utils"），避免和已存在模块名冲突
importlib.util 加载时如何避免命名空间污染？
动态导入的模块会注册到 sys.modules，如果多次用相同模块名加载不同文件，后续导入会命中缓存，导致旧代码被复用 —— 这是静默陷阱。
比如你两次调用同一段加载逻辑，第二次其实没 reload，还是第一次的代码。
立即学习“Python免费学习笔记（深入）”；
- 每次加载前手动从
sys.modules中删掉对应模块名：sys.modules.pop("my_utils", None) - 模块名别硬写死，可结合文件路径哈希生成唯一名，例如
f"dynamic_{hashlib.md5(path.encode()).hexdigest()[:8]}" - 如果只是临时用一次函数，加载完立即删掉
sys.modules条目，防止干扰后续正常 import - 注意：
del sys.modules["xxx"]不等于卸载，只是移除缓存，不影响已引用的对象
加载含相对导入或依赖的 .py 文件会失败吗？
会。因为 importlib.util.module_from_spec 创建的模块没有 __package__ 和 __name__ 上下文，相对导入（如 from .helper import foo）直接抛 SystemError: Parent module not loaded。
这不是 bug，是设计使然 —— 动态加载的模块默认被视为顶层脚本（__name__ == "__main__"），没有包层级概念。
- 最稳做法：改用绝对导入，把依赖也用同样方式动态加载，并手动设置
module.__package__和module.__path__ - 简单绕过：把目标文件改成纯函数/类集合，不写任何
from .xxx import yyy - 若必须保留相对导入，考虑用
runpy.run_path(path)替代，它模拟脚本执行环境，但无法返回模块对象，只能获取全局变量字典
Windows 下路径传参为什么总提示 FileNotFoundError？
不是路径错，是反斜杠没转义或没标准化。Python 的 importlib.util.spec_from_file_location 内部用 os.path.isfile 检查，而 "C:\utils\tool.py" 中的 \u 被当作了 Unicode 转义序列。
- 永远用原始字符串：
r"C:\utils\tool.py"或正斜杠："C:/utils/tool.py" - 更可靠：用
pathlib.Path.resolve()获取绝对路径：Path("/tmp/tool.py").resolve().as_posix() - 检查路径是否存在且可读：
os.access(path, os.R_OK)，避免权限问题被误判为路径不存在 - 注意：即使路径正确，某些 IDE 或沙箱环境（如 VS Code Remote-SSH）可能限制对非项目目录的文件访问
sys.path，没设 __package__，也没进 sys.modules 缓存 —— 它像个临时工，用完得自己收尾，漏一步就埋雷。 
