finally 中的 return 会接管整个函数退出流程，覆盖 try/except/else 中暂存的返回值，并影响可变对象的最终状态；正确做法是用局部变量承载结果，finally 仅执行无副作用的清理操作。
finally 中的 return 会接管整个函数退出流程
Python 不是“先 return 再执行 finally”，而是把 return 的值暂存，强制跳入 finally 执行完后再真正退出。只要 finally 里有 return，它就直接覆盖暂存值——不管这个值来自 try、except 还是 else。
常见错误现象：
- 调用方收到一个看似“成功”的返回值（比如字符串
"closed"），但实际业务逻辑失败了 - 日志里没报错、调试器看不到异常堆栈、HTTP 接口返回 200，问题却在线上静默发生
- 用
javap -v看字节码或 PyCharm 调试器单步，能清楚看到ireturn指令被finally分支重复触发
可变对象在 finally 中修改会影响返回值
return 可变对象（如 list、dict）时，返回的是引用而非副本。finally 里对它的任何修改，都会反映到调用方拿到的对象上。
示例中 result = [] 在 try 中 append() 后 return result，紧接着 finally 又 result.append(...)，最终调用方收到的列表末尾多了一项。
这种行为不是 bug，是 Python 对象模型和返回机制共同作用的结果。不可变对象（如 int、str）不受影响，因为 finally 里的赋值只是改了局部变量，不改变原返回值。
资源清理和返回值必须解耦
把文件关闭、锁释放等清理动作和业务结果返回混在同一个 finally 块里，是绝大多数误用的根源。正确做法是用局部变量承载结果，让 finally 只做无副作用操作。
安全写法要点：
- 声明
result = None或其他占位值 - 所有业务分支（
try/except/else）只负责给result赋值，不return -
finally只调用file.close()、lock.release()等，绝不碰result，更不return - 函数末尾统一
return result
静态检查和 IDE 警告值得认真对待
Python 解释器允许 finally 中写 return，但主流 IDE（PyCharm、VSCode + Pylance）默认会标黄警告：Finally block cannot complete normally。这不是建议，是明确提示该代码路径存在控制流劫持风险。
Java 编译器直接报错，Python 靠工具链和人工识别——这意味着问题往往要等到线上返回异常数据、或者测试覆盖不到的分支出错时才暴露。最容易被忽略的是：它不报错，也不抛异常，只是悄悄改掉你的逻辑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
