企业官网建设流程全解析

前阵子项目评估需要给一台设备加触摸屏界面，主控早早就定了 STM32F429，外设很快跑通，结果卡在了“界面怎么做”这个看似简单的问题上。裸写 LCD 驱动不是不行，只是按钮点击、字体渲染、滑动动画这种活，一旦全手写，工期会被拖得非常难看。那几天我一直在各条 GUI 技术路线之间反复横跳，最终真正留下来并跑起来的，是 TouchGFX。

这篇文章是从零开始把 STM32F429 和 TouchGFX 接起来的全过程记录，包含硬件选型思路、环境搭建、界面设计、性能优化和一次完整白屏故障排查。如果你也有一块 F429 板子、准备做带屏产品，或者只是想看看 TouchGFX 到底好不好上手，可以按我的路线走一遍，踩过的坑我已经帮你趟平了大半。

1. 为什么是STM32F429和TouchGFX这对组合

1.1 在选型阶段，我为什么锁定了F429

做带屏交互设备，主控芯片的选择其实比大多数人想象中要窄。你要考虑驱动 RGB 屏的能力、内存带宽、是否有硬件图形加速，还要考虑成本、供货和开发工具链。STM32F429 在这几个维度上正好卡在一个很舒服的位置。

首先是性能底线。F429 用的 Cortex-M4F 内核，主频最高 180MHz，带硬件 FPU。单纯跑业务逻辑不算顶级，但配合芯片内置的 LTDC（LCD 控制器）和 DMA2D（2D 图形加速器），做 4.3 寸、5 寸甚至 7 寸的 RGB 接口屏幕绰绰有余。LTDC 这个外设是关键，它可以直接输出 RGB 并行信号给屏幕，不需要再外挂一颗 RA8875 或者 SSD1963 之类的显示驱动芯片，BOM 成本低一大截。

其次是内存扩展能力。F429 的 FMC 控制器支持外接 SDRAM，我手头这块板子外挂了 8MB 的 SDRAM。对 GUI 应用来说，SDRAM 的重要性甚至超过 Flash——因为帧缓冲（Frame Buffer）必须放在里面。一块 480x272、RGB565 格式的屏幕，单帧缓冲就要 480x272x2 字节，大约 255KB；如果换成 RGB888 格式，直接翻倍到 765KB。内部那点 SRAM 根本装不下，SDRAM 几乎是必选项。

最后是资源与成本的平衡。F429IGT6 常见的是 1MB Flash 和 192KB 内部 RAM，比上不足比下有余。跟更高端的 F7/H7 比，它价格友好；跟 F1/F3 比，它又有完整的显示相关硬件单元。对产品形态固定、界面复杂度可控的项目来说，F429 是我认为最不容易选错的起点。

1.2 GUI方案横向比较：裸写底层、轻量GUI、TouchGFX

在决定用 TouchGFX 之前，我认真评估过另外两条路。

一条是裸写底层。用 LTDC 刷屏、DMA2D 加速拷贝，再自己实现按钮、进度条、文本换行、图片解码。说实话，画点、画线、填充矩形这些基础能力花一天就能跑通，但一旦涉及到触摸命中测试、控件重叠、焦点管理、字体抗锯齿、多国语言切换，工程量会指数级上涨。我评估过时间成本，至少得按三个月起步，而且做出来的效果大概率还是有点“工程味”。

另一条是轻量级 GUI 方案，比如 U8g2 这类纯软件渲染库。它们的优点是代码体积小、硬件要求低，适配 SSD1306 这种单色屏或者小型彩屏很快。但用在 4.3 寸 RGB 触摸屏上就显得吃力了，动画效果、图像处理、矢量字体这些能力都偏弱，界面做出来容易显得廉价。

TouchGFX 正好补上中间这个空档。它是原厂持续维护的 GUI 框架，对 STM32 自家芯片的适配程度是最深的，脚到 DMA2D 加速、LTDC 显示接口、SDRAM 帧缓冲，它都能自动感知。更重要的是它附带一个桌面端的所见即所得设计器，叫 TouchGFX Designer，界面布局直接拖拽完成，生成的是 C++ 代码。我第一次用它拖出一个带按钮、文本、图片的页面只花了不到半小时，这在裸写方案里是不可想象的。

当然，它也有学习成本。MVP 架构、生成代码的结构、资源文件的管理方式，都需要时间适应。但相比其他方案的长期维护成本，这部分投入完全值得。

1.3 配套硬件选型：屏幕、SDRAM、存储

选了 F429 之后，配套硬件需要注意三个点：屏幕接口、SDRAM 型号、资源存储介质。

屏幕必须选 RGB 接口的 TFT，不能选 MCU 8080 并口或 SPI 接口的屏幕，因为 F429 的 LTDC 只能输出 RGB 同步信号。分辨率我建议从 480x272 或者 800x480 起步。480x272 的 4.3 寸屏很经典，像素时钟只要 9MHz 左右，配置余量大；800x480 的 5 寸屏显示信息更多，但像素时钟要 33MHz 上下，对 PCB 走线和初始化参数要求更高。触摸部分一定要确认屏幕带的触摸屏是电容式的，控制器一般是 I2C 接口，比如常见的 GT911 系列，这样和 F429 连接非常简单。

SDRAM 的选择主要看帧缓冲策略。如果只是单缓冲 RGB565 480x272，4MB 就够；要做 800x480 RGB888 双缓冲，建议至少 8MB。我后来是从 4MB 板子换到 8MB 的，多出来的空间不仅能放双缓冲，还能给 TouchGFX 缓存一些中间图像，优化空间大很多。

资源存储是个容易被忽略的坑。界面一旦做复杂了，图片、字体、动画素材编译出来很容易超过 1MB Flash。我跑第一个 Demo 的时候，两张全屏背景图加中文字体就逼到了 700KB。如果你的产品素材量大，建议预留 SPI Flash 或者 QSPI Flash 的接口，TouchGFX 可以把资源单独存到外部存储，运行时直接从外部读取。

2. 开发环境搭建：版本匹配比想象中重要

2.1 一套可以照抄的软件组合

TouchGFX 的开发链路不是单一个软件，而是三个工具配合：STM32CubeMX 用来配置芯片时钟、引脚、外设并生成底层代码；TouchGFX Designer 用来设计界面、生成 UI 代码；编译调试可以用 STM32CubeIDE 或者 Keil MDK。我第一次装的时候，最大的感受就是版本一定要匹配。

我当时的组合是：STM32CubeMX 6.x + TouchGFX Designer 4.2x + STM32CubeIDE。CubeMX 版本太老会看不到 TouchGFX Generator 插件，TouchGFX Designer 版本太新又会要求你升级 CubeMX，所以建议直接去官网把两个软件都下到当前最新的稳定版，安装路径不要带中文和空格，我的习惯是装到C:\TouchGFX这类干净目录下。

另一个容易踩的是 TouchGFX Designer 的环境依赖。它需要 Java 运行时环境，如果本机之前装过乱七八糟的 Java 版本，可能启动时报错。保险做法是安装工具链时让软件自己选择内置 JRE，不要手动指定系统 Java。装完以后，打开 TouchGFX Designer 能看到示例工程模板，就说明环境基本没问题了。

2.2 时钟树与LTDC时序：别把pixel clock配错

CubeMX 配置的核心是时钟树。F429 跑 180MHz 主频时，要确保外部晶振频率和 PLL 参数正确，这些常规配置网上一搜一大把，我不展开。这里只强调和 LCD 相关的两路时钟：LTDC 的像素时钟和 FMC 的 SDRAM 时钟。

LTDC 像素时钟的来源一般是 PLLSAI 或者 PLL Q 分频得到的。在 CubeMX 的 Clock Configuration 界面里，如果你勾选了 LTDC 外设，它会自动生成一个像素时钟值，但你需要手动改成和屏幕匹配的值。不同的屏有不同的推荐像素时钟，不要凭感觉填。

时序参数这一块，是我认为最容易翻车的地方。LTDC 要求你填写水平同步宽度（HSW）、水平后肩（HBP）、水平前肩（HFP）、垂直同步宽度（VSW）、垂直后肩（VBP）、垂直前肩（VFP）以及同步极性和数据极性。这些参数直接决定屏幕能不能正常出图，任何一项填错，轻则画面偏移，重则直接白屏。我手头这块 4.3 寸 480x272 屏的参数示例是：HSW=1、HBP=40、HFP=5、VSW=1、VBP=8、VFP=5，像素时钟 9MHz，背光 GPIO 另配一个引脚由自己控制。不同屏幕差异很大，我后来换了一块 5 寸屏，参数完全变成了另一套，所以最稳妥的办法是直接找屏幕卖家或原厂要初始化参数，然后照着抄进 CubeMX。

2.3 SDRAM初始化：帧缓冲的地基，需要先检查

在 CubeMX 里启用 FMC 并配置 SDRAM 很简单，麻烦的是 SDRAM 芯片的时序参数。CubeMX 里有一堆下拉选项：行地址宽度、列地址宽度、CAS 延迟、写恢复时间、刷新周期等。这些参数必须和实际芯片对应，不能照搬网上的“万能配置”。

我的经验是，先确认你板子上 SDRAM 的型号和容量，再去查它的数据手册。比如常见的一种 8MB SDRAM，行列地址组合是 12 行 x 8 列，CAS 延迟选 2 至 3。刷新周期（Refresh）这个参数尤其容易被忽略，它如果配错，短时间读写没问题，过一会儿就会出现随机性的数据错误，表现就是屏幕上有一些区域花掉或者闪烁。我当时排查这个问题花了整整一个晚上，最后把刷新周期调大才稳定下来。

SDRAM 初始化还有一个隐蔽点：CubeMX 生成的MX_SDRAM_Init函数返回HAL_OK，不代表你就能直接访问整块 SDRAM。建议生成工程后，第一时间在main()里做一次读写测试，往 0xC0000000 起始地址连续写一段数据再读回来，能读回来再去跑 TouchGFX，要不然等界面刷出来才发现花屏，定位范围会大很多。

uint16_t *p = (uint16_t *)(0xC0000000); uint16_t testValue = 0x5A5A; for (int i = 0; i < 1024; i++) { p[i] = testValue; } // 再读回校验 for (int i = 0; i < 1024; i++) { if (p[i] != testValue) { Error_Handler(); } }

2.4 首次生成工程后的验收清单

CubeMX 配置完成后，在 Middleware 里勾选 TouchGFX Generator，然后生成工程代码。第一次生成的工程编译，大概率会碰到几个问题，我整理成清单方便你自检：

• 确认 TouchGFX 相关源文件已经加入工程：生成后的工程里应该有TouchGFX文件夹，里面有target和generated两个主要子目录，如果编译报找不到头文件，优先检查这里。
• 确认 C++ 编译支持已打开：TouchGFX 的核心代码是 C++，有些 IDE 模板默认只编 C，需要手动设置。
• 确认优化等级不要用 -O0：用 -O0 调试编译的时候，TouchGFX 渲染循环会慢到让人怀疑芯片是不是坏了。测试阶段可以先用 -Og，性能评估必须用 -O2 或者 -Os。
• 确认内存映射里 SDRAM 区域可见：如果你的链接脚本没有把 0xC0000000 区域映射进来，引用外部帧缓冲的符号会链接失败。

这部分通过以后，先把默认生成的空工程烧进去，屏幕上应该能看到一片纯色背景或者一个默认的 TouchGFX Logo。能跑出来，说明底层链路已经通了，接下来才是真正做界面。

3. 搭建第一个真实主界面：从设计器到设备

3.1 在TouchGFX Designer中完成界面初稿

TouchGFX Designer 的工作方式很像做网页设计，左边是控件面板，中间是画布，右边是属性面板。第一次打开可能有点懵，但上手速度会很快，因为它本质上是把“控件生命周期”这件事模板化了。

我的第一个界面做得比较简单，但足够覆盖完整链路：一个主页面上有背景图片、两个文本控件（一个显示标题，一个显示状态信息）和一个按钮；再新建一个次页面，放一个文本控件加一个返回按钮。在画布里把控件位置拖好，按钮设置圆角、填充色、按下效果，文本控件选择字号和颜色，差不多十分钟就能完成视觉部分。

这里有一个值得注意的点：TouchGFX 的界面层级关系是 Screen 下面挂 Container，Container 里放具体控件。如果所有控件都直接铺在 Screen 上，后续做动画效果时会非常痛苦。我的建议是哪怕最简单的页面，也先用一个 Container 把内容包起来，相当于在一个隔离的画布里做布局，后面加动画、加逻辑都更方便。

设计器里可以直接预览运行效果，它内置了一个 PC 端的模拟器。第一次做出来的界面，如果从模拟器看效果正常，再烧到开发板，能省掉不少反复烧录的时间。模拟器的帧率通常远高于真实硬件，所以你只能看布局和交互逻辑，不能把模拟器帧率当性能标准。

3.2 字体资源处理：中文变方块是每个人都逃不掉的坑

我做完界面兴奋地烧进板子，屏幕上其他都正常，只有中文全部显示成方块。这个坑只要是做中文界面的，几乎人人都会踩一次。

原因很简单：TouchGFX 默认生成的字体资源只包含英文和数字这些 ASCII 字符，中文字符集没有包含在内，所以你放什么中文文本进去，它都没有对应的字形可以渲染。解决方法是在文字资源的字体设置里，把需要显示的字符加入字符集。

具体怎么做呢？设计器里的 Globals 区域可以创建 Typography，也就是字体风格定义。你选择字体文件、字号、颜色模式后，关键一步是选择 Unicode 范围。如果只是界面上一句中文，我建议用“自定义字符”模式，直接把这句话包含的所有汉字打进去，生成的字体资源会很小；如果需要支持大量的可变化文本，比如用户输入，那就要把 GB2312 常用字集整体包含进来，代价是生成的字体文件会非常大，可能直接吃掉小半块 Flash。

字号方面，中文至少选 24 号以上才会有比较好的抗锯齿效果，如果屏幕分辨率是 480x272，正文 20 号、标题 32 号是比较平衡的选择。再提醒一句：字体资源生成后，不要频繁改文本内容，每次加新的汉字，字体文件都会重新生成一次，Flash 占用会缓慢增长。所以初期规划时要预留空间，或者尽早把字体资源挪到外部存储。

3.3 按钮点击与页面切换背后的MVP逻辑

TouchGFX 的代码结构用了 MVP（Model-View-Presenter）模式，这和很多嵌入式工程师熟悉的裸机思维不一样。简单理解：View 负责界面显示和事件接收，Presenter 相当于中间协调层，Model 负责业务数据和底层驱动。这样的好处是界面代码和业务逻辑解耦，坏处是刚接触时找一个回调函数的调用链路会找半天。

我第一个按钮的功能是“点击后从主页切换到次页”。在设计器里处理很简单：选中按钮，添加一个 Interaction，触发条件选“点击”，动作选“切换屏幕”，目标选次页，然后选择切换动画方向，比如向右滑动，就完事了。设计器会自动把相关代码生成到 View 里。

如果需要更复杂的业务逻辑，比如“点击按钮后要先把当前状态保存下来再切页”，那就要在 View 里覆盖clickHandler函数，或者通过 Interaction 触发一个自定义信号。这时你会看到系统生成的代码在 View 和 Presenter 之间来回跳。我的经验是，不要试图直接在生成代码的夹缝里改业务逻辑，正确做法是在 Presenter 或 Model 里写自己的函数，View 里只做事件转发。

一个非常容易踩的坑是：你在切换页面时的那个滑动动画，TouchGFX 默认会同时做两个页面的过渡帧，内存消耗会临时升高。如果屏幕分辨率高、帧缓冲又是双缓冲，叠加动画期间的内存峰值会很大，严重时会触发 HardFault。我在 800x480 屏上就遇到过，后来把过渡动画改成淡入淡出，内存峰值明显下降。

3.4 编译、烧录、联调的先后顺序

有了 Design 文件后，实际的开发流程是这样的：先在 TouchGFX Designer 里设计界面并生成代码，然后回到 STM32CubeMX 里重新生成一次工程，把两者合并，最后编译烧录。

这里我特别强调“先设计后合并”的顺序。如果你反着来，在 CubeMX 里改完配置去同步 TouchGFX 代码，可能会把 Designer 里最新的界面修改冲掉，导致你烧进去的还是旧界面。正确习惯是：Designer 永远是 UI 的源头，CubeMX 是底层配置的源头，改任何一侧之后都重新走一遍生成流程，然后编译。

烧录之后，联调顺序也很重要。我习惯先看三样东西：背光亮没亮、触摸事件有没有上报、文本渲染正不正常。前两样都能用串口打印日志来验证，文本渲染直接肉眼判断即可。不要一上来就去调动画流畅度，界面还没稳定就追求帧率，会浪费大量时间。

4. 初试中的性能优化：卡顿与内存的双重暴击

4.1 帧缓冲：一块、两块还是一个都不够

TouchGFX 的帧缓冲配置直接决定渲染上限。最简单的是单缓冲，渲染完一帧再整体搬到屏幕，缺点是会有撕裂感，动态效果越强越明显。双缓冲则是两块缓冲轮流使用，一块正在显示，一块正在渲染，配合帧同步可以让画面非常干净。

F429 这种芯片跑 TouchGFX，我强烈建议直接上双缓冲。单缓冲在 480x272 的屏幕上做按钮按下反馈还能忍，做页面切换动画就会看到明显的闪烁撕裂，体验差很多。双缓冲的内存开销，RGB565 格式 480x272 大约是 255KB 一块，两块 510KB，放在 8MB SDRAM 里毫无压力；即使 800x480 RGB565 双缓冲也就 1.5MB 左右。

帧缓冲位置也有讲究。TouchGFX 默认会放到 SDRAM，因为内部 RAM 不够用。但要注意，有些初始化代码如果买的是缺省配置，会把帧缓冲地址写到内部 RAM 或者一个无效地址，导致画面出不来。我建议在touchgfx_init()之前用调试器看一眼帧缓冲地址是否落在 0xC0000000 范围内，能省去很多玄学问题。

4.2 DMA2D参与渲染带来的直觉变化

DMA2D 可以说是 F429 在图形渲染上最值钱的外设。它能在不需要 CPU 干预的情况下完成图像拷贝、像素格式转换和 Alpha 混合。TouchGFX 对 DMA2D 的支持是自动的，前提是你必须正确启用了DMA2D时钟，并在 CubeMX 里勾选对应外设。

我第一次运行界面时，根本感觉不到 DMA2D 的加成，后来对照手册才发现，默认生成的代码里 DMA2D 的底层初始化看起来正常，但实际渲染路径没有完全跑起来。原因是我在 TouchGFX 的配置文件里把渲染模式设成了纯软件渲染。改回硬件加速模式之后，同样是页面滚动，明显能感觉到画面跟手了很多。

这里有一个细节值得注意：DMA2D 加速对图像格式和内存对齐是有要求的。比如源图片如果是 RGB565，目标也是 RGB565，加速效果最理想；如果要做 Alpha 混合，源图最好带 Alpha 通道，否则硬件混合的效率优势发挥不出来。我在初期做界面时习惯性的把背景图导出成 PNG 带透明通道，但其实背景图应该是不透明的 RGB565，透明通道只在真正需要叠加的小图标上才有必要。

4.3 图片格式和资源策略：改一个地方省一半内存

优化 GUI 性能，除了分辨率之外，最立竿见影的就是图片格式选择。TouchGFX 生成的图像资源有两类典型格式：RGB565 和 RGB888。RGB565 每个像素占 2 字节，RGB888 占 4 字节，相同尺寸的内存和 Flash 占用差了一倍。

刚开始我看到设计器默认支持 RGB888，就一股脑把所有素材都导成 RGB888，结果 800x480 的界面稍微放几张大图，Flash 直接告急。后来我把所有静态背景图都改成 RGB565，小图标、带透明度的按钮按下效果才保留 RGB888 或带 Alpha 的 ARGB8888。改完之后，同样的界面，Flash 占用从接近 900KB 降到了 500KB 以内，画面质量肉眼看不出明显差异。

另一个策略是避免大尺寸半透明图片。每次画面更新如果碰到大面积半透明区域，触屏渲染要逐个像素做混合计算，哪怕有 DMA2D 帮忙，内部总线的带宽消耗也非常大。我的经验是背景尽量不透明，半透明效果只给抠图小图标或者弹窗阴影用，渲染压力会小很多。

4.4 我的一组实测调优记录

拿我这块 480x272 的屏幕举例，初始状态是单缓冲、RGB888、软件渲染，页面切换动画肉眼可见卡顿，估摸着帧率在 15fps 上下。经过三步调整后，体验明显不是一个档次。

第一步，把整个工程的图像资源统一改成 RGB565；第二步，在 TouchGFX 配置里启用 DMA2D 硬件加速；第三步，把帧缓冲切到双缓冲。三步做完，同样的滑动切换动画，体感帧率到了 40fps 左右，界面非常跟手。这套调整没有引入任何复杂算法，纯粹是把每个环节的正确属性填上而已。

这套优化思路可以迁移到更大分辨率。换成 800x480 屏幕后，我先保持 RGB565，再开启局部刷新模式，只有触摸区域内的小范围变化才会触发重绘，平时背景静止时基本不消耗带宽，优化空间比 480x272 还大。

5. 一次白屏故障的完整排查链路

5.1 现场表现与第一步定位

调试完第一个界面后，我又加了一张 800x480 的副页面，烧录完成，点击按钮切换过去的一瞬间，屏幕直接白屏，而且触摸失灵。最诡异的是，回到主页面后画面正常。我当时第一反应是切换动画出了问题，因为白屏出现在动画开始的瞬间。

这种现场表现，我总结了一个定位原则：先看“静态能不能显示”，再看“切换后能不能显示”。如果是硬件链路彻底断了，那连主页面都应该白屏；现在主页面正常，说明 LTDC、SDRAM、帧缓冲这些基础配置没问题，问题大概率出在副页面加载那一刻的运行时资源上。

第一步，我用调试器在切换处打断点，观察到屏幕上确实出现了一段持续几毫秒的时间窗口，期间 DMA2D 没有新的渲染任务提交，之后 LTDC 就开始输出纯色。这意味着系统在切换动画阶段可能发生了硬件异常，进入了 HardFault 死循环。找到这个突破口后，排查范围缩小到了内存访问。

5.2 用调试器逐层回查：时钟、SDRAM、LTDC

我顺着 HardFault 的现场保留下钻，第一步看 Call Stack，发现挂掉的函数在图像解码相关的缓存拷贝里。这立刻让我联想到一个问题：副页面用了一张很大的全屏图片，在切换时会按需解码到 SDRAM 里，如果这一帧在 SDRAM 上的访问正好踩到了未经初始化的区域，就会触发总线错误。

于是回到 CubeMX 检查 FMC 配置。我意外地发现，副页面图片的解码临时缓存被分配到了 SDRAM 的一个高地址区域，而这个区域恰好超出了我那块 8MB SDRAM 的物理边界。TouchGFX 在设计资源时有一个默认的内存映射，我手动加了 800x480 的副页面素材后，没有同步调整这个映射，缓存地址自然就越界了。

再进一步验证，我用调试器直接读 0xC0000000 加偏移一个大地址，果然访问异常。接着我回查 LTDC 时钟和时序参数，一切正常，SDRAM 基础读写也正常，所以可以排除底层硬件问题。整个故障的根因就锁定为：资源映射配置错误导致 DMA2D 访问了不存在的物理内存。

5.3 验证修复：从白屏到画面正常

修复方法很简单，调整 TouchGFX 工程的存储映射配置，把副页面图片的解码缓存地址挪回 SDRAM 有效地址范围内，重新生成代码，重新编译烧录。再点击按钮切换，白屏消失，副页面正常显示，切换动画也恢复了流畅。

这次排查给我的启发很大。尽管大部分白屏问题都指向 LTDC 时序或 SDRAM 初始化，但“主页面正常、切换后白屏”这种特殊表现，往往意味着是运行时资源越界，而不是静态配置错误。以后遇到类似问题，我会先判断白屏是“通电即白”还是“运行中才白”，两者的排查路线完全不同。

5.4 初试阶段常见坑位清单

最后把初试阶段容易出现的坑列成一个表，方便你对照排查：

这套清单基本覆盖了我初试 TouchGFX 期间遇到的大部分问题。如果你也刚好卡在某一步，可以按这个表从根源上排查，而不是反复烧录碰运气。

最后说一点非常主观的体会：初试 TouchGFX，最容易让人上头的是界面设计与控件拖拽，它们带来的成就感比底层代码要强得多。但真正决定一个项目顺不顺的，反而是 SDRAM 初始化、时钟树、资源映射这些一点都不炫酷的底层细节。我在这些地方花掉的时间，远多于设计界面的时间，但正是它们把整套渲染链路撑了起来。如果你也准备在 STM32F429 上开始 TouchGFX，建议先把空跑的白屏阶段彻底打通，讲清楚每一条初始化路径，再去追求动画和炫酷效果。这条路径走通之后，你再回头看我上面的步骤，会发现每一步都有它的道理。