核心思路是尽量减少循环内的外部命令调用，优先使用 Shell 内置功能替代，并将频繁获取的静态信息缓存到变量中。

命令速用版

以下是几种常见场景的优化对照，可直接参考修改：

# 场景 1：循环内获取时间
# 低效写法
for i in {1..1000}; do
  echo "$(date): Task $i"
done

# 优化写法
# 注意：此优化会导致所有日志时间戳相同，仅适用于无需精确时间的场景
now=$(date +%s)
for i in {1..1000}; do
  echo "$now: Task $i"
done

# 场景 2：读取文件内容
# 低效写法（会触发 word splitting 且加载全文件）
for line in $(cat file.txt); do
  echo "$line"
done

# 优化写法（流式读取）
while IFS= read -r line; do
  echo "$line"
done < file.txt

# 场景 3：批量文件处理
# 低效写法（每次 find 匹配都启动一个新进程）
find . -name "*.log" -exec grep "error" {} \;

# 优化写法（xargs 批量传递参数）
find . -name "*.log" -print0 | xargs -0 grep "error"

# 场景 4：条件判断
# 推荐写法（[[ 是 Bash 内置关键字，支持模式匹配且更安全）
if [[ $var == abc* ]]; then
  ...
fi

为什么会这样

Shell 脚本本身解释执行的速度并不慢，慢的是每次调用外部命令（如 ls、grep、cut、date）时，Shell 都需要通过 fork 和 exec 系统调用创建一个新的子进程。在循环中，如果每次迭代都调用外部命令，成千上万次的进程创建和销毁开销会远超逻辑计算本身。此外，不必要的管道嵌套和文件 I/O 也会加剧上下文切换和内存拷贝的负担。

关于条件判断，虽然 Bash 中 [ 通常是内置命令，但 [[ 是 Bash 特有的关键字，支持模式匹配且无需担心变量引用问题，在复杂逻辑中更安全且略快。真正的性能杀手是在循环内调用 grep、awk 等外部工具。

分步处理

1. 定位瓶颈：在脚本开头加上 set -x 查看执行流程，或使用 time ./script.sh 测量总耗时。对于复杂脚本，可以在关键代码块前后插入 date +%s%N 计算局部耗时。

2. 替换外部命令：检查循环内是否有 date、hostname、basename、dirname 等命令。如果是静态信息，提到循环外赋值给变量；如果是字符串处理，优先用${var#pattern}等内置语法替代 cut 或 awk。

3. 优化循环结构：避免使用 for line in $(cat file) 这种写法，改用 while read 流式读取。如果必须处理文本过滤，尽量交给 awk 或 sed 一次性完成，而不是在 Shell 循环里逐行 grep。

4. 减少 I/O 和导出：避免在循环内频繁读写文件或执行 export。路径、配置值等静态信息首次获取后存入变量，后续直接引用。

怎么验证是否生效

1. 时间对比：使用 time 命令分别运行优化前后的脚本，观察 real 时间的变化。

# 优化前示例输出
real    0m15.342s
user    0m2.100s
sys     0m10.500s

# 优化后示例输出
real    0m2.105s
user    0m1.800s
sys     0m0.300s

2. 系统调用分析：使用 strace -c ./script.sh 统计系统调用次数。优化后，fork、execve 等调用的次数应显著下降。

# strace -c 优化前片段示例
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  80.00    0.012000          10      1200           execve
  20.00    0.003000           2      1200           fork

# strace -c 优化后片段示例
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  10.00    0.001000           1       100           execve
   5.00    0.000500           1        50           fork

3. 资源监控：在脚本运行时，通过 ps -p $$ -o %cpu,rss 观察 CPU 和内存占用，优化后的脚本在同等任务下资源波动应更平稳。

常见坑

1. 业务逻辑正确性：缓存 date 等动态信息会导致所有记录时间戳相同，仅适用于无需精确时间的场景。若需精确时间，可考虑批量获取或降低采样频率。

2. 兼容性问题：[[ ]] 是 bash/zsh 内置关键字，如果脚本需要在 sh 或 dash 下运行，不能使用该语法，需保留 [ ] 但尽量减少调用频率。

3. 变量作用域：在函数内修改全局变量时，慎用 declare -g 或频繁 export，这可能会触发额外的环境块更新开销。

4. 隐式阻塞：stat、find、realpath 等命令默认访问文件系统，大量调用时延迟明显，必要时加-L 参数或缓存结果。

参考来源

• GNU Bash Manual
• time(1) - Linux man page
• strace(1) - Linux man page
• BashPerformance - Wooledge Wiki