# Linux 脚本首行的秘密：`#!/usr/bin/env bash` 和 `#!/bin/bash` 到底是什么？

在 [[Linux]] 系统中编写脚本时，我们习惯性地会在文件顶部写上这样一行：

```bash
#!/usr/bin/env bash
```

或者

```bash
#!/bin/bash
```

乍一看，它似乎只是一个注释……那么，这一行的**真实含义**是什么？它们之间又有什么区别呢？本文将深入探讨这一行代码的含义，并为您总结何时应选择哪种方式。

---

## 1. 这不是注释：什么是 shebang？ {#sec-9f8041c620ba}

以 `#!` 开头的这一行被称为 **shebang**。

```bash
#!/bin/bash
```

在 Shell 看来，它以 `#` 开头，确实像一个“注释”。但对于**操作系统（内核）**而言，这并非注释，而是一个：

> “指示该脚本应由哪个**解释器程序**执行的指令”

也就是说：

* `#!/bin/bash` → “请使用 `/bin/bash` 执行此文件”
* `#!/usr/bin/env bash` → “请通过 `env` 查找 `bash` 解释器，并使用它执行此文件”

---

## 2. 内核如何执行脚本？ {#sec-33d96b8d8f01}

将执行过程极度简化，大致如下：

1. 用户执行具有执行权限的脚本

```bash
chmod +x script.sh
./script.sh
```
 
2. 内核读取 `script.sh` 
3. 检查文件**前两个字符**是否为 `#!` 
4. 如果是，则将该行的剩余部分识别为：

   * “解释器路径 + 参数”
   * 然后执行该程序，并**将脚本文件路径作为参数传递**

例如，如果 `script.sh` 的第一行是：

```bash
#!/bin/bash
```

那么内核实际执行的操作可以大致理解为：

```bash
/bin/bash script.sh
```

也就是说，内核代替我们执行了类似于直接运行 `bash script.sh` 的操作。

> 注意：
> `#!/` 前面**不能有空格**。
> 文件的**第一个字符**必须是 `#`，第二个是 `!`。

---

## 3. `#!/bin/bash` 的含义与特点 {#sec-52f9e12dce0d}

最常见的形式就是这种。

```bash
#!/bin/bash
```

### 含义 {#sec-a97a945792d4}

* “此脚本是 **bash 脚本**，且 `bash` 位于 `/bin/bash`。”
* 内核在执行此脚本时，总是会运行 `/bin/bash`。

### 优点 {#sec-a01bf708579d}

* **明确性**：始终使用 `/bin/bash`，因此很容易预测将使用哪个 bash 版本。
* **性能/简洁性**：无需通过 `env` 直接执行，省去了路径搜索过程。
* 在许多 [[Linux]] 发行版中，`/bin/bash` 实际上被视为“标准位置”。

### 缺点 {#sec-89064c01f1ea}

* **可能不具备可移植性**

  * 在某些系统中，bash 可能位于其他路径，例如 `/usr/bin/bash`、`/usr/local/bin/bash` 等。
  * 某些系统可能根本未安装 bash，或者只安装了 `/bin/sh`。
* 特别是在 **macOS、BSD 系列、NixOS 和某些容器环境**中，路径可能有所不同。

---

## 4. `#!/usr/bin/env bash` 的含义与特点 {#sec-97cd6f02458d}
如今，这种形式在脚本中越来越常见。

```bash
#!/usr/bin/env bash
```

这里的核心是 `/usr/bin/env`。

* `env` 是一个实用工具，用于“设置/检查环境变量 + 在 PATH 中搜索程序”。

* 您可以认为内核实际执行的操作是这样的：

```bash
/usr/bin/env bash script.sh
```

* `env` 会查看系统的 `PATH` 环境变量，并在其中查找并执行 `bash` 可执行文件。

### 优点 {#sec-9bc2075d78b3}

1. **可移植性强（在各种环境下运行良好）**

   * 无论 bash 位于 `/bin/bash`、`/usr/bin/bash` 还是 `/usr/local/bin/bash`，
   * 只要它正确注册在 PATH 中，`env` 就能找到它。
   
2. **使用符合用户环境的 bash**

   * 如果用户自定义了 `PATH`，优先使用特定版本的 bash，`env` 就会按此执行。

3. **Python 等语言也采用相同模式**

```sh
#!/usr/bin/env python3
```

### 缺点 {#sec-0ba7b1b3de08}

1. **前提是 `/usr/bin/env` 必须存在**

   * 尽管几乎所有现代 Unix/[[Linux]] 系统都包含它，但在某些非常特殊的条件下可能不存在。

2. **可能因 PATH 设置而捕获到不同的解释器**

   * 如果 PATH 配置混乱，或者意外的 bash 版本被优先找到，则可能运行非预期的版本。

3. **在安全敏感环境中需要注意**

   * 在高度安全敏感的环境中，一些人可能不喜欢基于 PATH 查找解释器的方式，因此更倾向于使用**绝对路径**。

---

## 5. 两种方式对比总结 {#sec-f327651f1197}

我们将通过简要对比表格进行总结。

| 类别               | #!/bin/bash  | #!/usr/bin/env bash   |
| ---------------- | -------------- | ----------------------- |
| 解释器位置指定方式   | 绝对路径固定       | 通过 `PATH` 搜索          |
| 可移植性（系统兼容性） | 较低（路径不同则中断） | 较高（只要 bash 在 PATH 中即可） |
| 使用哪个 bash    | 始终是 `/bin/bash` | PATH 中找到的第一个 `bash`   |
| 预期版本保障        | 相对容易         | 可能因 PATH 状态而异    |
| 安全性/控制力           | 更强（路径固定）   | 略宽松（依赖 PATH）      |
| 普遍最新趋势      | 相对旧式风格   | 近年来更推荐此方式     |

---

## 6. 何时选择哪种方式？ {#sec-a9bac1ab9ba4}

对于“我到底该用哪种？”这个问题，我们将根据不同情况进行总结。

### 1) 个人/团队开发脚本（常见开发环境） {#sec-fc5216000f29}

* 通常推荐使用以下方式：

```bash
#!/usr/bin/env bash
```

* 理由：  

  * 在开发者自行管理的服务器、本地环境、CI 环境等场景下，bash 的位置可能不同。
  * 基于 PATH 查找并执行更加灵活，现代工具和脚本也倾向于这种方式。

### 2) 针对特定服务器环境的运维脚本 {#sec-204ac6ba64d3}

* 例如，如果公司内所有服务器都统一在 `/bin/bash` 安装了 bash，

* 并且服务器环境相对固定：

```bash
#!/bin/bash
```

* 理由：

  * 确保始终使用相同的解释器。
  * 可以减少因 PATH 修改而导致的意外行为。

### 3) 如果希望脚本尽可能地可移植？ {#sec-6ef1b12d728e}

* 如果您认为在某些环境中可能根本没有 bash，那么首先应该考虑该脚本是否适合依赖 bash。

* 如果可能，请使用 `sh` 编写：

```bash
#!/bin/sh
```

* 这种方式可以在更广泛的环境中运行。但是，您不能使用 bash 独有的语法（例如 `[[ ]]`、数组、扩展字符串处理等）。

---

## 7. 使用 `#!/usr/bin/env bash` 的实用技巧 {#sec-e5a739214684}

### 1) 脚本执行方法 {#sec-83e5cc5b64a5}

要正确利用 shebang，不应仅仅这样做：

```bash
bash script.sh   # ← 这样执行 shebang 几乎没有意义
```

而是建议如下使用：

```bash
chmod +x script.sh   # 赋予执行权限
./script.sh          # 直接执行
```

只有这样，内核才会读取 `#!` 并使用指定的解释器。

### 2) 检查参数传递 {#sec-90ca3c9235bf}

例如，我们创建一个名为 `test.sh` 的文件，内容如下：

```bash
#!/usr/bin/env bash

echo "解释器: $0"
echo "参数: $@"
```

执行：

```bash
chmod +x test.sh
./test.sh hello world
```

输出：

```text
解释器: ./test.sh
参数: hello world
```

这里，`$0` 代表“脚本文件自身的路径”，您只需记住内核实际执行的是类似 `/usr/bin/env bash test.sh hello world` 的命令。

---

## 8. 常见问题 {#sec-99b0325925f3}

### 我见过没有 shebang 的脚本，这是怎么回事？ {#sec-751234a46d29}

* 没错，**shebang 并非总是必需的**。

* 如果您像下面这样直接指定解释器来运行脚本，则不需要 shebang。即使写了 shebang，也会被忽略。

```bash
bash myscript.sh
python3 myscript.py
```

* 但如果您想像下面这样直接执行脚本，shebang 就是必需的：

```bash
./myscript.sh
./myscript.py
```

* 特别是对于那些可以被他人当作“工具”来使用的脚本，**shebang 几乎是必不可少的**。


### “除了 `#!/usr/bin/env`，`#!/bin/env` 也可以使用吗？” {#sec-6de89a827da4}

* 在某些系统中，确实存在 `/bin/env`。
* 但通常情况下，`/usr/bin/env` 是更通用的标准位置。
* 如果没有特殊原因，使用 `#!/usr/bin/env …` 会更安全。

---

## 9. 总结 {#sec-971578a5a9d1}

* `#!/usr/bin/env bash` 或 `#!/bin/bash` **并非注释，而是指示内核“应使用哪个解释器来执行此脚本”的指令**。
* `#!/bin/bash`

  * 始终使用 `/bin/bash` → **在固定环境中可预测，但可能不具备可移植性**。
* `#!/usr/bin/env bash`

  * 在 `PATH` 中查找 bash 并使用 → **更灵活、更具可移植性，但受 PATH 状态影响**。
* 在一般的开发/部署环境中，如果希望以“现代风格”编写脚本，建议**默认使用 `#!/usr/bin/env bash`**。

![shebang 的工作原理图](https://blog.mikihands.com/media/editor_temp/6/692ed85d-0eb6-4fd1-ab7a-22a2d189175d.png "shebang 的工作原理图")