答案：获取Python脚本路径最可靠的方法是使用pathlib.Path(__file__).resolve()。该方法能正确解析符号链接并返回脚本的绝对路径，通过.parent属性可获取脚本所在目录，适用于处理配置文件、资源文件等与脚本同级的文件，且具有跨平台兼容性，优于传统的os.path.dirname(os.path.abspath(__file__))方式。
在Python中，要获取当前脚本的路径，最直接也最常用的方式是利用内置的
__file__
变量。通过结合
os
模块中的
os.path.abspath()
和
os.path.dirname()
，我们能精确地定位到脚本文件本身及其所在的目录。然而，这其中也有些细微的差异和“陷阱”，尤其是在脚本被导入、通过软链接执行或被打包成可执行文件时，需要我们更深入地理解。
解决方案
要获取当前Python脚本的完整路径及其所在目录，我们通常会用到以下几种方法，每种都有其适用场景和需要注意的地方。
1. 获取脚本文件的完整路径 (绝对路径)
这是最常见也最稳妥的方式，它能提供当前执行脚本的绝对路径，无论你在哪个目录下运行它。
立即学习“Python免费学习笔记（深入）”；
import os# 获取当前脚本的绝对路径script_full_path = os.path.abspath(__file__)print(f"脚本的完整路径: {script_full_path}")# 输出示例: /Users/youruser/projects/my_script.py
这里的
__file__
是一个内置变量，它代表了当前模块的文件名（包括路径）。但需要注意的是，
__file__
本身可能是一个相对路径，所以用
os.path.abspath()
将其转换为绝对路径是最佳实践。
2. 获取脚本文件所在的目录路径
一旦有了脚本的完整路径，获取其所在目录就非常简单了。
import os# 获取当前脚本的绝对路径script_full_path = os.path.abspath(__file__)# 获取脚本所在的目录路径script_dir = os.path.dirname(script_full_path)print(f"脚本所在的目录: {script_dir}")# 输出示例: /Users/youruser/projects/
这几乎是处理脚本内部资源（如配置文件、数据文件）时最常用的方式。通过这种方式，你可以确保无论脚本在哪里被调用，都能正确地找到与它相对位置的资源。
3. 使用
pathlib
模块 (更现代、更推荐)
从Python 3.4开始，
pathlib
模块提供了面向对象的路径操作方式，我个人觉得它比
os.path
更加直观和优雅。
from pathlib import Path# 获取当前脚本文件的Path对象script_path_obj = Path(__file__)# 将其解析为绝对路径，并处理符号链接resolved_script_path = script_path_obj.resolve()print(f"Pathlib解析后的脚本路径: {resolved_script_path}")# 获取脚本所在的父目录script_parent_dir = resolved_script_path.parentprint(f"Pathlib获取的脚本所在目录: {script_parent_dir}")# 输出示例:# Pathlib解析后的脚本路径: /Users/youruser/projects/my_script.py# Pathlib获取的脚本所在目录: /Users/youruser/projects
Path(__file__).resolve().parent
是
pathlib
中获取脚本所在目录的推荐方式，它不仅获取了绝对路径，
resolve()
方法还能处理符号链接，确保你得到的是真实文件的路径，而不是链接的路径。
4. 获取当前工作目录 (Current Working Directory, CWD)
这个和脚本路径是两个不同的概念，但经常被混淆。当前工作目录是你执行Python脚本时所在的目录。
import oscurrent_working_directory = os.getcwd()print(f"当前工作目录: {current_working_directory}")# 示例: 如果你在 /home/user/ 目录下运行 /opt/scripts/my_script.py# 那么 os.getcwd() 会返回 /home/user/# 而 os.path.dirname(os.path.abspath(__file__)) 会返回 /opt/scripts/
理解这两者的区别至关重要。
os.getcwd()
反映的是程序“当前看”的目录，而
os.path.dirname(os.path.abspath(__file__))
则反映的是脚本文件“实际躺”的目录。
为什么
__file__
__file__
有时会“骗人”？理解它的局限性
__file__
变量在Python中确实是一个非常方便的工具，但它并非总是那么“老实”。在我看来，理解它的工作原理和局限性，比单纯记住用法更重要。
1. 当脚本被直接执行时：这是最理想的情况。如果你直接运行
python my_script.py
，那么
__file__
通常会包含
my_script.py
的相对或绝对路径。
os.path.abspath(__file__)
会将其解析为完整的绝对路径。
2. 当脚本作为模块被导入时：如果你的脚本（比如
my_module.py
）被另一个脚本（比如
main.py
）导入，那么在
my_module.py
内部的
__file__
仍然会指向
my_module.py
的路径。这是符合预期的，因为我们通常希望模块能找到它自己的资源。
3. 符号链接 (Symbolic Links)：这是一个常见的“陷阱”。如果你通过一个符号链接来执行脚本，
__file__
可能会返回符号链接本身的路径，而不是它指向的真实文件的路径。这在某些场景下可能会导致问题，比如你需要访问与真实文件位于同一目录下的其他资源时。解决这个问题，
os.path.realpath(__file__)
或者
pathlib.Path(__file__).resolve()
就派上用场了。它们会追踪符号链接，返回真实文件的路径。
import osfrom pathlib import Path# 假设 script.py 是一个指向 real_script.py 的软链接# 当通过 script.py 执行时：# print(__file__) 可能输出 /path/to/script.py (软链接的路径)# print(os.path.abspath(__file__)) 仍然是 /path/to/script.pyprint(f"原始 __file__: {__file__}")print(f"os.path.realpath(__file__): {os.path.realpath(__file__)}")print(f"Path(__file__).resolve(): {Path(__file__).resolve()}")# 预期输出 (如果 __file__ 是软链接):# 原始 __file__: /path/to/link_script.py# os.path.realpath(__file__): /path/to/real_script.py# Path(__file__).resolve(): /path/to/real_script.py
4. 脚本被打包成可执行文件 (如PyInstaller)：当Python脚本被PyInstaller等工具打包成单个可执行文件时，
__file__
的行为会变得非常特殊。在打包后的环境中，
__file__
可能指向一个临时文件路径，甚至是一个虚拟路径。在这种情况下，你通常需要依赖
sys.executable
（可执行文件的路径）或PyInstaller提供的特殊变量
sys._MEIPASS
（临时解压目录）来定位资源。这是一个更高级的话题，但了解它的存在很重要。
5. 交互式环境或IDE中执行代码块：在Python的交互式解释器（如REPL）中，
__file__
可能不存在或被设置为
。在某些IDE中，运行选定的代码块时，
__file__
也可能无法提供预期的文件路径。因此，这些方法主要适用于作为独立脚本或模块运行的代码。
总而言之，
__file__
是一个起点，但为了确保健壮性，我们通常需要结合
os.path
或
pathlib
进行进一步的处理，特别是要考虑到符号链接和打包应用这些特殊场景。
os.getcwd()
os.getcwd()
和
os.path.dirname(__file__)
，到底选哪个？
这真的是一个非常经典的疑惑，我刚开始写Python程序的时候也经常纠结。在我看来，这两个方法并没有绝对的优劣，它们只是为了解决不同的问题而生。选择哪个，完全取决于你的程序想要“感知”到什么。
os.getcwd()
：关注程序的“当前视点”
os.getcwd()
获取的是“当前工作目录”（Current Working Directory），也就是你执行Python脚本时，Shell（或者说操作系统）所处的目录。
何时使用：当你希望程序能够根据用户从哪个目录启动它，来查找或保存文件时。当你的程序需要处理用户提供的相对路径时，这些相对路径通常是相对于CWD的。当你编写一个命令行工具，希望它的行为与用户在终端中的位置相关联时。举例：一个图片处理工具，用户在
/home/user/photos
目录下运行它，并输入
process image.jpg
。那么
image.jpg
就应该在
/home/user/photos
中查找。一个日志记录器，你希望日志文件默认保存在用户启动程序的目录下。
os.path.dirname(os.path.abspath(__file__))
：关注脚本的“物理位置”
这个表达式获取的是当前Python脚本文件本身所在的目录。它与你从哪个目录启动脚本无关。
何时使用：当你需要访问与脚本文件一同部署的资源时，比如配置文件、模板文件、数据文件等。当你的程序需要定位它自己的“家”在哪里，以便找到它自己的“行李”（其他依赖文件）时。当你在开发一个模块或库，希望它能独立于被调用的位置，总是能找到自己的内部资源时。举例：一个Web应用，其
settings.py
文件和
templates
目录都在应用的主目录里。无论你从哪个目录启动Web服务器，应用都应该能找到这些资源。一个数据分析脚本，它依赖于一个存储在脚本同目录下的
data.csv
文件。
核心区别与选择原则：
os.getcwd()
是动态的：它会随着你启动脚本的目录而改变。
os.path.dirname(os.path.abspath(__file__))
是静态的：它永远指向脚本文件所在的目录。
我个人的经验是，如果你的程序需要加载它自己的内部资源，那么几乎总是应该使用
os.path.dirname(os.path.abspath(__file__))
（或
pathlib
的等价物）。因为这样可以保证程序的健壮性，无论用户在哪个目录下运行你的程序，它都能找到自己的“行李”。
而
os.getcwd()
则更多用于与用户交互的场景，比如处理用户输入的相对路径，或者在用户指定的位置创建输出文件。
混淆这两者是新手常犯的错误，可能导致文件找不到或者文件创建在错误的位置。所以，在写代码之前，先问问自己：“我需要知道的是用户在哪儿启动了我的程序，还是我的程序文件本身在哪儿？”答案会指引你选择正确的方法。
拥抱
pathlib
pathlib
：更优雅、更现代的路径操作方式
说实话，在我最初接触Python的时候，
os.path
模块确实帮了大忙，但它的字符串拼接和各种函数调用总让我觉得有些笨拙。直到
pathlib
模块的出现，我才真正感受到了Python在路径操作上的优雅和现代化。它将路径视为对象，让操作变得直观且链式化，大大提升了代码的可读性和可维护性。
为什么
pathlib
更胜一筹？
面向对象： 路径不再是简单的字符串，而是
Path
对象。你可以直接对这些对象调用方法，而不是通过
os.path
的各种函数来处理字符串。更清晰的语义：
parent
、
name
、
suffix
、
stem
等属性让路径的各个组成部分一目了然。链式操作： 很多操作可以像链条一样连接起来，代码更简洁。平台无关性：
pathlib
在底层会自动处理不同操作系统（Windows、Linux、macOS）的路径分隔符和约定，你无需担心
和
/
的问题。内置文件系统操作： 不仅仅是路径拼接，
pathlib
还提供了创建目录、读写文件、检查文件是否存在等功能，很多时候可以替代
os
模块的一部分功能。
如何用
pathlib
获取脚本路径？
之前我们提到了
Path(__file__).resolve().parent
，这是获取脚本所在目录的推荐方式。
from pathlib import Path# 获取当前脚本的Path对象current_script_path = Path(__file__)print(f"原始 Path 对象: {current_script_path}")# .resolve() 处理符号链接，并确保是绝对路径resolved_path = current_script_path.resolve()print(f"解析后的绝对路径: {resolved_path}")# .parent 获取父目录script_directory = resolved_path.parentprint(f"脚本所在目录: {script_directory}")# 获取脚本文件名script_name = resolved_path.nameprint(f"脚本文件名: {script_name}")# 获取文件扩展名script_suffix = resolved_path.suffixprint(f"文件扩展名: {script_suffix}")# 获取不带扩展名的文件名script_stem = resolved_path.stemprint(f"不带扩展名的文件名: {script_stem}")
pathlib
的常见操作示例：
from pathlib import Path# 获取脚本所在目录base_dir = Path(__file__).resolve().parent# 拼接路径 (使用 / 运算符，非常直观)config_file_path = base_dir / "config" / "settings.ini"print(f"配置文件路径: {config_file_path}")# 检查文件或目录是否存在if config_file_path.exists(): print("配置文件存在！")else: print("配置文件不存在。")# 检查是否是文件if config_file_path.is_file(): print("它是一个文件。")# 检查是否是目录if base_dir.is_dir(): print("脚本所在目录是一个目录。")# 创建目录 (如果不存在)new_data_dir = base_dir / "data"new_data_dir.mkdir(exist_ok=True) # exist_ok=True 避免目录已存在时报错print(f"创建了数据目录: {new_data_dir}")# 读写文件 (更简洁)# new_data_dir.joinpath("output.txt").write_text("Hello from pathlib!")# content = new_data_dir.joinpath("output.txt").read_text()# print(f"文件内容: {content}")
在我看来，
pathlib
不仅让代码看起来更“Pythonic”，更重要的是它减少了犯错的机会。你不再需要担心路径分隔符的问题，也不需要记住
os.path.join
的各种用法，直接用
/
操作符就能完成路径拼接，这种体验是
os.path
无法比拟的。如果你的项目还在使用
os.path
进行大量的路径操作，我强烈建议你考虑迁移到
pathlib
，它会让你爱上文件系统操作。
处理复杂场景：打包应用与跨平台兼容性
在实际开发中，尤其当你的Python应用需要分发给其他人使用时，路径获取的问题会变得更加复杂。打包应用（比如使用PyInstaller）和确保跨平台兼容性是两个需要重点考虑的方面。
1. 打包应用 (如PyInstaller)：
当你的Python脚本被PyInstaller这类工具打包成一个独立的可执行文件时，
__file__
变量的行为会发生显著变化。在打包后的环境中，
__file__
通常不再指向原始的
.py
文件，而是指向PyInstaller在运行时创建的一个临时文件或虚拟路径。这意味着，如果你依然依赖
os.path.dirname(os.path.abspath(__file__))
来查找与原始脚本相对的资源，很可能会失败。
解决方案：
sys.executable
： 这是最通用的方法，它返回的是当前运行的可执行文件的完整路径。对于打包应用，这就是你分发出去的那个
.exe
或二进制文件。你可以通过
os.path.dirname(sys.executable)
来获取可执行文件所在的目录。然后，你可以将你的资源（如配置文件、图片等）放置在这个目录下，并通过相对路径访问。
import sysimport osif getattr(sys, 'frozen', False): # 应用程序已打包 application_path = os.path.dirname(sys.executable)else: # 应用程序未打包 (在开发环境中) application_path = os.path.dirname(os.path.abspath(__file__))print(f"应用根目录: {application_path}")# 假设你的配置文件在应用根目录下的 'config' 文件夹里config_dir = os.path.join(application_path, 'config')
sys._MEIPASS
(PyInstaller特有)： PyInstaller在运行时会把所有打包的资源（包括Python文件、数据文件等）解压到一个临时目录。
sys._MEIPASS
就是这个临时目录的路径。这个变量只在PyInstaller打包的应用中存在。如果你有很多数据文件需要与程序一起分发，并希望它们在运行时能被程序找到，那么
sys._MEIPASS
非常有用。
import sysimport osif getattr(sys, 'frozen', False) and hasattr(sys, '_MEIPASS'): # PyInstaller 打包的应用 resource_base_path = sys._MEIPASSelse: # 开发环境 resource_base_path = os.path.dirname(os.path.abspath(__file__))print(f"资源基路径: {resource_base_path}")# 假设你的图片文件在资源基路径下的 'images' 文件夹里image_path = os.path.join(resource_base_path, 'images', 'icon.png')
需要注意的是，
sys._MEIPASS
是PyInstaller的内部实现细节，虽然常用但并非官方标准。
2. 跨平台兼容性：
Python在路径处理上天生就具有很好的跨平台能力，这主要得益于
os.path
和
pathlib
模块。它们会自动处理不同操作系统（Windows、Linux、macOS）的路径分隔符 (
vs.
/
)。
使用
os.path.join()
或
pathlib
的
/
操作符：永远不要手动拼接路径字符串，例如
"/path/" + "to/" + "file"
，因为这在Windows上会出问题。始终使用
os.path.join()
或
pathlib
的
/
操作符。
import osfrom pathlib import Path# 不好的做法 (可能导致跨平台问题)# config_path_bad = script_dir + "/config/settings.ini"# 好的做法 (os.path)config_path_os = os.path.join(script_dir, "config", "settings.ini")print(f"os.path 拼接: {config_path_os}")# 更好的做法 (pathlib)config_path_pathlib = Path(script_dir) / "config" / "settings.ini"print(f"pathlib 拼接: {config_path_pathlib}")
确保路径是绝对路径：在跨平台环境中，相对路径可能会因为CWD的不同而产生意想不到的行为。尽可能地将所有关键路径解析为绝对路径，这样可以避免很多不必要的麻烦。
os.path.abspath()
和
pathlib.Path.resolve()
是你的好帮手。
处理大小写敏感性：Linux和macOS的文件系统通常是大小写敏感的，而Windows则通常不敏感。这意味着
MyFile.txt
和
MyFile.txt
在Linux上是两个不同的文件，但在Windows上可能被视为同一个。在代码中引用文件时，务必确保文件名的大小写与实际文件系统中的完全一致，以保证在所有平台上的可靠性。
在我看来，处理这些复杂场景的关键在于明确你想要定位的是什么：是可执行文件本身？是程序运行时解压的资源包？还是源代码目录下的某个文件？一旦目标明确，结合
sys
模块的变量和
os.path
或
pathlib
的
以上就是python中如何获取脚本的当前路径_Python获取当前文件及目录路径技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1371292.html
微信扫一扫 
支付宝扫一扫 
