VSCode任务变量仅在command、args、options.cwd、options.env字段有效，需严格匹配上下文；用错位置或缺少上下文（如未打开文件、未保存）将静默失效，调试应通过echo回显、检查编辑器状态及重新加载窗口验证。
VSCode 的任务变量（tasks variables）不是“写完就跑”的魔法符号，而是需要严格匹配上下文才能展开的占位符；用错地方、拼错名字、或在不支持的字段里使用，都会静默失效——连报错都没有。
哪些任务变量在 args 和 command 里真正可用
VSCode 只在特定字段解析任务变量，最常被误用的是把 ${fileBasenameNoExtension} 塞进 group 或 problemMatcher 里，那纯属白写。真正生效的只有：command、args、options.cwd、options.env 这几个字段。
-
${file}展开为当前打开文件的绝对路径（含扩展名），适合传给编译器或 linter -
${fileDirname}是文件所在目录，注意它不带尾部斜杠，cd ${fileDirname} && make没问题，但cp foo.txt ${fileDirname}/会因缺斜杠失败 -
${relativeFile}是相对于工作区根目录的路径，只在多根工作区且文件属于某个文件夹时才可靠；如果工作区根是空的或文件不在任一文件夹下，它会为空字符串 -
${input:xxx}需要提前在inputs数组里定义，否则展开为空——很多人漏写inputs段，还纳闷为什么变量没反应
env 字段里用变量要注意 Shell 层级隔离
在 tasks.json 的 options.env 中写 "PATH": "${env:PATH}:/my/toolchain/bin" 看似合理，但实际行为取决于 VSCode 启动方式：从桌面图标启动时，${env:PATH} 是系统 PATH；但从终端执行 code . 启动时，它继承的是终端当时的 PATH。两者可能完全不同。
- Windows 上
${env:USERPROFILE}可靠，但${env:HOME}常为空（尤其非 Git Bash 环境） - macOS/Linux 下
${env:SHELL}通常有效，但不要指望${env:VSCODE_PID}这类内部变量——它根本不在用户环境变量列表里 - 想确保环境干净可控？直接在
options.shell里指定bash -c并手动export，比依赖env字段更稳
调试 tasks variables 失效的三步定位法
变量不展开，90% 是因为位置错了或上下文不存在。别猜，直接验证：
- 把任务
command改成echo，args设为["${file}", "${fileBasenameNoExtension}"]，运行看输出——这是最直接的“回显测试” - 检查当前是否真有活动编辑器：没打开任何文件时，
${file}就是空字符串，不是报错，就是静默丢弃 - 确认工作区已加载：在未保存的临时文件（
Untitled-1）上运行任务，所有基于${file}的变量都无效；必须先保存为真实路径文件
最易被忽略的一点：VSCode 不会重新解析已缓存的任务定义。改完 tasks.json 后，必须手动触发一次“重新加载窗口”（Developer: Reload Window）或至少重启任务终端，否则旧变量值可能还在内存里挂着。
