VSCode的Jupyter插件是将Jupyter能力深度集成进编辑、调试与工程化流程，使.ipynb成为可调试、Git友好、可复用的开发单元；常见“Run Cell”失效源于内核环境未正确配置，需手动选择具体Python解释器路径、安装并注册ipykernel（带--user参数）、重启窗口；.ipynb适合交付含输出的报告，.py+#%%更适合日常开发与协作；变量面板仅显示当前内核全局命名空间中的对象；调试需点击“Run and Debug”按钮、使用本地内核且断点打在可执行语句上。
VSCode 的 Jupyter 插件不是“让 VSCode 跑 Jupyter”，而是把 Jupyter 的交互式计算能力深度缝进 VSCode 的编辑、调试和工程化工作流里——它让 .ipynb 文件真正成为可调试、可 Git 管理、可复用模块的开发单元，而不是浏览器里一个孤立的 notebook 页面。
为什么装了插件还点不动 “Run Cell”？
常见错误现象是右上角内核显示 “Python 3 (unavailable)” 或根本没下拉菜单；这几乎全是环境链路断了，不是插件没装好。
- 必须先通过
Python: Select Interpreter命令选中一个**具体路径**的 Python 解释器（比如~/miniconda3/envs/ds/bin/python），不能只选“Python 3.x”这种模糊项 - 该解释器下必须已安装
ipykernel：在终端激活对应环境后执行python -m pip install ipykernel，别用conda install ipykernel混用 - 注册内核时必须加
--user参数：python -m ipykernel install --user --name ds-env --display-name "Python 3 (ds-env)"；--name不能含空格，否则 VSCode 无法解析 - 注册完要重启窗口（
Developer: Reload Window），否则新内核不会出现在选择器里
用 .ipynb 还是 # %% 分隔的 .py？
这不是格式偏好问题，而是协作与调试成本的权衡。
-
.ipynb适合交付场景：含 Markdown、LaTeX、图表、输出结果，导出 PDF/HTML 即可当报告；但 JSON 格式导致 Git diff 失效，多人编辑易冲突 -
.py+# %%是日常开发首选：Git 友好、能直接import其他模块、支持完整断点调试、可被 pytest 扫描；VSCode 会把它当 notebook 渲染，Ctrl+Enter运行单块，体验一致 - 混合使用很自然：探索阶段用
.ipynb快速试模型，稳定后用Export → Export to Python导出干净脚本，再重构进工程目录
Variables 面板为啥看不到刚创建的 df？
变量面板只显示当前内核运行上下文中的对象，不是“当前文件里定义的所有变量”。
- 确保你是在 notebook 单元格或
# %%块里运行了df = pd.DataFrame(...)，而不是在普通 Python 文件的顶层代码中 - 如果用了
Restart Kernel，之前所有变量都会清空，面板自然为空；Run All Cells后再看 - 某些对象（如大型
numpy数组）默认不展开，点击变量名右侧的 “▶” 才加载预览；超大DataFrame会自动截断行数，避免卡 UI - 面板不显示局部作用域变量（比如函数内部定义的
df），只显示全局命名空间里的
调试 cell 时断点不生效？
VSCode 的 notebook 调试复用的是标准 Python 调试协议，但触发条件比普通脚本更严格。
- 断点必须打在可执行语句上：不能打在空行、注释行、
import行（除非该行触发了副作用）或纯 Markdown 单元格里 - 必须点击单元格右上角的
▶️ Run and Debug按钮（不是▶️ Run Cell），或按F5；仅按Shift+Enter不会进入调试模式 - 如果用了远程内核（比如 SSH 或 Jupyter Server URI），本地断点无效；调试只支持本地启动的内核进程
- 某些库（如
torch的异步数据加载）可能绕过调试器，此时建议把可疑逻辑抽成函数，在普通.py文件里单独调试
最容易被忽略的一点：Jupyter 插件的调试能力完全依赖于内核是否由 VSCode 自动管理。一旦手动配置了 "jupyter.jupyterServerType": "remote" 或填了 jupyter.remoteJupyterServerUri，本地断点和变量面板就会失效——这不是 bug，是设计使然。
