1. 项目概述为什么要在Windows驱动里用C异常如果你写过Windows内核驱动尤其是用C写过那你肯定对KeBugCheckEx这个蓝屏函数又爱又恨。爱的是它能帮你快速定位到致命错误恨的是整个驱动开发过程就像在走钢丝一个空指针解引用、一个数组越界系统就直接给你一个蓝屏“大礼包”。传统的驱动开发错误处理基本靠返回值层层向上传递代码里充满了if (NT_SUCCESS(status))的判断逻辑分支复杂可读性差。这时候你可能会想我在用户态用C写程序try/catch用得多顺手为什么内核里就不能用原因很简单Windows内核ntoskrnl.exe本身并不提供对C异常处理EH运行时的完整支持。Visual Studio编译器生成的、用于处理throw和catch的底层代码比如_CxxThrowException和__CxxFrameHandler3其默认实现依赖于用户态的运行时库如vcruntime140.dll这些库在内核环境下无法运行或者其行为是未定义的。所以“C Exceptions in Windows Drivers”这个项目直白点说就是给Windows内核驱动“打补丁”让它能支持原生的Ctry/catch/throw机制。这可不是简单的功能移植它涉及到对x86/x64平台下异常展开Unwinding、栈帧管理、安全cookie/GS校验等一系列底层机制的重新实现而且必须保证在中断请求级别IRQL为DISPATCH_LEVEL或更低时能安全运行。这个项目的价值在于它允许驱动开发者用一种更现代、更清晰的方式来处理错误将业务逻辑与错误处理分离大幅提升代码的可维护性和健壮性。注意在驱动中使用异常并不意味着你可以像在用户态那样随意throw。内核环境资源紧张、稳定性要求极高异常应仅用于处理真正的、罕见的错误情况如内存分配失败、硬件访问超时绝不能用于控制常规程序流。2. 核心原理内核态C异常处理的“黑魔法”要让C异常在内核里跑起来我们需要先理解在用户态它是怎么工作的。当你写下一句throw std::runtime_error(error)时编译器在背后干了三件大事构造异常对象在堆上或特定的异常存储区域分配并初始化一个异常对象这个对象包含了类型信息和可能的字符串信息。调用运行时库调用_CxxThrowException函数这个函数会准备一个EXCEPTION_RECORD结构体这是Windows结构化异常处理SEH的核心里面包含了异常代码、标志位以及一个指向异常对象和其类型信息的指针。发起SEH异常通过RaiseException这个Win32 API或者更底层的RtlRaiseException发起一个软件异常。操作系统内核的异常分发机制会捕获这个异常并开始沿着调用栈向上寻找能处理它的SEH处理器。在内核态问题就出在第二步和第三步的衔接上。内核有自己的异常分发路径KiDispatchException但标准的C异常运行时库vcruntime是为用户态设计的它假设的内存操作、堆分配等行为在内核中要么不存在要么语义完全不同。vcrtl项目的核心破解思路是“偷梁换柱”它自己实现了一套精简版的_CxxThrowException和__CxxFrameHandler这是编译器在每个包含try块或具有可析构对象的函数中插入的帧处理器。这套实现不依赖用户态运行时而是直接与内核的SEH机制对话。具体来说它的工作流程如下编译时链接你的驱动项目通过属性表.props文件链接到vcrtl提供的静态库.lib。这个库提供了上述函数的替代实现。抛出异常时你的代码执行throw编译器生成的代码会调用vcrtl实现的_CxxThrowException。这个函数会在内核栈上而不是堆上构造异常信息结构。这是关键避免了内核态动态分配的复杂性。填充一个符合SEH规范的EXCEPTION_RECORD其中异常代码被设置为MSVC_CPP_EXCEPTION_CODE一个微软未公开的魔数。调用内核导出的RtlRaiseException函数。内核异常分发RtlRaiseException会触发内核的异常分发流程。当内核遍历栈帧寻找异常处理器时会遇到编译器插入的__CxxFrameHandler。帧处理vcrtl实现的__CxxFrameHandler被调用。它的任务是检查作用域分析当前的函数栈帧确定try块的范围。类型匹配将抛出的异常对象的类型信息与catch语句中指定的类型进行匹配。这里vcrtl的一个优化是避免了字符串比较传统的运行时通过对比typeinfo的名字字符串来匹配类型效率较低它应该使用了基于RTTI指针或编译时生成的ID进行匹配的机制。栈展开如果找到匹配的catch块它需要执行栈展开Stack Unwinding即调用当前栈帧与catch块之间所有自动变量的析构函数。vcrtl需要正确地遍历这些对象的布局并调用其析构函数。转移控制权如果一切顺利它将清理现场跳转到对应的catch块代码开始执行。2.1 关键技术挑战与vcrtl的解决方案栈空间优化内核栈很小通常只有12KB或24KB。传统的异常处理在查找处理器时可能会消耗大量栈空间。vcrtl特别优化了这一点在x64平台上它将搜索期间的栈开销控制在约300字节并且在调用catch处理器之前会回收这部分空间。无动态分配与TLS整个异常处理过程完全在栈上进行不使用任何堆内存或线程局部存储这符合内核编程的最佳实践避免了在高端IRQL下引发页错误的风险。支持FH4 ABI在x64平台上微软后来引入了更高效的“FH4”Frame Handler 4异常处理ABI。vcrtl同时支持旧的FH3和新的FH4并推荐使用FH4因为它性能更好生成的代码更小。与内核/GS保护的协同编译器开关/GS会在函数栈中插入安全Cookie以防止缓冲区溢出。vcrtl需要感知这些Cookie并在栈展开时确保不会破坏其校验逻辑尽管项目TODO中提到完整的Cookie校验尚未实现。3. 环境准备与项目集成理论说再多不如动手搭环境。下面我们一步步把一个现有的WDK驱动项目改造成支持C异常。3.1 前置条件开发环境Visual Studio 2019 或更高版本并安装对应版本的 Windows Driver Kit (WDK)。确保你能正常编译和调试一个基础的“Hello World”内核驱动。编译器选项你的驱动项目必须启用C异常。在项目属性 - C/C - 语言中将“启用C异常”设置为“是 (/EHsc)”。/EHsc是“同步异常模型”的缩写它假设异常只会由throw语句产生并且假定外部函数不会抛出异常这能生成更高效的代码。运行库在项目属性 - C/C - 代码生成中“运行库”通常选择“多线程调试 (/MTd)”或“多线程 (/MT)”。注意绝对不能使用动态链接的DLL版本如/MD因为对应的DLL不存在于内核中。3.2 获取并集成vcrtlvcrtl项目以源代码形式发布在GitHub上但作者也提供了预编译的二进制文件方便集成。方法一使用预编译二进制推荐下载发布版访问项目的 Releases 页面下载最新版本的vcrtl.zip。解压后你会看到针对不同平台x86, x64和配置Debug, Release的.lib文件以及一个关键的vcrtl_driver.props属性表文件。集成到项目将解压后的文件夹例如vcrtl-0.1放在你的解决方案目录下或者一个全局的依赖库目录中。在Visual Studio中打开你的驱动项目。右键点击项目 - “添加” - “现有项”浏览并选择vcrtl_driver.props文件。这并不会真的添加文件而是将其作为属性表链接。打开项目属性在“通用属性” - “属性管理器”窗口中你应该能看到vcrtl_driver.props已经被添加。右键它选择“属性”检查“通用属性”下的“VC目录”。这里应该已经自动添加了vcrtl头文件目录和库文件目录的宏引用如$(VcrtlDir)\include。验证链接编译你的项目。链接器应该能自动找到对应的vcrtl.lib。你可以在项目属性 - 链接器 - 输入 - 附加依赖项中看到它被添加了。方法二从源码编译如果你需要修改vcrtl或针对特定编译器版本进行适配可以从源码编译。克隆仓库git clone https://github.com/avakar/vcrtl.git使用CMake生成项目使用CMake。你可以用Visual Studio的CMake集成或者命令行cd vcrtl mkdir build cd build cmake .. -A x64 -DCMAKE_BUILD_TYPERelease cmake --build . --config Release这会在build目录下生成库文件。手动配置项目将生成的include目录和lib目录路径手动添加到你的驱动项目的包含目录和库目录中并在链接器输入中添加vcrtl.lib。实操心得强烈建议使用方法一的预编译二进制和属性表。属性表会自动处理平台Win32/x64和配置Debug/Release的路径映射省去大量手动配置的麻烦。如果你有多个驱动项目可以把vcrtl目录放在一个公共位置然后在所有项目中引用同一个属性表。3.3 第一个测试驱动集成完成后我们写一个最简单的驱动来测试异常是否工作。// test_exception.cpp #include ntddk.h extern C NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) { UNREFERENCED_PARAMETER(RegistryPath); KdPrint((DriverEntry loaded.\n)); __try { // 尝试抛出一个标准异常 throw std::bad_alloc(); // 模拟内存分配失败 } __except (EXCEPTION_EXECUTE_HANDLER) { // 注意这里用的是SEH的__except不是C的catch。我们先不用C catch。 KdPrint((SEH caught an exception. Code: 0x%X\n, GetExceptionCode())); return STATUS_UNSUCCESSFUL; } // 注册卸载函数等... DriverObject-DriverUnload [](_In_ PDRIVER_OBJECT) { KdPrint((Driver unloaded.\n)); }; return STATUS_SUCCESS; }先别急着用catch。编译并加载这个驱动如果系统没有蓝屏并且在DbgView中看到了SEH caught an exception...的输出恭喜你vcrtl已经成功介入C的throw被转换成了SEH异常并被你的__except块捕获。这说明异常抛出和内核分发的通路是通的。4. 编写安全的异常感知驱动代码通过了基础测试我们现在来真正使用try/catch并探讨在内核中使用异常的最佳实践和严苛限制。4.1 基本的try/catch/throw让我们修改上面的例子使用真正的C异常处理#include ntddk.h #include exception // 对于std::exception void RiskyOperation() { // 模拟一个可能失败的操作 if (KeGetCurrentIrql() PASSIVE_LEVEL) { // 在过高的IRQL上执行非法操作我们抛出一个异常 throw std::runtime_error(Operation not allowed at current IRQL); } // ... 其他可能抛出异常的代码例如 // PVOID p ExAllocatePoolWithTag(PagedPool, 1024, TAG1); // if (!p) throw std::bad_alloc(); } extern C NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) { UNREFERENCED_PARAMETER(DriverObject); UNREFERENCED_PARAMETER(RegistryPath); KdPrint((DriverEntry with C EH started.\n)); NTSTATUS status STATUS_SUCCESS; try { RiskyOperation(); KdPrint((RiskyOperation succeeded.\n)); } catch (const std::bad_alloc e) { KdPrint((Caught std::bad_alloc: %s\n, e.what())); status STATUS_INSUFFICIENT_RESOURCES; } catch (const std::runtime_error e) { KdPrint((Caught std::runtime_error: %s\n, e.what())); status STATUS_UNSUCCESSFUL; } catch (const std::exception e) { // 捕获所有继承自std::exception的异常 KdPrint((Caught std::exception: %s\n, e.what())); status STATUS_UNSUCCESSFUL; } catch (...) { // 捕获所有其他类型的异常不推荐作为主要处理方式 KdPrint((Caught unknown exception.\n)); status STATUS_UNHANDLED_EXCEPTION; } return status; }这段代码看起来和用户态程序几乎一样。关键点在于你可以抛出和捕获标准库异常如std::runtime_error,std::bad_alloc。异常类型通过继承层次进行匹配。catch (...)可以捕获任何类型的异常但在内核中要慎用因为它会掩盖错误类型。4.2 必须遵守的“军规”vcrtl让异常处理成为可能但也带来了必须严格遵守的限制违反这些规则几乎必然导致系统崩溃。规则一异常不得跨模块边界这是最重要的一条限制。在模块A比如你的驱动MyDriver.sys中抛出的异常必须在同一个模块A中被捕获和处理。绝对不能让这个异常传播到模块B例如内核ntoskrnl.exe或另一个驱动的栈帧中。为什么因为异常处理依赖于编译时生成的类型信息和栈展开信息。这些信息存储在模块的.pdata异常数据段中。模块B的异常处理器__CxxFrameHandler无法理解模块A抛出的异常对象的类型信息也无法正确展开模块A的栈帧来调用析构函数。vcrtl会检测到这种跨模块传播并主动调用KeBugCheckEx触发蓝屏以防止内存泄漏或更不可预测的行为。如何避免在驱动入口函数如DriverEntry、分发函数DRIVER_DISPATCH、回调函数等可能被外部模块调用的边界处使用try/catch(...)捕获所有异常并将其转换为适当的NTSTATUS错误码返回。在内部函数之间可以自由使用异常传递错误。// 正确的做法在模块边界捕获并转换 extern C NTSTATUS MyDriverDispatch(_In_ PDEVICE_OBJECT DeviceObject, _In_ PIRP Irp) { UNREFERENCED_PARAMETER(DeviceObject); PIO_STACK_LOCATION irpSp IoGetCurrentIrpStackLocation(Irp); NTSTATUS status STATUS_SUCCESS; try { switch (irpSp-MajorFunction) { case IRP_MJ_CREATE: status HandleCreate(Irp); // 内部函数可以抛异常 break; // ... 其他MJ函数 default: status STATUS_NOT_IMPLEMENTED; break; } } catch (const MyDriverException e) { // 将自定义业务异常转换为NTSTATUS status e.ToNtStatus(); KdPrint((Dispatch caught exception: %s, converting to 0x%X\n, e.what(), status)); } catch (...) { // 兜底捕获任何未预料的异常 status STATUS_UNHANDLED_EXCEPTION; KdPrint((Dispatch caught unknown exception.\n)); } Irp-IoStatus.Status status; Irp-IoStatus.Information 0; IoCompleteRequest(Irp, IO_NO_INCREMENT); return status; } // 内部函数可以安全地使用异常 NTSTATUS HandleCreate(PIRP Irp) { if (!CheckAccess(Irp)) { throw AccessDeniedException(Insufficient privileges); } // ... 其他可能抛出异常的逻辑 return STATUS_SUCCESS; }规则二SEH异常不得穿越C异常帧Windows内核本身大量使用结构化异常处理SEH即__try/__except/__finally。vcrtl要求一个SEH异常例如访问违规STATUS_ACCESS_VIOLATION绝对不能穿越任何正在进行C异常处理的栈帧。“C异常处理的栈帧”包括正在执行try或catch块的函数。标记为noexcept的函数C11及以上。任何包含具有非平凡析构函数non-trivial destructor的自动变量的函数。为什么C异常处理机制在展开栈时需要调用析构函数。如果此时一个SEH异常“闯入”会破坏C运行时对栈状态的假设导致析构函数未被调用资源泄漏或对象处于矛盾状态。vcrtl会尝试检测这种冲突并蓝屏。如何避免谨慎混用SEH和C EH尽量避免在同一个函数或紧密调用的函数链中同时使用两者。如果必须使用SEH来捕获硬件异常如页错误请将其限制在最小的、不涉及C对象管理的代码块中。使用noexcept要小心将函数标记为noexcept意味着它承诺不抛出C异常。如果它内部或它调用的函数产生了SEH异常程序会调用std::terminate。在内核中这通常意味着蓝屏。// 危险的混用示例 void DangerousFunction() { MyResource res; // 非平凡析构函数 __try { // 可能产生访问违规的代码 ProbeForRead(someUserBuffer, length, 1); // 如果这里发生ACCESS_VIOLATIONSEH异常会穿越res的析构函数帧 // 这是未定义行为可能导致蓝屏 } __except (EXCEPTION_EXECUTE_HANDLER) { KdPrint((Access violation caught.\n)); } // res的析构函数在这里被调用但如果上面的SEH异常发生了栈展开可能已经乱了。 } // 更安全的做法将SEH隔离到不包含C对象的纯C函数中 bool SafeProbeBuffer(PVOID addr, SIZE_T len) { __try { ProbeForRead(addr, len, 1); return true; } __except (EXCEPTION_EXECUTE_HANDLER) { return false; } } void SaferFunction() { MyResource res; if (!SafeProbeBuffer(someUserBuffer, length)) { // 处理探测失败这里可以抛C异常或返回错误码 throw std::runtime_error(Buffer probe failed); } // ... 安全地使用buffer }4.3 资源管理与RAII异常处理最大的优势之一是与RAII资源获取即初始化模式的完美结合。确保在异常发生时资源能被正确释放。class AutoIrpCompletion { public: explicit AutoIrpCompletion(PIRP Irp, NTSTATUS ErrorStatus STATUS_UNSUCCESSFUL) : m_irp(Irp), m_errorStatus(ErrorStatus), m_complete(false) {} ~AutoIrpCompletion() { if (!m_complete m_irp) { m_irp-IoStatus.Status m_errorStatus; m_irp-IoStatus.Information 0; IoCompleteRequest(m_irp, IO_NO_INCREMENT); KdPrint((AutoIrpCompletion: IRP 0x%p completed in destructor with status 0x%X\n, m_irp, m_errorStatus)); } } void Dismiss() { m_complete true; } // 成功时调用阻止析构函数完成IRP private: PIRP m_irp; NTSTATUS m_errorStatus; bool m_complete; }; NTSTATUS ProcessRequest(PIRP Irp) { // 创建守卫对象承诺在函数退出时无论正常返回还是异常完成IRP AutoIrpCompletion irpGuard(Irp, STATUS_CANCELLED); // ... 可能抛出异常的业务逻辑 PVOID buffer ExAllocatePoolWithTag(PagedPool, 4096, MyTag); if (!buffer) { throw std::bad_alloc(); } // 另一个RAII类来管理内存 std::unique_ptrBYTE, decltype(ExFreePool) memoryGuard(static_castBYTE*(buffer), ExFreePool); PerformRiskyOperation(buffer); // 可能抛出std::runtime_error // 一切顺利 Irp-IoStatus.Status STATUS_SUCCESS; Irp-IoStatus.Information 4096; irpGuard.Dismiss(); // 手动完成IRP并阻止守卫对象再次完成 IoCompleteRequest(Irp, IO_NO_INCREMENT); return STATUS_SUCCESS; // 如果发生异常栈展开会按顺序调用 // 1. memoryGuard的析构函数 - ExFreePool(buffer) // 2. irpGuard的析构函数 - IoCompleteRequest(Irp, STATUS_CANCELLED) // 然后异常被上一层的catch块捕获。 }5. 调试与问题排查在内核里调试异常比用户态更棘手。下面是一些实用的技巧。5.1 启用调试输出确保你的调试器WinDbg/KD能接收到DbgPrint输出或者在系统中运行DbgView。在异常处理路径中加入详细的打印信息是定位问题最直接的方法。catch (const std::exception e) { KdPrint(([MyDriver] Exception in %s at IRQL %d: %s\n, __FUNCTION__, KeGetCurrentIrql(), e.what())); // ... 转换状态码 }5.2 分析蓝屏Dump文件如果驱动因为违反vcrtl规则而蓝屏BugCheck代码和参数是首要线索。使用WinDbg分析%SystemRoot%\MEMORY.DMP或小内存转储文件。加载符号确保加载了你的驱动和vcrtl的符号文件.pdb。分析BugCheck常见的相关BugCheck可能是KMODE_EXCEPTION_NOT_HANDLED (0x1E): 未处理的异常。DRIVER_OVERRAN_STACK_BUFFER (0xF7): 栈损坏可能与异常展开错误有关。vcrtl也可能会触发自定义的BugCheck。查看调用栈使用!analyze -v和k命令查看崩溃时的线程调用栈。关注栈帧中是否显示了你的函数和vcrtl的内部函数如__CxxFrameHandler。5.3 常见问题速查表问题现象可能原因排查步骤与解决方案链接错误未解析的外部符号__CxxFrameHandler3或_CxxThrowExceptionvcrtl库未正确链接。1. 检查项目属性中“附加依赖项”是否包含vcrtl.lib。2. 检查库目录路径是否正确是否区分了x86/x64和Debug/Release。3. 确保项目属性中“启用C异常”已设置为/EHsc。驱动加载失败或一执行throw就蓝屏异常跨模块传播。1. 检查throw是否发生在可能被外部调用的函数中如DriverEntry, Dispatch例程。2. 在这些边界函数的最外层添加catch(...)。3. 使用调试器在vcrtl源码的RaiseException或帧处理器函数中设断点观察异常传播路径。在catch块中或之后发生随机内存损坏或二次异常SEH异常穿越了C EH帧导致栈状态不一致。1. 审查代码查找混用__try/__except和C对象的区域。2. 将可能引发硬件异常的代码如访问用户模式内存ProbeForRead封装到独立的、不包含C对象析构的纯C函数中。3. 使用/EHa异常模型异步异常模型需极度谨慎并充分测试。抛出异常后某些资源如内存、句柄未释放RAII未正确实施或析构函数中又抛出了异常。1. 为所有需要手动管理的资源内存、互斥体、事件、IRP创建RAII包装类。2.确保析构函数是noexcept的。在析构函数中抛出异常会导致程序立即终止内核中即蓝屏。析构函数应只进行清理操作并吞掉任何次要错误。启用/GS缓冲区安全检查后程序行为异常vcrtl对/GS的完整支持尚在TODO中。1. 暂时关闭/GS编译选项进行测试确认是否是此问题。2. 避免在可能使用异常的函数中使用大的栈数组减少对/GS的依赖。3. 关注vcrtl项目的更新等待对/GS的完整支持。5.4 高级调试技巧设置WinDbg断点你可以在vcrtl的关键函数上设置断点来跟踪异常处理的每一步。0: kd x vcrtl!*CxxThrowException* 0000000001234567 vcrtl!_CxxThrowException (void *) 0: kd bp vcrtl!_CxxThrowException 0: kd bp vcrtl!__CxxFrameHandler3当断点命中时查看参数和调用栈可以清晰地看到异常对象是什么、从哪里抛出、以及正在尝试匹配哪个catch块。6. 性能考量与最佳实践总结在内核中使用异常不是零成本的但vcrtl已经做了大量优化。以下是性能和使用上的一些要点零成本模型Zero-Overhead Model在未发生异常的路径上try块几乎不产生额外开销。开销主要在于编译器为栈上的对象生成展开信息表.xdata/.pdata这会略微增加代码体积。抛出成本Throw Cost抛出异常是昂贵的操作。它涉及构造异常对象、遍历调用栈查找处理器、展开栈并调用析构函数。因此异常只应用于真正的错误情况而非正常的控制流。例如文件未找到可能是一个可预期的错误应使用错误码而内存分配失败是一个罕见的、严重的错误适合用异常。优先使用FH4在x64平台确保你的编译环境支持并使用FH4 ABI。这通常意味着使用较新版本的Visual Studio和WDK。FH4比FH3更高效。保持异常类型简洁抛出的异常对象最好小巧且可复制。避免在异常对象中包含大量数据或复杂的依赖。自定义异常类应继承自std::exception。清晰的错误转换在驱动模块的边界入口点、回调将捕获的C异常清晰地转换为对应的NTSTATUS值。这有助于上层调用者理解错误性质。// 自定义异常类包含NTSTATUS转换 class DriverException : public std::runtime_error { public: DriverException(const char* message, NTSTATUS status) : std::runtime_error(message), m_status(status) {} NTSTATUS GetStatus() const { return m_status; } private: NTSTATUS m_status; }; // 在边界处统一转换 extern C NTSTATUS MyDeviceControl(_In_ PDEVICE_OBJECT, _In_ PIRP Irp) { NTSTATUS finalStatus STATUS_SUCCESS; try { // ... 内部逻辑可能抛出DriverException或其他异常 ProcessIoControl(Irp); } catch (const DriverException e) { finalStatus e.GetStatus(); KdPrint((Controlled exception: %s - 0x%X\n, e.what(), finalStatus)); } catch (const std::bad_alloc) { finalStatus STATUS_INSUFFICIENT_RESOURCES; } catch (const std::exception e) { KdPrint((Unexpected std::exception: %s\n, e.what())); finalStatus STATUS_UNHANDLED_EXCEPTION; } catch (...) { KdPrint((Unknown exception caught at boundary.\n)); finalStatus STATUS_UNHANDLED_EXCEPTION; } Irp-IoStatus.Status finalStatus; IoCompleteRequest(Irp, IO_NO_INCREMENT); return finalStatus; }将C异常引入Windows驱动开发就像给一位习惯用扳手的老师傅递上了一套精密的电动螺丝刀。它不会改变内核编程对稳定性和严谨性的极致要求但却能在处理复杂错误逻辑时提供更清晰、更安全、更易于维护的代码结构。关键在于理解其底层机制严格遵守“不跨模块”、“不混SEH”的铁律并善用RAII管理资源。从一个小型的、非关键的驱动模块开始尝试逐步积累经验你会发现它在提升代码质量方面大有裨益。