diff --git a/2.Linux Shell 脚本编程最佳实践.md b/2.Linux Shell 脚本编程最佳实践.md
index d54e14c..0b8afd0 100644
--- a/2.Linux Shell 脚本编程最佳实践.md	
+++ b/2.Linux Shell 脚本编程最佳实践.md	
@@ -1,4 +1,3 @@
-
 ## 前言 
 
 
@@ -66,9 +65,61 @@ lrwxrwxrwx. 1 root root 4 May 13  2021 /bin/sh -> bash
 
 > env 命令用于显示系统中已存在的环境变量，以及在定义的环境中执行指令
 
-这种 `shebang` 写法的原理是：**当你执行 env bash 时，它其实会去操作系统的PATH环境变量的路径中去查找bash可执行文件。**
+这种 `shebang` 写法的原理是：**当执行 env bash 时，它其实会去操作系统的$PATH环境变量的路径中去查找bash可执行文件。**
 
 
+- `#!/bin/bash` 是直接指定，把bash可执行文件的路径硬编码到`shebang`中
+
+- `#!/usr/bin/env bash` 则是告诉系统去 $PATH 包含的目录中挨个去找吧，先找到哪个，就用哪个
+
+### `#!/usr/bin/env bash` 优缺点
+
+优点
+
+- `#!/usr/bin/env bash` 不必在系统的特定位置查找命令解释器，为多系统间的移植提供了极大的灵活性和便利性（某些系统的一些命令解释器并不在 /bin 或 一些约定的目录下，而是一些比较奇怪的目录）
+
+- 在不了解主机的环境时，`#!/usr/bin/env bash` 写法可以使开发工作快速地展开。
+
+
+缺点
+
+- `#!/usr/bin/env bash` 在对安全性比较看重时，该写法会出现安全隐患
+
+    > `#!/usr/bin/env bash` 从 $PATH 中查找命令解释器所在的位置并匹配第一个找到的位置，这意味着可以伪造一个假的命令解释器（如自己写一个假的 bash），并将伪造后的命令解释器所在目录写入 PATH 环境变量中并位于靠前位置，这样，就形成了安全隐患。而 /bin 由于一般只有 root 用户才有操作权限，所以，#!/bin/bash 这种写法相对较为安全。
+
+- `#!/usr/bin/env` 无法传递多个参数（这是由于 Shebang 解析造成的，并非 env 命令的缘故）
+
+ > 如：
+ #!/usr/bin/perl -w
+#!/bin/csh -f
+而如果使用 `#!/usr/bin/env perl -w` 这种写法的话，`perl -w` 会被当成一个参数，于是，根本找不到 perl -w 这个命令解释器，就会出错。
+
+### `#!/bin/bash` 优缺点
+
+优点
+
+- 准确指出所需命令解释器的位置
+
+- 安全性相对较高
+
+- 可以传递多个参数
+
+缺点
+
+- 移植性相对较差，很多系统的命令解释器位置不一致
+
+- 一些命令解释器的位置记不住
+
+到底用哪个
+
+- 两个都可以
+
+- 如果对安全性比较看重，使用 #!/bin/bash
+
+- 如果对安全性不是很看重，但对移植性（灵活性）比较看重，使用 #!/usr/bin/env bash
+
+- 看自己的意愿，喜好
+
 ## 什么时候用 SHELL