最稳妥获取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.pyprint(__file__)# 示例输出：script.py 或 ./script.py 或 /path/to/script.py
获取脚本的绝对路径：
os.path.abspath(__file__)
为了确保拿到的是一个完整的、不依赖当前工作目录的路径，通常我们会用
os.path.abspath()
来处理
__file__
。
import osscript_absolute_path = os.path.abspath(__file__)print(script_absolute_path)# 示例输出：/home/user/my_project/script.py
获取脚本所在的目录：
os.path.dirname(os.path.abspath(__file__))
这可能是我们最常需要的场景——知道脚本所在的文件夹在哪里。
import osscript_directory = os.path.dirname(os.path.abspath(__file__))print(script_directory)# 示例输出：/home/user/my_project
考虑符号链接（软链接）：
os.path.realpath(__file__)
如果你的脚本是通过符号链接运行的，
__file__
会指向那个链接本身。如果你想获取链接指向的真实文件路径，就需要用到
os.path.realpath()
。
import osreal_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 sysimport osscript_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__
真的靠谱吗？它在不同场景下会有哪些“小脾气”？
说实话，
__file__
这玩意儿虽然好用，但它也有自己的“脾气”，一不小心就可能给你个相对路径，让你找不着北。我刚开始学Python那会儿，觉得它简直是万能的，后来才发现它在不同运行环境下的表现确实有点微妙。
相对路径与绝对路径的纠葛：当你直接在脚本所在目录执行
python script.py
时，
__file__
通常会返回
script.py
，这是个相对路径。但如果你在其他目录执行
python /path/to/script.py
，它就会返回一个绝对路径。这种不确定性，就要求我们总是用
os.path.abspath()
去“扶正”它。交互式环境的困扰：如果你在Python交互式解释器里直接敲代码，或者在Jupyter Notebook里运行，
__file__
可能根本就不存在，或者返回
这样的特殊值。这时候你想获取当前“文件”的路径，基本上是没戏的，因为它压根就没有一个对应的磁盘文件。作为模块运行时的表现：当你用
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 osimport 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_directoryif __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 osimport sysdef 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
来定位可执行文件本身的目录。未打包时，它就回退到我们之前讨论的常规方法。这样一来，无论你的代码是作为普通脚本运行，还是被打包成了独立程序，都能相对准确地找到它所需的“家”或资源所在的位置。这在发布桌面应用时，是不可或缺的技巧。
以上就是python怎么获取当前脚本的路径_python获取脚本路径的几种方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1372169.html
微信扫一扫 
支付宝扫一扫 
