sys.path.append() 将路径加到末尾，仅作后备查找；sys.path.insert(0, ...) 插入开头，优先加载且可覆盖同名模块，但易引发标准库冲突；推荐用 Path 构造相对路径并验证实际加载文件。
sys.path.append() 是往末尾加，不改变已有优先级
它只是把新路径塞进 sys.path 列表的最后位置，Python 查找模块时会按顺序扫描，所以这个路径只有在前面所有路径都找不到目标模块时才起作用。
常见错误现象：import mymodule 依然报 ModuleNotFoundError，但你明明用 sys.path.append('/path/to/mymodule') 加了路径——大概率是因为该路径下没有符合 Python 模块命名规则的 mymodule.py 或 mymodule/__init__.py，或者路径本身拼写错误（比如漏了 /、用了反斜杠 \ 而没转义）。
-
sys.path.append('..')表示加当前文件上一级目录，适用于从兄弟目录导入；但若脚本是通过python -m启动，__file__可能不可靠，此时..指向的是执行时的工作目录上一级，而非源文件所在目录 - 绝对路径更稳，比如
sys.path.append('/home/user/project/utils')，但硬编码路径不利于协作和部署 - 该操作只在当前 Python 进程生命周期内有效，退出即失效
sys.path.insert(0, ...) 才真正控制“先找谁”
sys.path.insert(0, path) 把路径插到列表最前面，意味着它会成为模块查找的第一站。只要这个路径里有匹配的模块，后面的路径就完全不会被检查。
使用场景：你想强制让本地开发版模块覆盖已安装的同名包（比如调试中修改了 requests 的某个本地副本），或者项目结构复杂、需优先加载某子目录下的模块。
立即学习“Python免费学习笔记（深入）”；
- 序号必须是
0才能确保最高优先级；写成sys.path.insert(1, path)可能被sys.path[0]（通常是空字符串或当前工作目录）拦截，实际效果打折扣 - 推荐写法：
sys.path.insert(0, str(Path(__file__).parent / "lib"))，用Path构造相对路径，避免手动拼接../的歧义 - 注意：如果插入的路径下存在与标准库同名的模块（如
json.py），会直接屏蔽标准库，引发难以排查的兼容问题
为什么 print(sys.path) 看起来顺序对，但 import 还是错？
因为 Python 导入时不是“找所有匹配”，而是“找到第一个就停”。即使 sys.path 里有多个含 mymodule 的路径，也只加载排最前那个里的版本。
实操建议：在出问题的脚本开头立刻加这两行：
import sys<br>print('\n'.join(sys.path))
再补一句：
import mymodule<br>print(mymodule.__file__)
后者能直接告诉你 Python 实际加载的是哪个文件——这才是真相，比猜路径靠谱得多。
- 当前工作目录（
os.getcwd()）默认就是sys.path[0]，哪怕你没显式添加，它也在那儿；很多“莫名能 import”的情况其实就靠它撑着 - 虚拟环境未真正激活时，
sys.path前几项可能还是系统 Python 的路径，导致 pip 安装的包根本没被看到 -
PYTHONPATH环境变量只在 Python 启动时读取一次，改了之后不重启解释器进程，不会生效
真正该用哪个？看你要解决什么问题
想临时加个后备路径，且不干扰现有逻辑 → 用 sys.path.append()；想绕过默认行为、明确指定“必须从这里开始找” → 用 sys.path.insert(0, ...)。
但最容易被忽略的一点是：这两种方式都只是运行时补丁。它们掩盖了项目结构或依赖管理的问题。比如频繁靠 insert(0, ..) 才能 import，往往说明包没正确安装（pip install -e .）、__init__.py 缺失、或目录层级设计反直觉。真正的稳定解，是让模块路径天然符合 Python 查找规则，而不是靠代码去修路径顺序。
