VSCode运行LeetCode插件：本地调试与自动化测试用例构建

能本地调试，也能跑自动化测试用例——但这事儿得先想清楚一个关键点：你到底是冲着“开发插件”去的，还是单纯“用插件来刷题”？这两者的调试路径完全是两码事。

如果是前者，你需要编译 TypeScript，运行测试套件；如果是后者，则是把 LeetCode 的题目代码拉到本地，直接用 g++ 或 python3 来执行并打上断点。如果把这两者混为一谈，大概率会在 testSolution 报错或者 launch.json 配置不上这种问题上卡住。

vscode-leetcode 插件的 testSolution 命令，它只管跑测试，不管调试

插件里的 testSolution 命令，本质上是在后台调用 CLI 工具（比如 leetcode-cli）把你的代码提交到线上的判题机去跑，而不是在你的本地执行。它返回的是一个 JSON 格式的判题结果，像 {“status”:“Accepted”,“runtime”:12,“memory”:15.3} 这种，你根本没法在本地设断点、查看变量值。

• 这个命令背后就是一次 shell 调用：node leetcode-binary test “path/to/solution.cpp” -t “[[1,2],[3,4]]”。
• 就算你在 src/leetCodeExecutor.ts 里加个 debugger，那也只有当你是在插件开发模式（按 F5 启动 Extension Development Host）下才会生效。
• 平时刷题时右键选“Run Test Case”，走的就是这条路——它既不关心你本地有没有装 gdb，也不读你配置的 tasks.json。

想本地调试 LeetCode 题目代码？那就绕开插件，直接跟编译器对话

如果你想单步跟踪看看 vector 的内存布局是怎么变的，或者检查递归调用栈，那就得脱离插件，直接用 VSCode 原生的调试能力。这里的关键不是装没装对插件，而是配没配好 launch.json 和真实的可执行文件。

• 对于 C++：确保 g++ 已经在系统的 PATH 里，并且在项目根目录下要么有 CMakeLists.txt，要么手动写个 tasks.json 去调用 g++ -g -o main main.cpp。
• 对于 Python：相对简单，不需要额外配置。在 launch.json 里把 “program” 设为 “${file}” 就行。但有个麻烦点：你的测试用例得硬编码到脚本里，比如 assert Solution().twoSum([2,7,11,15], 9) == [0,1]。
• 一个常见的“坑”：插件传过来的 testString 是字符串格式的 JSON，而本地调试需要的是原生数据结构。千万别直接把插件生成的那个测试字符串原封不动地喂给你的 main() 函数，格式不对，肯定会出问题。

实现自动化测试，得靠“文件驱动”，而不是点插件按钮

插件自带的“Run Test Case”一次只能手动触发一条用例，根本没法做批量回归。真要搞自动化，就得自己动手组织好测试文件的结构，然后用脚本去驱动它。

• 推荐的目录结构：比如在 problems/1_two-sum/ 这个目录下，同时放 solution.cpp 和 test_cases.json（这个 JSON 文件里每一行存一组输入输出对）。
• 写个脚本驱动：写一个 Python 脚本，让它来读 test_cases.json。脚本里调用 subprocess.run([“g++”, “-g”, “solution.cpp”, “-o”, “a.out”]) 来编译，再用 echo ‘[2,7,11,15] 9’ | ./a.out 的方式来测试。
• 容易被忽略的一点：LeetCode 的输入格式（比如 [[1,2],[3,4]]）和你本地 cin 的解析逻辑必须完全一致。否则就会出现本地测试全过，一提交就失败的情况。

这里还有个最容易忽视的点：插件设置里的 leetcode.defaultLanguage，它只控制新建题目时的默认文件后缀名，根本不影响真正的执行环境。你拿一道 C++ 的题目，就算用 Python 调试器也照样能跑起来，只不过类型检查的逻辑和断点位置会完全错位——所以，别太相信那个设置项，要紧盯着 launch.json 里的 configurations 配置和终端里真正敲下去的命令。