STM32F103 I2C从机中断接收实战：事件状态机与避坑指南-北京尧图网络

简介STM32F103 I2C通信-中断接收数据是一份面向嵌入式开发者的标准库工程资源专注解决STM32F103CB在I2C通信中通过中断方式高效接收数据的实现问题适用于工业控制、医疗设备、消费电子等板级短距离通信场景。包内共227个文件包含.h/.c源码、I2C库函数与配置头文件以及标准库工程所需的uvprojx/uvoptx工程文件、编译中间文件.o/.crf/.lst、可烧录的hex文件并附axf/map镜像与映射文件便于排错压缩包整体约7.09MB。内容涵盖I2C接口初始化、中断优先级配置、中断服务函数编写、数据发送及GPIO引脚配置等关键步骤也涉及总线冲突与时序异常等常见问题的处理思路对理解标准库调用和中断接收逻辑很有帮助。资源另含作者整理的批处理脚本与删除编译垃圾文件的小工具便于直接调试验证。已有427人学习下载适合希望快速上手STM32 I2C中断通信的初级与中级嵌入式开发者。1. 为什么F103的I2C中断接收值得上手从轮询卡死说起用过STM32F103硬件I2C的人多半被坑过两次一次是网上铺天盖地的“硬件I2C有bug”传闻另一次是自己用轮询写法把外设卡在某个状态机里出不来。其实换个思路把I2C从机端接到中断事件上按地址匹配、每字节到达、停止条件三个节点来收数据驱动逻辑会清晰很多CPU也不需要一直空转等待寄存器翻转。这份资源围绕F103的I2C从机中断接收展开适合给传感器小板、主从板卡、上位机模拟器这类场景做低延迟数据通道也适合想彻底搞懂F103硬件I2C事件机制的开发者。从初始化到中断处理再到排错每个环节按可复现的方式写踩坑记录直接对着抄。2. 硬件I2C与外设中断先把事件拆清楚再动针脚I2C协议在物理层上只是一根时钟线SCL和一根数据线SDA但F103的I2C外设把所有传输过程拆成了十几个事件。用中断接收数据之前得先把这些事件映射到自己的接收流程里不然中断服务函数写出来只剩一堆if嵌套看着像在猜谜。2.1 I2C外设结构从机模式不看时序图也能算清事件F103的I2C外设核心是一组状态寄存器SR1和SR2。SR1里的每位代表一个事件标志SR2则存放当前总线状态和从机地址等附加信息。从机接收模式下重点关注四个事件事件标志位置含义需要做的动作ADDRSR1.ADDR总线上出现了匹配本机地址的帧读SR1再读SR2清标志准备接收缓冲区RXNESR1.RXNEDR寄存器里有一个新收到的字节立刻读DR把数据搬进缓冲区BT FSR1.BTF一个字节传输完成数据已经锁存通常在连续多字节时需要配合处理STOPSR1.STOPF主机发出了停止条件提交当前帧数据复位接收状态这几个事件是串行出现的但中断服务函数每次只能看到一个“当前最高优先级”的事件所以判断顺序很关键。典型顺序是先看ADDR、再看RXNE、最后看STOP这样每帧数据从开始到结束的事件流是连贯的。从机模式下一个容易被忽略的细节是时钟延展Clock StretchingF103在收到匹配地址后硬件会自动拉低SCL给自己争取时间等待软件来清除ADDR标志。这个过程保证了从机CPU来不及处理时主机不会把下一字节硬塞进来是中断接收能稳定工作的硬件基础。2.2 中断映射与优先级EV和ER双通道各管什么F103的I2C1中断分成两个向量事件中断I2C1_EV_IRQn和错误中断I2C1_ER_IRQn。两者触发源不同处理内容也不同。NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel I2C1_EV_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority 1; NVIC_InitStructure.NVIC_IRQChannelSubPriority 0; NVIC_InitStructure.NVIC_IRQChannelCmd ENABLE; NVIC_Init(NVIC_InitStructure); NVIC_InitStructure.NVIC_IRQChannel I2C1_ER_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority 1; NVIC_InitStructure.NVIC_IRQChannelSubPriority 1; NVIC_InitStructure.NVIC_IRQChannelCmd ENABLE; NVIC_Init(NVIC_InitStructure);上面这段把EV和ER都打开了。EV抢占优先级为1ER为1但子优先级更低这样正常事件永远比错误事件先被响应避免在总线异常时错误处理把正常接收流程打断。经验值优先级的抢占部分不要设成0F103上0留给系统滴答定时器比较稳妥也不要低于2否则I2C在400kHz快速传输时RXNE到达和ISR响应之间的延迟会超过一个字节的时间窗口导致数据覆盖。实际项目中ER中断里最常出现的标志是AF应答失败和BERR总线错误。这两个标志在F103硬件I2C上很容易被干扰信号触发所以ER中断处理函数要做得越短越好进去只做标志清除和状态复位不要试图在里面做协议解析。2.3 参数选型地址、时钟、上升时间这几个数字别乱填I2C初始化参数里最容易出问题的不是模式选择而是RiseTime和ClockSpeed的匹配。RiseTime表示总线上数据线从低电平到高电平所需时间单位是微秒。如果这个值填小了I2C外设计算SCL高电平宽度时会出错实测表现为总线频率偏差大或者STOP条件无法被外设正确识别。I2C_InitTypeDef I2C_InitStructure; I2C_InitStructure.I2C_Mode I2C_Mode_I2C; I2C_InitStructure.I2C_ClockSpeed 100000; /* 100kHz 标准模式 */ I2C_InitStructure.I2C_Ack I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_OwnAddress1 0x58; /* 从机自身地址 */ I2C_InitStructure.I2C_DutyCycle I2C_DutyCycle_2; /* 400kHz时用Fast Mode */ I2C_InitStructure.I2C_RiseTime 17; /* 对应100kHz使用4.7k上拉时典型值 */ I2C_Init(I2C1, I2C_InitStructure);几个参数的选择逻辑再展开说。I2C_OwnAddress1填的是7位地址如果主机那边配置的从机地址是0xB0那这个字段要填0x58因为0xB0是8位视角下的地址最低位是读写位。这个换算关系经常让新人在联调时翻车主机发0xB0从机填0x58两边都对得上。I2C_RiseTime的取值跟总线上拉电阻值直接相关。100kHz时上拉4.7k典型上升沿约1微秒保险起见填17微秒改为400kHz时RiseTime要填小通常在2到5之间。如果拿不准用示波器实测SDA上升沿时间乘2填入宁大勿小。OwnAddress2在从机模式下默认关闭。除非你确实要用双地址模式否则不要打开它。打开OwnAddress2后外设会多监听一个地址中断里判断地址来源时还要多写一层逻辑对接收流程没有好处。3. 从机中断接收状态机ADDR、RXNE、STOP三段式实现从机中断接收最忌讳的是在ISR里做业务处理、等待数据慢慢到齐。正确做法是把接收过程拆成三段地址匹配之后准备缓冲区每字节到达立刻搬走停止条件触发后提交给上层。下面给出一套可用性较高的标准写法这套逻辑可以覆盖绝大多数单主多从场景。3.1 状态机三段式ADDR、RXNE、STOP的事件边界ADDR事件发生在主机发出地址帧且与从机地址匹配成功的那一刻。此时外设已经自动回复ACK并拉低SCL程序需要先读SR1再读SR2来清除ADDR标志否则外设会一直停在地址阶段后续数据字节根本进不到DR寄存器。同时这一段还需要把接收计数清零保证上一帧残留数据不会混进新帧。RXNE事件说明DR寄存器里已经有一个完整的新字节。这里有个细节值得强调F103在读DR寄存器后会自动清除RXNE标志所以代码里不要画蛇添足去操作CR1的某些位来清标志只读DR即可。如果缓冲区满可以主动调用I2C_AcknowledgeConfig关闭ACK这样主机在发下一个字节时会收到NACK从而中断传输。这个动作叫“接收方主动终止”在不定长协议里很实用。STOP事件代表主机发送了停止条件整帧数据真正结束。这时候要把缓冲区里的数据提交给应用层并把ACK重新打开准备接收下一帧。对从机来说STOP事件是判定一帧数据完整性最重要的依据比任何超时机制都可靠。3.2 中断服务函数完整实现下面这份代码是基于标准外设库的写法实测在F103C8T6上稳定运行接收64字节以内数据无丢失。/* I2C1 从机中断接收标准外设库版本 */ volatile uint8_t i2c_rx_buf[64]; volatile uint16_t i2c_rx_len 0; volatile uint8_t i2c_rx_flag 0; /* 一帧数据接收完成后置1 */ void I2C1_EV_IRQHandler(void) { uint16_t event I2C_GetLastEvent(I2C1); /* 1. 地址匹配事件清ADDR准备接收新帧 */ if ((event I2C_EVENT_SLAVE_RECEIVE_ADDRESS_MATCHED) ! 0) { /* 清ADDR标志读SR1再读SR2返回值全部丢弃 */ (void)I2C1-SR1; (void)I2C1-SR2; i2c_rx_len 0; } /* 2. 每收到一个字节立即从DR寄存器取走数据 */ if ((event I2C_EVENT_SLAVE_BYTE_RECEIVED) ! 0) { if (i2c_rx_len sizeof(i2c_rx_buf)) { i2c_rx_buf[i2c_rx_len] I2C_ReceiveData(I2C1); } else { /* 缓冲已满发送NACK让主机停止继续发送 */ I2C_AcknowledgeConfig(I2C1, DISABLE); (void)I2C_ReceiveData(I2C1); } } /* 3. 停止条件整帧数据落地交给应用层处理 */ if ((event I2C_EVENT_SLAVE_STOP_DETECTED) ! 0) { /* 从机模式下写STOP位让外设内部状态复位 */ I2C_GenerateSTOP(I2C1, ENABLE); /* 把ACK重新打开方便接收下一帧 */ I2C_AcknowledgeConfig(I2C1, ENABLE); i2c_rx_flag 1; } }这段代码的逻辑对应前面说的三段式第一步清地址标志并重置计数第二步把DR里的字节搬进缓冲区第三步在停止条件到来后置标志位通知主循环。三块互相独立即使某个事件在这一帧没出现也不会影响另外两个事件的处理。代码里最容易漏掉的是第三段的I2C_GenerateSTOP。在从机模式下这个操作不是真的在总线上产生停止条件而是把外设内部的传输状态机复位使它重新回到监听地址的状态。如果漏了这一步下一帧主机再发地址时从机可能因为上一帧状态残留在错误的阶段里导致地址匹配不成功。还有第二段的NACK分支当缓冲区满时先关ACK再读DR顺序不能颠倒否则读DR把RXNE清了后续字节还会继续进来。3.3 关于HAL库和标准外设库的差异如果用的是CubeMX生成的HAL库代码中断入口变成了HAL_I2C_EV_IRQHandler内部的分发机制最终会落到几个回调函数上HAL_I2C_AddrCallback负责地址匹配HAL_I2C_RxCpltCallback负责接收完成HAL_I2C_ListenCpltCallback负责监听结束时提交数据。HAL库把SR1/SR2的读取顺序封装好了写起来确实省事但在F103上有一个实际体会HAL库的从机接收回调默认只触发一次需要手动重新调用HAL_I2C_Slave_Receive_IT或HAL_I2C_EnableListen_IT来恢复接收状态否则第二帧数据会“静默丢失”。标准外设库的写法更贴近寄存器底层ISR里每个事件分支都能和SR1的位对应上排查问题时直接用调试器看SR1寄存器即可不需要翻回调注册链。两种库的核心逻辑一致差别只在封装层。对完全新手用HAL库起步更快对需要反复调时序或者做故障注入的老手标准外设库更直接。这份资源里的状态机逻辑两种库都适用只是中断服务函数内部写法不同。4. CubeMX配置与验证Demo从初始化到逻辑分析仪理论讲完就该动手。这一章把从新建工程到抓波形的完整路径跑一遍新手照着走能避开一半的坑。所有配置以标准外设库和CubeMX两种方式对照来说明哪个顺手用哪个。4.1 CubeMX引脚与I2C参数配置CubeMX配置步骤如下以F103C8T6为例新建工程选F103C8T6封装RCC里把HSE设为Crystal/Ceramic Resonator在Pinout视图点击PB6选择I2C1_SCL点击PB7选择I2C1_SDA引脚自动变成开漏复用模式Connectivity I2C1参数按表格填写NVIC里勾选I2C1 event interrupt和I2C1 error interrupt时钟树保持默认72MHz直接生成代码。参数填写的值说明I2C ModeI2C标准I2C模式Clock Speed100000 Hz起步用100kHz联调成功后再试400kHzOwn Address 10x58作为从机时的本机地址Address Length7 bit绝大多数传感器和从机设备都用7位地址Rise Time17 ns对应100kHz若跑400kHz改为2到5生成代码后在main函数里调用HAL_I2C_EnableListen_IT进入监听状态。这句调用放在MX_I2C1_Init之后、主循环开始之前。int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); /* 进入从机监听状态等待主机发送地址 */ HAL_I2C_EnableListen_IT(hi2c1); while (1) { /* 主循环空转接收逻辑在I2C中断回调里完成 */ } }HAL_I2C_EnableListen_IT让I2C外设从“关闭”状态进入“监听”状态。这条语句要保证只执行一次。如果放在循环里反复调用会重复注册回调导致中断里收到地址后行为异常。4.2 硬件接线与上拉电阻的选择I2C总线必须外接上拉电阻F103虽然某些引脚内部有弱上拉但不足以驱动I2C总线快速翻转。至少要外接2.2k到4.7k的电阻到3.3V电源。信号从机侧接法主机侧接法SCLPB6上拉4.7kSCL线上拉4.7kSDAPB7上拉4.7kSDA线上拉4.7kGND与主机共地与从机共地上拉电阻选值逻辑板内短走线用4.7k板间长走线或400kHz高速模式用2.2k甚至1.8k。上拉太大SCL上升沿太慢波形爬不到高电平阈值上拉太小总线低电平时的灌电流增大超过MCU引脚容忍范围。F103在3.3V供电、2.2k上拉时灌电流大约1.5mA在数据手册允许范围内。有个更容易忽略的点如果主机那边已经接了上拉电阻从机这边不接也能工作因为I2C总线上所有上拉电阻是并联关系。如果两边都接4.7k并联等效约2.35k反而更接近高速模式的推荐值。千万别一个接4.7k、一个接10k却不计算并联效果那会让总线上等效上拉偏高。4.3 验证步骤从波形到打印初始化做完后需要验证两件事主机能不能正常发起传输从机能不能完整收到。我一般用串口打印从机缓冲区内容来确认同时用逻辑分析仪看SCL/SDA波形。while (1) { if (i2c_rx_flag) { printf([I2C] len%d data, i2c_rx_len); for (uint16_t i 0; i i2c_rx_len; i) { printf(%02X , i2c_rx_buf[i]); } printf(\r\n); i2c_rx_flag 0; } }从机收到完整帧后i2c_rx_flag置1主循环打印数据和长度。注意这里用串口打印一定要放在主循环里不能放在中断里。串口打印耗时太长放在中断里会影响I2C字节接收容易把RXNE覆盖。如果打印结果里总是比主机发的数据多一个字节那通常是地址帧被当成数据处理了。如果打印出来是乱码优先看逻辑分析仪的波形确认SDA上是否有多余毛刺以及地址字节的ACK阶段是否真的被从机拉低。硬件I2C在调试时逻辑分析仪比示波器好用因为它能直接解码出地址和读写位省去手动数时钟周期的工作。5. 避坑记录F103 I2C中断接收的5条血泪点这一章不是代码规范是实打实测出来的坑每条按“现象→原因→解决”写。遇到类似问题可以直接对照排查能省不少时间。5.1 坑A地址匹配事件里误读DR导致首字节丢失现象主机发送0x58后紧接着发0x01 0x02 0x03从机收到的数据变成0x02 0x03首字节0x01消失不见。原因在ADDR事件处理时调用了I2C_ReceiveData。地址匹配事件的清除条件是读SR1再读SR2但如果在该读SR2的时候顺手去读DR就会把地址帧读走。更隐蔽的版本是把SR2的值当作地址校验来做读SR2后去和预期地址比较结果占用了本该留给RXNE的DR读取时间。F103在地址匹配后DR并不是空的强行读会得到不可预期的值后续RXNE事件又不会重新产生首字节就丢了。解决地址匹配阶段只清ADDR标志绝对不碰DR。清ADDR的操作是读SR1再读SR2每次读取的返回值直接丢弃。从地址匹配到第一个RXNE之间程序只做一件事清标志、重置计数、准备缓冲区。从那以后我每次写这个分支都会用注释把“不要在这里读DR”这句话标进去。5.2 坑BRXNE清除太慢导致字节错位或丢字节现象主机连续发3个字节从机只收到第1个和第3个第2个字节丢失但ISR里i2c_rx_len显示收到了3个字节数据内容却是0x01 0x02 0x02。原因F103的I2C外设在RXNE置位后如果没有及时读走DR新字节到来时会覆盖旧数据。理论上从机会用时钟延展拉住SCL给CPU时间但在实际板子上如果NVIC里面I2C1_EV_IRQn的优先级太低或者ISR里在处理RXNE之前还做了别的事比如打印或延时读DR的操作就可能晚于下一个字节的到达时间。解决提升I2C事件中断的抢占优先级从默认的2调到1ISR里RXNE分支只做搬运不做任何业务逻辑缓冲区写指针的更新放在一条语句里完成避免编译器在多条语句之间被中断插队。在400kHz总线速度下ISR从触发到读走DR的平均时间应该控制在10微秒以内超过这个就有丢字节风险。5.3 坑CSTOP事件没接入提交逻辑数据包烂尾现象每次接收完数据应用层拿到的长度总是0或者上一次的数据混进本次数据里。原因很多初版代码只在RXNE事件里堆数据堆完就结束忽略了STOP事件。停止条件是I2C帧结束的唯一标识如果不在STOP事件里把数据提交给应用层缓冲区里的数据就永远留在ISR里应用层根本看不到。更糟的是下一帧地址匹配时如果不清空i2c_rx_len新数据和旧数据会连在一起形成一帧“混合包”。解决在ISR的STOP分支里做三件事调用I2C_GenerateSTOP复位外设内部状态、把ACK重新使能、把当前缓冲区的长度和数据一次性提交给主循环。同时在ADDR分支里清空i2c_rx_len。这样每一帧都是从零开始的干净数据上一帧残留被彻底隔离。5.4 坑D上电瞬间AF标志反复触发ER中断刷屏现象板子刚上电还没接主机I2C1_ER_IRQHandler就不停进入AF标志清零后立刻置位。原因总线上电瞬间各个设备的电源轨上升时间不同SCL和SDA线上会有毛刺或电平抖动。F103从机把这些毛刺误判为非法地址帧由于地址不匹配硬件自动置位AF错误标志。更常见的场景是主机和从机没有共地SDA线上有压差导致总线状态混乱。解决在ER中断里清掉AF后加一个几十毫秒的软件延时再重新使能中断给总线电平一个稳定时间。同时检查主机和从机是否共地GND线必须连接。如果板子上I2C总线上有多个设备还要确认每个设备的上电顺序最好让主机最后上电。实测把RiseTime配置从默认值改成与实际上升沿匹配的参数后这个现象也明显减少。5.5 坑E工程里混用不同版本外设库事件判断错位现象同一份中断处理代码在A工程编译运行正常拷贝到B工程后编译通过但中断永远不触发或者收到数据后程序跑飞进入HardFault。原因不同版本的标准外设库或HAL库对I2C事件的处理方式有差异。有的版本把地址匹配和数据接收放在一个事件枚举里有的版本拆成两个独立事件。把旧工程的事件定义直接搬到新版外设库里编译时可能因为宏定义相同而校验不出来但运行时的事件值已经不匹配了。解决整个工程只保留一套外设库不要混用。工程迁移时先检查外设库版本再检查事件枚举定义是否和当前库匹配。可以用一个简单方法测试在ISR入口处把SR1的原始值通过串口打印出来对比实际触发条件和代码里的判断条件一目了然。从那以后我每次建新工程都会先确认外设库版本再开始写中断函数。6. 进阶用法用DMA接管I2C从机接收加上软超时兜底中断接收在低速、短帧场景下很稳但主机连续发送几百字节、每字节间隔只有几个微秒时ISR逐字节搬移会占用大量CPU时间。F103的I2C从机可以借助DMA直接搬运接收寄存器把原来中断里的“搬字节”变成“搬缓冲区”CPU只在整帧完成时介入一次。HAL库下启动DMA接收只需要两行代码HAL_I2C_EnableListen_IT(hi2c1); HAL_I2C_Slave_Receive_DMA(hi2c1, rx_buf, RX_BUF_MAX);RX_BUF_MAX是要预设的接收上限比如256字节。主机发送的帧长度达不到这个上限时从机怎么判断一帧结束了答案是依赖STOP事件。当主机发出停止条件DMA传输会被截断同时I2C外设会触发监听完成回调。在这个回调里用DMA剩余计数器的值反推出实际收到的字节数。void HAL_I2C_ListenCpltCallback(I2C_HandleTypeDef *hi2c) { if (hi2c-Instance I2C1) { uint16_t remain __HAL_DMA_GET_COUNTER(hdma_i2c1_rx); i2c_rx_len RX_BUF_MAX - remain; HAL_I2C_Slave_Receive_DMA(hi2c, rx_buf, RX_BUF_MAX); i2c_rx_flag 1; } }有几个细节要提醒。DMA接收的初始长度就是预设上限主机发20字节时DMA计数器从RX_BUF_MAX倒数到剩余值用总量减去剩余量就是实际长度。但如果主机发送长度超过了RX_BUF_MAXDMA会填满整个缓冲后继续覆盖前面的数据那时候i2c_rx_len就不再可信。所以这个方案适合帧长上限明确的协议。DMA方式下还需要关闭I2C的PEC校验开了PEC后DMA接收的数据末尾会多出一个校验字节反而破坏帧格式。DMA接收还有一个隐患如果主机在发送中途异常停止既不发停止条件也不再发数据DMA就会一直等待从机永远不会触发ListenCplt回调。这个场景下没有任何中断会唤醒CPU整个接收通道像死了一样。常见处理是为I2C配一个低速定时器做超时比如1毫秒中断一次记录DMA计数器值的变化。如果连续多次定时器中断里计数器值都没有变化则认为主机已放弃传输此时主动复位I2C外设重新进入监听状态。这个软超时给协议加了一层保险无论主机是断电还是死机从机都能自动恢复不需要人工复位。从那以后我每次做F103的I2C从机都会强制走一遍先确认总线上拉存在、EV和ER两个中断都打开、事件处理里把ADDR、RXNE、STOP三段拆开再考虑是否上DMA加软超时兜底。这套流程帮我避开了大部分F103硬件I2C的玄学问题希望帮到你。本文还有配套的精品资源点击获取

STM32F103 I2C从机中断接收实战：事件状态机与避坑指南

相关推荐

YOLO复杂场景检测提升：C3k2融合CSAM三重注意力改进实践

时域降维STAP：机载雷达mDT杂波抑制从原理到仿真

STM32火灾报警装置Proteus仿真设计与避坑指南

更多资讯

智能化小区网络规划全解析：从拓扑选型到落地避坑指南

上下文模式实战：多端多状态系统的动态行为调度策略

微表情识别中的自适应关键帧提取方法

产品EMC设计与风险评估：从原理图到量产的全流程实战

基于深度学习与PyQt的湿滑路面自适应制动决策系统设计与实现

WSL下STM32固件烧录实战：从编译到烧录的完整指南

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？