terminal.integrated.cwd仅控制手动新建终端的起始路径，插件中需用createTerminal({ cwd: resolvedPath })显式指定且不支持变量；远程场景下须调用workbench.action.terminal.newLocal创建本地终端。
如何在插件中创建并控制本地/远程终端实例
VSCode 插件无法直接“复用”已有终端的 shell 进程，但可以通过 vscode.window.createTerminal() 创建新终端实例，并指定其运行上下文。关键在于区分本地与远程场景：
- 在本地工作区：直接调用
createTerminal({ name: "my-task", shellPath: "/bin/zsh" }) - 在 Remote - SSH 连接下：默认终端绑定远程环境；若需本地终端，必须显式调用
workbench.action.terminal.newLocal命令（该命令仅在远程会话中可用） - 插件中不能硬编码路径如
"C:\Windows\System32\cmd.exe"，应通过os.platform()+process.env.SHELL动态获取，否则跨平台失效
为什么 terminal.integrated.cwd 在插件里不生效
插件代码运行在渲染进程，而 terminal.integrated.cwd 是用户/工作区级配置项，只影响手动触发的终端（如 Ctrl+`）。插件调用 createTerminal() 时，该配置不会自动注入——它只作用于 VSCode 内部的“新建终端”逻辑。
- 正确做法：在
createTerminal()的options中传入cwd字段，例如{ cwd: "${workspaceFolder}/scripts" } - 注意：
cwd字段不支持变量展开（如${workspaceFolder}），必须提前 resolve。要用vscode.workspace.workspaceFolders?.[0].uri.fsPath手动拼接 - 如果目标路径不存在，终端会静默 fallback 到用户主目录，无报错提示，容易误判
自动化命令注入的两种可靠方式
想让终端一启动就执行 npm run dev 或 source ./env.sh，不能依赖 shell 的 .zshrc 自动加载（不可控、延迟高），而应由插件主动注入：
- 方式一（推荐）：用
terminal.sendText("npm run dev ", true)。第二个参数true表示不换行，适合连续输入；但注意：命令发送后终端不自动聚焦，需额外调用terminal.show() - 方式二：在
shellPath中包裹执行逻辑，例如shellPath: "/bin/bash", args: ["-c", "cd ${workspaceFolder} && npm run dev && exec bash"]。缺点是错误堆栈难追踪，且exec bash后历史命令可能丢失 - 严重陷阱：不要在
sendText后立刻dispose()终端，VSCode 不保证命令已执行完毕；建议监听onDidWriteData或加短延时
tasks.json 和插件终端的本质区别
插件创建的终端是纯 runtime 控制，而 tasks.json 定义的是声明式任务。两者不互斥，但定位不同：
-
tasks.json适合稳定、复用率高的命令（如构建、测试），它由 VSCode 主进程 spawn，支持problemMatcher、后台运行、输出捕获 - 插件终端适合动态、上下文强相关的操作（如根据当前文件类型启动调试容器、按 Git 分支切换 env 变量），但需自行处理错误重试、进程生命周期
- 混合使用更稳妥：插件调用
vscode.tasks.executeTask()触发预定义 task，比手写sendText更健壮，尤其涉及虚拟环境激活时
真正难的不是启动终端或发命令，而是判断“命令是否真正在运行”。sendText 只管发，不管结果；executeTask 能监听 TaskExecution 状态，但无法捕获 shell 内部的子进程退出码。这点必须由插件自己补全——比如用 child_process.spawn 在插件进程内跑命令，再把 stdout/stderr 转发到终端，才能拿到完整控制权。
