根本原因是vscode未打开bazel工作区根目录：必须确保打开的文件夹下存在workspace文件，且插件依赖bazel cli、支持的规则类型（如cc_binary）及正确配置（如usebazelrunfordebug）。
VSCode 装了 Bazel 插件却找不到构建目标
根本原因不是插件没装对，而是 BUILD 文件没被识别——Bazel 插件依赖工作区根目录存在 WORKSPACE 或 WORKSPACE.bazel 文件，且 VSCode 必须打开的是该工作区的**根目录**（不是某个子包）。打开 src/ 或 java/com/example/ 这类子目录，插件直接失能。
常见错误现象：Go to Symbol in Workspace 搜不到 cc_binary、右键没有 Run Bazel Target 选项、状态栏不显示 Bazel 图标。
- 确认当前打开的文件夹路径下有
WORKSPACE（哪怕只是空文件） - 关闭所有窗口，用
code /path/to/workspace/root重新打开（别用“Open Folder”点进子目录） - 插件默认只扫描当前工作区根下的
**/BUILD*，不递归扫描符号链接或外部仓库（external/）
bazel-vscode 插件安装后无法跳转到 BUILD 规则定义
跳转失效通常卡在语言服务器没起来，而不是插件本身问题。VSCode 的 bazel-vscode 插件依赖本地 bazel CLI 可执行，并需要它输出结构化信息（通过 --output_format=json）。
使用场景：按住 Ctrl（macOS 是 Cmd）点击 deps = ["//lib:util"] 想跳进 //lib:util 的 BUILD 文件，但光标没反应。
- 终端运行
bazel version，确保返回有效版本（bazel 6.4.0或更高；低于 5.0 的旧版不支持插件所需 API） - 检查 VSCode 设置里
bazel.bazelPath是否指向正确路径（如/usr/local/bin/bazel），不是别名或 shell 函数 - 插件首次激活时会调用
bazel query 'kind(rule, //...)' --output=label，若项目太大，可能超时失败——可在设置中加"bazel.queryTimeoutMs": 30000
运行 Bazel 目标时报错 “Failed to launch debug adapter” 或 “No targets found”
这不是构建失败，而是插件尝试生成 launch 配置时，没找到匹配的可执行规则类型。Bazel 插件只自动支持 cc_binary、java_binary、py_binary 和部分 sh_binary，其他如 genrule、filegroup 或自定义规则一律不显示运行按钮。
错误信息示例：No runnable targets found for current file 或 Error: Debug adapter process exited with code=127
- 右键菜单里的
Run Bazel Target只对当前光标所在行的 label 生效（比如光标停在name = "server"行，会尝试运行//:server） - 确保目标 rule type 是插件支持的——用
bazel query 'kind("(cc|java|py)_binary", //:all)'手动验证 - 如果目标是
go_binary，需额外安装rules_go并在WORKSPACE中注册，否则插件完全不可见
配置 launch.json 手动调试 Java/Python 二进制时环境变量丢失
Bazel 构建产物默认放在 bazel-bin/ 下，但直接运行会缺 CLASSPATH 或 PYTHONPATH，因为插件生成的调试配置没自动注入 Bazel 的运行时环境。
性能影响：手动写 launch.json 虽绕过插件限制，但每次改 target 都要重配；用插件自动生成则更稳，但必须让插件知道怎么补环境。
- 在
.vscode/settings.json中启用"bazel.useBazelRunForDebug": true（强制用bazel run启动，而非直接 exec） - Java 项目需确认
java_binary声明了jvm_flags或依赖java_runtime，否则bazel run会 fallback 到系统 JVM，版本可能不匹配 - Python 用户注意：
py_binary必须设python_version = "PY3"，否则插件可能选错解释器路径
最常被忽略的一点：Bazel 的 sandbox 机制会让 run 和 build 的环境不一致——调试时看到的文件路径，和你在终端 bazel build 后看到的 bazel-bin/ 结构，可能因 --sandbox_debug 开关而不同。别硬记路径，始终用 bazel info execution_root 确认真实输出位置。
