os.getcwd() 返回进程启动目录而非脚本目录，__file__ 才是脚本绝对路径；应统一基准：资源随代码用 __file__，随用户操作用 getcwd()。
os.getcwd() 返回的是进程启动时的工作目录，不是脚本所在目录
很多人以为 os.getcwd() 就是当前 Python 文件的位置，结果一打包或换路径运行就出错。它其实和终端里你敲 python script.py 时所在的目录强绑定——哪怕脚本放在 /home/user/proj/，你在 /tmp 下执行，os.getcwd() 就是 /tmp。
常见错误现象：
– 用 open("config.json") 报 FileNotFoundError，但文件明明和脚本放一起
– 打包成 exe 后找不到同级资源文件
– CI 环境中路径行为和本地不一致
- 适用场景：需要读取“用户当前操作位置”的文件（比如命令行工具接受相对路径参数）
- 不适用场景：加载与脚本强耦合的配置、模板、数据文件
- 性能/兼容性：无开销，所有平台行为一致，但语义容易误用
__file__ 给出的是当前 .py 文件的绝对路径（含文件名）
__file__ 是 Python 解释器自动注入的变量，值为当前模块的物理路径。它不受启动位置影响，稳定可靠，是定位脚本“老家”的唯一靠谱依据。
注意：它带文件名，不是目录；且在交互式环境（如 IPython、Jupyter）中可能不存在或为 <stdin>，不能无条件使用。
立即学习“Python免费学习笔记（深入）”；
- 获取脚本所在目录的标准写法：
os.path.dirname(os.path.abspath(__file__)) - Python 3.4+ 更推荐：
pathlib.Path(__file__).parent - 如果脚本被 zipimport 或 frozen（如 PyInstaller），
__file__可能指向临时解压路径，需配合getattr(sys, '_MEIPASS', None)判断
os.getcwd() 和 __file__ 混用时的典型坑
最危险的操作是把两者混着拼路径，比如：os.path.join(os.getcwd(), os.path.dirname(__file__), "data.txt")——这会把两个不同基准的路径强行拼接，结果不可预测。
常见错误现象：
– 路径变成类似 /tmp/home/user/proj/data.txt 这种嵌套结构
– 在 Windows 上出现 C:\tmp\X:\proj\... 这类非法路径
– os.path.exists() 返回 False，但手动检查路径又确实存在
- 原则：同一段逻辑里只选一个基准——要么全用
os.getcwd()（面向用户工作区），要么全用__file__（面向代码自身） - 跨模块调用时，
__file__是模块局部的，别在 A.py 里用__file__去找 B.py 的资源 - 写工具函数时，显式接收
base_dir参数比偷偷猜路径更安全
实际项目中怎么选：看资源归属关系
判断依据很简单：这个文件是“跟着代码走”，还是“跟着用户走”？
- 配置文件、模板、schema.json、static/ 目录 → 属于代码，用
pathlib.Path(__file__).parent / "config.yaml" - 用户上传的 CSV、日志输出目录、临时缓存 → 属于运行期上下文，用
os.getcwd()或显式传参 - 想兼顾两者？比如默认从脚本目录找 config，找不到再 fallback 到当前目录：
paths = [Path(__file__).parent / "config.toml", Path.cwd() / "config.toml"]
路径逻辑一旦复杂起来，pathlib 比 os.path 更少出错，也更容易链式写清楚意图。但别为了“现代”硬改老项目——只要路径基准统一，os.path 同样稳。
