STM32F103国产替代实战：GPS定位平台MCU替换与串口移植解析

前一阵做GPS定位平台的项目选型时最顺手的绝对是STM32F103——外设够用、例程多、资料满天飞。但等到真正下采购单的时候才发现货期和价格都在让人头疼于是我们认真评估了国产32位MCU的替换方案最终在国芯思辰的支持下把整块主控从STM32F103换成了国产32位高性能MCU。整个过程比预想中顺利但也确实藏着不少坑。这篇文章就把这次替换的核心思路、硬件移植细节、GPS平台上的串口与定位数据处理经验以及最后定型阶段踩过的坑完整梳理一遍给正在做国产替代或者打算在GPS类产品里换主控的工程师做个参考。1. 为什么把替换节点定在GPS平台从实际选型冲突说起1.1 STM32F103的处境不是不能继续用而是成本结构变了STM32F103这颗料在行业里的地位不用多说过去十年里大量车载、手持、工控产品都在用它。Cortex-M3内核、72MHz主频、最多64KB SRAM、128KB Flash外设从UART、SPI、I2C到ADC、定时器一应俱全绝大部分嵌入式项目都能在这个框架下跑起来。但这两年做方案选型我第一眼看的不是数据手册而是采购给的库存表。现货价格不再稳定交期从几周拉长到几个月甚至某些封装版本直接进入分配状态。这种供应链上的压力会让原本“闭着眼睛选F103”的思路变得很危险。关键是很多产品本身并没有用到F103的全部资源更多的外围电路、中断优先级、定时器通道都长期闲置。用一个性能相近、引脚兼容、供货稳定的国产32位MCU去替换并不是降低要求而是把方案重新拉回到成本可控、供货可靠的轨道上。需要说明的是拿国产MCU替换STM32F103并不是一个新话题但真正适配到GPS这类需要稳定串口通信、精准定时中断、低噪声电源环境的场景还是有不少细节值得单独聊一聊。GPS平台的核心负载是串口数据流和定时器中断不是大算力这对替换方案来说非常友好。1.2 兼容替换的三个层次决定了项目改动量很多工程师第一反应是“替换就是换一颗引脚兼容的芯片改改启动文件就完事”。实际项目中兼容程度通常分三个层次提前判断自己需要哪一种能省掉大量返工时间。第一层是硬件引脚兼容。这个最直接引脚排布、封装尺寸、电源域分配都和F103对应PCB改动最小。我们这次选的就是这种引脚级兼容方案硬件上只调整了去耦电容和部分GPIO的复用定义整体布线基本沿用原设计。第二层是寄存器级兼容。库函数和寄存器地址大体一致原有底层驱动可以基于标准外设库快速迁移。第三层才是应用层兼容完全复用原工程只替换芯片型号和编译器相关配置。这种改动最小但前提是原工程没有使用特殊寄存器特性或者依赖特定版本的固件库。实际做替换评估时建议先做个资源占用表把原工程用到的外设、中断、GPIO、DMA通道全部列出来再对照新MCU的资源清单做差异分析。我们这次只用了UART1、UART2、几个定时器、一个外部中断、若干GPIO资源重叠度很高这才放心往下走。1.3 GPS平台为什么适合做国产MCU的验证场选择GPS平台作为首个替换验证项目不是因为业务上没得选而是因为GPS应用本身非常适合用来暴露MCU方案的真实水平。GPS定位模块通过串口输出NMEA协议数据主控需要做的核心工作无非是串口接收、解析、坐标转换、定时器管理、对外通信。这个功能链条不算复杂但对串口时序的稳定性、定时中断的准确性、电源环境的纯净度都有比较硬的要求非常适合检验国产MCU的实际表现。另一个原因是GPS产品形态多样——车载定位终端、手持设备、资产管理追踪器、便携导航模块它们对成本、功耗、封装面积都极其敏感这正是国产MCU擅长的战场。做完这个平台之后同系列MCU后续再切入其他物联网场景技术验证路径就有了可以复用的基础。如果是第一次换主控我也建议从这种“外设依赖集中、业务逻辑清晰、调试手段完备”的项目入手而不是直接拿一个电机控制或者多路高速采集项目来冒险。2. 最小系统硬件替换电源、时钟、复位与下载电路怎么对接2.1 引脚级对照从F103封装到国产MCU的映射关系开始画原理图之前我先把我们常用的F103芯片TQFP48封装和国产MCU的引脚定义逐根做了对照。电源脚、地脚、BOOT0、NRST、OSC_IN、OSC_OUT这些关键脚基本一致GPIO分组也沿用了PA/PB/PC的命名逻辑这对习惯STM32开发风格的工程师非常友好。但有几个脚位要特别注意VCAP脚或者特定模拟电源脚在不同厂商的方案里位置可能不同还有部分芯片把VREF集成在VDDA引脚上原来电路里如果单独接了外部基准源需要重新确认内部基准电路是否兼容。建议的做法是先拿到目标MCU的引脚功能图和参考原理图直接在原PCB netlist上做一次“引脚映射替换”。我们是用脚本对BOM里的网络名做了批量比对凡是在新旧芯片上功能定义不一致的网络都用标注列出来然后人工确认。这个步骤看起来繁琐但确实能挡住大部分低级错误。对于TQFP48这类常用封装我们实测下来国产MCU和F103在封装焊盘上是兼容的PCB不改封装、不改结构直接替换器件就能点亮这点非常关键因为很多产品外壳和模具已经定型改封装等于改结构件成本完全不是一个量级。2.2 电源纹波与去耦GPS定位平台要额外较真GPS定位模块对电源质量的要求比普通MCU系统苛刻不少尤其是模块内部的射频前端如果纹波偏大会直接影响接收灵敏度和定位稳定性。很多工程师只关注MCU能不能跑起来忽略了给GPS模块供电的这路电源噪声问题。我们这次在电源设计上做了几个处理主供电统一从一颗低噪声LDO取3.3V而不是直接用DC-DC的输出。DC-DC的效率确实高但在GPS这类射频敏感场景里开关纹波会耦合到天线馈点或者串口信号上。LDO的静态功耗大一点对整机功耗影响有限但噪声特性干净很多。LDO之后再给MCU的数字电源和模拟电源单独加磁珠隔离VDDA引脚单独走线。给GPS模块的供电则用了一颗100Ω磁珠加10μF/0.1μF电容组成π型滤波实测这路电源纹波能做到20mV以内。去耦电容的布局也重新审视了一遍MCU每个电源引脚旁边都放了0.1μF陶瓷电容摆放位置距离引脚不超过3mm晶振附近不放高频走线模拟地与数字地采用单点连接避免地环路噪声进入射频路径。这些细节在仿真里看着影响不大但实际跑到定位精度对比时差异还是挺明显的。另外提醒一点GPS模块的天线馈电部分建议不要让MCU的高速GPIO翻转信号直接从天线下方或旁边穿过。如果板子面积紧张至少要保证天线有效辐射区的下方是完整的地平面否则干扰会直接体现在定位漂移上。2.3 时钟方案外部晶振优先内部RC只能应急国产MCU基本都内置了RC振荡器拿来跑UART这类低速外设没问题但GPS平台的串口通信和定时器中断对时钟精度有要求我们直接选择了外部8MHz晶振的方案。晶振的两个负载电容按数据手册推荐值选型最开始用了22pF后来实测发现对应这颗MCU的引脚寄生电容偏大导致时钟频率偏低了大约0.3%这个偏差换算到115200波特率上会造成无法接受的误码后面换成18pF才恢复正常。所以晶振负载电容一定要以实测为准不能只看参考设计抄了个值就完事。如果产品对成本极其敏感想省掉两颗负载电容用内部RC那至少要确认两点一是RC校准功能是否开启并且校准值已经写入二是串口通信的波特率容差是否允许。GPS模块默认9600波特率时还好但模块支持的最高波特率往往是460800甚至更高内部RC在这个区间基本没法稳定工作。2.4 Boot与下载电路别让下载器认不出人也上不了位国产MCU的Boot模式引脚定义和F103大体一致BOOT0拉低从主Flash启动拉高进入系统存储器启动。原板上的BOOT0下拉电阻和复位电路可以沿用但有一点需要注意部分国产MCU在复位脚上集成了内部上拉外部不再需要加上拉电阻加了下拉反而可能导致无法正常复位。调试接口方面我们使用SWDPA13/PA14作为SWDIO/SWCLK。这个在F103方案里大家都习惯了国产MCU同样支持但联调时发现有些调试器的固件版本识别不了新芯片的ID Code解决方案很简单——把Keil或者调试工具升级到支持该MCU的最新版本或者安装厂商提供的Device Pack。如果板子已经画完才发现调试器连不上先别怀疑硬件优先检查驱动和Pack版本。下载电路上还建议串入ESD保护器件尤其是在手持设备这类会频繁插拔调试器的场景。GPS模块的数据口对静电也敏感整机要通过静电测试的话串口线上的TVS管不要省略。3. 串口组网主串口对接GPS模块软件串口做扩展输出3.1 GPS模块接线与电平匹配GPS模块我们用的是常见的NEO-M8N系列和MCU之间就是标准的UART连接模块的TX接MCU的RX模块的RX接MCU的TXGND共地VCC接3.3V。模块的PPS秒脉冲输出也引到MCU的一个GPIO上用来做时间同步。有一个容易踩的坑是电平匹配。部分GPS模块虽然是3.3V供电但串口引脚可以容忍5V输入反过来有些模块的逻辑电平是2.8V甚至1.8V。MCU的RX引脚如果配置成普通的推挽输入而模块输出高电平偏低可能导致数据帧识别不稳定。我们这次在模块UART接口上做了电平确认确定两边都是3.3V逻辑之后才直连。如果模块是1.8V逻辑就需要加电平转换或者用电阻分压。接线上还要注意串口通信的接法MCU_TX → 模块RXMCU_RX ← 模块TX这是最容易接反的一对信号线。接反之后表现是完全没有数据而且不会立刻烧毁器件容易让人怀疑是固件问题查半天。GPS模块的配置通常还支持通过UART发送配置指令比如NEO-M8N用UBX协议可以修改输出语句类型、更新率、波特率等。我们让MCU在上电初始化后延时1秒再发送配置命令确保模块已经完成内部启动这个细节后面还会展开说。3.2 定时器模拟软件串口原理、代码与适用边界项目里除了接GPS模块的主串口还需要一个串口来做调试日志输出和参数反馈。原方案里MCU的UART资源够用但如果换到更低成本的型号或者遇到串口被占满的情况软件串口就派上用场了。STM32F103在没有硬件UART可用时会考虑用定时器加GPIO模拟串口国产MCU的思路完全一样。软件串口的实现原理并不复杂。发送方向先配置一个定时器按波特率对应的位时间触发中断在中断里依次把起始位、8个数据位、停止位写到GPIO上。接收方向稍微麻烦通常用外部中断检测起始位的下降沿然后在位时间的中间点采样数据线电平。这里“位时间的中间点”是关键——如果采样点恰好落在位边界附近因为信号抖动或定时偏差会导致误码所以要保证采样点稳定。以9600波特率为例一位的时间是104.17μs。如果MCU主频72MHz定时器预分频为71得到1MHz的计数频率那么每位需要104个计数周期但104μs和104.17μs之间有0.17μs的误差。单个位的误差可以忽略但连续接收一整帧10位时误差会累积所以更严谨的做法是每位结束后把定时器重新装载到104并且在起始位之后的每个采样点都重新对齐。这样误差不会跨位累积。下面是发送一个字节的核心代码框架思路是用定时器中断逐位翻转引脚用状态机管理发送过程volatile uint8_t tx_byte; volatile uint8_t tx_bit_cnt; volatile uint8_t tx_active; void SoftUART_StartTransmit(uint8_t byte) { tx_byte byte; tx_bit_cnt 0; tx_active 1; SOFT_TX_LOW(); // 起始位 TIM_Cmd(TIM2, ENABLE); } void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update)) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); if (!tx_active) return; tx_bit_cnt; if (tx_bit_cnt 8) { if (tx_byte 0x01) SOFT_TX_HIGH(); else SOFT_TX_LOW(); tx_byte 1; } else if (tx_bit_cnt 9) { SOFT_TX_HIGH(); // 停止位 } else if (tx_bit_cnt 10) { TIM_Cmd(TIM2, DISABLE); tx_active 0; } } }接收方向建议用“外部中断检测起始位 定时器延迟到采样点 定时器中断采样”的组合实现。注意不要在外部中断里做太多事情只做启动定时器和标记接收状态。起始沿到采样点之间延迟半个位时间然后在每个数据位的中间点进入中断采样中断里读GPIO电平并存入接收字节。软件串口的适用边界也要讲清楚9600波特率下非常稳定38400开始对中断响应速度的要求明显提高115200基本就不推荐了因为定时器中断本身有进出栈开销加上系统其他中断抢占采样点抖动会变得不可控。所以软件串口适合用来做调试日志、低频命令下发或者低速传感器数据采集不适合作为GPS主数据链路。3.3 波特率误差算一笔账为什么9600足够稳串口通信双方只要波特率误差在合理范围内通常±2%以内就能正常通信但GPS模块的数据帧动辄几十上百字节整帧累积误差会更明显。以9600波特率、主频72MHz、定时器预分频71为例装入值选104时实际每位104μs理论104.17μs误差0.16%。一帧10位累积约1.6μs远小于3%的容限所以软件串口在9600下跑GPS日志完全没有压力。但换到115200波特率就不同了一位时间只有8.68μs定时器装入值按整数计算会因为主频整除关系产生0.5μs左右的量化误差相当于5.7%的单比特误差加上中断延迟很容易误码。我们实测软件串口在115200下接收GPS模块数据基本不可靠所以最终GPS主链路始终用硬件UART软件串口只接了调试输出。如果确实需要在较高波特率下扩展串口最稳妥的思路是换一颗带更多硬件UART的国产MCU或者用SPI转串口的方案。省一个串口却损失数据可靠性在GPS平台这种场景里不划算。3.4 用软件串口实现调试日志输出的实际姿势我们在这次项目里把软件串口固定接在调试终端上输出定位状态、解析出的坐标、PPS同步时间等信息。具体使用时有一个心得日志输出频率要受控不能每个中断都打印否则软件串口本身就会占用大量定时器中断时间反过来影响主串口的数据接收。做法是把调试信息打包成结构体在主循环里以一定周期批量输出比如每秒输出一次状态帧。另外软件串口发送期间被打断的问题也要处理。如果系统里存在更高优先级的中断比如定时器主中断或者PPS外部中断它们在软件串口逐位发送过程中触发就会拉长某一位的电平时间。解决方法是发送期间临时屏蔽部分低优先级中断或者把软件串口的中断优先级设得足够高。GPS模块的PPS秒脉冲中断对实时性也有要求这两个中断之间的优先级需要仔细权衡。4. 从NMEA原始数据到定位结果协议解析与误差修正4.1 常用语句与字段GGA和RMC就够了GPS模块默认输出的NMEA语句通常是GGA、RMC、GSV、GSA、VTG等。实际做产品时我不建议全量解析大多数场景只需要GGA和RMC两条就够了。GGA语句里最重要的是定位质量指示、经纬度、UTC时间、海拔和可见卫星数。RMC语句则包含推荐最小定位信息带有有效状态、经纬度、地面速度、航向和日期。下面是两种语句的典型结构$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47 $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A其中GGA的第二个字段是UTC时间第三个和第五个字段是经纬度格式为ddmm.mmmm第六九位表示定位质量1表示GPS定位有效2表示差分定位。RMC第二个字段如果为A表示数据有效V表示无效这在轨迹记录类产品里必须作为第一道过滤条件。解析NMEA时还要注意语句体内逗号字段的计数方式两个连续逗号之间是空字段用字符串分割函数时别把空字段跳过。比如当某些模块不输出海拔时对应字段是空的如果解析器错误地拿下一个字段补充坐标就会偏移得离谱。4.2 解析状态机与坐标换算实现NMEA解析放在MCU上通常会有两种思路一种是用串口空闲中断配合行缓冲把完整的一行语句先收进数组再用逗号分割解析另一种是逐字符状态机在串口中断里直接解析。为了不占用太多中断时间我选择前者UART接收中断里只做压栈当检测到$符号开始暂存检测到换行符表示一行结束然后置一个标志位主循环里再解析整行。由于GPS模块数据持续不断缓冲区要能容纳最长的一行GGA最长可超过80字节建议缓冲区开到128字节。解析时用sscanf或者自定义的逗号分隔函数都可以嵌入式环境里我更推荐手写解析因为sscanf对格式错误的字符串处理效率低而且容易把空字段转换结果弄乱。经纬度转换是另一个关键点。NMEA输出的ddmm.mmmm格式先取前两位度剩余部分除以60转为小数分。举个例子4807.038表示48度07.038分转为十进制度是48 7.038/60 48.1173度。这个公式在原工程里必须处理南纬和西经用S和W后缀标记负数。float nmea_to_decimal(int deg, float minute) { return deg minute / 60.0f; }实测中发现部分模块输出固定保留两位小数换算成十进制度后精度约等于小数点后四位对应地面大约11米级别。如果要更细的精度建议在应用层通过多次采样滤波来平滑而不是依赖单帧数据的原始精度。4.3 定位误差的来源与软件级过滤手段GPS定位误差绝不仅仅是模块“准不准”的问题环境因素和天线布局影响往往更大。最常见的误差来源包括多径效应——城市峡谷里高楼反射信号导致卫星信号叠加定位点来回漂移卫星几何分布——可见卫星集中在某一方向时PDOP值高水平定位精度下降电离层和对流层延迟这是普通单频GPS模块无法完全消除的。软件层面能做的主要是过滤和状态判断。我们项目里做了这几个处理GPS定位状态有效GGA的定位质量指示才记录坐标无效帧直接丢弃。对移动目标速度异常跳变更新的点剔除。比如上一帧速度是30km/h下一帧瞬间跳到200km/h除非在高速场景里否则视为异常跳变。静止状态下做小半径漂移过滤例如定位点在50米范围内来回抖动时输出值保持第一次进入该范围的坐标直到漂移超过阈值才重新修正。构建地图匹配或路网约束对于车载类产品可以结合历史轨迹判断定位点是否落在合理道路上。这些手段不能根治误差但能让最终的轨迹看起来很“理智”。4.4 用PPS秒脉冲做授时与时间同步GPS模块的PPS输出是一个固定频率的秒脉冲上升沿通常与UTC整秒对齐精度在几十纳秒级别。对很多定位终端而言单纯用它灯亮灯灭意义不大但如果产品涉及事件记录、数据打戳或者多设备时间同步PPS就非常关键。我们在MCU上把PPS接到一个支持外部中断的GPIO上。每次PPS上升沿触发中断后在主中断里记录当前的系统计时器值同时读取模块RMC语句里给出的UTC时间将二者绑定实现软件时钟的秒级校准。这样系统运行长时间后本地时间的累计漂移不会超过几百毫秒。PPS中断处理的注意点是中断服务函数要足够短不能在里面做串口打印。我们实测如果在PPS中断里加调试输出中断响应时间会抖动几十微秒虽然对秒脉冲本身影响不大但会干扰软件串口的发送时序。所以PPS中断只做UART帧号记录和标志位置位具体时间校正放到主循环处理。5. 实测定型阶段踩过的坑从能点亮到稳定定位5.1 上电时序问题让GPS模块沉默样机第一次上电MCU程序跑起来了串口却始终收不到GPS模块任何数据。第一反应是检查模块供电万用表测量3.3V正常模块的电源指示灯也亮了但UART就是静默。排查过程是这样的先用USB转串口工具直接连接GPS模块确认模块本身能正常输出NMEA数据。排除了模块硬件问题之后回到MCU这边检查初始化代码发现UART配置看起来也没有问题。最后用逻辑分析仪抓MCU的TX引脚电平才发现MCU复位期间GPIO被释放为高阻态或者默认高电平而GPS模块接收到一段乱码脉冲触发了它内部的某种保护状态或者进入了异常配置流程暂时停止了NMEA输出。问题根因在于MCU的UART TX引脚在复位阶段和初始化之前处于不定状态而GPS模块对上电时序敏感。解决办法也很简单MCU初始化中先把TX引脚配置为推挽输出并锁定为高电平等GPS模块完成上电启动再延时100~200ms后初始化UART外设开始通信。如果是支持UBX配置的模块更稳的做法是模块完全启动后再发送配置命令并且发送命令之前先清空模块输入缓冲。这个坑也提醒我PCB上MCU到GPS模块的TX线上如果空间允许可以串联一个22Ω到33Ω的电阻既限制异常脉冲的摆率又能在调试时方便断开测量。5.2 软件串口的位偏移在高负载时放大软件串口在空闲状态下跑得很好但一接入正式业务代码日志输出就出现乱码。一开始以为是打印内容太多太频繁后来用示波器抓波形发现每一帧起始位和停止位之间的时间间隔在抖动高负载时某一位的电平持续时间比预期短了一大截。原因是软件串口发送过程中定时器中断被其他高优先级中断抢占导致某一位的翻转被延迟。如果系统里同时存在PPS外部中断、射频模块的SPI中断、或者ADC采样中断软件串口的位时钟就会不定期被拉伸或者压缩。这个问题有两个解决方向。一是给软件串口定时器中断一个足够高的优先级使它基本不会被其他中断延迟二是把软件串口的发送改成阻塞式发送期间关掉其他一切可能抢占的全局中断。但关闭全局中断会直接影响PPS同步和GPS数据接收所以最终方案是把软件串口保留给低频调试输出所有关键通信全部走硬件UART。如果产品形态确实需要多个串口跑数据建议直接选用带多路UART的国产MCU不要指望软件串口扛高负载。软件串口作为一个备用逃生通道是好的但不能把它当成正式数据链路来设计。5.3 外部晶振负载电容导致的波特率漂移有一轮整机测试时发现GPS模块和MCU之间9600波特率通信没问题但修改模块波特率到38400后误码率明显升高。排查到最后发现根因在MCU的时钟频率偏差——外部8MHz晶振因为负载电容匹配不合适实际振荡频率比标称值低了0.3%左右。9600波特率时0.3%的偏差远在容限之内但38400时累计误差变大加上模块本身的波特率误差最终超出容限。这个问题的排查思路值得记录先用MCU内部定时器测对外输出时钟频率或者用频率计直接测OSC_OUT引脚的波形确认实际主频。使用Keil调试时可以读取RCC寄存器算PLL倍频后的时钟但更可靠的是实测。确认主频偏差后调整晶振负载电容到实测频率最接近8MHz的值。很多国产MCU还提供了时钟校准功能利用内部RC校准或者外置时钟源的频率差做软件修正。但GPS平台的串口通信对绝对时钟精度要求高硬件层面把晶振调准才是治本。5.4 产品化阶段的收尾配置存储、电源管理与天线检测定位平台做到后期除了功能跑通之外还有几个容易被忽视的产品化细节。配置存储方面GPS模块的配置参数比如输出语句、更新率、波特率如果每次上电都通过MCU重新下发模块就会在每次复位后短暂地以默认配置工作一段时间。产品化做法是把配置参数解析后存入MCU内部Flash或者外挂EEPROM每次上电检查配置有效再决定是否重新配置模块。如果直接用内部Flash模拟EEPROM要注意擦写寿命不超过标称次数频繁写入时要做磨损均衡。电源管理方面手持设备对功耗敏感。GPS模块的接收电流约20~50mAMCU全速跑起来也有几十毫安如果产品支持待机模式建议把GPS模块的供电单独用MOS管控制待机时断开模块电源MCU进入低功耗模式之前先关闭UART和定时器避免外设漏电。PPS中断在低功耗模式下是否作为唤醒源也要在设计阶段就决定好。天线检测这一块更容易被忽略。陶瓷天线或者有源天线若发生短路或断路定位性能会直线下降但系统未必能感知。我们加了一个天线检测电路通过ADC采样天线的供电电流或者反射电压来判断天线状态异常时主动上报。对这个功能最开始觉得可有可无直到有客户反馈设备安装后一直无法定位排查发现是天线馈线被压断了系统却没有任何提示。最后想说的是这次把STM32F103替换成国产32位高性能MCU在GPS平台上实际跑下来之后我的体会是不要因为“国产”两个字就降低验证标准也不要因为“替换”两个字就指望完全无感切换。芯片本身不是瓶颈真正考验项目的是对时序、时钟、电源、串口这些基础细节的把控。如果让我再来一遍我会更早把软件串口的优先级降级、更早用逻辑分析仪抓上电时序这两个决定能省掉后面好几天的排查时间。国产MCU的生态越来越成熟从GPS平台这个切入点开始替换是个务实的选择。