VSCode无法原生调试Bash脚本，因DAP协议无法介入Bash执行流；bashdb插件已过时且兼容性差；可靠方案是bash -x配合set -u/set -e、手动打点及echo调试。
VSCode 本身不支持 Bash 脚本的原生单步调试和变量追踪，所谓“断点停住→看变量值→F11步入”在纯 Bash 场景下不可用；真要实现类似效果，必须绕过图形化调试器，改用 bash -x + 手动打点 + set -u/set -e 组合方案。
为什么 launch.json 里的 Bash 断点经常不触发
根本原因不是配置写错了，而是 VS Code 的调试协议（DAP）无法直接介入 Bash 解释器的执行流。即使装了 Bash Debug 插件，它底层依赖的是 bashdb —— 一个已多年未维护、对 Bash 5.2+ 兼容性差、且在 macOS（尤其 M1/M2）上常卡死的工具。
-
launch.json中"program": "${file}"看似合理，但实际启动的是bashdb --debug script.sh，而现代 Bash 默认禁用调试钩子（extdebug选项需手动开启，且 bashdb 不自动处理） - 你在
if [ "$x" = "y" ];这行设断点，bashdb可能根本没解析到这一层语法结构，直接跳过 - 变量作用域混乱：Bash 没有块级作用域，
local在函数外无效，declare行为因版本而异，调试器无法可靠映射变量生命周期
真正可用的变量追踪：用 bash -x 替代断点
bash -x 不是“替代方案”，它是 Bash 生态里最稳定、最贴近真实执行路径的追踪手段——它不模拟执行，而是让解释器自己打印每一步展开后的命令。
- 在脚本开头加
set -x，或终端中运行bash -x ./deploy.sh，你会看到类似：++ hostname + HOSTNAME=web01 + [[ web01 == \w\e\b\0\1 ]] + echo 'match'
每一行前面的+表示嵌套层级，变量已展开，逻辑一目了然 - 配合
set -u（访问未定义变量时报错）和set -e（任一命令失败即退出），能提前暴露${MISSING_VAR:-default}这类隐性问题，比等断点停住再查更早发现问题 - 想只追踪某一段？用
set -x/set +x包裹：set -x curl -s https://api.example.com/health set +x # 此后不再输出
手动打点比依赖 Watch 面板更可靠
VS Code 的 “Watch” 面板对 Bash 脚本基本无效——它没有语言服务支持变量提取，你输 $PATH 或 ${#arr[@]}，面板只会显示空或语法错误。
- 用
echo "DEBUG: var=${VAR:-null} count=${#items[@]}"直接输出，内容会出现在终端里，和bash -x输出混排，上下文完整 - 避免用
printf做调试：某些旧版 Bash（如 macOS 自带的 3.2）不支持printf '%q'，而echo兼容性最好 - 如果脚本被
source进其他环境（比如 Jenkins pipeline），bash -x仍有效，但 VS Code 调试器完全失联——此时打点是唯一可依赖的手段
复杂点在于：bash -x 输出太密，关键信息容易淹没；真正需要的不是“所有命令都展开”，而是“只看我关心的变量在何时变成什么值”。所以老手会在关键分支前加 echo "[$(date +%T)] ENTER stage_x: VAR=$VAR"，用时间戳+语义标签过滤日志，这比任何图形化调试器都直接。
