GCC参数顺序不重要，但带值选项如-o、-I、-D、-l必须紧邻其值；-c和-o需同时出现且-o后为.o文件名；-g与-O共用会降低调试体验；-L必须在对应-l之前。
参数顺序不重要，但参数和值必须紧邻
GCC 不强制要求选项顺序，-g -O2 -o app main.c 和 main.c -o app -g -O2 效果完全一样。真正容易出错的是带参数的选项——-o、-I、-D、-l 这类必须紧跟其值，中间不能插入其他选项。
常见错误写法：gcc -o -g app.c（-g 被误认为是 -o 的参数），正确应为 gcc -g -o app app.c 或 gcc -o app -g app.c。
-
-I后必须立刻跟路径，如-I./include，不能写成-I -g ./include -
-D定义宏时，-DDEBUG=1是合法的，-D DEBUG=1（空格分隔）会导致宏名变成DEBUG=1字面量，而非预处理符号 -
-l链接库时，-lpthread有效，-l pthread（带空格）会被当作两个独立参数，链接失败
-c 和 -o 搭配时最容易漏掉目标文件名
用 -c 编译单个源文件时，如果不显式用 -o 指定输出名，GCC 默认生成 xxx.o（比如 main.c → main.o）。这在单文件场景下没问题，但多文件时容易混淆或覆盖。
更危险的是：忘记加 -c 却写了 -o xxx.o，比如 gcc -o utils.o utils.c。GCC 会尝试链接，报错类似 /usr/bin/ld: cannot find crt1.o 或 undefined reference to `main' —— 因为它以为你要生成可执行文件，却没找到入口符号。
- 编译目标文件务必确认同时出现
-c和-o，且-o后是.o文件名 - 推荐统一风格：
gcc -c -o main.o main.c，把-c放前面，视觉上更易识别“这是编译阶段” - 多个源文件批量编译时，避免依赖默认命名，显式指定每个
-o，防止同名覆盖
调试与优化组合要小心 -O 和 -g 的协同
-g 和 -O2 可以共存，但调试体验会打折扣：优化可能内联函数、删掉未使用变量、重排代码顺序，导致 GDB 单步跳转不连贯、局部变量显示为 <optimized out></optimized>。
这不是 bug，而是优化的自然结果。真要边调边优，建议分两套配置：
- 开发调试用：
gcc -g -O0 -Wall（关闭优化，保留完整调试信息） - 发布构建用：
gcc -O2 -g -DNDEBUG（保留符号用于 crash backtrace，但关掉断言和调试逻辑） - 绝对不要用
-O3 -g做日常调试——栈帧被大幅简化，backtrace可能断裂，step行为不可预测
链接阶段的 -L 和 -l 顺序很关键
-L 指定库搜索路径，-l 请求链接具体库，但 GCC 解析顺序是从左到右，且只对后续出现的 -l 生效。写成 gcc main.o -L./lib -lcrypto -lssl 是对的；但若写成 gcc main.o -lcrypto -L./lib -lssl，-lcrypto 就找不到，因为 -L 还没生效。
另一个坑是静态/动态混链：-static -lpthread 会强制静态链接 pthread，但若系统没装 libpthread.a，就直接失败；而 -lpthread -static 则只对 -lpthread 生效，后面的库仍走动态。
- 所有
-L必须放在对应-l之前 - 如果要用
-static，最好放在最前，或明确限定范围，比如-Wl,-Bstatic -lcrypto -lssl -Wl,-Bdynamic -lpthread - 不确定库名时，用
find /usr -name "lib*.so*" 2>/dev/null | grep ssl确认实际文件名，再决定写-lssl还是-lssl3
