链接器参数（-L、-l、-static等）必须置于源文件之后、-o之前，否则g++误将库名当源文件导致“undefined reference to 'main'”等错误；多文件需显式列出或改用CMake，${file}仅指当前单文件，通配符*.cpp在tasks.json中无效。
tasks.json 里怎么加链接器参数（-L、-l、-static）
直接往 args 数组里塞就行，但顺序不能错——链接器参数必须放在源文件之后、输出选项（-o）之前。否则 g++ 会把库名当成源文件报错，比如 undefined reference to 'main' 或 no input files。
常见错误写法："args": ["-lglfw", "${file}", "-o", "a.exe"] → g++ 先看到 -lglfw，还没见到源码就去链接，失败。
-
"args": ["${file}", "-L./lib", "-lglfw", "-lopengl32", "-o", "${fileDirname}/a.exe"]✅ 正确：源文件在前，-L和-l紧跟其后 - 静态链接时加
-static-libgcc -static-libstdc++，放在-o前面，避免运行时缺 DLL - Windows 下用
-lopengl32而不是-lGL；Linux/macOS 反之。路径分隔符统一用/，VSCode 自动处理
为什么 ${file} 不能替换成 *.cpp 来链接多个目标文件
因为 g++ 对通配符 *.cpp 的展开发生在 shell 层，而 VSCode 的 tasks.json 是直接调用编译器进程，不经过 shell —— 所以 "*.cpp" 会被原样传给 g++，它找不到叫 “*.cpp” 的文件，报错 fatal error: no input files。
真要链接多个文件，有两个办法：
立即学习“C++免费学习笔记（深入）”；
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
- 显式列出：
"args": ["main.cpp", "utils.cpp", "render.cpp", "-lglfw", "-o", "app.exe"] - 用
${workspaceFolder}/**/*.cpp配合shell类型任务（不推荐，跨平台不可靠），或改用CMake管理多文件构建
注意：${file} 永远只代表当前打开的单个文件，和你有多少个 .cpp 文件无关。
miDebuggerPath 和链接器参数毫无关系，别混在一起配
launch.json 中的 miDebuggerPath 只控制 GDB/Lldb 启动路径，不影响链接行为。有人把 -static 加到 miDebuggerPath 里，结果调试器根本启动不了，报错 Cannot launch program; not found or missing dependencies。
真正影响可执行文件是否能独立运行的，只有 tasks.json 里的链接参数。调试器只读取已生成的二进制，它不管你是动态还是静态链接——除非你静态链接了 libstdc++，否则 Windows 上没 libstdc++-6.dll 就跑不起来，这时候你得看 tasks.json，而不是 launch.json。
Windows 下 -municode 和 -mwindows 这类参数容易被忽略
它们不是标准链接器参数，而是 GCC 的“目标平台开关”，必须出现在 args 里且位置敏感。例如：
-
-municode：让WinMain入口支持 Unicode，否则中文路径/参数可能乱码 -
-mwindows：隐藏黑窗口（console），适合 GUI 程序；但加了它，printf输出就看不到——得用OutputDebugString或日志文件查问题 - 这两个参数要放在
${file}后、-o前，和-l并列，不能塞到environment或options.cwd里
最麻烦的是：一旦用了 -mwindows，VSCode 内置终端默认捕获不到 stdout，externalConsole: true 也未必弹窗——这时候得靠日志或调试断点确认逻辑是否执行。
