根本原因是Python仅在sys.path列出的路径中按序查找模块，而非当前文件所在目录；需确认工作目录与模块路径一致，避免依赖IDE自动添加路径，合理使用pathlib动态计算路径而非硬编码。
为什么 import module 有时报 ModuleNotFoundError
根本原因不是模块没装，而是 Python 根本没在它搜的路径里找到那个文件。Python 只查 sys.path 列表里的目录，顺序从左到右，找到第一个就停——哪怕你本地有同名文件在别处，它也看不见。
常见错误现象：ModuleNotFoundError: No module named 'utils'，但你明明写了 utils.py 在当前目录；或者用 IDE 跑通了，命令行一跑就错。
- 确认当前工作目录（
os.getcwd()）是否和模块所在目录一致，import默认只认当前目录和sys.path里的路径 - 不要依赖 IDE 自动加的路径（比如 PyCharm 的 “Add content root”），命令行运行时这些路径不存在
-
__init__.py不是必须的（Python 3.3+ 支持隐式命名空间包），但缺了它，子目录不会被当包处理，from pkg import mod会失败
from x import y 和 import x 的行为差异在哪
表面看只是写法不同，实际影响变量绑定时机、重载行为和命名空间污染程度。
使用场景：写脚本快速验证时用 from math import sqrt 图省事；写库或长期维护项目时优先用 import math，避免名字冲突和调试困难。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
from module import func是把func的当前对象引用直接塞进当前命名空间，后续module.func = new_func不会影响已导入的func -
import module是引入模块对象本身，每次调用都走属性查找，能反映运行时变更（比如热重载调试） - 大量用
from xxx import *会掩盖真实来源，IDE 跳转失效，静态检查（如 mypy）也容易误判
想导入上层目录或隔壁文件夹的模块，该用 sys.path.append 还是 pathlib.Path(__file__).parent
sys.path.append 简单粗暴，但副作用强：它改的是全局搜索路径，可能污染其他模块导入，且路径硬编码后一挪位置就崩。更稳的方式是用相对路径动态算。
参数差异：硬写 ../src 容易出错（层级多时 ../.. 写错一个点就完蛋），而 pathlib.Path(__file__).parent.parent / "src" 是基于当前文件位置算的，可读性高、容错好。
- 绝对路径优先于相对路径：先用
Path(__file__).resolve().parent拿到脚本真实位置，再向上/向侧拼，避免软链接或工作目录干扰 - 加路径前先
str()转字符串再塞进sys.path，否则 Python 3.9+ 会报TypeError - 如果只是临时测试，加完记得
del sys.path[0]或用contextlib.redirect_stdout类似思路隔离，别让路径污染扩散
打包成 .pyz 或用 zipimport 时，__file__ 和相对导入还靠谱吗
不靠谱。__file__ 在 zip 包里指向的是类似 /path/to/app.pyz/module.py 的伪路径，pathlib.Path(__file__).parent 会返回 app.pyz 这个文件本身，不再是目录——再用它拼路径就会出错。
性能影响：zip 包里所有模块都在内存解压后加载，首次导入略慢，但整体 I/O 更少；兼容性上，只要没用 os.listdir 或硬读文件，纯 import 一般没问题。
- 别在 zip 包里依赖
__file__算路径，改用importlib.resources.files("pkg").joinpath("data.json")（Python 3.9+） - 老版本用
pkgutil.get_data("pkg", "data.json")，它内部适配了 zipimporter - 相对导入（
from .. import mod）在 zip 包里照常工作，前提是包结构完整、__init__.py存在（即使为空）
