g++默认不生成.exe，Linux/macOS下默认输出a.out且无扩展名；Windows下需用-o显式指定main.exe等名称，否则生成的可执行文件无.exe后缀。
g++ 默认不生成 .exe，得加 -o 指定输出名
在 Linux/macOS 上，g++ 编译出来的可执行文件默认没有扩展名；Windows 下即使用了 MinGW-w64 或 MSYS2 的 g++，也不会自动加 .exe 后缀——它只按你写的 -o 参数来命名。
常见错误现象：g++ main.cpp 之后运行 ./main.exe 报错 “No such file or directory”，其实是因为生成的是 a.out（默认名）或没加后缀的 main，根本不存在 main.exe 这个文件。
- 正确做法：用
-o显式指定带.exe的名字，比如g++ main.cpp -o main.exe - Windows 下若用 MSYS2 的 UCRT64 环境，生成的
main.exe可直接双击或命令行运行，依赖的 DLL（如libstdc++-6.dll）需在 PATH 中或同目录 - 不要依赖 IDE 自动生成的
.exe名——那是 IDE 封装了-o参数，命令行里不写就不会有
链接阶段决定能不能跑：缺 -l 或 -L 就会报 undefined reference
生成 .exe 文件只是链接成功的结果，不代表它真能运行。很多“生成了但一运行就崩溃/找不到 DLL”的问题，实际出在链接时没把依赖库带全。
典型场景：代码用了 std::regex 或 std::thread，但没告诉链接器要拉 libstdc++ 的线程/正则支持模块。
立即学习“C++免费学习笔记（深入）”；
- 必须加
-pthread才能用std::thread、std::mutex等，否则链接时报undefined reference to `pthread_create' - 某些标准库组件（如 regex）在部分 GCC 版本中需额外链接：
g++ main.cpp -o main.exe -lstdc++fs（C++17 filesystem）或-lstdc++显式补全 - 自定义库路径要用
-L/path/to/lib+-lmylib，顺序不能颠倒；-L必须在-l前面才生效
预处理和编译参数影响最终二进制行为
g++ 命令里混进的 -D、-I、-std= 看似只管编译，实则直接决定生成的 .exe 能不能在目标环境跑通。
-
-std=c++17和-std=c++20生成的符号名（mangled name）不同，混用会导致链接失败，哪怕都生成了.exe -
-D_DEBUG会激活 assert、调试日志等，而-DNDEBUG会删掉它们——同一份源码，参数不同，生成的.exe行为可能完全不同 -
-I/path/to/headers错了，预处理阶段就找不到头文件，根本到不了生成.exe这步；但错误提示常被误读成“链接失败”
Windows 下动态库路径是隐形陷阱
生成了 main.exe 不等于双击就能运行——MinGW-w64 编译出的 EXE 依赖 libgcc_s_seh-1.dll、libstdc++-6.dll 等，系统 PATH 里没有，就会弹窗报 “MSVCP140D.dll 缺失”（其实是混淆了 MSVC 和 MinGW 的运行时）。
- 最稳方案：用
-static-libgcc -static-libstdc++静态链接，生成的.exe自包含，无需外部 DLL - 不想静态链接？就把 MinGW 的
bin/目录加进 Windows PATH，或者把对应 DLL 复制到.exe同目录 - 别信网上“下载 MSVCP140D.dll 放进去就行”——那是 MSVC 的调试版 DLL，和 MinGW 完全不兼容，强行放只会崩溃
.exe 就是废文件。 
