VSCode插件不能盲目依赖“一键配置”，Qt Configure仅支持qmake和cmake，会错误填充meson/autotools项目路径；生成的c_cpp_properties.json需验证includePath是否匹配实际第三方库路径，且跨平台路径不可直接复用。
VSCode 插件能直接生成 c_cpp_properties.json、tasks.json、launch.json 这类配置文件，但前提是插件知道你用的是哪个编译器、哪个 SDK、哪个构建系统。盲目安装“一键配置”类插件，反而容易覆盖已有配置或填错路径，导致调试失败、头文件找不到、gdb 启动报错。
Qt Configure 插件只认得 qmake 和 cmake，不支持 meson 或 autotools
它扫描你指定的 Qt 安装路径（比如 C:\Qt\6.5.0\mingw_64），只找 qmake.exe 和 cmake.exe，并据此推导 includePath、defines 和 compilerPath。如果你项目实际用的是 meson + ninja，插件生成的 c_cpp_properties.json 里仍会硬塞 qmake 的宏定义，结果是 #include <qapplication></qapplication> 能识别，但自定义的 meson.build 中定义的头文件路径不会被补全。
- 验证方式：打开生成后的
c_cpp_properties.json，检查configurations[0].includePath是否包含你项目实际使用的第三方库路径 - 若用 CMakeLists.txt，确保插件扫描到的是你项目根目录下已
configure过的build/目录里的compile_commands.json，否则它只会 fallback 到 Qt 自带路径 - 插件不处理跨平台路径差异——Windows 下生成的
compilerPath是g++.exe，Linux/macOS 用户直接复制过去会报错
ms-python.python 插件的 python.defaultInterpreter 不等于 python.pythonPath
旧版 VSCode 使用 python.pythonPath 指定解释器路径，新版已弃用。如果 settings.json 里还留着这行，插件会忽略它，转而读取 python.defaultInterpreter。更麻烦的是，这个值在不同工作区可能被覆盖：全局设置写的是 /usr/bin/python3，但当前文件夹下 .vscode/settings.json 又写了 ./venv/bin/python，最终生效的是后者——而插件生成的 launch.json 里 python 字段却可能没同步更新。
- 执行
Python: Select Interpreter命令后，插件会在当前工作区的.vscode/settings.json写入python.defaultInterpreter，不是全局设置 - 若项目用
pyenv或conda，必须确保终端启动时已激活对应环境，否则插件检测到的 interpreter 路径可能是系统默认的/usr/bin/python3 -
launch.json中的python字段建议显式写成"${command:python.interpreterPath}"，避免硬编码路径失效
Remote-Containers 的 .devcontainer.json 不能依赖本地 settings.json
容器内运行的 VSCode 实例完全隔离于宿主机，它读取的是容器内部的 /root/.vscode-server 或挂载进来的 .devcontainer/devcontainer.json，而不是你本地 ~/Library/Application Support/Code/User/settings.json。常见错误是：你在本地设置了 "editor.formatOnSave": true，以为容器里也会生效，结果发现保存不格式化——因为容器里压根没加载这个配置。
-
customizations.vscode.settings字段必须显式声明，例如："editor.formatOnSave": true, "python.defaultInterpreter": "/usr/bin/python3" - 插件列表（
extensions）只控制安装行为，不控制启用状态；某些插件（如golang.go）需要额外配置go.toolsGopath才能正常工作 - 如果镜像里没预装
git，即使features声明了git，也需确认该 feature 支持你用的镜像基础（Alpine 和 Debian 的包管理器不同）
真正省时间的不是“一键生成”，而是生成后立刻验证三件事：编译器能否被 tasks.json 正确调用、调试器能否 attach 到进程、补全是否识别你项目里真实存在的类型。任何一步卡住，都要回头检查插件生成的路径是否指向了实际存在的二进制或目录，而不是相信“它应该没错”。
