finally在正常流程、异常被捕获时必执行；但遇SIGKILL、os._exit()、线程被强制终止、解释器致命错误时无法执行。
如果您在Python中使用try-except-finally结构，但发现finally子句似乎未按预期运行，则可能是由于程序在try或except块中遭遇了非正常终止。以下是分析finally执行时机的多个关键场景：
一、正常流程下finally必定执行
在try块无异常、或异常被except成功捕获并处理的情况下，finally子句一定会执行，无论try或except中是否包含return、break、continue语句。该机制确保资源清理逻辑不被跳过。
1、定义一个含finally的函数，其中try块内含return语句。
2、调用该函数并观察返回值及finally内print输出。
立即学习“Python免费学习笔记（深入）”；
3、确认finally中的代码在return值确定后、实际返回前执行。
二、系统级中断导致finally不执行
当Python解释器进程被外部信号强制终止时，finally无法获得执行机会。这类中断绕过了Python的正常控制流调度机制。
1、在运行含finally的脚本时，使用操作系统命令发送SIGKILL（Linux/macOS下kill -9）。
2、观察终端输出，确认finally内部语句无任何打印。
3、SIGKILL无法被捕获或忽略，因此finally绝对不执行。
三、os._exit()直接退出进程
os._exit()绕过Python的正常退出流程，不触发任何atexit注册函数、不执行finally、不刷新I/O缓冲区，直接终止当前进程。
1、在try块中调用os._exit(0)。
2、确认后续finally块中所有语句均未执行。
3、与sys.exit()不同，os._exit()不会引发SystemExit异常，因此不会进入finally。
四、线程被强制终止
在多线程环境中，若主线程调用threading.Thread对象的stop()方法（该方法实际不存在于标准库，此处指非安全强制终止手段），或通过外部机制杀掉线程，目标线程中正在执行的finally可能被截断。
1、启动一个子线程，其run()方法包含try-finally结构。
2、主线程使用非标准方式（如ctypes注入或信号）强行终止该线程。
3、Python标准线程API不提供安全强制终止接口；任何绕过正常退出路径的操作都可能导致finally丢失。
五、致命解释器错误
当Python解释器自身发生严重错误（如内存访问越界、栈溢出、GC崩溃），进程会立即中止，所有Python层控制流（包括finally）均无法继续。
1、构造递归深度远超sys.getrecursionlimit()的函数并在try中调用。
2、运行时触发Segmentation Fault或Fatal Python error。
3、此类错误发生在C运行时层面，Python的异常处理机制完全失效。
