简介这份PDF资料面向使用VS Code进行Python开发的程序员尤其是希望提升编码效率、优化开发环境的初中级开发者。内容系统梳理了8款实用扩展插件覆盖代码检查、调试、实时可视化、文本排序去重、Git版本管理、代码片段、注释高亮与自动缩进等环节帮助读者按需组合出更顺手的开发工具链。资源包为1个PDF文件大小约521KB轻量易读适合随时查阅或作为插件选型参考。目前已有4753人学习下载说明其在Python开发者社区中具备一定认可度。通过阅读读者可以了解微软官方Python扩展对Pylint、Flake8、Jupyter Notebook、Pytest与Unittest的支持方式掌握Python Preview的实时代码预览与主题切换能力以及Sort Lines在数据清洗中的排序去重技巧同时还能认识Git Graph的分支可视化操作、Python Snippets的常用片段插入、Better Comments的关键词高亮规则、autoDocstring的PEP 8注释生成和Python Indent的缩进纠正思路从而快速定位适合自己工作流的插件组合。1. 为什么这 8 个 Python 扩展能让你少写一半样板代码很多人装了一堆 VS Code 扩展结果日常真正高频用的就那么两三个剩下的要么互相打架要么在后台偷偷吃内存。我见过一个数据处理的活儿光是把 JSON 转成 DataFrame 再画个图有人手动敲了四十多行样板代码而隔壁工位的老哥用对了扩展三行就出结果。差距不在技术能力在于工具链有没有配到位。这篇要聊的是 VS Code 里 8 个真正能改变 Python 开发节奏的扩展。不是那种装完就忘的装饰品而是能直接减少你敲键盘次数、提前发现低级错误、把调试从玄学变成流程的实用工具。适合两类人刚配好 VS Code 环境、面对扩展市场不知道从哪下手的新手以及用了几年但一直没系统整理过工具链、想看看有没有漏掉关键拼图的熟手。下面按「装什么、为什么装、怎么配、坑在哪」的顺序拆开讲每个扩展都给出可复现的配置步骤和参数说明。2. 代码质量与格式化从保存文件那一刻就守住底线2.1 Pylance类型提示和智能补全的底座Pylance 是微软官方维护的语言服务器基于 Pyright 做静态类型检查。它和 VS Code 内置的 Python 扩展配合工作但真正干活的是 Pylance。装完之后最直观的变化是函数参数提示变准了导入模块时补全速度明显快一截类型不匹配的地方会直接标黄线。配置上我一般会在 settings.json 里显式指定语言服务器避免和旧版 Jedi 抢活{ python.languageServer: Pylance, python.analysis.typeCheckingMode: basic, python.analysis.autoImportCompletions: true, python.analysis.inlayHints.functionReturnTypes: true }typeCheckingMode有三个档位off、basic、strict。新手建议 basicstrict 会把很多第三方库的类型缺失也报出来容易劝退。autoImportCompletions打开后敲一个没导入的类名补全列表里会直接带出 import 语句省掉手动写 import 的步骤。inlayHints.functionReturnTypes会在函数调用处显示推断出的返回类型读别人代码时特别有用。有个细节要注意Pylance 对虚拟环境的识别依赖python.defaultInterpreterPath或工作区选择。如果补全突然失效先检查右下角解释器是不是选到了系统 Python 而不是项目 venv。2.2 Black Formatter把格式化争议一次性终结Black 是「不妥协的格式化器」它不给你留配置空间代码风格统一到没有讨论余地。VS Code 里的 Black Formatter 扩展让保存即格式化成为默认行为。安装后在 settings.json 里加{ editor.formatOnSave: true, editor.defaultFormatter: ms-python.black-formatter, [python]: { editor.defaultFormatter: ms-python.black-formatter }, black-formatter.args: [--line-length, 100] }--line-length默认是 88我习惯改成 100因为现代显示器横向空间够100 字符能减少很多不必要的换行。但团队协作时这个值必须统一否则每次提交都是格式化 diff代码评审没法看。Black 和 isort 的配合也值得提一句。isort 负责 import 排序Black 负责其余格式。两个都装的话把 isort 的 profile 设为 black避免两者打架{ isort.args: [--profile, black] }2.3 Ruff比 Flake8 快一个数量级的 linterRuff 是用 Rust 写的 linter速度比 Flake8 快几十倍而且一个工具覆盖了 Flake8、isort、pyupgrade 等一堆工具的功能。VS Code 的 Ruff 扩展让它在编辑器里实时跑。配置示例{ ruff.lint.enable: true, ruff.lint.args: [--select, E,F,W,I,N,UP,B], ruff.format.args: [--line-length, 100], editor.codeActionsOnSave: { source.fixAll.ruff: explicit } }--select里的字母含义E/W 是 pycodestyle 错误和警告F 是 pyflakes 逻辑错误I 是 isort 规则N 是 pep8-namingUP 是 pyupgrade 建议B 是 bugbear 潜在 bug。source.fixAll.ruff设为 explicit 表示保存时自动修复可修复的问题但需要你手动触发一次保存动作不会在打字过程中乱改。Ruff 和 Black 可以共存但建议让 Ruff 只做 lint 不做 format格式化交给 Black职责清晰。如果想让 Ruff 全包把ruff.format.args配上然后关掉 Black Formatter 扩展即可。3. 调试与运行把 print 大法换成正经断点3.1 Python Debugger条件断点和远程调试VS Code 内置的 Python Debugger 扩展ms-python.debugpy提供了完整的调试能力。很多人只用过 F5 启动其实条件断点和日志断点才是真正省时间的功能。在 launch.json 里配置一个带参数的调试任务{ version: 0.2.0, configurations: [ { name: Python: Current File, type: debugpy, request: launch, program: ${file}, console: integratedTerminal, justMyCode: false, env: { PYTHONPATH: ${workspaceFolder}/src } } ] }justMyCode设为 false 后可以步入第三方库源码排查库内部逻辑时有用但会拖慢调试启动速度。PYTHONPATH指定源码根目录避免 import 报错。console用 integratedTerminal 而不是 internalConsole因为后者对 input() 和彩色输出支持不好。条件断点的用法在断点红点上右键输入表达式比如i 100 and data[i] is None只有条件为真时才停下。日志断点更轻量不暂停程序只在调试控制台打印消息适合循环里看变量变化又不想中断执行流的场景。3.2 Jupyter在编辑器里跑交互式代码块Jupyter 扩展让 VS Code 直接支持 .ipynb 文件和 Python 交互窗口。做数据分析时不用在浏览器和编辑器之间来回切。关键配置{ jupyter.executeInInteractiveWindow: true, jupyter.interactiveWindow.textEditor.executeSelection: true, jupyter.askForKernelRestart: false }executeInInteractiveWindow打开后选中代码按 ShiftEnter 会发送到交互窗口而不是新建 notebook。executeSelection让普通 .py 文件也能享受这个能力写脚本时可以先跑几行验证逻辑。askForKernelRestart关掉后重启内核不再弹确认框频繁重启时少点一次是一次。变量查看器是 Jupyter 扩展的隐藏福利。交互窗口右侧的 Variables 面板能直接看到当前所有变量的类型和值DataFrame 还能点开成表格。比 print(df.head()) 直观得多。4. 效率提升让重复操作变成一次点击4.1 Python Indent解决粘贴代码缩进错乱从网页或聊天记录里复制 Python 代码到 VS Code经常出现缩进全乱的情况。Python Indent 扩展专门处理这个问题它会在粘贴时自动根据上下文修正缩进层级。这个扩展几乎不需要配置装完就生效。但有一个场景要注意如果你的代码里混用了 tab 和空格Python Indent 的修正结果可能不符合预期。建议在 settings.json 里强制统一{ editor.insertSpaces: true, editor.tabSize: 4, editor.detectIndentation: false }detectIndentation关掉很重要否则 VS Code 会根据文件内容自动猜缩进方式导致同一个项目里不同文件行为不一致。4.2 Better Comments给注释加颜色分层Better Comments 让注释按类型显示不同颜色比如 TODO 是橙色、疑问是蓝色、警告是红色。Python 项目里用得多的是# TODO:和# NOTE:。配置{ better-comments.tags: [ { tag: !, color: #FF2D00, strikethrough: false }, { tag: ?, color: #3498DB, strikethrough: false }, { tag: TODO, color: #FF8C00, strikethrough: false }, { tag: NOTE, color: #2ECC71, strikethrough: false } ] }这个扩展本身不复杂但配合 Todo Tree 扩展用效果更好。Todo Tree 会在侧边栏汇总所有 TODO 注释点击直接跳转。两个一起装代码里的待办事项就不会被遗忘在角落。4.3 GitLens看清每一行代码的来龙去脉GitLens 严格来说不是 Python 专属但在 Python 项目里排查「这行代码为什么这么写」时特别有用。它会在行尾显示最后修改这行的人和提交信息鼠标悬停能看到完整 diff。对 Python 开发者来说最有价值的场景是接手一个没有文档的老项目想知道某个函数为什么加了那个奇怪的边界判断。GitLens 的 blame 视图能直接告诉你那次提交的完整上下文。配置上建议关掉行尾的 blame 显示只保留悬停查看否则代码区域太花{ gitlens.currentLine.enabled: false, gitlens.hovers.currentLine.over: line, gitlens.codeLens.enabled: false }currentLine.enabled关掉行尾装饰hovers.currentLine.over设为 line 表示悬停时显示当前行的 blame 信息。codeLens.enabled关掉函数上方的作者信息减少视觉噪音。5. 避坑与常见问题这些扩展装完不配置等于白装5.1 扩展冲突导致补全失效现象装完 Pylance 后补全反而变慢了或者某些库的补全完全出不来。原因旧版 Python 扩展自带的 Jedi 语言服务器和 Pylance 同时运行两者抢着响应补全请求。或者工作区里存在多个 Python 解释器Pylance 索引了错误的那个。解决在 settings.json 里显式设置python.languageServer: Pylance然后命令面板执行「Python: Select Interpreter」确认选中的是项目 venv。如果还不行命令面板执行「Developer: Reload Window」强制重启语言服务器。5.2 保存时格式化与 lint 自动修复互相覆盖现象保存一次代码Black 格式化完Ruff 又改回去文件内容反复横跳。原因Black 和 Ruff 的格式化规则在某些边界情况上不一致比如长字符串的换行策略。两个都开了 formatOnSave 就会打架。解决只保留一个格式化器。我一般让 Black 负责格式化Ruff 只做 lint 不做 format。在 Ruff 配置里把ruff.format.args去掉或者直接把editor.defaultFormatter明确指向 Black。5.3 Jupyter 交互窗口内核启动超时现象ShiftEnter 后交互窗口一直显示「正在启动内核」等很久后报超时错误。原因VS Code 的 Jupyter 扩展需要 ipykernel 包如果当前虚拟环境没装或者版本太旧就会卡住。另外公司网络限制可能导致内核连接握手失败。解决在项目 venv 里执行pip install ipykernel --upgrade然后重启 VS Code。如果网络受限检查是否有代理配置影响了 localhost 通信。命令面板执行「Jupyter: Restart Kernel」也能强制重连。5.4 GitLens 在大仓库里拖慢编辑器现象打开一个提交历史很长的项目VS Code 明显变卡滚动代码时掉帧。原因GitLens 默认会索引整个仓库的提交历史仓库越大索引越慢内存占用越高。解决在 settings.json 里限制 GitLens 的索引范围{ gitlens.advanced.maxListItems: 50, gitlens.advanced.repositorySearchDepth: 1, gitlens.blame.ignoreWhitespace: true }maxListItems限制列表显示条数repositorySearchDepth限制搜索深度ignoreWhitespace让 blame 忽略空白变更。如果还卡直接在不需要看 blame 的工作区禁用 GitLens。5.5 扩展装太多导致启动变慢现象VS Code 启动要十几秒打开 Python 文件后语言服务半天才就绪。原因每个扩展都在启动时抢资源尤其是那些监听文件变化、跑后台索引的扩展。Pylance、Ruff、GitLens 都是资源大户。解决按工作区禁用不需要的扩展。比如做纯数据分析时GitLens 和 Ruff 可以关掉写库代码时Jupyter 可以关掉。命令面板执行「Extensions: Disable (Workspace)」按工作区管理。另外在 settings.json 里加extensions.autoUpdate: onlyEnabledExtensions避免自动更新一堆用不上的扩展。6. 进阶技巧用 Profile 把工具链切成场景化套餐VS Code 的 Profile 功能允许你保存多套扩展和配置组合按场景一键切换。这个功能对 Python 开发者特别实用因为数据分析、Web 开发、脚本编写需要的扩展组合完全不同。创建 Profile 的方式命令面板执行「Profiles: Create Profile」然后勾选这个场景需要的扩展。我一般建三个Profile 名称包含扩展适用场景Data-SciencePylance、Jupyter、Black Formatter数据分析、notebookWeb-BackendPylance、Ruff、Python Debugger、GitLensFastAPI/Django 开发ScriptingPylance、Python Indent、Better Comments写一次性脚本、自动化任务切换 Profile 后VS Code 会重新加载对应扩展集settings.json 也可以按 Profile 覆盖。比如 Data-Science Profile 里把editor.formatOnSave关掉因为 notebook 单元格里频繁格式化反而打断思路。导出 Profile 分享给团队命令面板执行「Profiles: Export Profile」会生成一个 .code-profile 文件。团队新人导入后直接获得统一的工具链配置省掉「你用什么格式化」这种讨论。还有一个技巧是把 Profile 和 devcontainer 结合。在 .devcontainer/devcontainer.json 里指定customizations: { vscode: { extensions: [...] } }容器启动时自动装好扩展。这样本地环境怎么折腾都不影响项目的一致性。我自己的习惯是每季度清理一次扩展列表把过去三个月没主动用过的扩展禁用掉。工具链不是越多越好每个扩展都应该有明确的、高频的使用场景。装之前问自己一句这个扩展能帮我省下什么操作如果答不上来就先别装。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 12:18:46 · 阅读 1.2k 8个VS Code Python扩展：减少样板代码，提升开发效率
简介这份PDF资料面向使用VS Code进行Python开发的程序员尤其是希望提升编码效率、优化开发环境的初中级开发者。内容系统梳理了8款实用扩展插件覆盖代码检查、调试、实时可视化、文本排序去重、Git版本管理、代码片段、注释高亮与自动缩进等环节帮助读者按需组合出更顺手的开发工具链。资源包为1个PDF文件大小约521KB轻量易读适合随时查阅或作为插件选型参考。目前已有4753人学习下载说明其在Python开发者社区中具备一定认可度。通过阅读读者可以了解微软官方Python扩展对Pylint、Flake8、Jupyter Notebook、Pytest与Unittest的支持方式掌握Python Preview的实时代码预览与主题切换能力以及Sort Lines在数据清洗中的排序去重技巧同时还能认识Git Graph的分支可视化操作、Python Snippets的常用片段插入、Better Comments的关键词高亮规则、autoDocstring的PEP 8注释生成和Python Indent的缩进纠正思路从而快速定位适合自己工作流的插件组合。1. 为什么这 8 个 Python 扩展能让你少写一半样板代码很多人装了一堆 VS Code 扩展结果日常真正高频用的就那么两三个剩下的要么互相打架要么在后台偷偷吃内存。我见过一个数据处理的活儿光是把 JSON 转成 DataFrame 再画个图有人手动敲了四十多行样板代码而隔壁工位的老哥用对了扩展三行就出结果。差距不在技术能力在于工具链有没有配到位。这篇要聊的是 VS Code 里 8 个真正能改变 Python 开发节奏的扩展。不是那种装完就忘的装饰品而是能直接减少你敲键盘次数、提前发现低级错误、把调试从玄学变成流程的实用工具。适合两类人刚配好 VS Code 环境、面对扩展市场不知道从哪下手的新手以及用了几年但一直没系统整理过工具链、想看看有没有漏掉关键拼图的熟手。下面按「装什么、为什么装、怎么配、坑在哪」的顺序拆开讲每个扩展都给出可复现的配置步骤和参数说明。2. 代码质量与格式化从保存文件那一刻就守住底线2.1 Pylance类型提示和智能补全的底座Pylance 是微软官方维护的语言服务器基于 Pyright 做静态类型检查。它和 VS Code 内置的 Python 扩展配合工作但真正干活的是 Pylance。装完之后最直观的变化是函数参数提示变准了导入模块时补全速度明显快一截类型不匹配的地方会直接标黄线。配置上我一般会在 settings.json 里显式指定语言服务器避免和旧版 Jedi 抢活{ python.languageServer: Pylance, python.analysis.typeCheckingMode: basic, python.analysis.autoImportCompletions: true, python.analysis.inlayHints.functionReturnTypes: true }typeCheckingMode有三个档位off、basic、strict。新手建议 basicstrict 会把很多第三方库的类型缺失也报出来容易劝退。autoImportCompletions打开后敲一个没导入的类名补全列表里会直接带出 import 语句省掉手动写 import 的步骤。inlayHints.functionReturnTypes会在函数调用处显示推断出的返回类型读别人代码时特别有用。有个细节要注意Pylance 对虚拟环境的识别依赖python.defaultInterpreterPath或工作区选择。如果补全突然失效先检查右下角解释器是不是选到了系统 Python 而不是项目 venv。2.2 Black Formatter把格式化争议一次性终结Black 是「不妥协的格式化器」它不给你留配置空间代码风格统一到没有讨论余地。VS Code 里的 Black Formatter 扩展让保存即格式化成为默认行为。安装后在 settings.json 里加{ editor.formatOnSave: true, editor.defaultFormatter: ms-python.black-formatter, [python]: { editor.defaultFormatter: ms-python.black-formatter }, black-formatter.args: [--line-length, 100] }--line-length默认是 88我习惯改成 100因为现代显示器横向空间够100 字符能减少很多不必要的换行。但团队协作时这个值必须统一否则每次提交都是格式化 diff代码评审没法看。Black 和 isort 的配合也值得提一句。isort 负责 import 排序Black 负责其余格式。两个都装的话把 isort 的 profile 设为 black避免两者打架{ isort.args: [--profile, black] }2.3 Ruff比 Flake8 快一个数量级的 linterRuff 是用 Rust 写的 linter速度比 Flake8 快几十倍而且一个工具覆盖了 Flake8、isort、pyupgrade 等一堆工具的功能。VS Code 的 Ruff 扩展让它在编辑器里实时跑。配置示例{ ruff.lint.enable: true, ruff.lint.args: [--select, E,F,W,I,N,UP,B], ruff.format.args: [--line-length, 100], editor.codeActionsOnSave: { source.fixAll.ruff: explicit } }--select里的字母含义E/W 是 pycodestyle 错误和警告F 是 pyflakes 逻辑错误I 是 isort 规则N 是 pep8-namingUP 是 pyupgrade 建议B 是 bugbear 潜在 bug。source.fixAll.ruff设为 explicit 表示保存时自动修复可修复的问题但需要你手动触发一次保存动作不会在打字过程中乱改。Ruff 和 Black 可以共存但建议让 Ruff 只做 lint 不做 format格式化交给 Black职责清晰。如果想让 Ruff 全包把ruff.format.args配上然后关掉 Black Formatter 扩展即可。3. 调试与运行把 print 大法换成正经断点3.1 Python Debugger条件断点和远程调试VS Code 内置的 Python Debugger 扩展ms-python.debugpy提供了完整的调试能力。很多人只用过 F5 启动其实条件断点和日志断点才是真正省时间的功能。在 launch.json 里配置一个带参数的调试任务{ version: 0.2.0, configurations: [ { name: Python: Current File, type: debugpy, request: launch, program: ${file}, console: integratedTerminal, justMyCode: false, env: { PYTHONPATH: ${workspaceFolder}/src } } ] }justMyCode设为 false 后可以步入第三方库源码排查库内部逻辑时有用但会拖慢调试启动速度。PYTHONPATH指定源码根目录避免 import 报错。console用 integratedTerminal 而不是 internalConsole因为后者对 input() 和彩色输出支持不好。条件断点的用法在断点红点上右键输入表达式比如i 100 and data[i] is None只有条件为真时才停下。日志断点更轻量不暂停程序只在调试控制台打印消息适合循环里看变量变化又不想中断执行流的场景。3.2 Jupyter在编辑器里跑交互式代码块Jupyter 扩展让 VS Code 直接支持 .ipynb 文件和 Python 交互窗口。做数据分析时不用在浏览器和编辑器之间来回切。关键配置{ jupyter.executeInInteractiveWindow: true, jupyter.interactiveWindow.textEditor.executeSelection: true, jupyter.askForKernelRestart: false }executeInInteractiveWindow打开后选中代码按 ShiftEnter 会发送到交互窗口而不是新建 notebook。executeSelection让普通 .py 文件也能享受这个能力写脚本时可以先跑几行验证逻辑。askForKernelRestart关掉后重启内核不再弹确认框频繁重启时少点一次是一次。变量查看器是 Jupyter 扩展的隐藏福利。交互窗口右侧的 Variables 面板能直接看到当前所有变量的类型和值DataFrame 还能点开成表格。比 print(df.head()) 直观得多。4. 效率提升让重复操作变成一次点击4.1 Python Indent解决粘贴代码缩进错乱从网页或聊天记录里复制 Python 代码到 VS Code经常出现缩进全乱的情况。Python Indent 扩展专门处理这个问题它会在粘贴时自动根据上下文修正缩进层级。这个扩展几乎不需要配置装完就生效。但有一个场景要注意如果你的代码里混用了 tab 和空格Python Indent 的修正结果可能不符合预期。建议在 settings.json 里强制统一{ editor.insertSpaces: true, editor.tabSize: 4, editor.detectIndentation: false }detectIndentation关掉很重要否则 VS Code 会根据文件内容自动猜缩进方式导致同一个项目里不同文件行为不一致。4.2 Better Comments给注释加颜色分层Better Comments 让注释按类型显示不同颜色比如 TODO 是橙色、疑问是蓝色、警告是红色。Python 项目里用得多的是# TODO:和# NOTE:。配置{ better-comments.tags: [ { tag: !, color: #FF2D00, strikethrough: false }, { tag: ?, color: #3498DB, strikethrough: false }, { tag: TODO, color: #FF8C00, strikethrough: false }, { tag: NOTE, color: #2ECC71, strikethrough: false } ] }这个扩展本身不复杂但配合 Todo Tree 扩展用效果更好。Todo Tree 会在侧边栏汇总所有 TODO 注释点击直接跳转。两个一起装代码里的待办事项就不会被遗忘在角落。4.3 GitLens看清每一行代码的来龙去脉GitLens 严格来说不是 Python 专属但在 Python 项目里排查「这行代码为什么这么写」时特别有用。它会在行尾显示最后修改这行的人和提交信息鼠标悬停能看到完整 diff。对 Python 开发者来说最有价值的场景是接手一个没有文档的老项目想知道某个函数为什么加了那个奇怪的边界判断。GitLens 的 blame 视图能直接告诉你那次提交的完整上下文。配置上建议关掉行尾的 blame 显示只保留悬停查看否则代码区域太花{ gitlens.currentLine.enabled: false, gitlens.hovers.currentLine.over: line, gitlens.codeLens.enabled: false }currentLine.enabled关掉行尾装饰hovers.currentLine.over设为 line 表示悬停时显示当前行的 blame 信息。codeLens.enabled关掉函数上方的作者信息减少视觉噪音。5. 避坑与常见问题这些扩展装完不配置等于白装5.1 扩展冲突导致补全失效现象装完 Pylance 后补全反而变慢了或者某些库的补全完全出不来。原因旧版 Python 扩展自带的 Jedi 语言服务器和 Pylance 同时运行两者抢着响应补全请求。或者工作区里存在多个 Python 解释器Pylance 索引了错误的那个。解决在 settings.json 里显式设置python.languageServer: Pylance然后命令面板执行「Python: Select Interpreter」确认选中的是项目 venv。如果还不行命令面板执行「Developer: Reload Window」强制重启语言服务器。5.2 保存时格式化与 lint 自动修复互相覆盖现象保存一次代码Black 格式化完Ruff 又改回去文件内容反复横跳。原因Black 和 Ruff 的格式化规则在某些边界情况上不一致比如长字符串的换行策略。两个都开了 formatOnSave 就会打架。解决只保留一个格式化器。我一般让 Black 负责格式化Ruff 只做 lint 不做 format。在 Ruff 配置里把ruff.format.args去掉或者直接把editor.defaultFormatter明确指向 Black。5.3 Jupyter 交互窗口内核启动超时现象ShiftEnter 后交互窗口一直显示「正在启动内核」等很久后报超时错误。原因VS Code 的 Jupyter 扩展需要 ipykernel 包如果当前虚拟环境没装或者版本太旧就会卡住。另外公司网络限制可能导致内核连接握手失败。解决在项目 venv 里执行pip install ipykernel --upgrade然后重启 VS Code。如果网络受限检查是否有代理配置影响了 localhost 通信。命令面板执行「Jupyter: Restart Kernel」也能强制重连。5.4 GitLens 在大仓库里拖慢编辑器现象打开一个提交历史很长的项目VS Code 明显变卡滚动代码时掉帧。原因GitLens 默认会索引整个仓库的提交历史仓库越大索引越慢内存占用越高。解决在 settings.json 里限制 GitLens 的索引范围{ gitlens.advanced.maxListItems: 50, gitlens.advanced.repositorySearchDepth: 1, gitlens.blame.ignoreWhitespace: true }maxListItems限制列表显示条数repositorySearchDepth限制搜索深度ignoreWhitespace让 blame 忽略空白变更。如果还卡直接在不需要看 blame 的工作区禁用 GitLens。5.5 扩展装太多导致启动变慢现象VS Code 启动要十几秒打开 Python 文件后语言服务半天才就绪。原因每个扩展都在启动时抢资源尤其是那些监听文件变化、跑后台索引的扩展。Pylance、Ruff、GitLens 都是资源大户。解决按工作区禁用不需要的扩展。比如做纯数据分析时GitLens 和 Ruff 可以关掉写库代码时Jupyter 可以关掉。命令面板执行「Extensions: Disable (Workspace)」按工作区管理。另外在 settings.json 里加extensions.autoUpdate: onlyEnabledExtensions避免自动更新一堆用不上的扩展。6. 进阶技巧用 Profile 把工具链切成场景化套餐VS Code 的 Profile 功能允许你保存多套扩展和配置组合按场景一键切换。这个功能对 Python 开发者特别实用因为数据分析、Web 开发、脚本编写需要的扩展组合完全不同。创建 Profile 的方式命令面板执行「Profiles: Create Profile」然后勾选这个场景需要的扩展。我一般建三个Profile 名称包含扩展适用场景Data-SciencePylance、Jupyter、Black Formatter数据分析、notebookWeb-BackendPylance、Ruff、Python Debugger、GitLensFastAPI/Django 开发ScriptingPylance、Python Indent、Better Comments写一次性脚本、自动化任务切换 Profile 后VS Code 会重新加载对应扩展集settings.json 也可以按 Profile 覆盖。比如 Data-Science Profile 里把editor.formatOnSave关掉因为 notebook 单元格里频繁格式化反而打断思路。导出 Profile 分享给团队命令面板执行「Profiles: Export Profile」会生成一个 .code-profile 文件。团队新人导入后直接获得统一的工具链配置省掉「你用什么格式化」这种讨论。还有一个技巧是把 Profile 和 devcontainer 结合。在 .devcontainer/devcontainer.json 里指定customizations: { vscode: { extensions: [...] } }容器启动时自动装好扩展。这样本地环境怎么折腾都不影响项目的一致性。我自己的习惯是每季度清理一次扩展列表把过去三个月没主动用过的扩展禁用掉。工具链不是越多越好每个扩展都应该有明确的、高频的使用场景。装之前问自己一句这个扩展能帮我省下什么操作如果答不上来就先别装。希望帮到你。本文还有配套的精品资源点击获取