在嵌入式开发这个圈子里，状态机是块难啃的骨头。尤其是做工业控制、汽车电子、复杂物联网设备的朋友，应该都有过这种体验：产品功能一多，逻辑判断一复杂，原先那套用switch-case手写状态机的办法就开始现原形了——代码膨胀到几千行，状态跳转理不清，加了新功能又怕改坏老逻辑，最后整个项目组都陷在维护的泥潭里。
我早年在一家做工业设备控制器的公司干活，当时固件里跑着一个核心控制逻辑，用传统的手写状态机加标志位维护。到了后期，三千多行的case嵌套，连原作者都要翻着笔记本才能改。后来我们把这一块彻底重写，换成了基于模型的设计方式，工具用的就是 IAR Visual State。这个决定可以说救了那个项目。近期看到 IAR 更新了 Visual State 针对大型复杂设计的支持，专门把这个事拿出来聊一聊，既有工具层面的解读，也有我在实际项目中积累的一些经验和踩过的坑，希望能帮到正在跟复杂状态逻辑搏斗的工程师。
1. 项目核心解读：IAR Visual State 到底解决什么问题
很多工程师一听到“模型驱动开发”，第一反应是“又要学一套新工具，值吗”。这个问题我当初也纠结过，但如果你手头的项目状态逻辑已经复杂到人力难以维护，模型驱动开发就不是“值不值”的问题，而是“不得不”的选择。
1.1 模型驱动开发的现实意义
先解释一下什么是模型驱动开发（Model-Based Design，MBD）。它的核心思想是：不直接用代码来表达复杂逻辑，而是先用图形化模型把逻辑画出来，然后通过工具自动生成代码。这个图形模型是“唯一真理”，代码只是它的产物。
IAR Visual State 就是这个理念在嵌入式领域的最佳实践之一。它专门针对 UML 状态图（Statechart）设计，允许你用可视化的方式构建状态机，然后用它内置的代码生成器直接产出标准 C 或 C++ 代码，跑在各类 MCU 上。我当年用它做工业控制器的核心调度逻辑，整个状态机的维护成本至少降低了 60%。碰到需求变更，改一张状态图比翻几百行case语句要快得多，而且不会因为手滑改出个隐藏 Bug。
这次更新的关键词是“Large Complex Designs”，也就是面向大规模复杂设计的优化。说白了，就是当你的状态图里有几百个状态、上千条迁移时，工具能不能扛得住，设计能不能一目了然，代码能不能还是保持高效。
1.2 大型复杂设计面临的真实瓶颈
嵌入式系统的复杂度在快速上升。以前一个系统有两三个状态就差不多了，现在的设备动辄十几个运行模式，各种异常处理、恢复流程、用户交互交织在一起，状态数量轻松突破几十个。当状态图膨胀到这个量级，一些之前不起眼的问题会变得非常致命：
- 可读性崩塌：几百个状态画在一张画布上，鼠标滚轮滚半天都找不到目标状态，设计者自己都要崩溃。
- 迁移关系错综复杂：状态一多，迁移条件互相交织，很容易出现“状态A能跳B，B也能跳A，但某条路径下会死循环”之类的隐性错误。
- 代码生成效率下降：工具处理大型模型时的响应速度、生成代码的体积和效率，直接关系到实时性。
- 团队协作困难：多人同时修改同一个状态图，合并冲突怎么处理，也是大型项目的难题。
1.3 适合哪些嵌入式场景
Visual State 不是所有嵌入式项目的万能药。根据我的实战经验，它特别适合下面这几类场景：
- 通信协议栈实现：协议状态多、迁移条件严格，非常适合用状态图表达。我曾经用它实现过一个 Modbus 从站协议栈，整个实现干干净净。
- 用户界面逻辑控制：多页面、多菜单、多交互模式，状态之间的流转用图表达比代码直观得多。
- 工业自动化控制流程：设备的启停、暂停、急停、复位、故障恢复，状态机的经典应用场景。
- 电池管理、电源管理：充放电状态、保护状态、异常状态的切换，对可靠性要求极高。
- 汽车电子中的控制逻辑：车窗防夹、空调模式切换、车身控制模块，这类逻辑复杂且对安全有严格要求。
如果你做的产品逻辑相对简单，状态就那么三五个，那完全没必要引入建模工具，手写代码反而更直接。选择 Visual State 的决策依据永远是一个：状态逻辑是否已经复杂到影响开发和维护效率。
2. 大型复杂建模的三大痛点与对应设计能力
说完了 Visual State 是干嘛的，接下来聊聊在大型复杂设计中它能否扛得住。我把自己在项目中真实遇到的痛点和这次更新对照着看，发现每个痛点都有对应的设计能力升级。
2.1 状态爆炸问题：从扁平状态机到层次化架构
我见过很多工程师画状态图，不管逻辑多复杂，全画在一个平面里。比如一个设备控制系统，光主状态就有初始化、待机、运行、暂停、故障、恢复这么 6 个，每个主状态下又有若干子状态，比如运行状态下又分前进、后退、急停等。如果全部用扁平方式画，状态数量直接爆炸，而且状态之间的迁移关系会乱成一锅粥。
Visual State 一直支持层次状态机（Hierarchical Statechart），这也是它区别于简单状态机插件的核心能力之一。它允许你把复杂系统拆解成多个层次：
- 顶层状态机（Root Statechart）：定义系统的主体运行流程。
- 嵌套状态（Composite State）：在主状态内部再细分子状态机。
- 正交区域（Orthogonal Regions）：处理真正并行的行为，比如同一个状态内同时处理通信和用户交互。
这次更新重点提到“支持大型复杂设计”，在我看来最值钱的就是对深层嵌套层次结构的管理能力。当状态图层次达到四五层，画布上元素多达几百个的时候，Visual State 依然能保持流畅的编辑响应。我实际试过，在展开所有层级的预览模式下，能够快速在多个子状态图之间切换，没有明显的卡顿感。
层次化架构带来的直接好处是：每个状态图都保持在可控的复杂度范围内。你不用在一张图上理解所有东西，而是可以先看顶层概览，再逐层下钻。这在团队协作里价值极大——不同成员负责不同的子状态图，互不干扰。
2.2 实时性焦虑：生成代码的效率与质量
模型驱动开发一直被老派工程师诟病的一点是——生成的代码效率不行。这个观点在小规模项目里也许还能成立，但到了大型复杂设计，手工代码的“效率优势”早就被“维护成本”给淹没了，而且现在优秀的代码生成器，产出的代码质量并不差。
Visual State 的代码生成器可以直接产出目标平台的源代码，然后整合进 IAR Embedded Workbench 的工程中。在大型项目中更关键的是以下两点：
代码体积控制。状态机逻辑通常需要一张二维数组存储状态迁移表，状态一多，表就会变大。Visual State 在编译时会对状态表做压缩和优化，避免庞大的静态表占用过多 Flash。实际在我的一个项目里，一个包含 100+ 状态的状态机，生成的完整模块代码量约 8KB 左右，在 32KB Flash 的 MCU 上完全可接受。
执行效率。状态机的执行不外乎两件事：事件分发和状态迁移。事件分发需要快速定位当前事件在哪个状态里被处理，状态迁移需要查找迁移表、执行迁移动作。Visual State 对这两块都做了针对性优化，事件索引和状态表查找的时间复杂度可以做到近似常量级别，对实时任务的确定性非常友好。
我在实际项目中把 Visual State 生成的代码跑在 72MHz 的 Cortex-M3 上，一次完整的状态迁移执行时间在微秒级。这个性能完全满足绝大多数嵌入式实时性要求。如果你需要极致优化，还可以通过对生成配置的调整，去掉不需要的功能模块，进一步缩减体积和耗时。
2.3 团队协作与文化阻力：多人协同建模的机制
这里多讲一点团队协作。很多团队在引入 MBD 工具时，最大的阻力来自人，而不是工具。有经验的工程师习惯了手写代码，会本能地质疑“画图能比写代码靠谱吗”。但真正用了你就会发现，团队协作的效率提升是实打实的。
比如一个做智能家居网关的项目，我负责设备通信模块，另一个同事负责 UI 交互模块。我们各自维护独立的子状态图文件，通过统一的模型接口集成。如果按照传统方式，两个人同时修改同一个control.c，天天都是合并冲突。现在所有的状态迁移逻辑都用图形化表达，代码由工具统一生成，冲突概率大幅降低。
大型设计的另一个痛点是模型与文档的一致性。传统开发中，代码更新了，设计文档往往就过期了。Visual State 生成的模型本身就是设计文档，修改模型就是修改设计，这个“设计即代码、代码即设计”的特性，在项目验收和交接时的价值是无法量化的。
3. 本次更新的关键设计能力拆解
我刚开始接触 Visual State 的时候，它已经具备相当成熟的建模和代码生成能力。而这次更新在大型复杂设计方面做了明显增强，我从实际使用角度拆解一下几个核心能力点。
3.1 可视化编辑与大型模型的支持
做状态图最怕什么？最怕画布大、元素多的时候操作卡顿，缩放迟钝。这次更新之后，对大型模型的编辑流畅度确实改善明显。
我在一个测试项目中把完整的工厂自动化设备控制状态机导入，这个模型包含 5 个层次、40 多个复合状态、超过 200 条迁移。在 Visual State 中打开后，无论是拖动元素、缩放画布，还是展开折叠子状态，响应都很跟手。之前用某些画图工具，一旦文件大了，鼠标拖一下要等半秒，完全没法干活。
另外一个细节是“上下文导航”。模型一大，你就需要一个全局视图来定位当前视角在哪。Visual State 的导航功能保留了从全局到局部的逐层下钻能力，操作逻辑清晰，不需要刻意学习就能上手。
3.2 更精细的验证与仿真手段
大型状态机最怕的不是画不出来，而是画出来了但整体行为不对。手动画图验证复杂模型的正确性，几乎不可能。Visual State 提供了模拟器（Simulator）和验证器（Verifier），这两个工具我在项目里用得最多。
模拟器：可以在没有硬件的情况下，手动触发事件，逐步观察状态机的行为。调试时我习惯把它和“事件跟踪”功能配合使用，状态迁移的过程会以轨迹形式记录下来，哪一步跳错了，一目了然。
验证器：这是 Visual State 的杀手锏。它可以自动化验证状态机是否符合某些特定属性。比如“无论发生什么事件，系统永远不会卡在某个无效状态”“某个故障发生后，系统最终能恢复到安全状态”。这类验证在传统编码方式下需要写大量的单元测试，而 Visual State 用模型检查（Model Checking）的方式做了形式化验证，这在安全关键嵌入式中尤其重要。
要强调的是，你验证的是模型本身的逻辑正确性。也就是说，Bug 在代码生成之前就会被发现。这比写代码然后反复调试的成本低得多。
3.3 代码生成链路的工作流整合
模型画的再漂亮，最终落地还是得靠代码。Visual State 现在与 IAR Embedded Workbench 的整合度很高，整个工作流可以这样串联：
- 在 Visual State 中构建或导入状态模型。
- 配置代码生成选项，选择目标语言和框架。
- 一键生成 C/C++ 源码，自动输出到指定目录。
- 在 IAR Embedded Workbench 中直接添加生成的源文件进行编译、烧录、调试。
关键在于，这个流程是双向的。你在 IAR Embedded Workbench 中调试的时候，如果发现状态机行为和预期不一致，不需要去翻生成的代码，而是回到 Visual State 修改模型，再重新生成。模型始终是唯一的权威，这对于大型复杂设计的迭代维护来说，意义重大。
3.4 从模型生成代码后如何维持一致性
很多工程师会担心一个问题：模型生成的代码，如果我又手动改了，下次再生成会不会被覆盖？
答案是：绝对不要改生成的代码。这些代码是编译产物而不是源产品，任何修改都会在下次生成时丢失。正确做法是：
- 所有逻辑改动都在模型里做。
- 生成代码只负责编译和烧录。
- 如果确实有模型表达不了的逻辑，考虑用“用户自定义代码”机制（即模型中嵌入的 C 语言片段），而不是去改生成文件。
我团队里有个同事刚上手时因为急着加一个功能，手改了生成的.c文件，结果下一次重新生成代码后，改动全部丢失，还找了半天原因。这个教训很典型。
4. 实操全记录：从状态图设计到目标板运行
讲再多理论，不如来一遍实操。我以一个典型的“智能设备控制系统”为例，演示从需求到目标板运行的完整过程。虽然我用的版本和项目细节可能与你的不完全一样，但整体思路是通用的。
4.1 需求拆解与状态图布局
假设我们做一个智能风扇控制器，功能需求如下：
- 设备有开机、关机按钮。
- 运行时有三档风力：低、中、高。
- 支持定时关机：15/30/60 分钟可选。
- 有异常保护：电机过流时进入故障状态，需要重启恢复。
这个系统不算大，但足以展示 Visual State 的操作流程。我画状态图之前，习惯先在笔记本上把状态清单列出来，避免建模时手忙脚乱：
- 顶层状态：关机、运行、故障。
- 运行状态的子状态：低档、中档、高档。
- 每个档位下都可以开启定时器。
4.2 用 Visual State 创建层次状态机
打开 Visual State 后，新建工程，创建一个状态图。先创建顶层状态机，然后依次添加三个主状态：Off、Run、Fault。
接着把Run设为复合状态，进入它的内部，创建三个子状态：Low、Medium、High。这个操作就是 Visual State 的层次化建模——双击复合状态进入下一层，编辑完成后回到上层。
四个核心状态建立好后，开始添加迁移。迁移就是状态之间的箭头，每个迁移可以添加条件（Guard）和动作（Action）。比如：
Off -> Run，条件是EVENT_POWER_ON，动作是“启动电机到低速”。Run -> Off，条件是EVENT_POWER_OFF。
这里注意，条件是事件发生的必要条件，动作是在条件满足、迁移执行时触发的操作。不要把两者混为一谈。
4.3 添加动作、条件与定时器事件
状态机模型中我最常用到的几个元素包括：
- 状态（State）：图中有明确含义的节点。
- 迁移（Transition）：状态之间的有向连线。
- 事件（Event）：触发迁移的外部信号。
- 条件（Guard）：事件发生时要额外检查的条件。
- 动作（Action）：迁移或进入状态时执行的操作。
具体到风扇项目，我定义了系统事件：
EV_POWER_ONEV_POWER_OFFEV_TIMEOUTEV_FAULTEV_FAULT_RESET
然后在模型中给每个迁移挂上条件和动作。比如Run状态下，不管是哪个档位，只要收到EV_FAULT，就无条件迁移到Fault状态。这个全局迁移在扁平状态机里要实现得写好几条重复逻辑，但在层次状态图里，可以直接从某个更高层级拉一条迁移，子状态自动继承。
定时器逻辑稍微复杂一点。我们定义了一个activeTimer变量，在进入定时状态时启动，并用一个整型变量记录剩余时间。EV_TIMEOUT由定时器中断触发，当超时后从对应状态迁移到Off。
Visual State 支持在模型中使用全局变量和函数调用，我直接把这些变量定义为项目中的全局变量，在生成代码中作为全局链接。这样状态机代码和业务代码可以无缝交互。
4.4 生成代码并与 IAR Embedded Workbench 集成
模型构建完成后，进入代码生成环节。VS 的代码生成器会询问几个关键配置：
- 目标语言：选择 C 语言（嵌入式使用最广泛，也便于移植）。
- 存储配置：选择生成的代码是否要处理掉未用状态。
- 对外接口函数：事件触发方式一般有两种——阻塞式轮询和中断式。我一般选择中断式，通过一个全局事件队列把外部事件送入生成代码的内部处理器。
生成代码后，会得到一批文件，我这里以简化的典型结构为例说明：
src/ ui_state.c // 状态机主体实现 ui_state.h // 状态机接口头文件 ui_state_own.c // 用户自定义逻辑代码 ui_state_own.h其中ui_state_own.c是用户扩展区。这个文件很重要，它是模型代码与手写代码之间的一道安全门。你可以在这个文件里填上具体的动作实现，比如“电机置为高速”“定时器启动”等，这些操作不会被模型覆盖。
生成完代码后，打开 IAR Embedded Workbench，新建或者打开现有工程，把生成的源文件加入工程。然后照常编写main.c，初始化硬件，调用状态机的初始化函数，最后在事件循环中把外部事件喂给状态机就行。
4.5 在目标板上调试与验证
实际调试环节，Visual State 和 IAR Embedded Workbench 的整合优势就体现出来了。IAR 的调试器可以直接调试生成的状态机代码，我习惯在关键迁移动作处打断点，观察状态跳转是否符合预期。
调试时我最常看的三个位置：
- 状态机主入口（事件分发函数）——看这个事件是否被正确路由。
- 状态迁移执行函数——看离开状态和进入状态的钩子函数是否正确被调用。
- 动作回调函数——确认具体硬件操作是否被执行。
除了断点，Visual State 的模拟器在前期也可以用来快速验证设计。我会在模拟器里把风扇控制的全部逻辑跑一遍，确认各种正常流程和异常流程都符合预期，然后再烧到真机上跑。真机调试主要用于确认对外设的控制参数没问题，逻辑本身在模拟器阶段已经被验证过。
5. 大型状态机项目中的常见问题与排查经验
最后聊点实操中容易踩的坑。状态机模型越大，这些坑越要提前避开。我根据自己的项目经验整理了下面几个高频问题，按“症状—原因—对策”的方式对照说明。
5.1 状态机“死锁”与状态事件丢失
症状：模型在某个状态下卡住，不管怎么发事件都不迁移。
排查思路：先确认事件是否真的发生了。我在一个项目里遇到“按了按钮但状态机没反应”，查了半天发现是事件函数没有正确从中断中调用。状态机的Event回调函数跑在主循环中，而中断优先级很高，事件被中断抢占后没能及时清掉，最终状态机永远收不到事件。反复分析后我改用事件队列，所有中断只往队列里丢事件，主循环统一处理，问题就解决了。
对策：建议所有外部信号统一经由事件队列转发，不要在中断服务函数里直接调用状态机处理函数。原因有二：第一，状态机内部可能有关键的状态表访问，如果中断打断，可能出现数据竞争；第二，多个事件同时到达时，队列能保证处理顺序的确定性。
5.2 生成代码过大或者实时性不达标
症状：状态机生成代码占用的 Flash 太大，或者事件分发耗时较长。
排查思路：先看状态图本身是否过于冗余。很多工程师用工具时习惯复制粘贴相同逻辑的状态，导致状态数量虚高。实际上可以用层次化结构 + 守卫条件来合并相似状态。
然后看代码生成配置。我一般会把“输出调试信息”关闭，把“未使用状态优化”打开。这能显著减少生成的代码体积。在性能方面，如果事件分发是大头，可以检查是否启用了“使用状态表索引”选项，它能省掉线性的if-else链。
对策：状态表最好做成静态只读表，一来速度可控，二来不会占用 RAM。生成代码后，用 IAR 的编译报告功能查看各模块的占用情况，定位是哪个模块占了空间，再做针对性裁剪。
5.3 与现有手写代码混合开发的边界问题
症状：项目里既有 Visual State 生成的代码，也有手写业务代码，集成后各种链接错误。
排查思路：绝大多数问题都出在“变量定义重复”和“函数命名冲突”。Visual State 生成代码时会使用模型中的变量和状态名，如果你在别的地方也定义了同名的全局变量，链接阶段必炸。所以建模之初就要统一命名规范，比如所有的模型全局变量统一前缀vs_，模型函数统一前缀vs_。
对策：实体交互逻辑强烈建议不要嵌在状态图中，而是通过ui_state_own.c里的用户函数去调底层驱动，或者用回调函数注册机制。状态图只负责“当条件满足时调用 vs_motor_set_speed(2)”，至于这个函数怎么实现，完全由你自己的业务代码决定。这样状态机代码非常干净，替换和移植都容易。
5.4 团队协作中的模型版本管理
症状：多人同时修改同一个状态机模型，合并时出现不可解决的冲突。
排查思路：Visual State 的模型文件本质上是文本格式，理论上可以跟踪，但图形元素的位置信息很容易在合并时产生大量噪声。不同的人拖一下框，两个版本的坐标就全不一样，合并起来惨不忍睹。
对策：我后来形成的团队分工方式是，尽量按模块拆分子状态图，一人负责一个子图，主图由一个人统一维护。各子图相对独立，冲突概率大幅下降。模型文件的变更注意及时提交差异记录，便于回滚和追溯。
另外还要提一个老生常谈但重要的点：版本控制工具要能处理模型文件，最好使用团队约定的流程。不要因为合并痛苦就直接跳过版本管理，那是把隐患留到后面。
5.5 调试 HardFault 的经验分享
这个问题在 IAR 使用中非常常见，尤其和状态机模型集成时。生成的代码直接跑在 MCU 上，遇到 HardFault 时，定位思路一定要清晰。
在 IAR 中调试 HardFault，最有效的方法是查看硬件故障寄存器（CFSR、HFSR、MMFAR、BFAR）。IAR 的调试器可以直接打开寄存器窗口查看这些值。比如：
MMFSR位被置位，说明总线/存储器管理异常，常见于非法地址访问。BFSR位被置位，说明总线异常，可能访问了外设地址但外设未使能。UFSR位被置位，说明未定义指令，可能是函数指针被改写、跳到了错误地址。
用状态机生成的代码时，HardFault 往往不是状态机逻辑本身的问题，而是动作函数里访问了不合法地址。比如某个事件触发了指向驱动层的回调函数，但这个驱动函数还没初始化，最终访问了空指针。
定位方法是：在异常回调函数HardFault_Handler()里打断点，查看故障发生时的 PC 寄存器和 LR 寄存器。然后在反汇编窗口跳转到 PC 地址，就能看到具体是哪个函数、哪一行触发的异常。再用调用栈回溯，就能找到是状态机的哪个动作调用了问题函数。我现在基本可以在 10 分钟内定位到问题源头，熟练后效率非常高。
6. 实战中的额外经验：模型设计习惯决定成败
模型驱动开发的工具链本身很成熟，但我观察很多人用不好，问题不在工具，而在设计习惯。这里分享几条我认为值钱的体会。
6.1 建模之前先想清楚边界
我用 Visual State 建模时，会刻意区分“状态机管什么”和“状态机不管什么”。比如状态机管“哪个状态、什么条件、跳到哪”，但不该去管理“具体怎么控制电机转速”——那是驱动层的事。模型里的动作，尽量写成对外部函数的调用，而不要堆业务逻辑。这样才能保持模型的清爽和可验证性。
6.2 不要把所有东西都塞进一张图
这是使用任何建模工具时最容易犯的错误。一个状态图包含所有细节，看起来面面俱到，结果就是谁都看不懂。正确的做法是分层：顶层只显示最关键的模式切换，细节放在子状态图里。Visual State 的复合状态在顶层显示为一张“卡片”，只有下钻才能看到内部细节，这就是为大型设计准备的体系结构。
6.3 守卫条件越简单越好
大型模型里最危险的是“复杂的守卫条件”。守卫条件本身也是代码，条件写得过于复杂，可读性会大幅下降，而且验证器做形式化验证时也更难收敛。我给自己定的一条纪律是：单个守卫条件尽量用简单的事件加一到两个布尔表达式的组合，超过三层逻辑就拆状态机或者拆变量。
6.4 保持代码生成配置的一致性
同一个项目组里，不同工程师的 Visual State 代码生成配置如果不统一，会导致生成的代码会有细微差异，合入版本库时产生大量无意义 diff。我建议项目启动时就把统一的代码生成配置方案固化下来，作为项目规范之一。这个细节看着不起眼，但在大型项目里能省很多事。
6.5 定期做模型评审
和代码评审一样，状态机模型也需要评审。因为我个人的经验是，画图比写代码更容易“自己骗自己”。图上的逻辑看起来顺理成章，但让另一个工程师按照业务需求走查一遍，很容易发现遗漏迁移条件、重复状态等问题。模型评审的成本远低于代码 Bug 排查的成本，这个性价比值得算。
写在后面：关于大型复杂模型驱动设计的一点体会
我始终认为，工具升级带来的不只是功能的堆叠，更是一种开发思维的刷新。Visual State 这次在大型复杂设计上的更新，本质上是承认了一个现实：嵌入式软件正在变得越来越复杂，传统的手写状态机方式在某个复杂度阈值之上，会不可避免地走向失控。
我在实际操作中体会到，模型驱动开发的最终收益不在于“自动生成代码”这一个环节，而在于它逼着你把状态逻辑梳理清楚、把边界划分明白、把验证做到前置。如果模型本身是一团乱麻，那生成出来的代码也只会是一团乱麻的另一种形式。这也是为什么我会反复强调建模前的设计习惯，而不仅仅是工具操作。
最后，再分享一个小技巧：如果你正在评估是否要把 Visual State 引入自己的项目，别急着拿最复杂的模块做试验，先挑一个中等复杂度的模块走通全流程。这样可以在最小的风险下验证工具链是否适合你的团队，也让团队先积累起建模的感觉。等大家真正上手了，再拿它去啃最硬的骨头，阻力会小很多。
