finally块几乎总在离开try/catch前执行，无论是否异常、是否catch捕获、甚至catch中return或抛异常；正常时执行try→finally，异常被捕获时执行try（中断）→catch→finally，finally中return会覆盖try/catch的返回值。
当代码中发生异常时，try-catch-finally 的执行顺序是固定的，且 finally 块几乎总会在离开当前 try/catch 结构前执行——无论是否抛出异常、是否被 catch 捕获、甚至在 catch 中再次抛出异常或 return 语句出现时。
正常无异常时的执行顺序
如果 try 块内代码全部顺利执行，没有抛出任何异常：
- 先执行
try中所有语句 - 跳过所有
catch块（不进入） - 执行
finally块
有异常且被 catch 捕获时
当 try 中某行抛出异常，且存在匹配的 catch 块：
- 立即中断
try中后续代码（不再执行） - 跳转到对应
catch块，执行其中语句 - 执行
finally块（即使catch中有return）
catch 中再次抛出异常或 return 时
finally 仍会执行，且优先级高于 catch 中的 return 或 throw：
- 若
catch中写return 42;，会先暂存返回值，再进finally -
finally执行完后，才真正返回（除非finally自己也return或抛异常） - 若
finally中抛出新异常，则覆盖原异常，调用栈中只体现 finally 的异常
finally 的关键特性与使用建议
finally 是释放资源最可靠的位置，比如关闭文件、释放数据库连接、解锁等：
- 它不依赖异常是否发生，也不依赖你有没有写
catch - 可以单独和
try配合使用（即try-finally），适合无需处理异常、只需确保清理的场景 - 避免在
finally中写return，否则会吞掉try或catch的返回值或异常 - .NET 6+ 推荐优先使用
using语句或IDisposable模式，它们底层也依赖类似 finally 的机制
基本上就这些。掌握这个顺序，能帮你写出更健壮、不易泄露资源的异常处理逻辑。
