F11跳不进函数体是因为它仅在存在可调试源码且非内置/C实现/优化函数时才生效；断点需设在函数定义内而非调用行，且须满足源码在工作区、Python扩展启用、justMyCode配置匹配等前提。
断点停在函数调用行时，F11 为什么跳不进函数体
因为 F11（单步跳入）的行为取决于当前执行位置的“实际可进入代码”，而不是你眼睛看到的那行源码。比如写 result = my_func() 并在此设断点，按下 F11 后，VSCode 会尝试进入 my_func 的定义——但前提是它能定位到该函数的**可调试源码**，且该函数不是内联、C 扩展或被优化掉的。
常见失败场景包括：
-
my_func是内置函数（如len()、print()）或 C 实现的第三方函数（如@lru_cache包装后的函数），F11 直接跳过，停在下一行 - 函数来自
site-packages，而launch.json中"justMyCode": true（默认）会主动跳过这些路径 - 函数被装饰器包裹，但断点没打在
wrapper内部，只打在@decorator或调用行上 → F11 实际跳入的是被装饰后的函数第一行，而非 wrapper 逻辑 - Python 扩展未激活，或解释器路径配置错误，导致调试器无法解析函数定义位置
确保 F11 能跳入的三个硬性前提
不是按了 F11 就一定进得去，必须同时满足：
-
my_func的源码文件必须在当前工作区中（不能是 zip 包、.egg、符号链接路径），且 VSCode 能正确识别其磁盘绝对路径 - 对应 Python 扩展已启用，且调试会话使用的是你预期的解释器（检查左下角 Python 版本，或
launch.json中"python"字段） -
launch.json中"justMyCode"设为true（推荐保持默认），但若目标函数就在第三方包里且你确实需要进，可临时设为false—— 注意这会让调试器卡在functools.py等标准库深处
验证方式：在 my_func 定义开头加一句 print("here")，运行看是否输出；没输出说明根本没走到那里，F11 自然无从谈起。
多层装饰器下 F11 只进最外层 wrapper 怎么办
比如有 @dec1 @dec2 def f(): ...，断点设在 f() 调用行，F11 默认只进入 dec1 的 wrapper，不会自动穿透到 dec2 或原函数。这不是 bug，是调试器按调用栈逐层展开的正常行为。
要查某一层内部逻辑，必须提前把断点打在那一层的 wrapper 函数体内：
- 打开
dec1源码，在def wrapper(*args, **kwargs):下一行设断点 → F11 进 dec1 - 在
dec1的wrapper里调用return func(*args, **kwargs)这行再按 F11 → 若func是dec2的 wrapper，且其源码可达，则继续进入 - 如果
dec2是第三方装饰器（如tenacity.retry），无法编辑源码，就只能在它返回的 callable 上右键 → “Go to Definition” 看是否跳转成功；跳转失败，说明 F11 必然无效
用 @functools.wraps 会掩盖真实函数名，让调试器显示 f 却执行 wrapper，此时 F11 行为更依赖断点位置而非函数名显示。
替代方案：当 F11 失效时，用什么补救
别卡在“必须 F11”的思维里。真正要的是看清执行流和变量状态，不一定非得靠跳入：
- 在目标函数第一行设断点（而非调用行），直接暂停在其入口，效果等同于“跳入成功”
- 用 F10（单步跳过）配合 Variables 面板观察参数传入值，再结合 Step Into 查看关键子调用
- 对可疑函数右键 → “Add Log Point”，输入
args, kwargs, result等表达式，不中断执行也能捞出上下文 - 在 DEBUG CONSOLE 中手动执行
my_func(1, 2)，看是否报错或返回异常值，快速隔离问题域
最常被忽略的一点：F11 是否生效，和你有没有保存文件、Python 进程是否热重载无关，但和 launch.json 里 "console" 设置有关——设成 "integratedTerminal" 比 "internalConsole" 更稳定支持断点命中。
