CMSIS-DSP源码审计：从FPU到Cache的嵌入式信号处理性能优化指南

我写这篇东西的起因其实有点现实：一个做电机状态监测的客户，把一批准备量产的Cortex-M7板子交过来，抱怨CMSIS-DSP的1024点实FFT跑出1.2毫秒，跟官方文档标称值差了将近一半。当时第一反应是怀疑他调用姿势不对，结果打开工程检查，FPU没有真正使能、DMA的Cache没做clean、链接脚本里缓冲区对齐也是错的。那一刻我就意识到，很多人其实从来没把这套库当成一份“可以读的源码”，而是一直把它当作“链接进去就能跑得飞快”的黑盒。

ARM官方维护的CMSIS-DSP，可以说是嵌入式信号处理领域覆盖面最广的库。从q7/q15/q31定点运算，到f32/f64浮点滤波、矩阵分解、FFT、MFCC，再到SVM分类，基本把Cortex-M系列上能见到的数字信号处理场景都包进去了。这篇文章想做的事，是把这颗“官方黑盒”的螺丝一颗颗拧开，从架构设计、源码实现路径、编译期行为，一直聊到工业固件集成时最容易翻车的工程细节。适合正在用CMSIS-DSP做产品、做算法验证，或者纯粹想搞懂“为什么同样一段代码在不同芯片上性能差好几倍”的读者。

1. 为什么CMSIS-DSP值得啃源码：它不是一个“链接即最优”的库

1.1 官方库的复杂度远比你想象的高

CMSIS-DSP并不是一个几十个函数组成的简单工具包。我数过当前正式版本的Source目录，包含BasicMathFunctions、ComplexMathFunctions、ControllerFunctions、FastMathFunctions、FilteringFunctions、InterpolationFunctions、MatrixFunctions、StatisticsFunctions、SupportFunctions、TransformFunctions、BayesFunctions、DistanceFunctions、SVMFunctions这些功能域，每个功能域里又按数据类型拆成q7、q15、q31、f32、f64等多个实现文件，总量在六七十个源文件级别。

这个规模意味着两件事。第一，全量编译链接后，库的体积可能达到几百KB，这在Flash资源紧张的MCU上是不可接受的；第二，不同函数之间存在明显的“性能落差”，有的走硬件指令加速路径，有的退化成纯C标量循环，如果你不知道哪些函数吃硬件红利、哪些不吃，性能预期就无从谈起。只有读过源码，你才能在构建层面做裁剪，在调用层面做预期管理。

1.2 源码目录本身就是一张设计蓝图

以标准CMSIS仓库为例，目录结构大致如下：

• Include/：对外公共头文件，最重要的是arm_math.h，其次是arm_math_types.h、arm_mve_tables.h
• PrivateInclude/：内部私有定义，通常不直接对外暴露
• Source/：按功能域分子目录组织实现代码
• Examples/：示例工程，通常用于验证库基本功能

有人觉得目录无非是官方随手分的，不值得研究。但实际工程里，这个目录划分就是裁剪库的依据。你完全可以只把FilteringFunctions和TransformFunctions加进编译，其他目录全部排除，链接后体积能缩小到原来的三分之一甚至更少。CMSIS-DSP没有提供类似Linux内核的Kconfig机制，所以“按目录裁剪”就是它在构建系统层面的定制方式。

在工业固件项目里，我通常会在CMake里做一个CMSIS_DSP_ENABLE_*的开关组，按产品功能去开关这些子目录。这个习惯就是读源码目录结构读出来的灵感，比用官方预编译库省下的Flash空间非常可观。

1.3 读源码的核心目的是理解“编译期行为”

CMSIS-DSP和很多Desktop端DSP库最大的不同，是它有大量编译期宏开关。同一个函数名，在不同芯片、不同编译器选项下，实际编译出来的机器码可能是完全不同的实现。这就导致一个现象：你在A芯片上测出来的性能数据，搬到B芯片上完全不适用；你在Keil MDK下验证没问题，换到GCC后行为可能微妙地变化。如果不能从源码层面理解这些宏开关的作用，就很难排查这类“换平台就变慢/出错”的问题。

2. 架构全景：arm_math.h里的编译期“方言系统”

2.1 头文件里藏着三类关键信息

arm_math.h是全库最值得逐行读的头文件。它做的事情可以归成三类。

第一类是数据类型别名。CMSIS-DSP定义了q7_t、q15_t、q31_t、float32_t、float64_t这些统一类型，分别映射到int8_t、int16_t、int32_t、float、double。这套别名不是为了好看，而是为了让同一套算法代码可以跨越不同编译器和平台。你在自己的固件工程里定义DSP缓冲区时，最好也用这些类型别名，避免在接口处做强制转换时产生歧义。

第二类是设备特性宏。这是名副其实的“方言系统”。比较常见的一组宏包括：

这部分宏决定了编译器会不会把#if defined(ARM_MATH_MVE)里面的向量代码段编译进去。如果你在Cortex-M55上忘记定义ARM_MATH_MVE，库会按普通M33的路径编译，性能可能直接降低一半以上。反过来，如果你在Cortex-M4上误定义了ARM_MATH_MVE，编译通常能过，但执行结果可能是错的，甚至直接触发硬件异常。

第三类是错误码枚举。arm_status里定义了ARM_MATH_SUCCESS、ARM_MATH_ARGUMENT_ERROR、ARM_MATH_LENGTH_ERROR、ARM_MATH_SIZE_MISMATCH、ARM_MATH_NANINF、ARM_MATH_SINGULAR。很多调库的人不检查这些返回值，但审计源码后你会发现，矩阵求逆这类函数在遇到奇异矩阵时，会通过返回码告诉你结果无效。不加检查直接往下用，轻则输出错误数据，重则在PID闭环系统里引发震荡。

2.2 两种典型的编译期分支路径

以矩阵乘法为例，CMSIS-DSP在Cortex-M4/M7上用的是SMULT、SMLALD这类DSP指令做定点矩阵乘加，在M55上则切换成MVE的vld1q批量加载加vmlalvq向量乘加。这两条路径的代码风格差异极大，但对外API完全一致。这种“接口稳定、实现分裂”的设计，保证了上层应用代码的可移植性，但也要求你在做源码审计时，必须留意当前工程实际定义了哪些宏，否则你看到的代码和你预期的优化路径可能根本不是同一段。

2.3 宏定义缺失的排查方法

如果怀疑库里某段优化路径没被激活，最直接的办法是看编译后的反汇编。比如FFT的f32实现如果真正跑的是硬件FPU指令，你会看到vldr、vmla.f32这类指令；如果退化成软浮点，反汇编里会频繁出现__aeabi_fmul、__aeabi_fadd这类软浮点库调用。这类调用一出现，性能基本就没救了。业界常说“FPU开了但没完全开”，说的就是这个状态。

另一个排查点是编译器的优化等级。CMSIS-DSP源码里大量使用了循环展开和常量折叠，如果优化等级设置在-O0，哪怕宏定义全对，性能也一样惨淡。一般建议至少-O2起步，Keil里对应-O3 --optimize=time，GCC里对应-O2或-O3。

3. 源码审计：一条典型信号链路从调用到内核的完整走读

3.1 从ARM_MATH宏到函数实现的映射关系

很多人第一次打开CMSIS-DSP源码时会被文件名吓到，比如arm_fir_f32.c、arm_cfft_f32.c、arm_mat_mult_f32.c，但当你真正开始追一条调用链时，会发现它并不复杂。

以最常用的arm_fir_f32为例。入口函数在FilteringFunctions下，它的核心逻辑是：

void arm_fir_f32( const arm_fir_instance_f32 * S, const float32_t * pSrc, float32_t * pDst, uint32_t blockSize) { float32_t *pState = S->pState; const float32_t *pCoeffs = S->pCoeffs; ... }

函数整体是一个加窗滑动卷积。你会注意到它把当前输入块放进pState状态缓冲区，然后把输入样本和系数做乘累加。这里有一个非常容易踩坑的细节：pState缓冲区的大小是numTaps + blockSize - 1，而不是numTaps。如果你在配置实例时只分配了numTaps长度的缓冲区，运行几次之后就会出现内存越界写，表现是“跑一段时间后系统突然崩溃”，非常隐蔽。

3.2 定点Q格式：Q15乘法里的标定与溢出策略

CMSIS-DSP里大量使用Q格式定点数。不理解Q格式的标定，就谈不上正确使用这个库。

拿arm_mult_q15为例，它的核心实现大致是这样：

void arm_mult_q15( const q15_t * pSrcA, const q15_t * pSrcB, q15_t * pDst, uint32_t blockSize) { uint32_t blkCnt = blockSize >> 1; while (blkCnt > 0U) { q31_t inA1 = *pSrcA++; q31_t inB1 = *pSrcB++; q31_t inA2 = *pSrcA++; q31_t inB2 = *pSrcB++; q31_t out = (inA1 * inB1) >> 15; *pDst++ = (q15_t)out; } }

这里的关键是(q31_t)a * b >> 15。两个Q15数相乘，小数点位置是两个15位尾数的和，即Q30格式；为了把结果存回Q15，需要右移15位。右移之后还要截断到16位，所以如果输入信号接近满幅，乘积很容易溢出到16位之外，削波失真就会出现在输出里。

实际工程中，我会在进入DSP算法前对原始信号做一次归一化，比如AD采样值为±2048的12位数据，先左移到Q15的合理范围，再进入滤波。否则你调了半天算法参数，发现性能没改善，其实信号早就在定点乘法里被削成方波了。

3.3 矩阵运算的访存局部性与MVE向量化

矩阵乘法是另一个值得深挖的源码模块。朴素的矩阵乘法是三重循环，CMSIS-DSP在arm_mat_mult_f32里做了两件关键优化。

第一件是循环展开。它不是一次算一个输出元素，而是连续算多个输出元素，减少循环控制开销。第二件是数据分块。矩阵数据被切成小块，让每次读入的数据能尽量落在Cache里复用，而不是反复到主存里搬。

到了MVE指令集上，写法就变得更“向量化”了。比如一次vld1q可以加载8个float32到向量寄存器，vmlaq.f32同时做8路乘加。这种向量化的收益非常可观，但前提是数据在内存里是连续且对齐的。如果你的矩阵是按列主序存储的，MVE的连续加载优势会大打折扣。

这里要提醒一个我在实际项目中踩过的坑：很多人以为矩阵越大越能体现MVE优势，但其实小矩阵（比如4x4、6x6的旋转矩阵）反而可能因为数据布局和分支开销，表现不如Cortex-M7上的纯FPU优化。所以benchmark一定要按实际工况来测，不能只看广告数据。

3.4 实FFT的实现结构与旋转因子表

FFT是CMSIS-DSP里被问得最多的模块。实数FFT在arm_rfft_f32.c里实现，它的设计并不是直接跑复数FFT，而是先把N点实数序列“打包”成N/2点复数序列，做一次复数FFT，再通过对称性拆出实数频域结果。这样做的好处是计算量几乎减半，坏处是接口和中间缓冲区的组织方式让不少人看不明白。

在使用arm_rfft_f32时，必须先调用arm_rfft_fast_init_f32来做实例初始化。这个初始化函数会把旋转因子表和处理函数指针都填进arm_rfft_fast_instance_f32结构体。源码里旋转因子是编译期常量数组，存放在类似arm_cfft_sR_f32_len64的结构里。你不需要手动生成，但要知道这个表占用了Flash空间，使用多个不同长度的FFT实例时，Flash占用会随长度表增加。

审计时一个容易看漏的点：arm_rfft_fast_f32的输入输出缓冲区支持原地操作，也就是pSrc和pDst可以指向同一个地址。但是中间的纯复数FFT阶段会临时使用额外的缓冲区，这个缓冲区由arm_cfft_f32内部管理。我看到过有人在中断里同时跑两个FFT实例，共用了同一个暂存缓冲区，结果两个FFT互相污染数据。这种问题单看单线程代码根本发现不了，只有理解了内部缓冲区生命周期才会意识到。

4. 工业固件落地：把CMSIS-DSP跑进产品前要过的四道关

4.1 第一道关：链接脚本与堆空间对齐

CMSIS-DSP在Cortex-M7上表现出色的前提是数据对齐。为什么是8字节？因为Cortex-M7的FPU加载双精度和MVE的向量加载都要求数据地址按8字节对齐，一旦不对齐，硬件会触发UsageFault，即使通过配置把非对齐访问变成“能跑”，性能也会显著劣化。

具体到固件工程，你需要检查两处。

一处是启动文件或链接脚本里堆的起始地址。如果堆从某个奇地址开始，malloc出来的缓冲区可能不对齐。CMSIS-DSP的实例结构体里一般都有__ALIGNED(8)之类的修饰，但你自己定义的原始样本缓冲区不一定有。

另一处是分散加载文件里的region对齐。Keil的.sct文件里，加载域和执行域的ALIGN设置建议从8起。GCC的.ld文件里，注意.data、.bss段的起始地址也对齐到8。很多“性能与标称差30%”的问题，排查到最后就是对齐少了一位。

4.2 第二道关：FPU使能和编译选项的“隐形组合拳”

芯片里有硬件FPU，不等于编译器就会用。CMSIS-DSP的f32函数真要跑出硬件速度，需要同时满足几个条件：

• 启动文件里的FPU使能代码存在，一般会配置CPACR寄存器
• 全局宏__FPU_PRESENT定义为1，__FPU_USED定义为1
• 编译器选项带有硬件浮点ABI参数，例如GCC的-mfloat-abi=hard -mfpu=fpv5-d16，Keil的--cpu Cortex-M7.fp.sp或--fpu fpv5-sp-d16
• 优化等级至少-O2

这几个条件缺一个，结果就可能退化为软浮点。判断方法很简单，编译后看map文件或者反汇编，如果出现了__aeabi_fmul、__aeabi_dadd这类符号，说明软浮点路径被激活了。

我在做固件评审时，经常看到有人在工程里定义了ARM_MATH_CM7，却忘了开__FPU_USED。结果库确实走了CM7的文件，但浮点操作全是模拟的，性能比Cortex-M4还慢。这类问题的排查思路应该从“头文件宏”和“编译器选项”两个维度同时入手，不要只盯着一处。

4.3 第三道关：中断上下文里的可重入性设计

CMSIS-DSP的大部分函数不是可重入的。拿arm_fir_f32来说，滤波状态是放在arm_fir_instance_f32结构体里维护的，如果高优先级中断和主循环同时用同一个实例，那状态缓冲区会出现竞争，输出波形出现随机毛刺，产品表现就是“时好时坏”。

解决办法有几个层次。

最简单的是“分配独立实例”，每个中断上下文和主循环各自维护自己的arm_fir_instance_f32，系数一样但状态独立。这个方案我推荐优先考虑，除非你的内存紧张到连多一份状态缓冲区都放不下。

如果必须共享实例，就得用临界区保护，在调用滤波函数前__disable_irq()，调用结束后再__enable_irq()。但要注意，临界区保护会影响中断响应实时性，如果中断里面正好在跑ADC采集，临界区太长可能导致采样点丢失，表现就是采样率不稳定。

还有一个容易被忽略的细节：有些CMSIS-DSP函数内部会调用memcpy或memset，它们在极端情况下可能会抢占部分CPU周期。如果在高实时性中断里调用超大块变换，比如4096点FFT，中断服务函数的执行时间会不可控，这在设计阶段就应该评估掉。

4.4 第四道关：Cache一致性导致的“随机偶发错误”

Cortex-M7这类带Cache的内核，DMA和CPU之间天然存在缓存一致性问题。工业场景里，ADC或外部通信控制器通过DMA把数据直接搬到内存，CMSIS-DSP库再从这个内存地址读数据做处理。如果这个内存地址已经被CPU读进Cache并在Cache里保留了旧版本，DMA写入的新数据在物理内存里，CPU读的确实Cache里的旧快照，处理结果自然不对。

这种问题可怕在偶发性。比如信号幅度小时正常，幅度大时出错；或者复位后第一次运行正常，运行几分钟后开始出现随机跳变。从DSP库本身看，函数实现没有任何问题，问题出在数据路径上。

解决办法通常有以下几种：

• DMA缓冲区按Cache Line对齐，通常是32字节，并使用SCB_CleanDCache_by_Addr和SCB_InvalidateDCache_by_Addr做手动一致性维护
• 通过MPU把DMA缓冲区配置成非Cache属性，这就是所谓的“DMA专用非缓存内存”
• 如果芯片支持，使用双缓冲机制，DMA在缓冲A写入时，CPU处理缓冲B，交替进行

我见过一个案子，某设备上电后偶尔出现“数据中间有一段全是0”，排查了半个月，最后发现是DMA缓冲区没对齐到32字节，Cache Line在刷新时把相邻缓冲区数据一并清掉了。这种问题在源码审计阶段根本不会暴露，必须在固件架构层面提前做好规划。

5. 实测数据与平台差异：让性能预期回到现实

5.1 一套适合固件项目早期的Benchmark方案

在评估CMSIS-DSP性能是否满足产品需求时，我会在项目早期跑一套固定benchmark，避免后期陷入“都做完了才发现性能不够”的困境。方案包括下面几组：

• FIR滤波：256阶，1024个样本
• 实数FFT：256点、1024点、4096点各跑一次
• 矩阵乘法：8x8、16x16的f32矩阵
• 统计函数：均值、RMS、方差

测量工具用DWT->CYCCNT指令周期计数器，比HAL_GetTick()精确得多。要注意在测量前关掉中断，或者至少记录中断造成的周期消耗，保证数据干净。

5.2 不同内核上观察到的差距

我针对Cortex-M4F、M7、M33、M55四类内核做过同源固件的性能对比，结论有代表性。以1024点实数FFT（f32）为例，大致数据如下：

这些数据受编译器版本、优化等级、Flash等待周期影响很大，但比例关系基本稳定。它说明一个道理：如果产品需要大量FFT运算，选MVE内核的MCU，性能红利非常明显；如果只是简单FIR滤波，M4F和M7的差异其实没那么大。

5.3 用反汇编验证实际走的优化路径

推荐一个很实用的验证方法：编译后打开反汇编文件，搜索关键特征指令。

• 如果函数跑的是普通软浮点，你会看到__aeabi_fmul、__aeabi_fadd这类符号
• 如果跑的是FPU硬件指令，会看到vadd.f32、vmla.f32、vldr这类指令
• 如果跑的是MVE向量路径，会看到vld1q、vmlalvq、vpst这类向量指令

这一招用在库函数性能优化上特别有效。比如你期望M55跑MVE路径，但反汇编里全是标量指令，那就要回头检查ARM_MATH_MVE和ARM_MATH_CM55宏是不是没定义对。用反汇编说话，比凭感觉猜要靠谱得多。

6. 从源码审计到生产级代码：移植与裁剪经验

6.1 按需裁剪库体积的具体做法

CMSIS-DSP不像某些中间件那样自带一键裁剪菜单，它靠的就是构建系统层面的“目录剪裁”。在CMake里，我通常会这样设计：

CMSIS-DSP/ Source/ BasicMathFunctions/ # 基础加减乘除 FilteringFunctions/ # FIR/IIR/Biquad TransformFunctions/ # FFT/DCT/MFCC MatrixFunctions/ # 矩阵运算 StatisticsFunctions/ # 均值/方差/RMS SupportFunctions/ # 数据拷贝/类型转换 ...

在CMakeLists.txt里加一组开关：

option(CMSIS_DSP_ENABLE_TRANSFORM "Enable FFT functions" ON) option(CMSIS_DSP_ENABLE_FILTERING "Enable FIR/IIR" ON) option(CMSIS_DSP_ENABLE_MATRIX "Enable Matrix" ON) option(CMSIS_DSP_ENABLE_BASIC_MATH "Enable Basic Math" ON)

然后按开关把对应的源文件加入编译列表。这样裁剪后，一个只做FIR滤波的固件，DSP库的Flash占用能从全量编译的一两百KB降到二三十KB以内，效果非常明显。

6.2 在工程里保留一份自己的“适配层”

任何优秀的第三方库，都不建议在业务代码里到处直接调用。CMSIS-DSP也一样，它API的命名风格和参数格式偏向通用性，缺少业务语义。我在项目里会包一层薄薄的适配层，比如：

DSP_Result_t DSP_FirFilterRun(DSP_FirHandle_t *handle, const float32_t *in, float32_t *out, uint32_t len); DSP_Result_t DSP_Rfft1024(float32_t *buffer);

这层适配的好处有三个：一是业务代码可读性提高，二是如果将来从CMSIS-DSP换到其他DSP库，只需要改适配层而不动业务层，三是可以在适配层统一检查函数返回值、做参数合法性判断，避免CMSIS-DSP的错误码被业务代码忽略。

6.3 把核心算法搬到PC上验证

CMSIS-DSP虽然为ARM优化，但其中绝大多数算法是纯C实现，完全可以拿到PC上做桌面级验证。具体做法是把arm_math.h做少量适配，去掉ARM专属类型定义和部分编译宏分支，保留数学函数源码编译到x86平台。用Windows或Linux下的Visual Studio/GCC运行算法，配合Python的numpy对比结果，能非常快地把滤波器系数、FFT变换逻辑、矩阵运算逻辑调试正确，再回迁到MCU。

这个流程我几乎每个项目都在用。它最大的价值是能快速确认“算法逻辑有没有问题”和“MCU实现有没有问题”之间的边界。PC上验证通过的逻辑，在MCU上如果输出不一致，往往就是定点溢出、数据类型别名、字节序这类平台相关的问题，排查范围一下就缩小了。

7. 几个值得反复琢磨的源码细节

7.1 实例结构体的初始化与内存生命周期

CMSIS-DSP大部分模块都要求先调用xxx_init_f32之类的初始化函数。这个初始化函数做的事往往包括：填充系数指针、配置状态缓冲区、根据变换长度选择对应的旋转因子表。很多人图省事，会在系统启动时初始化一次，之后就再也不管。这在单任务模型下还行，但在多实例、多核或动态创建任务的场景下，就可能出现实例结构体被覆盖、缓冲区未清零导致的错误结果。

审计源码时，我建议特别关注结构体里的指针成员。例如arm_fir_instance_f32里的pCoeffs和pState，它们都只是指针，不负责分配内存。所以分配内存的责任完全在你这边，一旦缓冲区被销毁了但实例结构体还在，指针就成了野指针。这类问题在长期运行的产品里特别危险，因为内存被复用后看起来可能正常，但偶发一次异常就够你排查几周。

7.2 状态缓冲区初始化为零的重要性

FIR和IIR滤波器的状态缓冲区，必须初始化为0。如果你用的是局部变量数组，一定要先memset清0，否则滤波器初始阶段的输出会出现一段非零瞬态，表现为“开机波形先是乱的，过一会才正常”。这个问题在调试录音或振动分析功能时很容易被误判为传感器启动异常。

7.3 关于函数返回值的“职业习惯”

CMSIS-DSP里不少函数是有返回值的，尤其矩阵求逆、解线性方程这类带数值风险的函数。但很多示例代码都不检查arm_status，这就给固件埋下了隐患。矩阵接近奇异时，求逆结果可能误差巨大，如果你直接拿去算控制量，产线测试可能过，但极限工况下会出大问题。所以我在固件代码里有一条不成文的规矩：所有带arm_status返回值的调用，必须做错误分支处理，哪怕只是把错误码放进日志，也比无视强。

7.4 与RTOS结合时的优先级与任务栈规划

在RTOS环境里调用CMSIS-DSP，比裸机多一个问题：任务栈深度。FFT这类函数用到大量局部变量，栈消耗不容小觑。我记得在一个FreeRTOS项目里，任务栈配置为1024字节，运行到4096点FFT时直接HardFault，后来把栈加大到2048字节才稳定。所以如果你在RTOS任务里用CMSIS-DSP，建议先通过静态分析工具或实测最大栈深度，再配置任务栈大小，别拿默认值赌运气。

另外，CMSIS-DSP内部不会主动让出CPU，如果它在低优先级任务里运行时间过长，会影响高优先级实时任务的调度。一般做法是把大块计算放到专用任务里，并合理设置任务优先级和调度时隙，或者在裸机里用时间片轮转，分块处理数据。

最后再说点实在话

很多朋友问我，CMSIS-DSP到底有没有必要读源码。我的看法是：如果只是抄几个示例跑通Demo，那确实不需要；但如果你要把它用在工业产品里，要压Flash、压延迟、压异常率，那就非读不可。库本身经过大量验证，出问题的地方大多是集成层的“错位”——宏没配对、数据没对齐、Cache没做一致性处理、状态缓冲区被踩、栈不够深、没有检查返回值。

实际项目里遇到CMSIS-DSP表现异常，我的第一反应从来不是怀疑库本身，而是先把工程环境里那些“看不见的宏”梳理一遍，再去看数据路径和内存布局。这套源码审计下来，绝大多数“库有bug”的结论，最后都变成了“我用错了”。希望这篇走读式的源码评测，能帮你在自己的固件项目里少踩几个坑，把时间花在真正需要算法的业务逻辑上。