最稳妥获取Python脚本路径的方法是结合os.path.realpath(__file__)、os.path.abspath()和os.path.dirname()，并针对打包环境使用sys._MEIPASS或sys.executable。首先通过realpath解析符号链接，再用abspath确保路径绝对，最后用dirname提取目录；若程序被PyInstaller等工具打包，则利用sys.frozen判断，并优先使用sys._MEIPASS定位临时资源目录，否则回退到常规方法，确保在各种运行环境下都能准确获取脚本或可执行文件所在目录，适用于加载配置、资源文件等场景。
在Python开发中，我们经常需要知道当前脚本文件到底躺在哪个目录里。这事儿听起来挺基础的，但实际操作起来，尤其是考虑到各种运行环境，里面还是有些小门道的。简单来说，Python提供了几种方式来摸清脚本的“老家”，最常用的就是利用它自带的一些特殊变量和模块功能，帮你定位到脚本在文件系统中的位置，这对于加载配置文件、图片或者其他同目录资源来说，简直是刚需。
解决方案
要获取当前Python脚本的路径，我们可以主要依赖
__file__这个内置变量，并结合
os模块的一些函数来处理。
-
最直接的方式：
__file__
这个特殊变量会给你当前执行脚本的文件名（可能包含相对路径）。# script.py print(__file__) # 示例输出：script.py 或 ./script.py 或 /path/to/script.py
-
获取脚本的绝对路径：
os.path.abspath(__file__)
为了确保拿到的是一个完整的、不依赖当前工作目录的路径，通常我们会用os.path.abspath()
来处理__file__
。import os script_absolute_path = os.path.abspath(__file__) print(script_absolute_path) # 示例输出：/home/user/my_project/script.py
-
获取脚本所在的目录：
os.path.dirname(os.path.abspath(__file__))
这可能是我们最常需要的场景——知道脚本所在的文件夹在哪里。import os script_directory = os.path.dirname(os.path.abspath(__file__)) print(script_directory) # 示例输出：/home/user/my_project
-
考虑符号链接（软链接）：
os.path.realpath(__file__)
如果你的脚本是通过符号链接运行的，__file__
会指向那个链接本身。如果你想获取链接指向的真实文件路径，就需要用到os.path.realpath()
。import os real_script_path = os.path.realpath(__file__) print(real_script_path) # 如果 script.py 是 link_to_script.py 的软链接，且运行的是 link_to_script.py # __file__ 可能是 link_to_script.py # os.path.realpath(__file__) 会是 /path/to/original/script.py
-
通过
sys.argv[0]
sys.argv
是一个列表，包含了命令行参数。sys.argv[0]
通常是执行脚本的名称。它和__file__
类似，也可能是一个相对路径。import sys import os script_name_from_argv = sys.argv[0] print(script_name_from_argv) # 获取其绝对路径和目录 argv_absolute_path = os.path.abspath(sys.argv[0]) argv_directory = os.path.dirname(argv_absolute_path) print(argv_absolute_path) print(argv_directory)
不过，我个人觉得，在获取脚本自身路径这事儿上，
__file__
通常比sys.argv[0]
更可靠，因为它直接指向当前模块文件，而sys.argv[0]
在某些情况下（比如作为模块运行）可能行为不一致。立即学习“Python免费学习笔记（深入）”；
__file__
真的靠谱吗？它在不同场景下会有哪些“小脾气”？
说实话，
__file__这玩意儿虽然好用，但它也有自己的“脾气”，一不小心就可能给你个相对路径，让你找不着北。我刚开始学Python那会儿，觉得它简直是万能的，后来才发现它在不同运行环境下的表现确实有点微妙。
-
相对路径与绝对路径的纠葛：当你直接在脚本所在目录执行
python script.py
时，__file__
通常会返回script.py
，这是个相对路径。但如果你在其他目录执行python /path/to/script.py
，它就会返回一个绝对路径。这种不确定性，就要求我们总是用os.path.abspath()
去“扶正”它。 -
交互式环境的困扰：如果你在Python交互式解释器里直接敲代码，或者在Jupyter Notebook里运行，
__file__
可能根本就不存在，或者返回<stdin>
这样的特殊值。这时候你想获取当前“文件”的路径，基本上是没戏的，因为它压根就没有一个对应的磁盘文件。 -
作为模块运行时的表现：当你用
python -m my_package.my_module
这种方式运行一个模块时，__file__
依然会指向my_module.py
这个文件的实际路径，这倒是挺符合预期的。但要注意，此时sys.argv[0]
可能会是my_package/my_module.py
或者干脆就是my_module
，行为上和直接运行脚本略有不同。 -
符号链接（软链接）的陷阱：如果你的脚本文件本身是个符号链接，那么
__file__
会指向这个符号链接的路径，而不是它实际指向的那个文件。这在某些需要定位真实文件位置的场景下，可能会导致误判。这时候，os.path.realpath(__file__)
就显得尤为重要，它能帮你穿透符号链接，找到真正的源头。
总的来说，
__file__多数时候是你的好帮手，但了解它的这些“小脾气”，能让你在处理文件路径时更加游刃有余，避免一些不必要的坑。
想要稳妥地获取脚本所在目录，最“硬核”的姿势是什么？
在实际项目开发中，我个人最推荐、也最常用的获取脚本所在目录的“硬核”姿势是这样的：
import os
import sys
# 这是一个非常健壮的获取当前脚本目录的方法
def get_script_dir():
# 1. 首先，获取 __file__ 的真实路径，以防它是符号链接
# os.path.realpath(__file__) 会解析所有符号链接，直到找到最终的文件
real_path = os.path.realpath(__file__)
# 2. 接着，确保这个路径是绝对路径
# os.path.abspath() 会将相对路径转换为绝对路径
absolute_path = os.path.abspath(real_path)
# 3. 最后，从绝对路径中提取目录部分
# os.path.dirname() 返回路径的目录名
script_directory = os.path.dirname(absolute_path)
return script_directory
if __name__ == "__main__":
current_script_dir = get_script_dir()
print(f"当前脚本的稳妥目录是: {current_script_dir}")
# 举个例子，如果想加载同目录下的 config.json
# config_path = os.path.join(current_script_dir, 'config.json')
# print(f"配置文件路径可能是: {config_path}")这套组合拳，可以说是我个人在项目里最常用、也最推荐的方式了。它能应对绝大多数复杂场景，保证你拿到的路径是准确无误的。
-
os.path.realpath(__file__)
：这一步是关键，它能解决符号链接的问题。如果你的脚本是通过一个软链接运行的，__file__
会给你软链接的路径，而不是实际文件的路径。realpath
会追踪到真实的物理文件路径，这对于很多需要定位资源（比如配置文件、模板文件）的场景非常重要。 -
os.path.abspath(...)
：无论realpath
返回的是相对路径还是绝对路径（通常是绝对路径，但以防万一），abspath
都会确保我们得到一个完整的、不含歧义的绝对路径。 -
os.path.dirname(...)
：最后一步，从这个完整的绝对文件路径中，提取出它所在的目录。
通过这样的层层剥离和处理，我们就能得到一个在各种运行环境下都相对可靠的脚本所在目录。这对于构建可移植性强的Python应用，尤其是在需要加载同目录或相对目录下的资源时，简直是标准操作。
当脚本被打包成可执行文件时，路径获取还能玩得转吗？
这可真是个有意思的挑战！当我们的Python脚本通过PyInstaller、cx_Freeze这类工具打包成独立的可执行文件（exe或二进制文件）时，之前那些获取
__file__路径的方法，它们的行为会变得非常不一样，甚至可能失效。打包后的程序，它的“家”和源代码的“家”就不是一回事了。
__file__在PyInstaller这类工具打包后，往往会指向一个临时的、解压出来的路径，而不是你期望的那个可执行文件所在的目录。
这时候，我们得换个思路。通常，打包工具会提供一些特殊的机制来帮助我们定位资源。
1. 利用sys.executable
和sys._MEIPASS
(针对PyInstaller)
-
sys.executable
：这个变量总是指向当前正在运行的可执行文件的完整路径。所以，获取它的目录，就能知道你的打包程序放在哪里。 -
sys._MEIPASS
：这是PyInstaller特有的一个变量。当PyInstaller打包一个单文件程序时，它会把所有的依赖文件解压到一个临时目录中。sys._MEIPASS
就指向这个临时目录。如果你想访问打包在程序内部的额外资源（比如图片、配置文件），并且这些资源被PyInstaller正确地处理了，那么你就应该通过sys._MEIPASS
来构建路径。
import os
import sys
def get_bundle_dir():
if getattr(sys, 'frozen', False):
# 如果是打包后的程序
# sys.frozen 为 True 表示程序已经被冻结（打包）
# 对于单文件模式 (onefile)，PyInstaller会把所有东西解压到一个临时目录
# sys._MEIPASS 会指向这个临时目录
# 如果你需要访问打包在程序内部的资源，通常会用它
if hasattr(sys, '_MEIPASS'):
return sys._MEIPASS
# 对于单目录模式 (onedir) 或者获取可执行文件本身的目录
# sys.executable 指向可执行文件的路径
return os.path.dirname(sys.executable)
else:
# 如果是未打包的脚本，就用常规方法
return os.path.dirname(os.path.abspath(os.path.realpath(__file__)))
if __name__ == "__main__":
current_app_dir = get_bundle_dir()
print(f"当前应用程序（或脚本）的根目录是: {current_app_dir}")
# 假设你有一个图片文件 'data/image.png' 被打包进去了
# 在打包前，它可能在脚本的同级目录下的 data 文件夹里
# 打包后，如果通过 PyInstaller --add-data 方式添加，它可能在 sys._MEIPASS 下
# resource_path = os.path.join(current_app_dir, 'data', 'image.png')
# print(f"资源文件路径可能是: {resource_path}")这段代码考虑了程序是否被打包的情况。当程序被打包时，它会尝试使用
sys._MEIPASS（如果存在，通常用于单文件模式下的内部资源），否则就用
sys.executable来定位可执行文件本身的目录。未打包时，它就回退到我们之前讨论的常规方法。这样一来，无论你的代码是作为普通脚本运行，还是被打包成了独立程序，都能相对准确地找到它所需的“家”或资源所在的位置。这在发布桌面应用时，是不可或缺的技巧。
