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 代表什么。每一步都要问：这行命令执行完，$? 是多少？变量有没有被展开？路径里有没有空格？答案不明确，就别往下写。
