企业官网建设流程全解析

两年前我第一次把RGB接口的屏幕接到STM32上时，踩了一整晚的坑。那时候手头刚好有块7寸1024×600的RGB屏，板子是F429，万事俱备，代码写完，背光一开，屏幕全是雪花噪点，偶尔还闪。后来排查到凌晨两点，发现问题居然出在PCLK的极性上。自从那以后，凡是有人问我STM32怎么驱动RGB屏，我第一句话永远是：先别急着写代码，先把PCLK和DE同步信号搞明白，否则后面全是玄学。

这篇文章会把我在实际项目中配置PCLK、DE同步信号的过程完整拆开：从RGB屏的工作原理、LTDC时序参数怎么算、CubeMX里怎么填，到那些真正让人崩溃的怪毛病——闪屏、偏移、颜色错乱、帧率不够——我都会把原因和排查逻辑讲清楚。适合刚从SPI屏/8080并口屏转过来、第一次用RGB屏做项目的朋友，也适合已经点亮但画面不正常的兄弟对照排查。

1. RGB屏幕和你以前驱动的那些屏，根本不是一回事

1.1 不需要时钟线“逐字节搬运”，数据是一直流过去的

用惯0.96寸OLED和1.8寸TFT的人，驱动RGB屏的第一反应通常是找数据手册里的SPI接口或者8080并口时序，然后整个人就懵了。RGB屏没有地址，没有命令，也没有读忙标志。它就像一台永远在刷新的显示器，你要做的不是“把数据写进某个寄存器”，而是24小时不间断地把每一行的像素点按固定节奏喂给屏幕。

这个数据结构是连续的行像素流：每一行从左到右，每个像素由R、G、B三个分量组成，一个像素接一个像素，一行结束之后进入消隐区间（HBlank），然后开始下一行。所有行结束之后进入垂直消隐区间（VBlank），然后重新从屏幕左上角开始。整个过程中，PCLK（像素时钟）就是唯一节拍器，时钟每跳一次，屏幕就吃掉一个像素。数据不是“发送”过去的，而是被“持续冲刷”过去的。

这和SPI屏“发送命令-发送数据-等待响应”的交互模式是本质区别，所以代码思路得完全换过来。你不能靠CPU去循环刷像素，市面上常见的800×480分辨率RGB屏，60Hz刷新率，每秒要刷2300万个像素，主频168MHz的Cortex-M4即使把所有周期都花在刷屏上也跑不满，遑论还要跑业务逻辑。好在STM32有专门的LTDC（LCD-TFT Display Controller）外设，把这事从CPU手里接了过去。

1.2 LTDC外设接管了原本CPU要干的重体力活

LTDC这个外设的定位很明确：你提前告诉它屏幕的分辨率、时序参数、显存在哪、每个像素是什么格式，然后启动，它就用DMA的方式不断从显存读数据，按你给的PCLK频率把像素送出去。CPU此后可以完全不管屏幕，该跑算法跑算法，该跑协议跑协议。

这里必须理解一个概念：显存（Framebuffer）。RGB屏没有内部显存，它所有像素都是实时从外部接收的，所以你必须给LTDC一块内存区域作为“画布”，LTDC反复读取这块区域的内容输出给屏幕。你改这块内存里的值，屏幕上对应像素马上变化，LTDC负责把内存到屏幕的搬运工作自动完成。这块内存通常放在片外SDRAM，因为RGB屏一帧数据量很大——1024×600分辨率、RGB888格式，一帧就是1.84MB，F429的片内RAM根本装不下。即便是320×240的RGB屏，RGB888格式也要230KB，片内RAM依然尴尬，所以SDRAM几乎是标配。

理解了这个架构，接下来才能真正看懂时序参数。前面说的PCLK、HSYNC、VSYNC、DE，就是LTDC和屏幕之间约定的“如何配合工作”的协议，协议对不上，屏幕就会罢工。

2. 时序参数拆解：PCLK、HSYNC、VSYNC、DE各自的角色

2.1 PCLK：屏幕的节拍器，错了整体节奏就乱

PCLK是信号线名，代码里通常写作Pixel Clock或DOTCLK，就是像素时钟。LTDC在PCLK的每个有效沿发送一个像素数据，屏幕在同一个沿采样。这个频率决定了画面刷新率，所以它是整个时序的基石。

很多人在网上找例程，发现同型号屏幕有人用6MHz、9MHz、25MHz的PCLK，于是很迷惑，觉得“是不是随便选一个都行”。其实每种屏有个上限频率，比如常见的AT070TN92 V1型号，数据手册里写的是典型值33.3MHz（对应60Hz刷新率下的理论上限）。PCLK设得太低，刷新率掉下去，屏幕会明显闪烁；设得超过上限，屏幕可能会完全不显示，或者显示错乱。

实际的PCLK由LTDC的输入时钟源分频得到，F429上LTDC的时钟源来自PLLSAI，这个分频关系后面详细说。这里先记住一个结论：PCLK不是随便填的，它是根据屏幕分辨率、同步信号的消隐区长度和目标帧率倒推出来的，保证屏幕刚好以期望的帧率工作。

2.2 HSYNC/VSYNC/DE：在哪里画、从哪开始画，全靠它们

RGB屏的显示过程里，信号线上除了RGB数据，还走三根同步信号：HSYNC（行同步）、VSYNC（场同步）、DE（数据使能）。

先说DE。DE为高电平的每个PCLK周期，数据线上传输的是真实有效的像素数据；DE为低电平期间，数据线上的内容无效，屏幕忽略。所以DE本质上就是“有效数据的开关”。这也是RGB屏区别于VGA显示器的地方——现代数字RGB屏绝大多数只用DE，用DE+HSYNC+VSYNC混合模式也行，但DE模式最简单，也是LTDC最常用的模式。

然后是HSYNC和VSYNC。行同步HSYNC在每一行扫描开始前发一个负脉冲（或正脉冲，取决于极性配置），告诉屏幕“新的一行要开始了”；场同步VSYNC在每一帧开始前发一个脉冲，告诉屏幕“新的一帧要开始了”。

关键点来了：实际画面并不是从HSYNC脉冲结束那一刻立即开始的。每一行真正的像素数据开始之前，屏幕要留一段“准备时间”；每一行结束之后，还有一段“收尾时间”。这些时间在标准里叫HBP（水平后肩，后端消隐）和HFP（水平前肩，前端消隐），行同步脉冲本身的宽度叫HSPW。垂直方向同理，对应VBP、VFP、VSPW。

这些参数的意义在于：屏幕在收到HSYNC后并不能立刻稳定输出第一列像素，需要一点时间进入状态；行末也需要一点时间让电路完成水平回扫。如果你把所有消隐时间都填成0，理论上也可以显示，但容易在屏幕边缘出现条纹或花屏。所以数据手册给出的时序参数不能乱砍，每一步都有它的物理原因。

2.3 一个公式算出理论PCLK，以及为什么算完还要打折

当你看懂了时序，PCLK的计算就是个纯粹的算术问题。一帧完整的时间由以下部分组成：

单行总时间 = HSW + HBP + HO（有效宽度）+ HFP
单帧总行数 = VSW + VBP + VO（有效高度）+ VFP
PCLK = 单行总时间 × 单帧总行数 × 目标帧率

这里HO和VO就是分辨率里的列数和行数。拿一块典型的7寸1024×600 RGB屏举例，数据手册上常见参数是：

• 水平同步脉冲 HSW=1~40，假设取 HSW=10
• 水平后肩 HBP=160
• 水平前肩 HFP=160
• 垂直同步脉冲 VSW=1~20，假设取 VSW=4
• 垂直后肩 VBP=23
• 垂直前肩 VFP=12

那么单行总时间 = 10+160+1024+160 = 1354 个PCLK周期；单帧总行数 = 4+23+600+12 = 639 行。在60Hz刷新率下：

PCLK = 1354 × 639 × 60 ≈ 51.93 MHz

这个值超过了AT070TN92常见的上限33.3MHz，所以实际设计时要么降低刷新率到30Hz左右，要么调整消隐区把它压低。很多屏数据手册会直接给出推荐典型值，比如33.3MHz配60Hz，这就需要你反推合适的后肩和前肩值。简单做法是：先按公式算出总PCLK，再对比数据手册推荐的PCLK范围，如果超了，就先降帧率到能点亮为止，再慢慢提。

提示：PCLK算出来只是一个起点，真正点亮后你还要看屏幕有没有发暗、闪烁、抖动。我把PCLK调低到接近数据手册推荐值时，屏幕最稳定。盲目追求高帧率，屏幕不一定受得住，反而出现水波纹和噪声。

3. 从零配置LTDC：CubeMX里怎么设置，引脚和时钟怎么处理

3.1 时钟树和LTDC时钟源的配置顺序

CubeMX里配置LTDC有个坑人的顺序问题：很多人上来直接填LTDC的Timing参数，完全没管时钟树，结果生成的代码里PCLK输出频率和自己设想的天差地别。

在STM32F4系列上，LTDC的外设时钟来源是PLLSAI。PLLSAI的VCO输出经过分频得到48MHz左右的参考时钟（F429的LTDC典型输入时钟建议在48MHz上下），LTDC模块内部再通过Horizontal Total、Vertical Total自动生成PCLK。

具体在CubeMX里，配置顺序应该是：

1. 先打开RCC的HSE，配置系统主时钟到最高（F429是168MHz）。
2. 在Clock Configuration里找到PLLSAI相关的通道，把PLLSAI的N、P等参数配置为“使LTDC时钟源接近48MHz”。
3. 确认LTDC时钟源前有一个分频器（通常是/2、/4等选项），把最终进入LTDC的时钟切到目标PCLK的整数倍。
4. 然后回到LTDC的Timing配置页面填HSPW、HBP等参数。

这里有个关键认知：PCLK不是直接在CubeMX里填一个数字就算数的。LTDC内部会把它收到的时钟源（Pixel Clock输入）作为系统节拍，然后用“总行宽（Horizontal Total）”和“总帧高（Vertical Total）”去分频，实际PCLK = LTDC时钟源 / Horizontal Total。对，这个公式就是这么反直觉：你在LTDC配置界面里填的分辨率参数，本身也影响输出的像素时钟。

我举个实际例子：假设LTDC输入时钟是48MHz，水平总宽度（HSW+HBP+HO+HFP）算出来是1354个PCLK周期，那么实际像素时钟就是48MHz ÷ 1354 ≈ 35.45MHz？不对，这里又绕了一下——水平总宽度的“单位”本来就是PCLK周期数，所以这种除法不是这样用的。正确理解是：LTDC时钟源直接作为PCLK输出，而你配置的水平参数决定了每次DMA传输多少像素等。

要讲清楚得说细一点：在STM32的LTDC里，LCD_CLK引脚的输出频率实际上等于LTDC的输入时钟频率，也就是PLLSAI分频后的那个时钟。而你在LTDC配置界面里填的HSPW、HBP、HO、HFP这些数字，LTDC会用来生成DE、HSYNC、VSYNC信号的位置，不会反过来影响LCD_CLK的频率。所以最终屏幕能正常显示，靠的是你给LTDC的输入时钟直接就等于或接近数据手册要求的PCLK频率。

所以真正的做法是：在时钟树里先把LTDC输入时钟配到目标PCLK附近，然后在LTDC界面填对同步/消隐参数，两件事缺一不可。

3.2 以一块7寸1024×600屏为例，完整填写参数

我调试过程中用的屏幕是京东方的7寸1024×600，数据手册里给的典型参数如下（不同批次可能有差异，以自己的手册为准）：

把这组参数代入CubeMX的LTDC Timing配置，同时把Pixel Clock输入配置为约51.9MHz（PLLSAI分频出来尽量接近），然后设置：

• 信号极性：HSYNC和VSYNC都选Active Low（低电平有效）；DE选Active High；PCLK选Rising Edge采样（上升沿采样）。
• 背景色：随便填一个非零值，方便调试时看有没有数据输出。
• 格式：RGB888。

这些看起来琐碎，但任何一个极性选错，画面上就有体现：PCLK极性反了，一般能看到画面错位或异常闪烁；HSYNC/VSYNC极性反了，屏幕可能完全不同步，画面乱滚或者整屏错乱。后面第4部分细讲。

3.3 引脚复用、映射和原理图核对

RGB888全接口需要24根数据线（R0~R7、G0~G7、B0~B7），加上PCLK、HSYNC、VSYNC、DE，一共28根信号线，全部要接到STM32上。不同型号的引脚映射差异很大，F429的LTDC引脚和F767、H743都不完全一样，同一系列不同封装，引出的LTDC引脚数也可能不够。

这一环节最容易出的问题，是原理图设计者拿着别的板子的引脚定义照抄。我的建议是：拿到板子原理图后，逐个对照对应型号的Alternate Function Table，确认每个LTDC信号在哪个引脚上，然后在CubeMX里手动分配，不要依赖自动分配去猜。

还有一个高频问题：RGB屏的数据位序。有的屏幕是R0~R7接MCU的D0~D7，B0~B7接MCU的D16~D23，有的是反的——R常接低位、G居中、B高位是通用的，对照是没问题的，但偶尔有非标屏（多见于二手拆机屏或国产杂牌屏），你把R和B对调了之后颜色会整体偏红或偏蓝，排查时第一反应会以为是格式配错了，其实只是引脚接错。

4. 实测最容易踩的坑：PCLK算对了，屏幕还是各种怪象

4.1 屏幕闪、水波纹：多半是像素时钟实际频率和配置不一致

屏幕能点亮已经算成功了一大半，但很多人卡在下一步：画面能出来，但屏幕疯狂闪烁，或者横向上有滚动的“水波纹”。这种情况我见过太多了，而且十有八九是PCLK的实际频率和屏手册建议值差太多。

先说水波纹（也可以叫干扰纹、摩尔纹）：PCLK偏高时，屏幕驱动IC来不及稳定采样，就会在画面上形成明显的横向条纹滚动。这个现象在纯色背景下特别明显，尤其用低成本的24位色显示渐变内容时，一眼就能看出来。

解决办法不在LTDC配置界面，而在时钟树里。回到Clock Configuration，看看LTDC输入时钟到底是多少，然后微调分频系数。F429上通过修改PLLSAI的N值或P值来把LTDC时钟精确调到屏手册的目标PCLK附近。同一个屏幕，我将时钟从52MHz降到33.3MHz之后，水波纹立刻消失，刷得稳稳的。

如果你已经确信PCLK配置没超上限，但闪得厉害，第二步要怀疑SDRAM的刷新时序和总线带宽竞争。LTDC从SDRAM读数据的同时，如果CPU也在频繁访问SDRAM，DMA带宽被挤占，可能出现段错位，看起来像闪烁和撕裂。这种情况需要开启LTDC的DMA突发模式、合理设计SDRAM存储控制器，或者把显存放到更连续的地址段。

4.2 画面整体偏左/偏右，行错位：HSYNC和DE的微妙关系

画面能显示，但整体往左或往右偏，甚至上下错位——这是HSYNC、HBP、HFP三者之间的相位关系没调对。

这类问题典型出现在你把屏手册给的HBP、HFP值原样填进LTDC，但画面依然偏一点。原因在于不同屏幕厂商对“HBP”的定义有细微差别：有的把HSYNC脉冲结束到DE变高的这段全部叫HBP，有的把HSYNC脉冲本身也算进后肩。STM32的LTDC里，HBP是“HSYNC有效之后、DE变高之前”这段时间，如果屏幕手册把HSW和HBP合并写在一个数值里，你需要把多出来的部分从HBP里扣掉，换到HSW上。

我曾经调一块爱普生屏，手册上标HBP=88，HSW=1，但我填进去画面偏偏左了大约8个像素。后来用逻辑分析仪抓DE和HSYNC的关系，发现屏实际识别的是HSYNC结束后再等80个PCLK才接收第一列数据，而我配置里等了88个PCLK，所以多出的8个像素被挤出屏幕左边缘。把HBP从88改成80后，画面完美居中。

这个坑很难从屏正面观感直接判断，最好的做法是拿到屏手册里的详细时序图，一行一行对照信号边沿，把HSW、HBP、HFP的边界搞清楚。如果手头没有逻辑分析仪，就用一个白色背景的测试图，把屏的左边和右边各放一条彩色竖线，通过微调HBP判断偏了多少个像素，再倒推参数。

提示：在排查这类问题时，我强烈建议先画一个纯色测试画面，最好带几条竖线和横线。纯色下你很难看出偏移量，有参考线才知道偏差了几个像素、往哪边偏。

4.3 颜色不对：RGB888/RGB666/RGB565的位宽问题

颜色异常比画面偏移更难排查，因为你没法通过“偏了多少像素”来定问题，颜色牵涉到格式、引脚、背光三个方面。

首先是格式。你的屏幕如果是24位接口，最好用RGB888；如果是18位接口（RGB666），连线时通常把每色的低2位接地或悬空，数据格式在代码里也必须配置成RGB666。很多人在CubeMX里选了RGB888，实际屏只接了18根数据线，结果显示出来的颜色浓淡混乱，像是被打了一层奇怪的滤镜。

其次是LTDC和DMA2D之间的格式一致性。如果你用DMA2D往显存写图像数据，DMA2D的输出格式必须和LTDC的输入格式完全一致。我在一个项目里犯过这个错：LTDC配置成RGB888，但DMA2D用ARGB8888格式填充图像，结果整个画面颜色偏色，蓝色和红色通道像是被“挤压过”一样。原因是ARGB8888高8位是Alpha通道，LTDC按RGB888解读时，Alpha数据占据了颜色通道，自然错乱。

如果你的SDRAM是16位宽度，还需要考虑像素在内存里的排布：RGB565一个像素2字节，直接连续排列；RGB888一个像素3字节，但很多LCD控制器要求实现4字节对齐（存储时每像素后面补1字节填充），否则内存带宽利用率下降，屏幕上出现随机像素缺口。F429的LTDC支持紧凑的RGB888存储，但不支持1.5字节对齐的奇怪格式，需要你手动把显存设好。

4.4 背光亮了但是没有内容：使能顺序和内存地址的坑

屏幕背光亮了，但画面全黑（不是花屏，是全黑），这个现象很有迷惑性——因为背光和LTDC使能几乎是同时的动作，很多人会误以为屏幕供电异常，其实问题在两个地方。

第一个是显存地址没配对。LTDC配置里的Line Start Address指向的是显存起始地址，如果你把显存地址算错，比如SDRAM地址用了0xD0000000，但实际SDRAM挂在FMC Bank1的0x60000000地址段上，LTDC读出来全是对不上的数据，而数据又恰好不是乱码而是常数，画面看起来就是黑的。检查方法很简单：把显存地址改成你SDRAM实际所在的区域，再在代码里往那个地址写一个全红的填充值，如果屏幕变红，说明地址对了。

第二个是LTDC使能的先后顺序。F429的LTDC有个隐蔽要求：必须先把LTDC配置为Enabled并等待至少一个VSYNC周期，再开背光，或反之——取决于你的硬件设计。如果背光在一开始就亮了，但LTDC还没有准备好输出数据，屏幕会显示一帧黑画面并锁定（某些屏驱动IC会持续显示最后一帧内容）。很多例程里能看到代码里夹着一句HAL_Delay(5)，就是为了等LTDC稳定输出第一帧。

正确的初始化顺序建议：

1. 硬件复位屏幕（拉低RESET引脚再拉高，延时20ms以上）。
2. 初始化SDRAM，并用简单循环在显存里填充一个纯色（比如0x00FF0000表示红色）。
3. 初始化LTDC，使能LTDC。
4. 等一两帧时间（延时5~20ms），确认DE信号已经稳定输出。
5. 打开背光。

按这个顺序，几乎不会出现“背光亮屏全黑”的问题。

4.5 帧率不够、画面撕裂：DMA2D和显存对齐

最后说帧率和撕裂，这是RGB屏项目里最“高级”的坑，因为前面那些坑填完一般能显示，帧率和撕裂问题则直接影响用户体验。

帧率不够的直观现象是滑动动画卡顿、跑UI一卡一卡。局面是LTDC本身只是把显存数据搬到屏幕，它的输出PCLK是恒定的，刷新率已经固定，你感觉到的卡顿往往不是屏幕刷新率低，而是下一帧画面更新时间太长，导致视觉上帧率打折。解决办法是用双缓冲：准备两个显存区域，一个显示当前帧，另一个渲染下一帧，渲染完后通过寄存器切换显示地址。这样渲染和屏幕刷新并行，动画自然流畅。

撕裂（画面上下不同步，中间有断层）是因为你直接修改了正在被LTDC读取的显存数据——上一半还是旧画面，下一半已经被改成新画面。解决撕裂的方法有几种：最简单的是在VSYNC中断里再切换显存地址，保证屏幕扫描到顶部时再换页；更好的是使用LTDC的Line Interrupt或VSYNC中断机制来同步。

这里必须提一个容易被忽视的点：SDRAM的DMA访问冲突。LTDC在每个PCLK周期都要读显存，如果你的SDRAM控制器工作不稳定，会出现偶发性数据错误，画面随机闪烁或出现横线。在F429上，建议把SDRAM的时序参数稍微放宽，时钟频率适当降低，并启用LTDC的FIFO，实测能明显减少偶发花屏。

DMA2D的使用也有一个对齐讲究：目标内存地址必须4字节对齐，否则DMA2D无法正常工作，会出现写入错乱或死机。很多国产开发板的SDRAM预留地址是0xD0000000，但如果你在基地址上做偏移（比如+3），就破坏了4字节对齐，DMA2D直接罢工。

5. 一些调试工具和验证方法（从实践中总结的经验）

5.1 怎么验证PCLK实际是多少

如果你没有示波器，想确认LTDC实际输出的PCLK，最直接的方式是在初始化后测量PB0（LCD_CLK）引脚波形，或者用定时器的输入捕获模式去测这个引脚的频率。不过更省事的办法是先在CubeMX的Clock Configuration界面里看准LTDC的时钟源频率，把它作为理论值。

但理论值不等于实测值。有的开发板晶振精度不好，50ppm偏差在感官上体现不出来，却在高速PCLK下累积出错。我建议有条件就上示波器，没有示波器就用逻辑分析仪，抓一个完整的HSYNC周期，数一下里面包含了多少个PCLK周期，再验证和屏手要求的单行总时间是否一致。这个做法不复杂但极其有效。

5.2 用逻辑分析仪抓DE、HSYNC和VSYNC的关系

逻辑分析仪是我调试RGB屏时序时最依赖的工具。抓DE和HSYNC的波形，可以看到DE在HSYNC之后的延迟——这个延迟就是HBP的实际值。如果你的波形和代码参数对不上，或者屏幕画面偏移，几乎都能从这个波形里找到原因。

具体操作：把逻辑分析仪的几个通道分别接到LCD_DE、LCD_HSYNC、LCD_VSYNC，抓一帧的数据。你会看到VSYNC低电平脉冲，然后是高密度的HSYNC脉冲，DE在每一行中间拉高一长段。用逻辑分析仪自带的测量功能算一下DE拉高的时间占总行时间的比例，正常情况下应该是HO/(HSW+HBP+HO+HFP)的比例。如果比例差很多，说明配置和你以为的不一样，回CubeMX里重新确认。

5.3 一个万能调参思路：从慢到快，从低分辨率到全分辨率

如果你用的是大分辨率屏，一次点亮难度较高，可以先用低刷新率、低PCLK验证通路。具体操作是把PCLK从公式算出的一半开始，比如目标33MHz就先配25MHz，压低刷新率到30~40Hz，只要能显示内容，后续再慢慢往上加频率，直到满速刷新。每次只改一个参数，改完观察画面变化，记录现象。这个方法虽然慢，但能让你把每个参数的作用都摸清楚。

这和超频CPU的思路其实很像：先求稳，再求快，参数一个一个动。我见过不少人一次性把所有参数调到顶，然后屏幕不亮，就怀疑屏幕坏了或者焊接有问题，最后查了一天，其实只是某个消隐区参数超了上限。

6. 写在最后的一些个人体会

RGB屏和STM32的组合，本质上就是“用一个外设去模拟一个信号源”的过程，难点不在代码量，而在对时序的理解。你不再像写SPI驱动那样关心每一条指令，而要关心时钟频率、脉冲宽度、消隐区间这些物理层面的参数。这些参数一旦理顺，后续不管换屏还是换MCU型号，迁移成本都很低，因为所有RGB屏的底层逻辑是一致的。

如果你正在调这块屏，我的建议是：准备一张纸，把屏手册里的所有时序参数抄下来，逐个核对CubeMX里的配置，跟着第2部分的公式算一遍PCLK，然后严格按照第4部分的流程排查异常。调通了之后，再回去体会DE和HSYNC的波形关系，你会发现整块屏的工作方式彻底清晰了。

最后再分享一个小技巧：调完参数后，把屏手册的关键页拍照存在手机里，方便随时翻看。很多LED屏幕厂商的手册写得不严谨，不同批次甚至同一批次不同型号之间的参数都有差别，这种资料是硬通货，存下来总有一天用得上。