PyCharm性能调优实战：从卡顿到丝滑的三层配置体系

1. 这不是“又一个IDE教程”，而是PyCharm从卡顿到丝滑的实战通关手册

你点开这个标题，大概率不是想学“怎么新建一个Python文件”——那种基础操作，PyCharm官网文档写得比谁都清楚。真正让你停下来、想点进来的，是这几种真实场景：写完一段代码按Ctrl+Enter没反应，等三秒才弹出运行窗口；调试时断点明明打了，却直接跳过；项目一加到Django或FastAPI，智能提示突然变哑巴，连request.后面该跟啥都猜不出来；更别提每次升级后插件全崩、解释器路径错乱、venv莫名其妙失效……这些不是Bug，是PyCharm在用它的方式告诉你：“你还没真正‘拥有’我。”

Mastering PyCharm，关键词就在这“Mastering”上——它不指代“会用”，而是指对底层机制有判断力、对配置偏差有诊断力、对性能瓶颈有干预力。我带过三十多个Python开发团队，发现87%的所谓“PyCharm不好用”，根源从来不是软件本身，而是开发者把IDE当成记事本在用：不设解释器、不配编码、不调索引、不关冗余服务。这篇内容就是为那些已经写过至少2万行Python、被IDE拖慢过节奏、想把开发效率从“能跑”拉到“快如呼吸”的人写的。它不讲菜单在哪，只拆解“为什么这里必须选System Interpreter而不是Conda”、“为什么Project SDK选错会导致整个类型推导失效”、“为什么你关掉的那项后台索引，恰恰是代码跳转快3倍的关键”。接下来的内容，每一处配置都有实测数据支撑，每一个建议都来自线上项目踩坑后的回滚记录。

2. 项目整体设计逻辑：为什么PyCharm的“高级感”全藏在配置层？

2.1 不是功能堆砌，而是三层能力模型的协同

很多教程把PyCharm功能列成一张大表：调试、测试、Git、数据库……这就像教人开车只讲“方向盘、油门、刹车”，却不说“什么时候该松油门降档入弯”。PyCharm真正的 mastery，建立在三个相互咬合的层次上：

• 第一层：环境层（Environment Layer）
  这是90%新手忽略的根基。它不单指“Python解释器路径”，而是包含解释器类型（CPython/PyPy）、版本精确性（3.11.2 vs 3.11）、包管理方式（pip/conda/poetry）、虚拟环境隔离粒度（per-project vs per-module）以及编码协议（UTF-8 with BOM？LF/CRLF？）。举个典型反例：你在Windows上用conda创建了py311环境，但PyCharm里Project Interpreter却指向了系统Python 3.9——此时所有依赖安装都发生在3.9环境，而代码却在3.11下运行，类型检查失效、第三方库import报红、甚至typing.Literal这种3.11新增特性直接不识别。这不是PyCharm的错，是你没让环境层对齐。

• 第二层：索引与分析层（Indexing & Analysis Layer）
  PyCharm的智能提示、跳转、重构之所以快，靠的不是实时解析，而是后台构建的符号索引树（Symbol Index Tree）和控制流图（CFG）缓存。这个过程默认开启，但有两个致命陷阱：一是索引范围过大（比如把node_modules或.git目录纳入），导致内存爆满、CPU持续100%；二是分析精度不足（如关闭“Unresolved reference inspection”），结果是from utils import helper明明存在，却标红提示“Cannot find reference 'helper'”。我实测过：一个5万行的Flask项目，关闭__pycache__和dist目录索引后，首次索引时间从4分12秒降到1分07秒，后续编辑响应延迟下降63%。

• 第三层：交互层（Interaction Layer）
  这才是用户每天接触的界面，但它高度依赖前两层。比如“Find Usages”功能，表面是右键菜单，底层调用的是索引层的符号反向映射；再比如“Refactor → Rename”，看似简单，实则需同步更新：源码中的变量名、字符串里的硬编码、测试文件中的断言、甚至文档字符串里的示例代码——这背后是分析层对AST（抽象语法树）的深度遍历。如果环境层的解释器不支持当前Python语法（如用了3.12的match语句但解释器设为3.10），分析层就无法正确构建AST，交互层的所有重构功能都会降级为纯文本替换，埋下严重隐患。

这三层不是并列关系，而是环境层是地基，索引层是承重墙，交互层是门窗。地基不稳，墙再厚也裂缝；墙没建好，门窗装得再漂亮也漏风。Mastering PyCharm的第一步，永远是先校准环境层，再优化索引层，最后才谈交互层的快捷键技巧。

2.2 方案选型背后的硬逻辑：为什么不用VS Code + Python插件？

常有人问：“VS Code轻量、插件多、免费，PyCharm专业版要钱，为啥还要主推PyCharm？”这不是立场问题，是工程约束下的理性选择。我把对比维度拉到生产环境最敏感的五个硬指标上：

结论很清晰：VS Code适合原型验证、脚本编写、轻量Web开发；PyCharm Professional是中大型Python应用的生产力基础设施。它贵在“省心”——省去你花三天配置Pylance、Jinja2、Black、Ruff、Docker插件并调通兼容性的成本；贵在“确定性”——当线上服务凌晨报警，你能在30秒内定位到utils/cache.py第87行的redis.Redis()连接池泄漏，而不是和插件日志搏斗。这笔钱，买的是时间确定性，不是软件许可证。

2.3 架构设计避坑指南：新手最容易栽的三个“默认陷阱”

PyCharm的“开箱即用”背后，藏着三个精心设计的默认值，它们对小项目友好，却会在中大型项目中成为性能黑洞。我称之为“甜蜜陷阱”。

• 陷阱一：默认启用“Power Save Mode”（节能模式）的隐性开关
  表面看，这是个手动开启的选项（File → Power Save Mode）。但实际触发条件是：当PyCharm检测到系统内存低于2GB可用时，会自动激活节能模式，并静默关闭所有后台索引与代码分析。后果是：代码跳转失效、类型提示消失、实时错误检查停摆。很多人以为是IDE坏了，其实是内存被Chrome占光了。解决方案不是关Chrome，而是在Help → Edit Custom Properties中添加idea.max.intellisense.filesize=5000（单位KB），强制提升大文件分析阈值，避免因内存波动导致功能降级。

• 陷阱二：“Project Encoding”与“Default encoding for properties files”分离设置
  新建项目时，PyCharm默认将Project Encoding设为UTF-8，但Properties文件（如application.properties）的默认编码却是ISO-8859-1。当你在Spring Boot项目里写server.port=8080一切正常，但一旦加入中文注释# 数据库连接地址，保存后文件实际以ISO编码写入，Java读取时就会乱码。这不是Bug，是Java Properties规范强制要求。解决方法：进入Settings → Editor → File Encodings，将**“Default encoding for properties files”明确改为UTF-8，并勾选“Transparent native-to-ascii conversion”**——这会自动将中文转为\u4f60\u597d格式，确保Java运行时正确解码。

• 陷阱三：“Excluded Folders”未主动配置，导致索引污染
  默认情况下，PyCharm只排除.idea和__pycache__。但现代Python项目必然包含venv/、.git/、dist/、build/、htmlcov/（pytest-cov输出）等目录。这些目录下可能有数万个小文件（如.pyc、.js、.html），PyCharm会尝试为它们构建索引，消耗大量I/O和内存。我见过最极端案例：一个venv/lib/python3.11/site-packages/目录被索引，导致PyCharm内存占用飙升至4.2GB，编辑延迟超2秒。正确做法：右键点击这些目录 → Mark Directory as → Excluded。注意，Excluded后该目录在项目视图中变灰，且不会出现在任何搜索、跳转、重构范围内——这才是真正的“隔离”。

这三个陷阱，没有一个是PyCharm的缺陷，而是它对不同规模项目的适应性设计。Mastering的第一课，就是学会看穿“默认”的意图，并在自己的项目上下文中主动覆盖它。

3. 核心细节解析与实操要点：从配置到调优的颗粒度拆解

3.1 环境层实操：解释器、虚拟环境与编码的三位一体校准

PyCharm的环境配置，核心就三件事：选对解释器、锁死依赖、统一编码。少做一步，后续所有智能功能都可能失准。

第一步：解释器选择——为什么System Interpreter是毒药，而Poetry是解药？
在Settings → Project → Python Interpreter界面，你会看到几个选项：System Interpreter、Virtualenv Environment、Conda Environment、Pipenv Environment、Poetry Environment。新手常选“System Interpreter”，因为它“最简单”。但这是最大误区。System Interpreter意味着：

• 所有pip install操作都作用于全局Python环境；
• 项目A依赖requests==2.28.1，项目B依赖requests==2.31.0，冲突无法共存；
• 升级系统Python（如macOS自动更新）可能导致所有项目崩溃。

正确姿势是为每个项目创建独立虚拟环境。但选哪种？我们实测对比了三种主流方案：

结论：新项目无脑选Poetry。在PyCharm中配置步骤极简：

1. 确保系统已安装Poetry（终端执行poetry --version验证）；
2. 在项目根目录，PyCharm会自动检测pyproject.toml，弹出“Add Poetry Environment”提示，点击即可；
3. 若未弹出，手动进入Settings → Project → Python Interpreter → Add → Poetry Environment → 选择项目根目录。
   此时，PyCharm的Interpreter列表会显示Poetry (myproject)，所有依赖从pyproject.toml实时同步，poetry add django后，IDE立即识别新模块。

第二步：编码统一——UTF-8的三重保险
编码混乱是Python开发者的隐形杀手。PyCharm提供三重防护，缺一不可：

• Project Encoding（项目编码）：Settings → Editor → File Encodings → “Project Encoding”设为UTF-8。这是所有新文件的默认编码。
• Default encoding for properties files（Properties文件编码）：同上界面，将此项也设为UTF-8，并勾选“Transparent native-to-ascii conversion”。这是为Java生态项目（如Spring Boot）准备的。
• Console Encoding（控制台编码）：Settings → Editor → Color Scheme → Console Font → 勾选“Use color scheme font”并确认字体支持UTF-8（推荐JetBrains Mono）。更重要的是，在Settings → Tools → Python Console → “Default encoding”设为UTF-8。否则，你在Python Console里打印中文，会看到b'\xe4\xbd\xa0\xe5\xa5\xbd'这样的字节串。

提示：完成上述设置后，务必重启PyCharm。PyCharm的编码设置是进程级的，热更新不生效。重启后，新建.py文件顶部会自动添加# -*- coding: utf-8 -*-声明（可通过Settings → Editor → File and Code Templates → Python Script模板修改）。

第三步：解释器路径的“绝对可靠”验证法
很多人配置完解释器，以为万事大吉。但PyCharm的“解释器路径”可能是个软链接（如macOS的/usr/bin/python3实际指向/opt/homebrew/bin/python3.11），一旦Homebrew升级，链接断裂，PyCharm就找不到解释器。终极验证法：在PyCharm中打开Terminal（Alt+F12），执行：

which python python -c "import sys; print(sys.executable)"

两个命令输出的路径必须完全一致，且该路径下存在python可执行文件。如果不一致，说明PyCharm指向的是软链接，应手动修改Interpreter路径为sys.executable输出的绝对路径（如/opt/homebrew/Cellar/python@3.11/3.11.8/bin/python3.11）。这是保证环境长期稳定的基石。

3.2 索引与分析层实操：让PyCharm的“大脑”只处理关键信息

PyCharm的索引不是黑箱，它是可观察、可干预、可定制的。理解它的运作逻辑，是提速的核心。

索引原理简述：
当你打开项目，PyCharm会启动Indexing后台进程，它做三件事：

1. 文件扫描（File Scanning）：遍历所有非Excluded目录，识别.py、.pyi、.pyx等Python相关文件；
2. 符号提取（Symbol Extraction）：对每个Python文件，解析AST，提取类、函数、变量、导入语句等符号，并记录其位置（文件+行号）；
3. 索引构建（Index Building）：将符号与位置映射存入本地数据库（位于<project>/.idea/index/），供后续跳转、查找、重构调用。

这个过程耗时，但索引一旦建成，90%的智能功能都从中读取，而非实时解析。所以，优化索引 = 优化所有后续交互。

实操一：精准控制索引范围——Excluded目录的科学清单
哪些目录必须Excluded？我们基于100+项目统计，给出黄金清单：

• venv/,.venv/,env/,ENV/（所有虚拟环境目录）
• dist/,build/,htmlcov/,.pytest_cache/（构建与测试产物）
• .git/,.hg/,.svn/（版本库元数据）
• node_modules/（即使Python项目含前端，也不应索引JS）
• __pycache__/,*.pyc,*.pyo（编译缓存）
• logs/,tmp/,cache/（运行时临时目录）

注意：Excluded不是删除！文件依然可见、可编辑、可提交Git。它只是告诉PyCharm：“别为这些文件建索引，也别对它们做语法检查。” 操作路径：右键目录 → Mark Directory as → Excluded。PyCharm会立即将其变为灰色，并在项目视图左下角显示“Excluded: X items”。

实操二：索引性能调优——JVM参数的实战配置
PyCharm本质是Java应用，其性能受JVM内存限制。默认配置（-Xms128m -Xmx2048m）对大型项目捉襟见肘。调整方法：

1. 关闭PyCharm；
2. 找到配置文件：
   • Windows:<PyCharm>\bin\pycharm64.exe.vmoptions
   • macOS:/Applications/PyCharm.app/Contents/bin/pycharm.vmoptions
   • Linux:<PyCharm>/bin/pycharm64.vmoptions
3. 修改关键参数（以16GB内存机器为例）：

   -Xms2g -Xmx6g -XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50

   解释：-Xmx6g将最大堆内存设为6GB，避免频繁GC；-XX:+UseG1GC启用G1垃圾收集器，更适合大内存场景；-XX:SoftRefLRUPolicyMSPerMB=50降低软引用回收频率，防止索引缓存被过早清理。
   效果实测：一个含200个Django App的项目，索引时间从3分48秒降至1分22秒，内存峰值稳定在5.1GB，无GC卡顿。

实操三：分析精度强化——关键Inspection的必开清单
PyCharm内置200+代码检查（Inspection），但默认只开启基础项。以下5项是专业开发的“生命线”，必须开启：

• Unresolved reference：检测import和变量使用是否有效。关闭它等于放弃所有跳转和补全。
• Shadowing names from outer scopes：警告for i in range(10):中的i覆盖了外层函数参数i，这是常见bug源。
• Unused local variable：标记未使用的局部变量，减少认知负担。
• PEP 8 naming convention：强制snake_case函数名、PascalCase类名，保持团队风格统一。
• Type checker：启用mypy或pyright（需额外配置），对def func(x: int) -> str:这类类型注解进行静态检查。

开启路径：Settings → Editor → Inspections → Python → 勾选对应项。建议将Severity设为Warning（黄色波浪线），而非Error（红色），避免过度干扰。

3.3 交互层实操：超越快捷键的“肌肉记忆”构建

快捷键是PyCharm的表皮，真正的交互 mastery，在于理解每个操作背后的意图，并形成条件反射式的操作链。

高频操作链一：从报错到修复的“三秒闭环”
场景：编辑时出现红色波浪线，提示NameError: name 'user_id' is not defined。

• Step 1（0.5秒）：将光标置于user_id，按Alt+Enter（Quick Fix）。PyCharm会智能列出修复选项：Create variable 'user_id'、Import 'user_id' from module、Change to 'user_id_'（如果存在相似变量）。
• Step 2（0.5秒）：用方向键选择Create variable 'user_id'，回车。PyCharm自动在作用域顶部插入user_id = None。
• Step 3（1秒）：光标仍在None处，按Ctrl+Shift+Space（Smart Type Completion），PyCharm根据上下文（如前面有get_user(）推测应为int，自动补全为user_id: int = None。
• Step 4（0.5秒）：按Ctrl+Shift+Enter（Complete Current Statement），自动补全冒号后的换行与缩进。

这套组合拳，将传统“查文档→写变量→加类型→调格式”的15秒操作，压缩到3秒内。关键是Alt+Enter的Quick Fix是PyCharm最强大的AI，它比任何Copilot都懂你的代码上下文。

高频操作链二：重构不是重写，而是“安全手术”
场景：一个utils.py中有函数def get_user_data(user_id): ...，现在需要拆分为get_user_profile(user_id)和get_user_settings(user_id)。

• Step 1：光标置于get_user_data函数名，按Ctrl+T（Refactor This）→Extract Method。
• Step 2：在弹窗中，PyCharm已自动选中函数体，输入新函数名get_user_profile，勾选Make static（若无self参数）。
• Step 3：点击OK，PyCharm在utils.py底部创建新函数，并将原函数中对应逻辑替换为return get_user_profile(user_id)。
• Step 4（关键）：按Ctrl+Shift+Alt+T（Refactor This → Safe Delete），选中原get_user_data函数，PyCharm会扫描整个项目，确认无其他调用后，才允许删除。

注意：Safe Delete是PyCharm重构的底线保障。它比Find Usages更严格，会检查字符串中的硬编码、文档字符串、测试断言等所有潜在引用。永远不要用Delete键直接删函数！

高频操作链三：调试不是“看变量”，而是“问问题”
PyCharm调试器的强大，在于它让你像审讯一样追问代码：

• 问“它从哪来？”：在变量上按Ctrl+Shift+I（Quick Definition），直接跳转到该变量的定义处（如user_id来自request.args.get('id')）。
• 问“它去哪了？”：在变量上按Ctrl+Alt+H（Find Usages），列出所有使用该变量的地方，支持按“Read”、“Write”、“Declaration”过滤。
• 问“它为什么是这个值？”：在断点处，打开Evaluate Expression（Alt+F8），输入type(user_id), user_id.__class__.__mro__，瞬间看清类型继承链。

这些操作，不是为了炫技，而是把调试从“随机猜测”变成“结构化侦查”。每一次Ctrl+Shift+I，都在加固你对代码流向的理解。

4. 实操过程与核心环节实现：一个Django项目的全流程配置实录

4.1 项目初始化：从django-admin startproject到PyCharm零配置接入

我们以一个真实的Django项目myshop为例，全程记录PyCharm配置步骤。这不是理想化的演示，而是包含所有坑点的真实流水账。

Step 0：环境准备（前置硬要求）

• 系统已安装Python 3.11.8（python --version验证）
• 已安装Poetry（poetry --version验证）
• 已安装Django 4.2.9（pip install django==4.2.9，用于startproject）

Step 1：终端创建项目骨架

# 创建项目目录 mkdir myshop && cd myshop # 使用Django官方命令初始化 django-admin startproject config . # 创建apps目录 mkdir apps # 创建核心app python manage.py startapp products apps/products python manage.py startapp users apps/users

此时目录结构为：

myshop/ ├── config/ # settings.py, urls.py所在 ├── apps/ │ ├── products/ │ └── users/ ├── manage.py └── pyproject.toml # 尚未创建

Step 2：Poetry初始化与依赖声明

# 初始化Poetry poetry init # 交互式填写：项目名myshop，Python版本^3.11，添加Django依赖 poetry add django==4.2.9 poetry add psycopg2-binary==2.9.7 # 数据库驱动 poetry add pytest-django==4.5.2 # 测试框架 # 生成pyproject.toml，内容关键段： [tool.poetry.dependencies] python = "^3.11" django = "4.2.9" psycopg2-binary = "2.9.7" pytest-django = "4.5.2"

注意：poetry init会询问是否创建pyproject.toml，务必选Yes。PyCharm的Poetry集成依赖此文件。

Step 3：PyCharm首次打开与自动识别

• 启动PyCharm → Open → 选择myshop目录。
• PyCharm检测到pyproject.toml，弹出“Add Poetry Environment”对话框，点击OK。
• 关键观察：右下角状态栏显示“Indexing...”，同时Python Interpreter设置中已出现Poetry (myshop)，且django、psycopg2等包已列出。
• 验证：打开config/settings.py，在INSTALLED_APPS中输入'apps.products'，PyCharm应立即识别apps.products为有效App，无红色波浪线。若出现，说明Poetry环境未正确加载，需手动Rebuild（File → Reload project from Disk）。

Step 4：Django专属配置激活
PyCharm Professional对Django有深度支持，但需手动开启：

• Settings → Languages & Frameworks → Python Frameworks → Django → 勾选“Enable Django Support”。
• 在“Django project root”中，浏览并选择myshop目录（即manage.py所在目录）。
• 在“Settings”中，选择config/settings.py。
• 在“Manage script”中，选择manage.py。
• 效果：此时，urls.py中的path('products/', include('apps.products.urls'))，include函数能跳转到apps/products/urls.py；models.py中的class Product(models.Model):，models.Model能跳转到Django源码。

Step 5：运行配置（Run Configuration）一键生成

• 点击右上角Add Configuration→+→Django Server。
• Name:Run myshop
• Host:127.0.0.1
• Port:8000
• Python interpreter: 自动选择Poetry环境
• Environment variables: 添加DJANGO_SETTINGS_MODULE=config.settings
• Working directory:$ProjectFileDir$
• 关键点：勾选“Run browser”并设置URL为http://127.0.0.1:8000/admin/，这样每次Run都自动打开Admin登录页。
• 点击OK保存。

此时，点击绿色三角形▶️，PyCharm会自动执行python manage.py runserver 127.0.0.1:8000，并在浏览器打开Admin页面。整个过程无需手动敲命令。

4.2 调试配置：从“断点不生效”到“变量全掌控”的七步排查

调试是PyCharm的皇冠功能，但新手常卡在“断点灰了”、“Variables窗口空空如也”。以下是我在客户现场手把手解决的标准化流程。

Step 1：确认调试器已挂载
启动Debug（Shift+F9）后，观察PyCharm右上角：

• 应显示“Debug”工具栏（含Stop、Resume、Step Over等按钮）；
• 左下角Services窗口应显示“Django Server: Running”；
• 如果只有“Running”没有“Debug”，说明PyCharm未进入调试模式，而是普通运行。

Step 2：检查断点状态
在views.py中设置断点（行号左侧点击），断点图标应为实心红点。若为空心红点，表示断点未启用；若为红点带斜杠，表示断点被禁用。鼠标悬停断点，查看提示：

• “Breakpoint disabled” → 右键断点 → Enable；
• “No executable code found” → 说明该行无Python字节码，常见于：
  • 代码在if False:块内；
  • 该文件未被Django加载（如apps/products/views.py未在urls.py中引入）；
  • 解释器路径错误，PyCharm在调试时加载了错误的.pyc文件。

Step 3：验证Django Debug模式
Django的DEBUG=True是调试前提。检查config/settings.py：

DEBUG = True # 必须为True ALLOWED_HOSTS = ['127.0.0.1', 'localhost'] # 必须包含请求Host

若DEBUG=False，Django会返回500错误页面，而非PyCharm调试器。

Step 4：检查Python Path
调试时，PyCharm需将项目根目录加入sys.path，否则import apps.products.views会失败。在Debug配置中：

• Environment variables→ 添加PYTHONPATH=$ProjectFileDir$；
• 或在config/settings.py顶部添加：

  import sys import os sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..'))

Step 5：Variables窗口数据源确认
Debug时，Variables窗口默认显示“Frames”下的局部变量。若为空：

• 点击Variables窗口右上角齿轮图标 → 勾选“Show values inline”；
• 在“Frames”列表中，确保选中的是当前执行的栈帧（如views.py:25），而非<module>；
• 若仍为空，按F8（Step Over）执行一行，变量值会动态填充。

Step 6：Watch表达式实战
Variables窗口只能看当前作用域。要监控跨函数变量，用Watch：

• 在Debug工具栏，点击+→Add Watch；
• 输入request.user.is_authenticated，回车；
• 此时Watch窗口会实时显示该表达式的值，即使request不在当前栈帧中。

Step 7：异常断点（Exception Breakpoints）
捕获未处理异常：

• View → Tool Windows → Breakpoints（或Ctrl+Shift+F8）；
• 点击+→Python Exception Breakpoints；
• 勾选BaseException（捕获所有异常）或ValueError（捕获特定异常）；
• 当代码抛出ValueError("Invalid price")时，PyCharm会立即中断，并高亮抛出位置。

这套流程，覆盖了95%的调试失败场景。记住：调试不是玄学，是路径、环境、配置的精确匹配。

4.3 性能调优实录：从“卡成PPT”到“丝滑如德芙”的量化改进

我们以一个真实客户的Django项目（12万行代码，47个App，PostgreSQL+Redis）为例，记录调优全过程与数据。

初始状态（调优前）：

• 启动PyCharm：2分18秒（索引中CPU 100%，内存占用3.8GB）
• 编辑响应：输入字符后平均延迟1.2秒
• 跳转到定义（Ctrl+Click）：平均耗时2.7秒
• Find Usages（Ctrl+Alt+F7）：搜索User类，耗时8.4秒，返回127处

调优步骤与效果：

Step 1：Excluded目录清理（耗时2分钟）

• Excludedvenv/,dist/, `build/