它告诉解释器，当你有多个版本的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")

考虑到python2和python3之间的可移植性问题，您应该始终指定其中一个版本，除非您的程序与两个版本都兼容。

一些发行版现在已经发布了python符号链接到python3 -不要依赖于python是python2。

PEP 394强调了这一点:

为了容忍不同平台的差异，所有的新代码 需要调用Python解释器时不应该指定Python，但是 而是应该指定python2或python3(或更具体的 python2。X和python3。x版本;参见迁移说明)。这 当从shell调用时，应该在shebangs中进行区分 脚本，当通过system()调用调用时，或在任何 其他上下文。

强调一件大多数人都忽略了的事情可能是有道理的，这可能会妨碍立即理解。在终端中输入python时，通常不会提供完整路径。相反，可执行文件在PATH环境变量中查找。反过来，当你想直接执行Python程序/path/to/app.py时，必须告诉shell要使用哪个解释器(通过hashbang，其他贡献者在上面解释的内容)。

Hashbang期望到解释器的完整路径。因此，要直接运行你的Python程序，你必须提供Python二进制文件的完整路径，这差异很大，特别是考虑到使用virtualenv。为了解决可移植性，使用了/usr/bin/env的技巧。后者最初的目的是就地改变环境并在其中运行命令。当没有提供任何更改时，它将在当前环境中运行该命令，这将有效地导致相同的PATH查找。

源代码来自unix stackexchange

您可以使用virtualenv尝试解决这个问题

这里是test.py

#! /usr/bin/env python
import sys
print(sys.version)

创建虚拟环境

virtualenv test2.6 -p /usr/bin/python2.6
virtualenv test2.7 -p /usr/bin/python2.7

激活每个环境，然后检查差异

echo $PATH
./test.py

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

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

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