在 Shell 脚本中，通过sh 1.sh、bash 1.sh、source 1.sh或. 1.sh调用子脚本，行为有本质区别，主要体现在执行环境（进程/作用域）和变量/函数可见性上。
✅ 对比总结表
| 调用方式 | 是否新建子进程 | 能否修改父脚本变量 | 能否继承父脚本变量 | 能否使用父脚本函数 | 执行速度 | 典型用途 |
|---|---|---|---|---|---|---|
sh 1.sh | ✅ 是 | ❌ 不能 | ❌ 仅export的 | ❌ 不能 | 稍慢 | 独立任务、隔离执行 |
bash 1.sh | ✅ 是 | ❌ 不能 | ❌ 仅export的 | ❌ 不能 | 稍慢 | 同上（指定 bash） |
source 1.sh | ❌ 否 | ✅ 能 | ✅ 全部 | ✅ 能 | 快 | 加载配置、共享状态 |
. 1.sh（点命令） | ❌ 否 | ✅ 能 | ✅ 全部 | ✅ 能 | 快 | 同source（POSIX 标准） |
🔍 详细解释
1.sh 1.sh或bash 1.sh：启动新进程
- 会创建一个新的 Shell 子进程来执行
1.sh。 - 父脚本的普通变量（未
export）对子脚本不可见。 - 子脚本中修改的变量不会影响父脚本。
- 子脚本无法调用父脚本定义的函数。
- 即使子脚本中
exit，也只退出子进程，不影响父脚本继续执行。
📌 示例：
# parent.shname="Alice"shchild.sh# child.sh 里 echo $name → 空（除非 export name）echo$name# 仍为 "Alice"
2.source 1.sh或. 1.sh：在当前 Shell 中执行
- 不创建新进程，直接在当前 Shell 环境中逐行执行
1.sh。 - 完全共享父脚本的变量、函数、当前目录、umask 等上下文。
- 子脚本中修改变量，父脚本能感知到变化。
- 如果子脚本中写了
exit，整个父脚本会退出！ . 1.sh是 POSIX 标准写法，source是 Bash/Zsh 的别名，功能相同。
📌 示例：
# parent.shname="Alice"sourcechild.sh# child.sh 中 name="Bob" → 父脚本 name 变为 "Bob"echo$name# 输出 "Bob"
🛠 实际应用场景
| 场景 | 推荐方式 | 原因 |
|---|---|---|
加载配置文件（如.env） | source config.sh | 需要将变量导入当前环境 |
| 执行独立部署任务 | bash deploy.sh | 隔离环境，避免污染父脚本 |
| 在脚本中复用函数库 | source lib.sh | 直接调用库中的函数 |
| 临时测试脚本 | sh test.sh | 不影响当前 Shell 状态 |
| 在 Dockerfile 或 CI 中运行 | sh entrypoint.sh | 通常需要独立进程 |
⚠️ 常见陷阱
误用
exit
在被source的脚本中写exit会导致整个终端或主脚本退出！变量污染
source时，子脚本的变量会覆盖父脚本同名变量（可用local限制作用域）。路径问题
source ./1.sh和sh ./1.sh对$0、$PWD的处理不同，影响相对路径解析。
✅ 最佳实践建议
- 需要“导入”配置或函数？→ 用
source或. - 需要“运行”一个独立任务？→ 用
sh或bash - 不确定时？→ 默认用
sh更安全（隔离性好） - 写可移植脚本？→ 优先用
. script.sh（POSIX 兼容）
💡 小技巧：查看当前是否在子 shell 中
echo$SHLVL# 每进一层子 shell +1总结一句话：
sh是“请别人帮你做事”，source是“你自己做这件事”。
前者隔离干净，后者共享状态。根据需求选择即可。
