news 2026/9/9 5:42:53

电机控制技术演进:从STM32 FOC到车规级芯片平台开发

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
电机控制技术演进:从STM32 FOC到车规级芯片平台开发

1. 从实验室到流水线:我的电机控制技术路线图

这些年我一直在一线做嵌入式开发,从早期摆弄有刷电机、用PWM调速开始,到现在做车规级芯片的平台化开发,中间的路程跨度挺大,但回头看,所有核心能力都是围绕电机控制这个起点长出来的。电机控制看起来是个老领域,但越是深入越发现它像一棵大树的根,往下扎得越深,上面能长出的枝干就越多——无论是后来做STM32G4系列的高性能FOC,还是转战车规芯片的AUTOSAR平台适配,底层那套对电流、转速、位置的“三环”理解,始终是我吃饭的本钱。

这篇“序章”我想把整套技术演进路线完整梳理一遍。内容会从电机控制的基础原理入手,拆解FOC控制、BLDC驱动、PWM调速这些核心概念,然后结合我自己用STM32F407ZGT6驱动大疆3508电机的实操经历,展开电机三环控制的调参细节、多电机协同位置控制的难点,再到Proteus仿真、全速域仿真这些工具链怎么配套使用。最后聊聊从电机控制往车规芯片平台开发转型的路线图,包括两者之间哪些技能能直接迁移、哪些思维需要推倒重建。这篇文章适合正在学电机控制的学生、刚入行的嵌入式工程师,还有那些打算往汽车电子方向转的朋友,我希望把那些文档里不写、课堂里不讲的实战经验一次性讲透。

2. 电机控制全景:先搞清楚你在控什么

2.1 有刷、BLDC、FOC——不同电机不同的控制思维

电机控制的第一步不是写代码,而是先认清你手里这个执行器的脾气。我最早接触的是有刷电机,结构简单得感人:电刷换向,通电就转,调速就是调电压,PWM一给,占空比越大转速越高。用STM32输出两路互补PWM加上一个H桥驱动,一个礼拜就能搞定正反转和加减速,这种“暴力直接”的控制方式特别适合入门,能让你快速建立对PWM调速、死区时间、电流纹波这些基本概念的直觉。

但真正让电机控制变得有技术含量的是无刷电机。BLDC(无刷直流电机)把机械换向变成了电子换向,转子是永磁体,定子绕组靠驱动器按顺序通电产生旋转磁场。这里立刻冒出一个关键问题:你怎么知道转子当前在哪个位置?所以BLDC控制的第一步往往是反电动势过零检测,通过检测不导通相上的反电动势来确定换向时刻,这就是所谓的“六步换向法”。它实现简单、成本低,但有一个天生的毛病——转矩波动大,低速表现尤其拉胯。

FOC(Field-Oriented Control,磁场定向控制)就是冲着这个痛点来的。它的核心思路是把三相交流电流通过Clark变换从abc坐标系转到αβ坐标系,再用Park变换从αβ旋转到dq坐标系,让交流电机在数学上“变成”直流电机来控制——你不再需要头疼三相正弦波怎么精确跟踪,只需要控制d轴电流和q轴电流两个直流量就行。id控制励磁,iq控制转矩,两者解耦之后,转矩响应能做到毫秒级,低速平稳性、高速弱磁性能都甩开六步换向几条街。我现在做车规平台,里面驱动电机、转向电机、油泵电机几乎清一色FOC方案,就是因为它在全速域范围内的控制品质最稳定。

2.2 电流环、速度环、位置环:“三环”才是电机控制的灵魂

FOC听起来高级,扒开来看骨架其实就是三个嵌套的控制环。最内层是电流环,直接控制电机绕组里的电流,它的带宽决定整个系统的动态响应上限,一般要求电流环的响应速度是速度环的5到10倍,调参时PI参数给得激进一些,但也不能激进到振荡。中间是速度环,它把编码器测到的实际转速和指令转速做差,输出给电流环作为给定,带宽通常是电流环的十分之一到五分之一。最外层是位置环,只在需要精确到位的时候才用,常见于舵机、机械臂关节、云台这类场景。

三环嵌套的结构本质上是一种“层层兜底”的设计哲学:内环越稳,外环越好调;外环出了问题,内环还能把系统拽住不至于飞车。我调试3508电机的时候最深的体会是:千万不要一上来就去调位置环的PID,那会是一团乱麻。正确顺序是从内往外逐个闭环:先把电流环的PI调到一个不振荡的临界状态,然后锁住电流环去调速度环,最后才是位置环。每一层闭环都确保稳定了再接下一层,看似慢,实际上是最快的路径。

这里也要提一嘴PWM频率这个很多人忽略的底层参数。PWM频率太低,电流纹波大,电机发热明显,噪音也刺耳;PWM频率太高,开关损耗上来了,驱动芯片发热严重。我常用的经验值:有刷电机直接调速用10kHz到20kHz,FOC的PWM频率一般选20kHz左右,这样既超出人耳听觉范围避免啸叫,又不会让MOS管的开关损耗失控。STM32F407ZGT6和STM32G4的定时器都能轻松输出多路高分辨率PWM,但注意G4系列内置了硬件数学加速器(CORDIC和滤波协处理器),算Park变换和PI运算的耗时能比F407省掉将近一半,做FOC的时候优势非常明显。

3. 实操拆解:从STM32控制3508电机到多电机协同

3.1 硬件选型与电气连接:F407ZGT6驱动3508的完整方案

先说说我最早做的“标准实验平台”:主控是STM32F407ZGT6,电机是大疆RoboMaster的M3508无刷电机,配套的驱动器是C620电调。这个组合在学生竞赛和实验室里非常常见,原因很简单——M3508自带减速箱、内置霍尔传感器,配合C620能直接接收PWM或CAN指令,上手门槛特别低。

F407ZGT6这芯片的IO资源丰富,主频168MHz,带多个高级定时器,输出6路PWM驱动三相全桥完全够用。但要注意,F407本身没有内置CAN收发器,需要外挂一个TJA1050这类CAN收发芯片,连接到定时器的刹车输入或者直接走FDCAN外设。实际上,用CAN总线控制C620比PWM更推荐,因为CAN是差分信号、抗干扰强,而且一条总线上可以挂多个电调,天然支持多电机协同。

硬件连接上有个关键点必须提醒:功率地和信号地必须共地。C620电源端和电机母线是高压大电流回路,STM32这边的控制信号是3.3V逻辑,两者如果不共地,CAN或者PWM信号的参考电位就会漂移,轻则通信误码,重则烧毁主控。我第一次搭系统就吃过这个亏,CAN信号一直乱码,查了半天最后发现是电源模块的隔离地没处理好。

3.2 从PWM到CAN:控制指令链路的“最后一公里”

C620电调同时支持PWM和CAN两种控制方式。PWM方式很直观:50Hz到500Hz的PWM信号,脉宽500us到2500us对应-10000到+10000的电流给定值,控制频率低、精度一般,适合快速验证。CAN方式则是标准做法:每毫秒发送一帧8字节的数据,其中前4字节是电流值(int32),后4字节是角度值和速度值回传,电调会以1kHz的频率回传电机的实际转速、位置、电流等状态。

这里有个重要设计决策:控制频率到底跑多高?我的做法是CAN发送频率设在1kHz,也就是控制周期1ms。这个频率下,速度环和电流环都有足够的时间余量,同时CAN总线负载可控。如果你追求更高的动态响应,可以提升到2kHz甚至5kHz,但这时候主控的调度压力会增大,而且C620电调内部有电流闭环,外部再给高频电流指令意义不大。

下面是C620电流指令的实际发送代码(基于STM32 HAL库的CAN驱动):

/* C620 电流指令帧 */ typedef struct { int16_t current_value; // 电流值 -10000~+10000,对应-20A~+20A uint8_t control_byte; // 控制字,默认0 uint8_t padding[2]; // 填充字节 } C620_CMD_Frame; /* 组帧并发送 */ void C620_SendCurrent(uint8_t motor_id, int16_t current) { CAN_TxHeaderTypeDef tx_header; uint8_t tx_data[8]; uint32_t mailbox; tx_header.IDE = CAN_ID_STD; // 标准帧 tx_header.RTR = CAN_RTR_DATA; tx_header.DLC = 8; tx_header.ExtId = 0; tx_header.StdId = motor_id; // 电机ID,0x1FF为广播帧 C620_CMD_Frame frame; frame.current_value = current; frame.control_byte = 0; frame.padding[0] = 0; frame.padding[1] = 0; memcpy(tx_data, &frame, 8); HAL_CAN_AddTxMessage(&hcan, &tx_header, tx_data, &mailbox); }

这段代码看着简单,但有几个坑要提醒:C620的电流值是带符号的int16,正负号决定电机转向;发送ID要和电调上拨码开关设置的ID一一对应;如果使用0x1FF广播帧,所有电调都会同时执行同样的指令,这在多电机同步测试时很有用,但正式闭环控制时不要用广播帧。

3.3 三环PID调参的实战顺序:我的“慢即是快”方法

调参是整个电机控制实操里最磨人、也最能积累经验的部分。我总结出一套“由内向外、逐环闭环”的调试法,现在带学生做毕设也是按这个套路。先用开环(直接给固定PWM或固定电流)确认电机能转、方向正确、编码器读数光滑,然后才进入闭环。

第一步调电流环。在FOC里电流环PI参数一般直接套用理论值:比例系数Kp= Ls / (3 * Tpwm * Kt),积分系数Ki = Rs / (3 * Tpwm * Kt),其中Ls是相电感、Rs是相电阻、Tpwm是PWM周期、Kt是转矩常数。不过实际中我都是从小到大试,先设Kp为理论值的30%,Ki先给0,给定一个阶跃电流指令,观察dq轴电流的跟踪波形,如果没有振荡就逐步加大Kp,直到出现轻微超调再往回调一点。

第二步调速度环。速度环的输出就是电流环的给定,所以先把电流环关掉,用速度环直接输出电流指令。方法还是老一套:给定一个目标转速,观察实际转速曲线,先调Kp让响应变快,再调Ki消除稳态误差。这里容易犯的毛病是Kp给的太大导致转速过冲然后来回振荡,听到电机发出“嗡嗡”的共振声就说明参数太激进了。

第三步调位置环。位置环的输出是速度给定,通常只用PD控制,不加积分项,因为积分容易导致到位后的稳态振荡。调试时可以先给一个小的阶跃位置指令,观察响应曲线,调Kp让到达目标位置的速度快而不冲,再调微分项Kd压制超调。位置环是最容易“调疯”的一环,我见过不少人花一整个下午就为了消掉一个小小的超调量,最后发现其实是速度环带宽不够导致的,所以前面每一步的稳定都是后面步骤的地基。

3.4 CSP多电机协同位置控制:当一颗芯片操控一支机械臂

单电机玩明白之后,多电机协同才是真正拉开差距的地方。“CSP多电机协同位置控制”这个词在竞赛圈和工业机械臂领域已经不算新鲜,它的本质是:多个电机在同一个控制周期内,各自运动到指定位置,而且彼此之间保持严格的时间同步。

我在一个六轴机械臂项目里实现过一套基于CAN总线的主从式协同方案。主控用F407ZGT6,六个关节电机每毫秒广播一次同步帧,然后依次给六个电调发送各自的位置指令。由于CAN总线是广播式的,天然具备同时性,但这不代表执行会同步——每个电机的负载不同、摩擦不同,实际到达目标位置的时间会有差异。为了解决这个问题,我在位置环外面加了一层虚拟主轴(Virtual Master)同步机制:所有轴不是独立追踪自己的目标位置,而是共同追踪同一个虚拟主轴的位置,每个关节按照虚拟主轴的位置插值计算自己的期望位置。这样六个轴在运动过程中始终是一条合成轨迹,不会出现“某个轴提前到位、其他轴还没走完”的脱节现象。

这种“虚拟主轴”思想特别适合传送带追剪、飞剪、印刷套准这类需要严格同步的工业场景,后来我做车规芯片平台开发时,发现新能源汽车里的四轮独立转向、电子差速控制也用到了同样的同步思路。说到底,多电机协同的核心不是单点控制得好,而是多点的“时钟一致”和“轨迹一致”。

4. 仿真先行:Proteus、全速域仿真和PLC场景的价值

4.1 Proteus电机控制仿真:硬件还没到,代码先跑起来

很多人觉得Proteus仿真就是个玩具,画个原理图、点个LED,没什么技术含量。但我在做电机控制项目时,反而把Proteus用出了价值。尤其是在手头硬件还没到齐的时候,提前用Proteus搭一个STM32+电机驱动的虚拟原型,先把控制流程图、PWM输出的逻辑、按键和显示的交互调通,等硬件一到就能直接烧录验证,省下的时间非常可观。

Proteus里做电机控制仿真要把注意力放在“逻辑”而不是“精度”上:它的虚拟示波器能看PWM波形占空比的变化,虚拟终端能调通串口通信逻辑,这些对早期验证足够了。不过说句实话,Proteus的电机模型远远达不到FOC调试所需的精度——你没法在Proteus里调出漂亮的电流环阶跃响应,它模型的机电常数、反电动势波形都和真实电机有差异,硬要靠仿真调PID参数就是刻舟求剑。所以我的使用原则是:Proteus用来验证代码流程和通信逻辑,真实电机参数的整定必须放到硬件平台上做。

4.2 全速域电机控制仿真:为什么实验室好用的方案一上车就崩

“全速域”这三个字是我在从实验室控制走向工程化控制时第一次真正理解的词。实验室里测试电机,通常就是空载或者轻载跑几个固定的转速点,PI参数在这几个点调得顺手就以为大功告成了。但电机一旦装到车或机械臂上,会面对零速启动、低速重载、高速弱磁、负载突变等一整套极端工况,这时候你会发现原来那套参数在低速段振荡、高速段跟不上、重载时还带不动。

全速域仿真解决的就是这个问题:它把电机模型放在一个完整的工况循环里跑,包括满载启动、阶跃变速、正反转切换、堵转恢复这些工况。我建议用MATLAB/Simulink搭一套完整的FOC仿真模型,电机用永磁同步电机的数学模型,逆变器用平均模型,在最外层叠加一个工况序列,然后把电流环、速度环的PI参数放在里面扫一遍,看哪个参数组合在整个工况集下的综合表现最好。这种“参数面”的寻优方式比单个工况调参更全面,也是从“调参员”走向“控制系统工程师”的必经之路。

做这类仿真我最大的心得是:不要迷信PI参数能通吃所有工况,现代做法是在电流环用PI,在速度环和位置环引入自抗扰控制或者模型预测控制的思路,至少要在调参时加入对负载转矩的前馈补偿,否则高速轻载往低速重载切换的那一刻,系统的表现一定让你头疼。

4.3 三菱PLC的485控制电机:工控现场的另一片天空

聊完嵌入式MCU方案,还得提一嘴工控现场最常见的PLC方案。三菱PLC通过485总线控制变频器或伺服驱动器,在产线设备、风机水泵、传送带这类场景里遍地都是。和STM32+FOC这种“全自研”路线不同,PLC方案的核心是“选型与组态”而非“算法”——你不需要自己写电流环,变频器内部都帮你处理好了,你要做的是把启停、频率给定、加减速时间这些工作通过485总线配置好。

三菱FX系列PLC走485通信控制变频器,一般用Modbus RTU协议,通过RS-485总线发送写保持寄存器指令,控制变频器的启停和频率设定值。下面是典型的通信报文格式示例:

发送:01 06 20 00 0BB8 CRC // 将站号1的变频器频率设定寄存器(0x2000)写入3000(0x0BB8) // 含义:地址码=01,功能码=06(写单个寄存器),寄存器地址=0x2000, // 写入数据=0x0BB8(300,对应30.0Hz),CRC校验由PLC自动计算 发送:01 06 20 01 0002 CRC // 将站号1的变频器控制字寄存器(0x2001)写入0x0002 // 含义:0x0002通常对应“正转运行”指令

这套玩法在工业现场比嵌入式方案更加“皮实”,它不需要你自己处理死区、换向、电流保护,因为变频器都内置了完善的保护逻辑。PLC的梯形图编程也更适合电气工程师去维护。我当时在产线调试时总结出一个经验:PLC控制电机适合“设备级”控制——启停、调速、正反转、报警处理;而STM32这类MCU适合“算法级”控制——FOC、多轴同步、在线调整。两个方向不矛盾,关键看项目需求落在哪个层级。

5. 从电机控制到车规芯片平台开发:技能迁移与认知升级

5.1 车规芯片平台到底在做什么

很多人问我说“我做电机控制做得好好的,为什么要转车规芯片平台开发”。我当时的理解是:电机控制是“用芯片去控制电机”,车规芯片平台开发则是“为控制电机的芯片搭建一套可靠的运行平台”。这里面有本质的区别——前者关心控制算法,后者关心芯片本身能不能在车内环境里稳定运行几万小时。

车规芯片和普通MCU相比,多了一大堆“约束”:工作温度范围要覆盖-40℃到125℃,要满足AEC-Q100的可靠性认证要求,要支持功能安全标准ISO 26262(至少ASIL-B级别),要具备ECC内存、时钟监控、电源监控这些安全机制。所以车规芯片平台开发的工作内容,远不止“写驱动”这么简单:你要做MCAL(微控制器抽象层)的配置适配,要把AUTOSAR的软件架构在具体芯片上跑通,要做功能安全相关的内存保护和时钟监控,还要在HIL(硬件在环)台架上做故障注入测试,验证芯片在极端工况下的行为是否符合预期。

5.2 哪些电机控制技能可以直接迁移

我刚转做车规平台时,最开始以为以前积累的嵌入式技能全都要推倒重来,后来发现不是这样。里面有一大块能力是完全能平滑迁移过来的:

第一是外设驱动的底层理解。电机控制里你对定时器PWM、ADC采样、CAN通信、编码器接口的寄存器级操作烂熟于心,这些东西在车规芯片上原理完全一样,只是寄存器名变了、外设模块增强了一些。比如我在STM32上玩得很熟的CAN外设,到了英飞凌TC3xx或者恩智浦S32K系列上,帧结构、波特率配置、报文过滤的逻辑都通用。

第二是中断和实时性思维。电机控制对中断延迟极度敏感,FOC一个控制周期ms级,中断里做的事情必须极简,这种实时系统的思维迁移到车规平台非常值钱。车规平台里大量功能都有严格的时序要求,比如安全相关的监测任务必须在几毫秒内响应,你的中断优先级设计、临界区保护、任务调度经验直接能派上用场。

第三是调试与定位手段。逻辑分析仪看波形、示波器查信号完整性、在调试器里设断点看寄存器状态,这些基本功是跨平台通用的。你会FOC调参时“看电流波形”找出问题根源的能力,迁移到车规平台上就是“看电压监控寄存器的变化规律”定位故障源,方法论是相同的。

5.3 需要重建的认知:功能安全、MBD与AUTOSAR

迁移过来的东西很多,但需要重建的东西也绝不能轻视。最大的差距在于功能安全思维。电机控制里死机了顶多复位重启,但在车里,死机可能意味着转向助力失效或者刹车失灵,这是人命关天的事。所以车规开发从头到尾都贯穿着“如果这里出错了会怎么样”的反思,FMEA(失效模式与影响分析)、FMEDA(失效模式影响与诊断分析)、故障树分析这些方法需要重新学习,而且要接受“设计必须冗余”的理念——一个传感器信号可能同时被两路ADC采样,一路异常时系统要自动切换到另一路或者进入安全状态。

其次是模型化开发(MBD)的工程范式。电机控制时代我习惯直接写C代码,调试看波形;车规平台开发推崇基于模型的设计,控制逻辑先在Simulink里建模,自动生成C代码,再部署到目标芯片上。刚开始我觉得这简直是脱裤子放屁,代码要是我手写更简洁。但接触下来才明白,MBD的价值在于模型本身可以直接做形式化验证、单元测试、覆盖率分析,这些对功能安全认证是必需的。代码好不好看不是重点,重点是“可证明正确”。

最后是AUTOSAR软件架构。普通嵌入式开发里你想怎么写就怎么写,函数随便放;AUTOSAR把软件分成应用层、RTE(运行时环境)、基础软件层,每一层的接口、时序、配置都是标准化约束。刚开始做AUTOSAR适配的体验就像是从自由写作变成写格律诗,处处是规则。但适应之后你会理解为什么车厂都愿意用这套标准——软件组件可以在不同芯片平台之间复用,供应商之间的接口统一,整个产业链的协作效率大幅提升。

5.4 拓展方向:直线电机控制与车规芯片的“交集”

最后聊聊一个特别有意思的交叉方向——直线电机控制。直线电机可以想象成把旋转电机的定子和转子“展开”成一条直线,动子直接做直线运动,省掉了旋转到直线运动的传动机构。在新能源汽车里,直线电机技术被用在主动悬架、电磁制动这些前沿领域,和车规芯片平台开发形成了天然的交集。

直线电机和旋转电机的FOC控制原理相似,但多了一个难题:动子位置是无限行程的,没有一圈一圈的周期,所以位置检测不能用增量式编码器,要么用绝对式光栅尺,要么用磁栅尺,而且换向时的位置估计算法要处理端部效应。我在实验室验证过一版直线电机动子的S曲线位置规划算法,底层还是三环结构,但位置环不再是简单的PID能搞定的,需要加前馈和S曲线加减速规划,否则动子高速移动到位时会剧烈冲击。

这和车规芯片平台开发有什么关系?关系大了。直线电机动子的精确定位需要高速、高实时性的位置反馈处理,而车规芯片的片上硬件模块(比如高分辨率定时器、硬件位置管理单元)就是为这类任务设计的。我在车规平台上实现过一个基于硬件位置管理单元的位置同步触发功能:电机走到某个精确位置时,硬件自动触发ADC采样或者PWM更新,完全不需要CPU干预。这一套逻辑,如果只停留在通用MCU层面,你是接触不到的,一定要有车规芯片平台的经验才能真正上手。所以我的建议是:如果对电机控制有深入的理解,再叠加车规芯片平台的能力,在电动化、智能化的产业浪潮里,你会发现自己处于一个相当有竞争力的交叉位置。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/9 5:42:27

Humanizer:面向真实交互的语义校准方法论

1. 项目概述:这不是一个“拟人化工具”,而是一套面向真实交互场景的语义重塑方法论最近在多个技术社区和产品团队内部讨论中,“humanizer”这个词高频出现,但它既不是某个新发布的SaaS产品,也不是某家大厂刚开源的AI模…

作者头像 李华
网站建设 2026/9/9 5:42:26

Python列表参数全解析:可变默认值、原地修改与引用传递陷阱

我最早被列表参数坑到,是在一个库存盘点脚本里。当时写了个函数,负责把某个仓库的退货商品加进一个公共的待处理列表,结果每次运行完,主流程里的原始列表都被"顺手"改掉了——新增的商品跑到了所有分支的共用数据里&…

作者头像 李华
网站建设 2026/9/9 5:42:09

ponytail:面向前端开发期的轻量级能力调度 CLI 工具

1. “Ponytail”不是发型,是前端开发者圈里悄悄流传的 CLI 工具代号最近在几个前端技术群和 GitHub Trending 页面反复刷到ponytail这个词——它既不是新出的 UI 框架,也不是某个明星开源项目,更不是某家大厂的内部工具代号。它安静地躺在 np…

作者头像 李华
网站建设 2026/9/9 5:38:30

WPF 精美左侧菜单栏实战:从数据绑定、MVVM 到自定义模板

简介:面向WPF桌面应用开发者的左侧菜单栏源码包,聚焦于使用XAML与C#构建美观、可交互的导航界面,适合需要快速实现侧边栏布局或深入学习Menu控件定制的中初级开发者。压缩包内共49个文件,以cs后台逻辑、xaml界面布局、config配置为…

作者头像 李华
网站建设 2026/9/9 5:37:40

技能管理实战:从硬技能到刻意练习,打造可调用的核心竞争力

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/9 5:37:33

C语言预处理指令全解析:宏定义、头文件与条件编译实战

用C语言写东西,时间长了你会发现一个规律:程序里最隐蔽、最磨人的bug,往往不是算法写错了,也不是指针用飞了,而是栽在与#开头的行上。宏定义、文件包含、条件预处理,这些在编译正式开始之前就被“处理掉”的…

作者头像 李华