VSCode默认终端调试Shell脚本易卡住，根本原因是未启用伪终端（PTY）或未透传TTY控制权，导致sudo、dialog等交互命令挂起；需在tasks.json中配置"type": "shell"并确保PTY启用，避免用shell: false绕过解析。

为什么默认终端调试 shell 脚本容易卡住

VSCode 内置终端执行 sh 或 bash 构建脚本时，常出现“输出不刷新”“read 阻塞无响应”“信号中断失效”等问题。根本原因是终端模拟器未启用伪终端（PTY）或未透传 TTY 控制权，导致交互式命令（如 sudo、dialog、git rebase --interactive）直接挂起。

• 确认是否启用 PTY：在 tasks.json 中检查 "isBackground": true 时是否漏配 "problemMatcher"，否则 VSCode 不会等待任务结束，日志被截断
• 避免用 shell: false 运行脚本——它绕过 shell 解析，$PATH、~ 展开、管道符都会失效
• Windows 用户若用 Git Bash，需显式设置 "terminal.integrated.profiles.windows" 指向 git-bash.exe，否则默认 cmd.exe 不识别 #!/bin/bash

Code Runner 插件对构建脚本的局限性

Code Runner 默认将脚本当作“单次表达式”执行，不保留上下文环境变量，且无法复现 CI 环境中的 CI=true、GITHUB_ACTIONS 等关键变量。更严重的是，它静默忽略 set -e 失败退出，掩盖真实错误。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• 临时修复：右键脚本 → “Run Code”，再手动在终端中执行 export CI=true && ./build.sh —— 但每次都要重输
• 替代方案：改用 Task Runner（即 tasks.json），可定义完整环境块："env": {"CI": "true", "NODE_ENV": "production"}
• 注意 Code Runner 的 executorMap 配置里，shell 对应命令是 bash -c，不是 bash --norc，会导致本地 .bashrc 干扰构建一致性

推荐用 Tasks + Terminal API 实现真调试流

VSCode 原生 tasks.json 结合 Terminal API，能复现真实构建环境并支持断点式调试（比如在 if [ $? -ne 0 ]; then 前暂停）。关键是把脚本拆成“准备 → 执行 → 验证”三阶段任务链。

• 在 .vscode/tasks.json 中定义："type": "shell"（非 process），并启用 "group": "build" 方便一键触发整套流程
• 添加 "presentation": {"echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true} —— 避免每次运行都新建终端页签
• 调试技巧：在脚本关键行插入 echo "DEBUG: $(date)"; read -p "Press ENTER to continue..."，配合 Ctrl+Shift+P → “Tasks: Run Task” 触发，比加 set -x 更可控

ShellCheck 插件必须开启自动修复

ShellCheck 是唯一能静态捕获 [[ 与 [ 混用、未引号包裹变量、错用 $@ 和 $* 的工具。但默认只报错，不开自动修复等于白装。

• 在设置中启用："shellcheck.enableAutoFix": true，保存时自动修正 if [ $var = "ok" ] → if [[ $var == "ok" ]]
• 配合 editor.codeActionsOnSave：添加 "source.fixAll.shellcheck"，确保保存即修复
• 注意 ShellCheck 不检查逻辑错误（如 rm -rf $DIR/* 中 $DIR 为空），这类必须靠 set -u 运行时兜底

真实调试体验的关键不在“看到更多日志”，而在于能否让脚本在 VSCode 里像在服务器上一样运行——环境一致、信号可靠、中断可控。很多团队卡在“本地能跑，CI 报错”，问题往往出在任务配置漏了 env 或终端未启用 PTY，而不是脚本本身。