使用makefile编译时编译器无法识别flags 非makefile编译运行正常

手动执行编译命令可以正常跑通，说明编译器、程序代码本身没有问题，故障几乎全部出在Makefile的语法、参数传递逻辑上，常见诱因如下：

• 缩进格式错误：这是最高发的问题。Makefile规则要求，目标依赖下行的所有可执行编译命令，必须使用Tab字符做缩进，不能用同等宽度的空格替代。如果误用空格缩进，make工具会跳过命令行的正常传递逻辑，把这一行的内容当成Makefile自身的语法规则解析，最终根本不会把-Wall、-O2这类编译flags传递给编译器，最终报错就会表现为编译器无法识别无意义的字符串，和手动编译的效果完全脱节。
• 变量赋值逻辑错误：定义编译flags变量时，如果等号前后带了不必要的空格，比如写法为CFLAGS = -Wall -g，前置空格会被直接计入变量值，最终传给编译器的参数就会变成带无效前缀的字符串，触发参数不识别报错；另外如果变量名拼写错误，比如定义时写MY_FLAGS，调用时误写为MY_FLAG，也会导致flags没有被拼接到编译指令里，传了空参数给编译器。
• 参数拼接顺序错误：部分编译器对命令行参数的顺序有严格要求，如果Makefile里把源文件写在flags前面，比如编译指令写为gcc main.c $(CFLAGS) -o main，而flags里带了需要链接的库选项，就可能被编译器误判为源文件路径，触发“无法识别参数”的报错。
• 转义逻辑缺失：如果编译flags里包含Shell特殊字符（比如括号、管道符、引号），没有在Makefile里做对应转义，make在传递参数时会直接截断特殊字符前后的内容，剩下的参数残片就会被编译器判定为无效选项。

内容的提问来源于stack exchange，提问作者Gal Zaken