1. 项目概述：为什么需要读写内部Flash？

在STM32项目开发中，我们常常会遇到一个看似简单却至关重要的需求：如何让单片机记住一些数据，哪怕是在断电之后。比如，一个温控设备需要记住用户设定的温度阈值；一个计数器需要保存累计的运行次数；或者一个简单的设备需要记录其唯一的校准参数。你可能会想到用外部的EEPROM芯片，但这会增加成本、占用宝贵的PCB空间和I/O引脚。实际上，STM32内部就自带了一块“非易失性存储区”——内部Flash，它不仅能存放程序代码，还能在特定区域用来存储用户数据。

这个操作，业内通常称为“Data EEPROM Emulation”（数据EEPROM模拟）。它不是简单地像操作内存数组一样去写，而是有一套严格的规则。直接蛮干，轻则数据写入失败，重则可能“锁死”芯片甚至擦除程序本身。我见过不少新手工程师，在项目后期为了加一个参数保存功能，因为对内部Flash操作理解不透彻，导致整批产品需要返工升级，教训深刻。

因此，掌握STM32内部Flash的读写，是嵌入式开发中一项非常核心的“生存技能”。它关乎产品的可靠性、稳定性和可维护性。本文将从原理到实践，手把手带你搞懂STM32内部Flash的“脾气”，并提供经过大量项目验证的、可直接复用的HAL库与标准库代码，让你避开我踩过的那些坑。

2. 核心原理与风险预警

在动手写代码之前，我们必须先理解内部Flash的物理特性和操作逻辑，这是安全操作的前提。

2.1 Flash存储结构与操作单元

STM32的内部Flash和我们电脑上的U盘、SSD类似，都属于Flash存储器。它的基本操作单元有三个层次，理解错了就会出问题：

1. 位（Bit）：Flash存储数据的最小单位，但不能单独编程（写）。你无法只改变一个位从1变成0。
2. 字节（Byte）：我们读写数据时常用的单位。但Flash的写入有严格限制。
3. 页（Page）/扇区（Sector）：这是擦除（Erase）操作的最小单位。STM32不同系列，这个大小不同，比如F1系列常是1KB或2KB一页，F4/F7系列则是按扇区划分，有16KB、64KB、128KB等不同大小。

这里就引出了Flash操作最核心的规则：Flash的位只能从1变成0（通过“编程”操作），而要从0变回1，必须对整个页/扇区进行“擦除”操作。

举个例子，假设一个Flash地址初始状态是全1（0xFFFFFFFF）。你可以写入0x00000000，这相当于把所有位从1变成0。但之后你想再改成0xAAAAAAAA就不行了，因为有些位需要从0变回1（A的二进制是1010）。此时你必须先擦除整个扇区（恢复为全1），然后再重新写入。

2.2 读写操作的本质区别

• 读操作：和读内存（RAM）几乎一样简单、快速，可以按字节、半字（16位）、字（32位）读取，没有特殊限制。
• 写（编程）操作：
  • 必须以“字”（32位，对于Cortex-M3/M4内核）或“半字”（16位，对于某些系列）为单位进行。你不能只写一个字节。如果你要写一个字节，也需要以字或半字的形式写入，未使用的部分通常需要保持为0xFF或与原有数据做“与”操作（这涉及到更复杂的磨损均衡算法，后文会讲）。
  • 每个存储单元（位）只能从1编程为0，不能反着来。
  • 在写入前，目标地址所在的区域必须是已擦除状态（全为0xFF），或者新数据相对于旧数据是“按位与”的关系（即新数据的1位对应旧数据可以是0或1，但新数据的0位对应旧数据必须是1）。最安全、最通用的做法就是：先擦除，再写入。

2.3 关键风险与操作禁区

警告：以下操作如果失误，可能导致芯片无法启动或程序被破坏，请务必谨慎。

1. 程序自毁：最严重的错误就是在程序运行时，错误地擦除或写入了当前程序代码所在的Flash扇区。这会导致单片机立即跑飞或下次无法启动。绝对不能在存放正在运行代码的扇区进行写操作。
2. 中断打断：Flash的擦写操作耗时较长（毫秒级）。如果在擦写过程中被中断打断，可能导致操作失败或数据错误。因此，在关键的擦写序列期间，必须禁止全局中断。
3. 超时与硬件错误：Flash控制器有操作超时机制。如果操作不符合规范（如地址不对齐、在写保护区域操作），会触发硬件错误（HardFault）。代码中必须有相应的判断和容错处理。
4. 选项字节（Option Bytes）：这是一块特殊的Flash区域，用于配置读写保护、看门狗、复位模式等。误操作选项字节可能锁死芯片（如开启读保护），导致无法再次下载程序，必须通过芯片复位或特定的解锁序列才能恢复。新手切勿轻易尝试修改选项字节。

理解了这些“雷区”，我们才能安全地规划我们的操作区域和流程。

3. 实战准备：规划与底层驱动解析

3.1 如何选择安全的操作地址

这是第一步，也是决定项目成败的一步。你需要查阅你所使用的具体STM32型号的参考手册（Reference Manual）和数据手册（Datasheet）。

1. 查找Flash内存映射图：在参考手册的“Memory and bus architecture”章节，找到Flash的地址范围。例如，STM32F103C8T6有64KB Flash，地址从0x0800 0000 到 0x0800 FFFF。
2. 确定程序占用大小：在IDE（如Keil， IAR）中编译工程后，查看生成的.map文件或编译输出信息，找到程序代码和常量数据所占用的总大小。例如，你的程序编译后大小为20KB。
3. 预留安全空间并确定用户Flash起始地址：
   • 为程序后续升级留出余量，比如预留50%的空间。那么20KB的程序，可以按30KB估算占用。
   • 从Flash末尾开始向前划分用户区。例如，64KB Flash，末尾地址是0x0800 FFFF。我们可以选择最后一个或几个完整的扇区作为数据存储区。
   • 必须对齐到扇区起始地址。假设F103最后一个扇区是2KB（0x800），起始地址为 0x0800 F800。那么我们就可以将 0x0800 F800 到 0x0800 FFFF 这块区域用作参数存储。
   • 强烈建议：在工程中，将这个起始地址定义成一个宏，方便管理和修改。

   /* 根据STM32F103C8T6定义， 最后一个2KB扇区 */ #define USER_FLASH_START_ADDR ((uint32_t)0x0800F800) #define USER_FLASH_SECTOR FLASH_SECTOR_7 // 扇区编号，HAL库使用 #define USER_FLASH_SIZE (2 * 1024) // 2KB

3.2 HAL库与标准库的底层操作解析

无论用哪种库，最终都要调用芯片的Flash控制寄存器。库函数帮我们封装了复杂的底层操作。

HAL库流程解析（以STM32F4系列为例）： HAL库的流程相对统一但稍显冗长，其擦写一个扇区的核心步骤封装在HAL_FLASHEx_Erase()和HAL_FLASH_Program()函数中，但调用它们前后需要严格的“解锁-擦除/编程-上锁”和“等待操作完成”逻辑。

1. 解锁Flash：Flash默认是上锁的，防止误写。需要向特定的密钥寄存器（FLASH_KEYR）依次写入两个密钥（KEY1和KEY2）。

   HAL_FLASH_Unlock(); // 这个函数内部完成了密钥写入和标志位检查

2. 清除错误标志：在操作前清除之前的错误状态是个好习惯。

   __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_ALL_ERRORS);

3. 擦除扇区：填充一个FLASH_EraseInitTypeDef结构体，指定擦除类型（扇区擦除）、扇区编号、擦除数量等，然后调用擦除函数。这是一个阻塞操作，耗时很长。

   FLASH_EraseInitTypeDef EraseInitStruct; uint32_t SectorError = 0; EraseInitStruct.TypeErase = FLASH_TYPEERASE_SECTORS; EraseInitStruct.Banks = FLASH_BANK_1; // 对于单Bank芯片 EraseInitStruct.Sector = USER_FLASH_SECTOR; EraseInitStruct.NbSectors = 1; EraseInitStruct.VoltageRange = FLASH_VOLTAGE_RANGE_3; // 根据芯片电压设定 if (HAL_FLASHEx_Erase(&EraseInitStruct， &SectorError) != HAL_OK) { // 擦除失败处理， SectorError会指示是哪个扇区出错 HAL_FLASH_Lock(); return ERROR; }

4. 编程（写入）数据：擦除成功后，扇区变为全0xFF。此时可以按字（32位）写入数据。

   uint32_t Address = USER_FLASH_START_ADDR; uint32_t Data = 0x12345678; if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD， Address， Data) != HAL_OK) { // 写入失败处理 } Address += 4; // 地址增加4字节，准备写下一个字

   注意：HAL_FLASH_Program函数内部会等待编程完成，但连续编程多个字时，最好在循环中检查__HAL_FLASH_GET_FLAG(FLASH_FLAG_BSY)标志位是否清除，确保上一次编程已完成。

5. 上锁Flash：操作完成后，重新上锁，保护Flash。

   HAL_FLASH_Lock();

标准库（StdPeriph）流程对比： 标准库的API更直接，但错误处理需要开发者自己多做一点。核心函数是FLASH_ErasePage()和FLASH_ProgramWord()。流程同样是解锁->清除标志->擦除->编程->上锁。代码更紧凑，但可移植性不如HAL库。

我的经验选择：对于新项目，我强烈推荐使用HAL库。虽然代码量稍大，但其错误处理机制更完善，跨STM32系列移植更方便。标准库已停止更新，且在不同系列间差异较大。

4. 代码实现：封装健壮的读写驱动

理解了底层原理和流程后，我们将这些步骤封装成安全、易用的函数。这里以HAL库为例，提供两个核心函数：Flash_Write和Flash_Read。

4.1 Flash写入函数的深度封装

一个健壮的写入函数不能只做“写入”动作，它必须管理好整个生命周期：检查地址、执行擦除、按规则编程、处理错误。

/** * @brief 向指定Flash地址写入一段数据（自动处理擦除） * @param pData: 指向源数据缓冲区的指针 * @param WriteAddr: 写入的起始地址（必须字对齐） * @param Size: 要写入的字节数（必须是4的倍数） * @retval HAL_OK: 成功 * 其他: 失败 (HAL_ERROR， HAL_BUSY， etc.) */ HAL_StatusTypeDef Flash_Write(uint32_t *pData， uint32_t WriteAddr， uint32_t Size) { HAL_StatusTypeDef status = HAL_OK; uint32_t i = 0; uint32_t *pSrc = pData; uint32_t *pDst = (uint32_t*)WriteAddr; /* 1. 基础检查 */ if (WriteAddr < USER_FLASH_START_ADDR || WriteAddr + Size > USER_FLASH_START_ADDR + USER_FLASH_SIZE) { return HAL_ERROR; // 地址越界 } if (Size == 0 || (Size % 4 != 0)) { return HAL_ERROR; // 大小无效或未字对齐 } if ((WriteAddr & 0x3) != 0) { return HAL_ERROR; // 地址未字对齐 } /* 2. 解锁Flash并清除旧错误标志 */ HAL_FLASH_Unlock(); __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR | FLASH_FLAG_PGPERR | FLASH_FLAG_PGSERR); /* 3. 计算并执行扇区擦除 (简化版：假设数据量不超过一个扇区) */ // 在实际项目中，这里需要计算WriteAddr和Size跨越了哪些扇区，然后循环擦除。 // 本例假设我们只操作预先定义好的一个完整扇区。 FLASH_EraseInitTypeDef EraseInitStruct; uint32_t SectorError = 0; EraseInitStruct.TypeErase = FLASH_TYPEERASE_SECTORS; EraseInitStruct.Banks = FLASH_BANK_1; EraseInitStruct.Sector = USER_FLASH_SECTOR; // 使用我们定义的扇区 EraseInitStruct.NbSectors = 1; EraseInitStruct.VoltageRange = FLASH_VOLTAGE_RANGE_3; status = HAL_FLASHEx_Erase(&EraseInitStruct， &SectorError); if (status != HAL_OK) { HAL_FLASH_Lock(); return status; // 擦除失败 } /* 4. 循环编程（写入）数据 */ uint32_t num_words = Size / 4; for (i = 0; i < num_words; i++) { status = HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD， WriteAddr， *pSrc); if (status != HAL_OK) { break; // 写入失败，跳出循环 } // 验证写入（可选但推荐） if (*(__IO uint32_t*)WriteAddr != *pSrc) { status = HAL_ERROR; break; } WriteAddr += 4; // 地址递增 pSrc++; // 数据指针递增 } /* 5. 无论成功与否，最后都上锁Flash */ HAL_FLASH_Lock(); return status; }

关键点解析与心得：

• 地址对齐检查：这是很多错误的根源。Cortex-M内核访问非对齐地址会触发硬件错误。务必在函数开头进行严格检查。
• 擦除策略：上面的代码是简化版，一次性擦除整个扇区。在实际应用中，如果你的数据很小（比如几个结构体），而扇区很大（如128KB），频繁擦除整个扇区会严重缩短Flash寿命。此时需要实现更复杂的“磨损均衡”和“扇区管理”算法，例如将扇区虚拟化成多个可循环写的“页”，只有页写满后才擦除整个扇区。这是EEPROM模拟库（如STM32CubeMX自带的EEPROM Emulation中间件）所做的事情。
• 写入验证：在写入后立刻读回比较，是保证数据可靠性的有效手段。虽然增加了时间开销，但对于关键参数存储是值得的。
• 中断处理：HAL_FLASH_Program函数内部有等待，但为了极致的安全，可以在整个擦写期间（解锁到上锁）关闭全局中断：__disable_irq()和__enable_irq()。但要注意，这会影响到系统的实时性，请根据实际需求权衡。

4.2 Flash读取函数

读操作就简单安全多了，几乎就是内存访问。

/** * @brief 从指定Flash地址读取一段数据 * @param pData: 指向目标数据缓冲区的指针 * @param ReadAddr: 读取的起始地址 * @param Size: 要读取的字节数 * @retval None */ void Flash_Read(uint32_t *pData， uint32_t ReadAddr， uint32_t Size) { uint32_t i = 0; uint32_t *pSrc = (uint32_t*)ReadAddr; uint32_t *pDst = pData; uint32_t num_words = Size / 4; /* 简单的地址边界检查（可选，但建议有） */ if (ReadAddr < USER_FLASH_START_ADDR || ReadAddr + Size > USER_FLASH_START_ADDR + USER_FLASH_SIZE) { // 可以在这里返回错误码，或者直接assert return; } for (i = 0; i < num_words; i++) { *pDst = *pSrc; pDst++; pSrc++; } // 如果Size不是4的倍数，还需要处理剩余的1-3个字节（按字节读取），这里省略。 }

4.3 应用示例：存储与读取一个系统参数结构体

让我们看一个完整的例子，如何保存一个设备参数。

#include <stdint.h> #include <string.h> // 用于memcpy /* 定义参数结构体（注意4字节对齐） */ typedef struct { uint32_t magic_number; // 魔数，用于识别数据是否有效，例如 0xAA55CC33 uint32_t system_version; uint32_t temperature_threshold; uint32_t operation_count; uint8_t device_name[16]; uint32_t crc32; // 校验和，确保数据完整 } SystemParams_t; SystemParams_t g_system_params; /* 参数在Flash中的存储地址 */ #define PARAMS_FLASH_ADDR USER_FLASH_START_ADDR /** * @brief 保存参数到Flash */ HAL_StatusTypeDef Save_Params_To_Flash(void) { HAL_StatusTypeDef status; /* 1. 在写入前，更新校验和 */ g_system_params.magic_number = 0xAA55CC33; g_system_params.crc32 = Calculate_CRC32((uint8_t*)&g_system_params， sizeof(SystemParams_t) - 4); // 计算除CRC本身外所有数据的CRC /* 2. 调用封装的Flash写入函数 */ status = Flash_Write((uint32_t*)&g_system_params， PARAMS_FLASH_ADDR， sizeof(SystemParams_t)); return status; } /** * @brief 从Flash加载参数 * @retval 0: 成功且数据有效， -1: 读取失败或数据无效 */ int32_t Load_Params_From_Flash(void) { SystemParams_t params_in_flash; uint32_t calculated_crc; /* 1. 从Flash读取整个结构体 */ Flash_Read((uint32_t*)&params_in_flash， PARAMS_FLASH_ADDR， sizeof(SystemParams_t)); /* 2. 检查魔数 */ if (params_in_flash.magic_number != 0xAA55CC33) { return -1; // 数据无效（可能是第一次使用或Flash被擦除） } /* 3. 检查CRC校验和 */ calculated_crc = Calculate_CRC32((uint8_t*)&params_in_flash， sizeof(SystemParams_t) - 4); if (calculated_crc != params_in_flash.crc32) { return -1; // 数据损坏 } /* 4. 数据有效，复制到全局变量 */ memcpy(&g_system_params， &params_in_flash， sizeof(SystemParams_t)); return 0; } /** * @brief 初始化参数系统：尝试加载，失败则使用默认值并保存 */ void Params_System_Init(void) { if (Load_Params_From_Flash() != 0) { // 加载失败，使用默认值 g_system_params.magic_number = 0xAA55CC33; g_system_params.system_version = 0x00010000; g_system_params.temperature_threshold = 50; g_system_params.operation_count = 0; strncpy((char*)g_system_params.device_name， "MySTM32Device"， sizeof(g_system_params.device_name)-1); g_system_params.device_name[sizeof(g_system_params.device_name)-1] = '\0'; // 保存默认值到Flash Save_Params_To_Flash(); } // 加载成功，g_system_params已包含最新参数 }

这个示例展示了工程中常用的模式：魔数验证 + CRC校验。魔数用于快速判断Flash区域是否有过有效数据；CRC校验则用于确保数据在存储过程中没有因意外断电或其他干扰而损坏。Calculate_CRC32函数可以利用STM32自带的CRC硬件单元实现，效率极高。

5. 高级话题与避坑指南

5.1 Flash寿命与磨损均衡

Flash的擦写次数是有限的，通常标称是1万到10万次。如果频繁地在同一个扇区擦写，该扇区会率先损坏。为了解决这个问题，需要实现“磨损均衡”算法。

简单双扇区交替存储法： 这是最基础的策略。分配两个扇区（Sector A和B）。第一次写数据到A，写满或需要更新时，不是擦除A，而是把有效数据复制到B，然后擦除A。下次再写时，又从B复制到A，擦除B。如此循环，将擦除次数分摊到两个扇区上，寿命理论上翻倍。

更复杂的EEPROM模拟： STM32CubeMX软件包中提供了EEPROM Emulation中间件（例如EEPROM_Emulation驱动），它实现了更复杂的虚拟EEPROM管理，包括：

• 将多个物理扇区虚拟成连续的EEPROM地址空间。
• 自动管理数据的写入、更新和垃圾回收。
• 内置磨损均衡算法。 对于需要频繁保存小数据量的应用（如记录运行时间、事件次数等），直接使用这个中间件是更可靠、更省心的选择，尽管它会占用更多的Flash空间和RAM作为缓存。

5.2 电源稳定性与操作完整性

Flash擦写操作对电源电压非常敏感。在电压不稳或突然掉电的情况下进行擦写，极易导致数据错误甚至扇区损坏。

防护措施：

1. 硬件上：确保电源电路有足够大的滤波电容，能在掉电后维持核心电压（VDD）一段时间（通常需要几毫秒以上），让Flash操作完成。可以使用大电容或超级电容。
2. 软件上：
   • 操作前检查电压：有些STM32系列有内部电压监测器（PVD），可以在电压低于阈值时产生中断，在中断中紧急停止Flash操作。
   • 实现原子操作：对于关键数据，采用“准备新区-写入-验证-提交”的多步操作。例如，使用两个固定的标志位（如0x55AA和0xAA55）来标识数据的“准备中”和“有效”状态。只有验证新数据完全写入且正确后，才将状态改为“有效”。这样即使掉电发生在中间，系统重启后也能通过状态标志识别出损坏的未完成数据，并回退到旧版本。
   • 减少单次写入量：将大数据分拆成多个小块，每次写入一个块并验证，降低单次操作的风险。

5.3 调试与下载冲突（Flash Download Failed）

这是新手最常遇到的令人抓狂的问题之一。当你尝试通过ST-LINK、J-Link等调试器下载程序时，IDE（如Keil）报错“Flash Download Failed - Cortex-M3”或类似错误。

常见原因及排查步骤：

1. 目标芯片未正确复位或连接：

   • 检查调试器连接线是否松动。
   • 尝试给目标板完全断电再上电，然后立即点击下载。
   • 在IDE的下载配置中，勾选“Reset and Run”选项。

2. Flash编程算法选择错误：

   • 在Keil的Options for Target -> Debug -> Settings -> Flash Download中，确保添加了与你芯片型号完全匹配的Flash编程算法（.FLM文件）。STM32F1、F4、H7等的算法不同，甚至同系列不同容量也不同。

3. 芯片处于低功耗模式或某种保护状态：

   • 确保程序没有将芯片置于深度睡眠（Stop， Standby）模式且无法被调试器唤醒。
   • 检查是否误开启了读保护（RDP）。这是最隐蔽的原因之一。如果代码中或通过工具（如STM32CubeProgrammer）不小心将RDP级别设为1，芯片会禁止调试器访问Flash。解决方法通常是进行全片擦除（Mass Erase），这会同时清除读保护。注意：全片擦除也会清除你的程序。

4. 用户代码正在读写Flash，干扰了调试器的编程操作：

   • 这是本文主题相关的关键原因！如果你的程序中有Flash_Write这样的函数，并且它可能在main函数初始化或某个中断中被调用，那么当调试器试图连接并擦写Flash时，你的代码也在操作Flash控制器，必然导致冲突。
   • 解决方案：
     • 最根本的：确保你的Flash操作函数不会在调试器连接期间自动执行。例如，不要在上电初始化时就调用Load_Params_From_Flash（除非必要），可以将其放在一个由特定按键或命令触发的函数中。
     • 在调试阶段，可以暂时注释掉所有Flash操作代码。
     • 使用条件编译：#ifndef DEBUG_MODE ... #endif来包裹Flash操作代码，在调试时将其禁用。
     • 检查是否有中断服务程序（如定时器中断）在后台进行Flash操作。

5. 硬件问题：

   • BOOT引脚配置错误。确保BOOT0和BOOT1引脚（根据芯片型号）被正确拉低（通常是从用户Flash启动）。
   • 芯片电源不稳定。用示波器检查VDD电压在下载期间是否平稳。
   • 晶振不起振。虽然不影响下载，但某些芯片的下载过程与时钟有关。

我的排查口诀：“一查连接二查电，三看算法四看护，代码冲突最头疼，条件编译来开路。” 遇到“Flash Download Failed”，按这个顺序排查，能解决90%的问题。

6. 项目集成与优化建议

将Flash读写功能集成到实际项目中时，还有一些细节需要考虑。

优化建议：

1. 缓存机制：对于需要频繁读取的参数（如系统配置），不要在每次使用时都从Flash读取。可以在系统启动时一次性从Flash加载到RAM中的一个全局结构体变量中。修改参数时，先改RAM中的变量，然后在合适的时机（如定时保存、关机前）再统一写回Flash。这极大地提高了访问速度并减少了Flash擦写次数。
2. 异步操作：Flash擦写耗时很长（毫秒到几十毫秒），如果在主循环或高优先级任务中同步执行，会阻塞系统。可以考虑将Flash操作放入一个低优先级的后台任务（如果使用RTOS），或者使用状态机在非实时性的空闲循环中分步执行。
3. 错误重试与降级：Flash操作不是100%可靠。你的驱动函数应该具备错误重试机制（例如，失败后延迟几毫秒再试一次）。如果多次重试失败，系统应能降级运行，使用默认参数或上一次的有效参数，并记录错误日志。
4. 版本兼容：当你的产品固件升级，参数结构体SystemParams_t可能会增加新字段。为了兼容旧版本存储的数据，可以在结构体开头保留一个version字段。加载数据时，根据version的值来决定如何解析后面的数据，必要时进行数据迁移或初始化默认值。

最后，再分享一个我调试时的小技巧：在开发初期，可以先用STM32CubeProgrammer或ST-LINK Utility这类工具，手动读取、修改、擦除你规划的用户Flash区域，直观地验证你的地址规划是否正确，数据是否按预期写入。这比单纯看代码和日志要直观得多。

STM32的内部Flash操作就像一把锋利的刀，用好了能极大增强产品功能，用不好则会伤及自身。希望这篇结合了原理、代码和大量实战经验的长文，能帮你安全、高效地驾驭它。记住，理解规则、规划好地址、处理好异常，是成功的关键。