Shell 脚本调试技巧：set -x 与 bash -n

发布时间:2025-11-07 15:41

## 概念 脚本不报错但结果不对，是最耗时间的故障类型：退出码是零，备份文件却没生成；循环正常结束，统计数却少了半截。bash 自带两个低成本工具对付这类问题：bash -n 只做语法解析不执行，用于干跑检查；set -x 在执行时打印每条命令与展开后的实际参数，用于跟踪逻辑走向。两者组合，能覆盖脚本草稿阶段的大部分问题，不需要安装任何额外软件。 ## 原理 bash -n 逐行读入脚本做语法分析，遇到不配对的引号、缺失的 fi 或 done 立刻报出行号，因为不执行任何命令，对生产脚本零风险，可以放心对线上文件反复运行。set -x 打开的执行跟踪会在每条命令执行前，把它按展开后的样子打印到标准错误：变量是不是空值、通配符展开成了哪些文件、分支走进了哪一边，一目了然。配合 PS4 变量还能在每行前缀里加上行号与脚本名，长脚本里定位语句位置快得多。 ## 最小实操 先干跑一遍检查语法，这一步应该成为提交前的固定动作。 ``` bash -n deploy.sh ``` 在脚本内把可疑区段包起来做局部跟踪，范围之外的输出不受影响。 ``` set -x rsync -a --delete src/ dst/ set +x ``` 也可以不改脚本，从外部以跟踪模式启动，适合一次性诊断。 ``` bash -x deploy.sh ``` 需要行号时在脚本开头加一行 export PS4='+ ${LINENO}: '，输出里每条命令前都会带上所在行号，对照编辑器里的行号即可秒级定位。输出量太大时，把标准错误单独重定向到文件再慢慢检索，比在终端里回滚翻找可靠。 ## 常见错误 一是全程开着 set -x 跑生产，日志里混满命令回显，密钥类变量还会被明文打印出来，跟踪务必限定区段并及时关闭；二是只看有没有报错，不去读展开结果，漏掉变量为空的分支；三是把干跑当成测试，bash -n 查不出逻辑错误，条件写反、路径拼错这类问题只有真实执行才暴露；四是忘了把跟踪输出与正常输出分离，排查结束后把 stderr 重定向混进了业务日志。在顺云云服务器上执行脚本前，建议保留一份带时间戳的执行日志，出问题时先有留痕，再谈定位。