如果安装了多个版本的Python， /usr/bin/env将确保使用的解释器是环境$PATH中的第一个解释器。另一种方法是硬编码类似#!/usr/bin/python;这是可以的，但是不太灵活。

在Unix中，要解释的可执行文件可以通过#!在第一行的开头，后面跟着解释器(以及它可能需要的任何标志)。

如果您谈论的是其他平台，当然，这条规则不适用(但“shebang行”没有害处，如果您将该脚本复制到基于Unix的平台，如Linux、Mac等，则会有所帮助)。

这样做的主要原因是使脚本可跨操作系统环境移植。

例如，在mingw下，python脚本使用:

#!/c/python3k/python 

在GNU/Linux发行版下，它是:

#!/usr/local/bin/python 

or

#!/usr/bin/python

在最好的商业Unix sw/hw系统(OS/X)下，它是:

#!/Applications/MacPython 2.5/python

或在FreeBSD上:

#!/usr/local/bin/python

然而，所有这些差异可以通过使用以下方法使脚本可移植:

#!/usr/bin/env python

这是一个shell约定，告诉shell哪个程序可以执行脚本。

#!/usr/bin/env python

解析为Python二进制文件的路径。

扩展一下其他的答案，这里有一个小例子，说明你的命令行脚本会因为不小心使用/usr/bin/env shebang行而陷入麻烦:

$ /usr/local/bin/python -V
Python 2.6.4
$ /usr/bin/python -V
Python 2.5.1
$ cat my_script.py 
#!/usr/bin/env python
import json
print "hello, json"
$ PATH=/usr/local/bin:/usr/bin
$ ./my_script.py 
hello, json
$ PATH=/usr/bin:/usr/local/bin
$ ./my_script.py 
Traceback (most recent call last):
  File "./my_script.py", line 2, in <module>
    import json
ImportError: No module named json

json模块在Python 2.5中不存在。

防止这类问题的一种方法是使用通常与大多数python一起安装的版本化python命令名:

$ cat my_script.py 
#!/usr/bin/env python2.6
import json
print "hello, json"

如果你只需要区分Python 2。3. Python。x，最近发布的Python 3也提供了一个python3名称:

$ cat my_script.py 
#!/usr/bin/env python3
import json
print("hello, json")

如果你在虚拟环境(比如venv)中运行脚本，那么在venv上执行哪个python将显示python解释器的路径:

~ / env / venv / bin / python

请注意，虚拟环境的名称嵌入在Python解释器的路径中。因此，在脚本中硬编码这个路径会导致两个问题:

如果将脚本上传到存储库，则会强制其他用户使用相同的虚拟环境名称。前提是他们首先发现了问题。 即使在其他虚拟环境中有所有必需的包，也不能跨多个虚拟环境运行脚本。

因此，为乔纳森的回答补充一点，理想的shebang是#!/usr/bin/env python，不仅可以跨操作系统的可移植性，还可以跨虚拟环境的可移植性!

在我看来，没有这一行，文件运行是一样的。

如果是这样，那么也许你是在Windows上运行Python程序?Windows不使用这一行——相反，它使用file-name扩展名来运行与文件扩展名相关的程序。

然而，在2011年，一个“Python启动器”被开发出来，它(在某种程度上)在Windows上模仿了Linux的这种行为。这仅限于选择运行哪个Python解释器——例如，在安装了Python 2和Python 3的系统中选择Python 2和Python 3。在Python安装时，启动器可选地作为py.exe安装，并且可以与.py文件相关联，以便启动器将检查这一行，然后启动指定的Python解释器版本。