简介ARMCompiler 5.06(960)是嵌入式开发中常用的ARMCC编译器安装包专门解决ARM 32位处理器上C语言编译、优化与调试问题。它通过Keil MDK工具链可完成ANSI C标准代码编译支持ARM、Thumb、Thumb-2指令集并能针对代码大小或运行速度做优化也可在下载固件前进行模拟验证适合从入门开发者到需要固定编译器版本的工程团队使用。压缩包共3个文件总大小80.52MB其中MSI为主安装程序HTML是releasenotes版本说明EXE负责安装引导拿到后可直接安装、查看更新内容和已知问题省去四处找历史版本的麻烦。该资源已有3594人学习下载目前仍是不少ARM项目选用的编译工具。通过这份资源读者可获得稳定可用的ARMCC 5.06(960)编译器环境配合Keil MDK完成代码优化、在线调试和固件下载同时releasenotes中的变更记录也有助于版本迁移或环境复现时规避兼容性风险提升嵌入式开发效率。1. 老工程卡在 ARMCC 5.06这版编译器到底能救什么做嵌入式开发的人大概都有过这种经历手里维护着一个跑了五六年的老工程代码里到处是__inline、__weak、__attribute__((packed))这类 ARMCC 5 时代的写法换到 Keil MDK 新版本自带的 AC6 编译器一编译就是上百个 error从语法到链接全在报错。改代码业务逻辑还没动光兼容性就够喝一壶。这时候你才明白ARMCC 5.06b960这个老编译器依旧是很多存量项目离不开的东西。这个 MSI 包本质上是 ARM Compiler 5.06 工具链在 Windows x86 平台上的完整发布版包含armccC/C 编译器、armasm汇编器、armlink链接器和fromelf镜像转换工具。它解决的问题很具体让老工程在干净的环境里恢复可重复的构建同时支持脱离 IDE 的纯命令行编译方便做持续集成。适合手里有存量代码、被 AC6 迁移搞得焦头烂额的嵌入式工程师也适合那些想搭自动化构建但被 Keil 图形界面绑住手脚的人。这篇文章把工具链拆开讲从参数到底层脚本再落到实际坑位。2. 编译器工具链全景四个可执行文件的分工与配合2.1 armcc 与 armasmC/C 源码到目标文件的产出规则ARMCC 5.06 的工具链和 GCC 系的差别不小最明显的一点是它默认不遵循 ELF 的那套宽松规则而是用 EABI 规范约束目标文件。armcc负责把.c、.cpp编译成.o目标文件armasm负责把.s汇编文件汇编成.o。两者共同的特点是都有--cpu、--apcs这类架构相关参数。--cpu指定目标内核型号比如--cpu Cortex-M3或者更精确的--cpu Cortex-M4F带 FPU--apcs指定过程调用标准常见的是--apcs /interwork用于 ARM/Thumb 状态切换Cortex-M 系列基本都是 Thumb 指令集这个参数实际是保持 ARM/Thumb 混合代码互操作的兼容性。还有一个容易忽视的参数--split_sections它让每个函数生成独立的段section而不是把所有函数塞在一个.text段里。这个参数直接影响链接阶段的垃圾回收效率配合链接脚本的--remove选项能把未调用的函数从最终镜像里剔除是减小固件体积的经典做法。如果你的老工程没开这个选项而你又想优化 flash 占用加这一个参数通常就能见效。编译阶段最常用的命令形式如下armcc --cpu Cortex-M4F --apcs /interwork --split_sections \ -I./inc -I./rtos/include -DUSE_STDPERIPH_DRIVER -DSTM32F407xx \ -O2 --endianlittle --signed_chars --enum_is_int \ -c ./src/main.c -o ./build/main.o注意几个关键点-I是头文件搜索路径-D定义宏-O2是优化等级--endianlittle指定小端模式--signed_chars让char类型默认有符号ARMCC 默认char是无符号的这是和标准 C 的一个显著差异跨平台移植时最容易踩--enum_is_int强制枚举类型占 4 字节。-c表示只编译不链接输出main.o。如果你的代码里有位域操作或者结构体对齐的强需求--enum_is_int建议保持开启否则不同编译单元对同一枚举类型的大小判断可能不一致结果就是结构体内存布局错位运行时数据全是乱的。2.2 armlink分散加载、段选择和镜像布局的编排者armlink是 ARMCC 工具链里最容易被低估的一个。很多从 GCC 转过来的人习惯把链接脚本.ld文件当成唯一的布局控制手段但 ARMCC 的链接选项和分散加载描述文件.sct是两套互补的机制。armlink用--scatter指定分散加载文件用--ro-base和--rw-base指定只读段和可读写段的基地址。对于内部 flash 和内部 SRAM 都在固定地址的 MCU 工程直接用这两个参数可以省掉写分散加载文件的麻烦--ro-base 0x08000000是 flash 起始地址--rw-base 0x20000000是 SRAM 起始地址。但如果你的工程有外部 SDRAM、有 bootloader 和 app 分区或者需要把某个大数组单独放到外部存储区就必须用分散加载文件。armlink另一个常用选项是--first它指定入口点符号所在的段在镜像中的起始位置。对于 Cortex-M 系列向量表的第一项是初始 SP第二项是复位向量链接器默认把__Vectors符号放在最前面但如果你手动写过启动文件符号名变了就得用--first强制指定。--map选项生成详细的内存映射文件--list指定输出文件名。我在实际项目里习惯把--map --list ./build/app.map加上这个 map 文件几乎是我排查 hardfault、内存越界、变量覆盖的第一手资料。armlink --scatter ./app.sct --entry Reset_Handler --first __Vectors \ --map --list ./build/app.map \ ./build/startup.o ./build/main.o ./build/stm32f4xx_it.o \ --library-path ./lib --librarylibc.a -o ./build/app.axf这里的--entry Reset_Handler声明复位入口--first __Vectors让向量表占据镜像头部--library-path和--library指定要链接的库。-o输出的是.axf文件它包含调试信息和符号表是烧录前最后的中间产物。如果链接后__main符号找不到多半是 C 库初始化代码没有被拉进来检查一下是不是漏了--library或者链接顺序有误。2.3 fromelf生成烧录文件、反汇编与镜像校验fromelf是工具链里最灵活的一个它把.axf转换成各种目标格式。最常用的是生成 Intel HEX 和二进制文件fromelf --bin ./build/app.axf -o ./build/app.bin fromelf --i32 ./build/app.axf -o ./build/app.hex--bin输出纯二进制烧录时需要指定起始地址--i32是 32 位 Intel HEX自带地址信息用烧录器直接加载就行。另外fromelf还能反汇编fromelf --text -c ./build/app.axf -o ./build/app.dis生成带 C 源码混排的汇编清单调试 hardfault 时拿这个对照着看效率高很多。我一般会在每次出固件后顺手生成一份.dis压缩存档后续出问题对比查证非常有用。反汇编时推荐用--disassemble或者--disassemble-with-source。前者输出纯汇编指令后者会把对应的 C 代码行也打进去体积大一些但排错时省事。注意--text和--disassemble不能混用想要完整信息就分开写两条命令输出到同一个.dis文件里。生成.bin后记一个校验习惯用fromelf --text -d把数据段内容打出来看一眼末尾确认没有多余填充字节避免镜像尾部出现垃圾数据这个问题在后续章节会展开讲。3. 纯命令行编译实战不打开 Keil 也能出固件3.1 手动编译的最小完整流程脱离 IDE 编译嵌入式工程最大的好处不仅是自动化更是构建过程完全可追溯。Keil MDK 的图形界面虽然方便但隐藏了大量中间步骤出了问题很难从日志里定位。用命令行之后每一步都可见、可控。最简流程分三步第一步编译所有 C 源文件第二步编译启动汇编文件第三步链接生成镜像。以一个典型的 Cortex-M4 工程为例# 第一步编译 C 源文件假设工程根目录为 proj_root cd proj_root mkdir -p build armcc --cpu Cortex-M4 --apcs /interwork --split_sections \ -I./inc -I./CMSIS/Include -I./Device/ST/STM32F4xx/Include \ -DUSE_STDPERIPH_DRIVER -DSTM32F407xx \ -O2 --signed_chars --enum_is_int --littleend \ -c ./src/main.c -o ./build/main.o armcc --cpu Cortex-M4 --apcs /interwork --split_sections \ -I./inc -I./CMSIS/Include -I./Device/ST/STM32F4xx/Include \ -DUSE_STDPERIPH_DRIVER -DSTM32F407xx \ -O2 --signed_chars --enum_is_int --littleend \ -c ./src/stm32f4xx_gpio.c -o ./build/stm32f4xx_gpio.o # 第二步编译汇编启动文件 armasm --cpu Cortex-M4 --apcs /interwork \ -I./Device/ST/STM32F4xx/Source \ ./Device/ST/STM32F4xx/Source/startup_stm32f407xx.s \ -o ./build/startup.o # 第三步链接 armlink --scatter ./stm32f407_flash.sct --entry Reset_Handler \ --first __Vectors --map --list ./build/app.map \ ./build/startup.o ./build/main.o ./build/stm32f4xx_gpio.o \ -o ./build/app.axf # 第四步生成烧录文件 fromelf --bin ./build/app.axf -o ./build/app.bin fromelf --i32 ./build/app.axf -o ./build/app.hex这段流程中armasm编译启动文件时不需要-c选项它默认就是对汇编源文件做汇编。启动文件里通常会引用一些外部宏定义比如STM32F407xx所以-I要指到包含stm32f4xx.h的路径。链接时--first指定的__Vectors必须在启动文件里有定义否则链接器会报L6218E: Undefined symbol __Vectors。解决办法是检查启动文件里向量表标签名是否被条件编译切掉了或者手写的 startup 文件里是否用了AREA RESET, CODE, READONLY正确声明段属性。3.2 批处理脚本与增量编译策略工程大了以后每次全量编译既慢又无聊。实际项目中我会用批处理脚本配合文件时间戳做增量编译。Windows 环境下借助forfiles或 PowerShell 的Where-Object比较源文件和对象文件的修改时间决定是否重新编译。不过更省心的方案是直接使用 make 工具MDK 安装目录里自带GNUmake或者用 mingw32-make。下面是一个简化的 makefile 片段展示 ARMCC 工具链如何集成进构建系统# ARMCC 工具链路径根据实际安装位置调整 CC C:/Keil_v5/ARM/ARMCC/bin/armcc AS C:/Keil_v5/ARM/ARMCC/bin/armasm LD C:/Keil_v5/ARM/ARMCC/bin/armlink FROMELF C:/Keil_v5/ARM/ARMCC/bin/fromelf CFLAGS --cpu Cortex-M4 --apcs /interwork --split_sections \ -I./inc -I./CMSIS/Include \ -DUSE_STDPERIPH_DRIVER -DSTM32F407xx \ -O2 --signed_chars --enum_is_int --littleend AFLAGS --cpu Cortex-M4 --apcs /interwork SRCS $(wildcard src/*.c) OBJS $(patsubst src/%.c,build/%.o,$(SRCS)) build/%.o: src/%.c $(CC) $(CFLAGS) -c $ -o $ build/startup.o: Device/ST/STM32F4xx/Source/startup_stm32f407xx.s $(AS) $(AFLAGS) $ -o $ app.axf: $(OBJS) build/startup.o $(LD) --scatter ./stm32f407_flash.sct --entry Reset_Handler \ --first __Vectors --map --list build/app.map \ $(OBJS) build/startup.o -o $ app.bin: app.axf $(FROMELF) --bin $ -o $ .PHONY: clean clean: rm -rf build/*.o build/*.axf build/*.map build/*.bin build/*.hex这个 makefile 里有个隐含的坑--split_sections会让目标文件膨胀每个函数一个段链接时如果--remove没生效镜像反而可能变大。所以链接参数里要确认分散加载文件的ANY选择器能覆盖所有生成的段名否则链接器会报类似L6220E: Execution region ... cannot be placed的错误下面章节细说分散加载文件的写法。3.3 分散加载文件.sct的写法与作用域分散加载文件是整个 ARMCC 工具链区别于 GCC 的关键。它的核心作用是告诉链接器哪些段放在哪个地址范围以及加载视图和执行视图如何映射。对于从 bootloader 跳转到 app 的双分区工程.sct文件的执行区地址必须和链接地址完全一致稍有偏差程序就跑飞。一个典型的内部 flash 内部 SRAM 工程的分散加载文件如下; 这是 stm32f407_flash.sct 的完整内容 LR_IROM1 0x08000000 0x00100000 { ; 加载区起始地址 0x08000000最大 1MB ER_IROM1 0x08000000 0x00100000 { ; 执行区只读 *.o (RESET, First) ; 启动文件里的向量表必须放最前面 *(InRoot$$Sections) ; __main、__scatterload 等 C 库启动代码 .ANY (RO) ; 其余所有只读段 } RW_IRAM1 0x20000000 0x00020000 { ; 可读写区起始 0x20000000大小 128KB .ANY (RW ZI) ; 所有可读写段和零初始化段 } }First是 ARMCC 链接脚本语法里的关键修饰符它强制RESET段排在执行区的最前面这比--first参数更直接推荐优先在.sct里用First控制。.ANY是通配选择器表示任意目标文件中的对应段类型。InRoot$$Sections是 C 库初始化代码的特殊段名如果你的工程里没有用到标准 C 库的__main启动流程这段可以去掉但那样就得自己处理堆栈初始化和 C 运行时环境损失很大一般不建议。链接时如果把--scatter和--ro-base同时用--ro-base会被忽略所以要么用分散加载文件要么用简单参数不要混着写。.sct文件里的注释用;不是 C 语言的//写错会导致解析失败报错信息可能很隐晦——比如L6221E: Execution region ... cannot be placed这种看到它先检查.sct语法和地址范围顺序很重要。4. 构建过程实战条件编译、库依赖与镜像校验4.1 条件编译的宏定义传递与生效边界存量工程里条件编译玩得非常多#ifdef满天飞。命令行编译时宏定义通过-D传入但要注意作用域边界。-D定义的宏对所有源文件生效但如果某些源文件里有#undef或者头文件里重定义实际生效值可能和预期不符。排查这类问题时不要只盯着编译器命令先看预处理输出。armcc 支持--preinclude选项可以在编译前强制包含一个头文件用于统一定义某些环境相关宏armcc --cpu Cortex-M4 --preinclude ./preinclude.h -c ./src/main.c -o ./build/main.opreinclude.h里的内容会在源文件第一个#include之前插入适合统一配置#define、#undef和#pragma。我一般会在里面放板级版本号和特性开关避免每个源文件顶部都手动加一堆宏。不过要小心--preinclude对汇编文件不生效汇编器armasm有对应的--predefine选项两者要分开处理。条件编译最让人头疼的场景是某个宏在头文件里被定义但定义值取决于另一个宏而这些宏又分散在多个头文件里。这种情况下依赖 IDE 的虚拟工程文件管理宏定义很容易乱代码移植到命令行环境时必须把宏定义集中化。我的做法是把所有宏定义收敛到一个build_config.h然后源文件里#include它命令行只传一个核心宏-DBUILD_CONFIG_H来兜底确保所有编译单元看到的配置一致。4.2 静态库.a的生成与链接顺序模块化开发中把外设驱动、协议栈、算法封装成静态库是很常见的做法。ARMCC 工具链生成静态库用的是armar命令。假如有一组编译好的目标文件需要归档armar --create ./build/lib_drivers.a \ ./build/stm32f4xx_gpio.o ./build/stm32f4xx_usart.o ./build/stm32f4xx_dma.oarmar --create直接生成.a文件和 GCC 的ar rcs作用类似。链接时通过--library指定库文件armlink --scatter ./app.sct --library./build/lib_drivers.a \ ./build/main.o -o ./build/app.axf链接顺序很关键。armlink和 GNU ld 一样是单遍扫描库出现在命令行的位置决定了符号解析的时机。如果主程序里有符号引用drv_uart_init而这个函数定义在lib_drivers.a里那么lib_drivers.a必须出现在main.o之后。反过来如果你在库里定义了某个弱符号想在主程序里覆盖它顺序又要反过来安排。工程一复杂链接报L6218E: Undefined symbol时先检查是不是库放错了位置这个错误信息往往会指向库文件本身误导你去查源码实际就是顺序问题。还有一种情况库之间有相互依赖比如lib_drivers.a依赖lib_rtos.a链接时要把被依赖的库放后面。如果不确定依赖关系可以考虑用--library重复列出库文件或者干脆把库全部展开成目标文件参与链接牺牲一点编译时间换取定位问题的速度。我调试阶段喜欢直接armar -x解包静态库到临时目录编译链接都直接指定.o等确认无误再重新归档。4.3 镜像的段布局校验方法从 map 文件到 bin 文件出固件前必须做一次镜像体检。第一步是看.map文件里的内存占用总结通常链接器会在文件末尾打印Total RO Size (Code RO Data) 32180 ( 31.43kB) Total RW Size (RW Data ZI Data) 5236 ( 5.11kB) Total ROM Size (Code RO Data RW Data) 32308 ( 31.55kB)这三行数据对应 flash 占用和 RAM 占用。RW Size 包含 ZI零初始化数据这部分不占 flash 但占 RAM。把 RW Size 和芯片 SRAM 容量比较如果超过就说明内存溢出了。还有一种隐患是 RW Size 小但实际运行时堆栈溢出这种需要配合运行时检测这里不展开。第二步是用fromelf交叉验证 bin 文件的头部向量表fromelf --text -d ./build/app.bin -o ./build/app_hexdump.txt head -n 20 ./build/app_hexdump.txt正常 Cortex-M4 的 bin 文件开头应该看到00 00 02 20初始 SP指向 0x20020000 之类的 SRAM 地址和xx xx xx 08复位向量指向 flash 区。如果开头的值完全不是这两个规律大概率链接脚本的--first没生效向量表没放最前面。遇到这种情况不要急着烧录先回头改链接脚本。5. 避坑指南ARMCC 5.06 环境下最常翻车的五个细节5.1 文件编码导致的注释乱码与隐性编译错误源码文件是 GB2312 编码命令行环境下用 UTF-8 终端或者相反中文字符串字面量会乱码更麻烦的是某些中文字符的字节序列恰好包含 C 注释终止符*/的字节组合导致注释提前闭合后续代码全被注释掉编译报一堆悬空错误。解决办法是统一源码编码为 UTF-8并且用--utf8选项显式告诉编译器源文件是 UTF-8。armcc --utf8选项解决的是源码中字符串字面量的编码解释问题。最稳妥的方案是所有源文件另存为 UTF-8不带 BOM命令行加上--utf8头文件同样处理。这个坑在旧工程里非常常见因为早期 Keil 默认用本地代码页保存文件。出问题时编译日志里会出现[error] #27: illegal character in ...或者更让人摸不着头脑的[warning] #188-D: enumerated type mixed with another type。一旦出现这些信息且源码确认没问题先检查文件编码这个概率最高。5.2 --gnu 模式的隐性行为差异很多老工程师喜欢给 ARMCC 加--gnu选项目的是让编译器更贴近 GCC 语法方便代码跨平台。但 ARMCC 的--gnu模式不是完全等同 GCC它只是放宽了一些语法限制比如支持__attribute__的写法更多样但某些 GCC 的内建函数和关键字在 ARMCC 下仍然不兼容。我见过翻车最惨的一次是某开发者把一段在 GCC 下编译得好好的代码直接扔给 ARMCC--gnu模式结果typeof关键字和语句表达式Statement Expression全部报错最后只能逐个替换。所以--gnu模式是兼容层不是万能层。能用标准 C 语法写的就用标准写法少依赖 GNU 扩展后期无论切换编译器还是给别的团队维护都少点坑。另外注意--gnu模式下char类型的默认符号性仍然是 ARMCC 的规则不是 GCC 的规则。如果代码里用char做有符号数运算需要显式加signed限定。这个差异不报错只在运行结果上翻车属于最难排查的一类问题。5.3 启动文件与编译选项的适配问题旧工程的启动文件是早期 MDK 版本生成的当时可能没开 FPU或者内核版本参数不同。换到 ARMCC 5.06 构建时启动文件里的SCB-CPACR寄存器操作如果被#if条件屏蔽掉FPU 实际上没被使能但编译选项却开了--cpu Cortex-M4F后果就是浮点指令一执行立马进 hardfault。排查方法也简单反汇编启动文件看CPACR寄存器的赋值语句有没有编译进去再检查startup.s里的FPU预编译宏和编译命令的-D宏是否匹配。如果启动文件是老版本建议从当前 SDK 包或标准库配套目录里拿一份新的替换。还有一种情况是启动文件里的堆栈大小设置太小。老工程里Stack_Size EQU 0x000004001KB很常见但现在的协议栈和中间件动不动就要 2KB 以上。栈溢出不会在编译期报错只会体现为程序跑飞或者进 hardfault非常隐蔽。拿到一个旧工程第一件事就是检查Stack_Size和Heap_Size必要时增大到0x000010004KB级别同时用调试器的栈水位检测功能观察实际占用。5.4 链接顺序与段名约束导致的镜像异常链接报错L6220E: Execution region ... cannot be placed时很多人会去调.sct文件地址但根源往往是启动文件里自定义段的名字和.sct里的通配符不匹配。比如启动文件里写的AREA RESET, DATA, READONLY如果链接脚本写的是*.o (Vectors, First)那就对不上因为段名是RESET不是Vectors。报错信息会提示某个执行区无法放置看到这个先对照段名。解决方法是统一段名要么把启动文件的AREA改成和其他工程一致要么把.sct的选择器改成实际段名。这类问题在从别的平台移植工程时特别多因为每个开发者的命名习惯不一样。我的习惯是链接脚本里明确列出启动文件的段名避免用模糊通配符*缩小匹配范围的同时也能提前暴露命名冲突。不过要注意列出段名后如果新增了目标文件里包含同名的不同段链接器也会报错这时候要回到命名规范上而不是继续加通配。5.5 C 库初始化与__main的依赖链断裂很多从 GCC 转过来的人会忽略 C 库初始化这回事。GCC 的启动流程里_start负责初始化.data段和.bss段然后跳main。ARMCC 体系里链接器默认把__main作为 C 库初始化入口它会调用__scatterload完成数据段复制和零初始化再跳转到__rt_entry最后才进入用户的main。如果链接时缺了某个运行时库或者--library指定的库路径不对链接器会报L6218E: Undefined symbol __main。解决办法是确认工具链路径里的libc.a存在并且用--library-path指定正确的搜索目录。还有一个容易忽视的点如果工程里用--entry指定了和__main无关的入口函数比如在裸机环境里完全舍弃 C 库自己写初始化那就要在.sct里去掉InRoot$$Sections并自行保证.data和.bss的初始化逻辑。但这种做法会让printf这类标准库函数完全不可用除非你自己实现了fputc等底层函数并链接了微库microlib。6. 进阶技巧用 fromelf 与 map 文件做镜像依赖反查拿到一个陌生的.axf或者.bin想知道它里面包含了哪些模块、某个符号来自哪个目标文件、代码体积主要被谁吃掉这时候就不要开 IDE 了命令行两条命令就能搞定。第一步先反汇编fromelf --text -c ./build/app.axf -o ./build/app.dis打开app.dis后搜索目标函数名比如drv_uart_write。汇编清单里会列出函数的入口地址、指令流水以及调用的子函数。顺着 BL 指令能看出这个函数是否依赖了其他模块。如果要看某个目标文件贡献了多少代码用armlink --map生成的.map文件搜索目标文件名就能看到该文件下每个段的大小和地址分布。更实用的场景是排查意外引用。比如你的代码里没人直接调用assert但镜像里却有__aeabi_assert符号。这说明某个库函数内部调用了断言。用fromelf --text找到__aeabi_assert的地址再在.map文件里查这个地址对应的函数一路回溯就能定位到具体是哪个模块拉进来的。这种方法在裁剪固件体积时特别有用比一个个看源码快得多。另一个技巧是确认分散加载文件的预期布局。写完.sct后先链接一把再用fromelf --text -d看输出文件头部确认第一个 32 位字是初始 SP第二个是复位向量。同时用fromelf --text -e可以导出异常向量表适合排查中断不触发的问题fromelf --text -e ./build/app.axf -o ./build/except_vectors.txt这个命令生成的异常向量表会列出每个中断入口的偏移量和对应的处理函数。如果中断处理函数名是弱符号比如WEAK定义的默认 handler这里也能看到地址是指向默认中断处理还是你的实际 handler。比如某次排查串口中断不进来一导这个表发现向量表地址指向的是Default_Handler那问题就在中断处理函数没有写对或者没链接进去。这套「反汇编 异常向量表 map 符号定位」的组合拳我应该用了有上百次了。从那次在客户现场用fromelf反汇编找出一段被编译器优化掉的延时函数之后我每次拿到新工程都会强制走一遍这套流程先fromelf --bin出烧录文件再fromelf --text -c出反汇编最后对照.map确认内存占用。养成这个习惯之后很多运行时的灵异问题都变成了编译层面的正常现象。希望这套方法对你也有用。本文还有配套的精品资源点击获取