Shell脚本需建立脚本思维，避免路径、变量、错误处理等常见陷阱：用绝对路径或command -v调用命令；解释器声明须真实存在；变量必须双引号包裹；优先用[[ ]]替代[ ]；glob前检查匹配结果或改用find。

Shell 脚本不是“写完就能跑”的玩具，它本质是把人对任务的拆解逻辑，翻译成系统能逐条执行的指令流。没建立起脚本思维，光记 for 语法或 sed 参数，写出来的脚本迟早会卡在路径没引号、变量没展开、错误没捕获这些地方。

为什么你的脚本在自己机器上好使，一换环境就报 command not found

根本原因常是环境路径和解释器声明脱节。比如你用 #!/bin/bash 开头，但目标机器只有 /usr/bin/bash；或者脚本里直接写 python3，却没确认该命令是否在 $PATH 中且版本兼容。

• 始终用绝对路径调用关键工具：写 /usr/bin/python3 而非 python3，或用 command -v python3 动态查路径
• 第一行解释器声明必须真实存在：运行 ls -l /bin/bash /usr/bin/bash 确认路径，再选其一；不确定时可用 #!/usr/bin/env bash（但注意 env 本身也得在 $PATH）
• 避免隐式依赖：比如 ll 是别名，不是命令，脚本中必须写成 ls -l

if 判断总出错？重点不是语法，是退出状态和字符串边界

Shell 的 if 不判断“真假值”，只看命令执行后的 $?。而字符串比较、文件测试这些看似简单的操作，稍不注意就会因空格、未引号变量、空值导致逻辑翻车。

• 变量必须加双引号：if [ "$name" = "admin" ]，否则 $name 为空或含空格时，[ = "admin" ] 直接报错
• 用 [[ ]] 替代 [ ]：它更安全，支持 =~ 正则、无需引号保护部分场景，且不会因单词拆分崩溃
• 测试前先确认变量有值：if [[ -n "$input" ]] && [[ "$input" =~ ^[0-9]+$ ]]，避免空输入进正则引发意外

循环处理文件列表，为什么 for file in *.log 有时不工作？

这是 glob 展开与空匹配的经典陷阱。当当前目录下没有 .log 文件时，*.log 字面量不会被替换，for 就真的去遍历字符串 "*.log" —— 你代码里就多了一个叫 *.log 的“假文件”。

• 先检查通配结果：files=( *.log ); if [[ ${#files[@]} -eq 0 ]]; then echo "no logs"; exit 1; fi
• 用 find 更可靠：while IFS= read -r -d '' file; do ... done ，规避空格、换行、无匹配等问题
• 如果坚持用 for，加上 nullglob 选项：shopt -s nullglob; for file in *.log; do ...; done，此时无匹配时循环体不执行

调试时加 set -x，但输出太乱看不清关键变量？

set -x 是利器，但它把所有展开后的命令都打出来，变量值混在一堆路径和参数里，反而掩盖问题。真正要盯的是“这个变量此刻到底是什么”。

• 不要全程开 set -x，只在可疑段落前后控制：set -x; echo "DEBUG: dir=$DIR, count=$count"; set +x
• 用 declare -p 查看变量完整状态：declare -p PATH USER DIR，它会显示类型、引号、空格等细节，比 echo $VAR 可靠十倍
• 临时改用 set -u（报未定义变量错误）：能立刻暴露 $CONFIG_PATH 拼写错误这类低级但致命的问题

脚本思维的核心，是始终把 Shell 当作一个严格、吝啬、不替你兜底的协作者——它不会自动补空格，不会猜你想用哪个 Python，也不会告诉你 $? 是 127 还是 1 代表什么。每一步都要问：这行命令执行完，$? 是多少？变量有没有被展开？路径里有没有空格？答案不明确，就别往下写。