Python包管理实战：PyPI、pip与虚拟环境全解析

1. 这不是“查文档”，而是 Python 开发者每天都在做的呼吸式操作

你刚装好 Python，打开终端敲下python --version，心里松了口气——环境齐了。可下一秒，想读 Excel 文件，import pandas报错；想发个 HTTP 请求，requests模块不存在；甚至想画个折线图，matplotlib提示“ModuleNotFoundError”。这不是你的代码写错了，是你还没真正踏入 Python 生态的第一道门：PyPI（Python Package Index）。它不是某个高级工具，而是 Python 开发者每天呼吸的空气——看不见，但缺了它，项目寸步难行。我带过二十多个从零起步的转行学员，90% 的第一周卡点不在语法，而在“怎么让 pip install 成功”这件事上。有人反复重装 Python，有人手动下载 .whl 文件双击安装，还有人把整个 GitHub 仓库 clone 下来改 setup.py……这些都不是弯路，是每个 Python 新手必经的“认知校准期”。这篇指南不讲抽象概念，不列官方定义，只还原真实场景：当你在终端里输入pip install的那一刻，背后发生了什么？为什么有时快如闪电，有时卡在“Building wheel for xxx”不动？为什么pip list显示的包名和你import时用的名字不一致？为什么公司项目要求你用requirements.txt，而你自己写脚本却从来不用？我会带你从命令行开始，一层层剥开 PyPI 的真实结构、pip 的工作逻辑、虚拟环境的必要性，以及那些藏在报错信息里的关键线索。无论你是刚学完print("Hello World")的纯新手，还是会写函数但没碰过第三方库的进阶者，只要你需要调用别人写好的代码，这篇就是为你写的实操地图——没有理论铺垫，只有每一步敲什么、为什么这么敲、出错了怎么看日志、换台电脑怎么快速复现。

2. PyPI 本质不是“应用商店”，而是 Python 的“源码与二进制分发协议中枢”

2.1 理解 PyPI 的真实角色：它不托管代码，只托管“发布声明”

很多初学者以为 PyPI 是像 App Store 一样，把所有 Python 包的源码或编译后文件都存放在自己的服务器上。这是根本性误解。PyPI 实际上是一个元数据注册中心（Metadata Registry），它的核心职责只有一项：记录“谁在什么时候，发布了哪个包的哪个版本，以及这个版本的源码/二进制文件放在哪里”。你可以把它想象成图书馆的索引卡片柜——卡片上写着《深入理解计算机系统》第三版，作者是 Randal Bryant，出版年份 2015，存放位置是“三楼科技区 A-12 架第3排”，但卡片本身不包含书的内容。PyPI 的每一条记录（称为一个 “project”）包含：包名（如requests）、所有已发布版本号（如2.31.0,2.32.0）、每个版本对应的分发文件（distribution files，即.tar.gz源码包或.whl预编译轮子）、文件哈希值（用于校验完整性）、Python 兼容版本、操作系统标签等。当你执行pip install requests，pip 并不是直接从 PyPI 服务器下载代码，而是先向 PyPI 查询requests最新版本的元数据，拿到.whl文件的下载链接（比如指向https://files.pythonhosted.org/packages/py3/r/requests/requests-2.32.0-py3-none-any.whl），再由 pip 自己发起 HTTP 请求去那个 URL 下载。这个设计决定了三件事：第一，PyPI 本身可以非常轻量，它不需要存储海量二进制文件；第二，包作者可以将大文件（如含 C 扩展的包）托管在自己的 CDN 或对象存储上，只在 PyPI 注册链接；第三，国内用户访问慢，根源往往不是 PyPI 服务器本身，而是 pip 去下载.whl文件的那个外部链接被阻断或延迟——这解释了为什么换镜像源（如清华源）能显著提速：它替换的是 pip 下载分发文件的地址，而不是 PyPI 元数据查询的地址。

2.2 pip 不是“安装器”，而是“依赖解析器 + 构建引擎 + 分发文件安装器”的三合一工具

pip这个名字常被误读为 “Pip Installs Packages”，其实它最初是 “Pip Installs Python”，强调其 Python 专属属性。但它的实际能力远超“安装”二字。当你运行pip install numpy，后台发生的是一个精密协作流程：

1. 依赖解析（Dependency Resolution）：pip 首先检查numpy的pyproject.toml或setup.py中声明的依赖（如numpy依赖libcxx和特定版本的python）。它会递归地拉取这些依赖的元数据，构建一棵依赖树，并检测是否存在版本冲突（例如，你已安装pandas==1.5.0，它要求numpy>=1.21.0，而你要装的numpy==1.20.0就会触发冲突警告）。

2. 构建阶段（Build Phase）：如果找到的是源码包（.tar.gz），pip 会调用build工具（现代项目默认用build，旧项目用setuptools）在本地编译。这一步会触发pyproject.toml中[build-system]定义的构建后端（如setuptools.build_meta），并可能调用gcc编译 C 扩展。这就是为什么你常看到终端卡在 “Building wheel for xxx…” —— 它真正在你的机器上编译代码，而非单纯复制文件。

3. 安装阶段（Installation Phase）：构建成功后，pip 将生成的.whl文件（或直接解压.tar.gz）中的内容，按约定规则复制到 Python 环境的site-packages目录下。同时，它会创建.dist-info文件夹（如numpy-1.26.4.dist-info/），里面包含METADATA（包描述）、RECORD（所有安装文件的路径与哈希值）、INSTALLER（记录安装工具为 pip）等关键文件。正是这个RECORD文件，让pip uninstall numpy能精准删除所有相关文件，而不是靠猜路径。

提示：pip install --no-deps numpy会跳过步骤1，只装 numpy 本身，不装其依赖。这在调试依赖冲突时是救命命令，但生产环境慎用。

2.3 为什么必须用虚拟环境？—— 一个被严重低估的“隔离协议”

新手最常犯的错误，是直接在系统 Python（如 macOS 的/usr/bin/python3或 Windows 的C:\Python39\）里pip install。这看似省事，实则埋下三颗定时炸弹：

• 权限炸弹：系统 Python 的site-packages通常需要管理员权限才能写入。你被迫加sudo pip install（macOS/Linux）或以管理员身份运行 CMD（Windows），这违反最小权限原则，且一旦安装损坏，可能影响系统工具（如apt在 Ubuntu 依赖 Python）。

• 污染炸弹：所有项目共享同一套包。A 项目用Django==4.2，B 项目用Django==5.0，pip install会不断覆盖，导致一个项目跑起来，另一个就报错。pip list输出几十页，你根本记不清哪个包是哪个项目需要的。

• 不可复现炸弹：你在自己电脑上pip install了一堆包，项目代码传给同事，对方pip install -r requirements.txt却失败——因为他的系统 Python 版本不同，某些包不兼容；或者他之前装过其他包，产生了隐式依赖冲突。

虚拟环境（virtual environment）的本质，是创建一个独立的 Python 解释器副本 + 独立的site-packages目录。它不复制 Python 二进制文件，而是通过符号链接（Linux/macOS）或批处理脚本（Windows）指向原 Python，但所有包安装路径都被重定向到新目录（如venv/lib/python3.9/site-packages/）。这意味着：

• venv/bin/pip（macOS/Linux）或venv\Scripts\pip.exe（Windows）只管理这个环境下的包；
• import语句优先从此环境的site-packages查找；
• 删除整个venv文件夹，就彻底清空该环境，不留任何痕迹。

注意：python -m venv myenv创建的虚拟环境，其pip默认指向 PyPI 官方源。如果你在国内，首次激活环境后应立即执行pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple，否则每次pip install都会慢得怀疑人生。

3. 从零开始的完整实操链路：搜索、验证、安装、使用、管理

3.1 搜索包：别只用 Google，掌握 PyPI 官网与 pip search 的替代方案

PyPI 官网（https://pypi.org）是唯一权威来源，但它的搜索体验并不友好。新手常犯两个错误：一是直接搜功能关键词如“excel”，结果返回几百个包，无从判断哪个是主流；二是搜到包后，只看下载量，忽略关键健康指标。正确做法是“三层过滤法”：

1. 第一层：功能锚定
   不要搜“excel”，搜具体任务动词+名词组合。例如：

   • 读写 Excel 文件 → 搜read excel或write xlsx
   • 解析 HTML 表格 → 搜parse html table
   • 发送邮件 → 搜send email smtp

2. 第二层：质量筛选
   进入包详情页（如pandas），重点看三个区域：

   • 左侧边栏：“Project description” 是否清晰说明用途；“Home Page” 链接到 GitHub 或文档，点击进去看README.md是否有活跃更新（最近 commit 在 3 个月内）；“Download files” 里是否有.whl文件（表明支持预编译，安装快）。
   • 中间主区：“Latest release” 版本号是否为稳定版（非alpha/beta）；“Release history” 中近期版本发布频率（高频更新通常意味着维护积极）；“Classifiers” 中的Development Status :: 5 - Production/Stable是黄金标准。
   • 右侧边栏：“Requires:” 列出的依赖是否合理（如一个轻量工具包依赖django就可疑）；“Repository” 链接 GitHub 后，看Issues标签页是否有大量未关闭的 bug 报告。

3. 第三层：社区验证

   • 在 Stack Overflow 搜pandas read_excel site:stackoverflow.com，看最高票答案是否推荐它；
   • 在 GitHub 搜stars:>10000 language:python pandas，确认其 star 数和 fork 数；
   • 在 Real Python 或 Full Stack Python 等专业博客搜该包名，看是否有深度教程。

实操心得：我教新手时，强制要求他们对每个拟安装的包，必须打开其 GitHub 仓库，滚动到README.md底部，截图保存 “Quick Start” 示例代码。这不是形式主义——90% 的安装失败，源于你复制的示例代码版本过旧（如用pandas 0.x的pd.read_excel()语法，而当前是1.x）。截图能让你在出错时，立刻比对“官方说的应该什么样”。

3.2 安装包：从pip install到pip install -e的进阶路径

基础安装pip install package_name适用于绝大多数场景，但有四个关键变体必须掌握：

• 指定版本安装：pip install requests==2.31.0。这是生产环境的铁律。不写==，pip 默认装最新版，而新版本可能引入不兼容变更（如requests 2.32.0移除了urllib3的某些内部 API）。我在一个金融项目中吃过亏：测试环境用requests==2.28.0，上线前自动升级到2.32.0，导致自定义 SSL 证书验证逻辑失效，凌晨三点紧急回滚。

• 升级包：pip install --upgrade package_name。注意，它会连同依赖一起升级，可能引发连锁反应。更安全的做法是pip install --upgrade --no-deps package_name（只升本体），再单独升级关键依赖。

• 从 Git 仓库安装：pip install git+https://github.com/pallets/flask.git@2.3.3。当你需要尚未发布到 PyPI 的修复补丁，或想测试 PR 分支时，这是唯一方法。URL 中@2.3.3指定 commit hash 或 tag，确保可复现。

• 可编辑安装（Editable Install）：pip install -e /path/to/local/project。这是开发自己的包时的必备技能。它不会复制代码到site-packages，而是在那里创建一个指向你本地源码的链接（.pth文件）。你修改本地代码，import时立即生效，无需反复pip install。我开发一个数据分析工具包时，用-e模式迭代了两周，节省了至少 200 次重复安装时间。

提示：安装时加-v（verbose）参数，pip install -v requests，能看到 pip 每一步在做什么：查询元数据、下载文件、校验哈希、构建轮子、复制文件……当安装卡住，这是第一手排查依据。

3.3 使用包：import之后发生了什么？从__init__.py到命名空间包

import pandas as pd这行代码，背后是 Python 解释器的一场精密调度：

1. 路径查找（sys.path）：解释器按顺序扫描sys.path列表中的每个目录，寻找pandas/子目录或pandas.py文件。sys.path默认包含：当前脚本所在目录、PYTHONPATH环境变量路径、标准库路径、site-packages路径。虚拟环境激活后，site-packages会优先指向该环境的路径。

2. 模块加载（__init__.py）：找到pandas/目录后，解释器会执行其中的__init__.py文件。这个文件是包的“启动脚本”，它负责：

   • 导入子模块（如from .core.api import *）；
   • 设置包级变量（如__version__ = "1.26.4"）；
   • 执行初始化逻辑（如pandas的__init__.py会自动调用pandas._libs.skiplist.init()加载 C 扩展）。

3. 命名空间处理：对于import matplotlib.pyplot as plt，matplotlib是包名，pyplot是其子模块。Python 通过.分隔符逐级解析。如果matplotlib目录下没有pyplot.py，但有pyplot/子目录，则会尝试加载pyplot/__init__.py。这种嵌套结构让大型包（如scikit-learn）能组织成清晰的模块树。

常见问题：ModuleNotFoundError: No module named 'xxx'。90% 的原因是sys.path没包含你的包路径。解决方案：在脚本开头加import sys; sys.path.append('/path/to/your/module')；或更好的方式，将你的模块目录设为 Python path，export PYTHONPATH="/path/to/your/module:$PYTHONPATH"（Linux/macOS）。

3.4 管理包：pip list、pip show、pip freeze的精确用法

• pip list：列出当前环境中所有已安装包及其版本。但它显示的是“当前状态”，不区分哪些是直接安装的，哪些是作为依赖自动装上的。pip list --outdated可以列出所有可升级的包，但要注意，升级前务必查文档，确认新版本是否兼容。

• pip show package_name：查看单个包的详细信息。这是诊断问题的核心命令。输出包括：

  • Name:包名（注意：pip install flask后，import用flask，但pip show显示Name: Flask—— PyPI 上包名和导入名可以不同）；
  • Version:当前版本；
  • Summary:一句话简介；
  • Home-page:项目主页；
  • Author:作者；
  • License:许可证；
  • Location:安装路径（确认是否在正确的虚拟环境内）；
  • Requires:直接依赖列表；
  • Required-by:依赖此包的其他包（反向依赖，极有用！）。

• pip freeze：生成当前环境所有包的精确版本列表，格式为package==version。这是创建requirements.txt的标准方式。但注意，pip freeze会导出所有包，包括你没直接安装、只是作为依赖进来的包（如pip install django会连带装sqlparse、asgiref）。生产环境推荐用pipreqs工具（pip install pipreqs），它通过静态分析你的 Python 代码，只提取import语句中实际用到的包，生成更精简的requirements.txt。

实操心得：我部署一个 Web 服务时，习惯在requirements.txt顶部加一行注释# Generated by pipreqs on 2024-06-15，并在 Git 提交信息里写明“更新 reqs：升级 flask 从 2.2.5 到 2.3.3，修复 CVE-2024-1234”。这样半年后回溯，一眼知道为什么升级、是否经过安全审计。

4. 深度避坑指南：那些官方文档不会告诉你的 7 个致命细节

4.1 “Permission Denied” 不是权限问题，而是路径锁定

错误信息：ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied: '/usr/local/lib/python3.9/site-packages/some_package'。新手第一反应是加sudo，但这会污染系统环境。真实原因是：你的终端当前工作目录（pwd）是某个受保护的路径（如/usr/local/），而 pip 在安装过程中会尝试在当前目录创建临时文件。解决方案极其简单：cd ~切换到家目录，再执行pip install。我曾帮一个学员调试了两小时，最后发现他一直cd /opt后运行 pip，/opt目录权限为root:root，pip 无法在其下创建临时文件。

4.2 “Failed building wheel” 的三种真相与对应解法

当 pip 卡在 “Building wheel for xxx…” 时，不要盲目重试。先看日志末尾的错误行：

• 缺少编译器：error: Microsoft Visual C++ 14.0 or greater is required（Windows）或gcc: command not found（Linux/macOS）。解法：Windows 安装 Microsoft C++ Build Tools ；macOSxcode-select --install；Ubuntusudo apt-get install build-essential。

• 缺少系统库：fatal error: jpeglib.h: No such file or directory（安装Pillow时）。这是包依赖的底层 C 库未安装。解法：Ubuntusudo apt-get install libjpeg-dev libpng-dev libtiff-dev；macOSbrew install libjpeg libpng libtiff。

• 网络超时：ReadTimeoutError。pip 在下载源码包或构建依赖时超时。解法：pip install --timeout 1000 package_name延长超时；或换国内镜像源。

注意：--no-cache-dir参数能强制 pip 不用缓存，对调试构建问题很有用，但会显著拖慢重复安装速度。

4.3requirements.txt的隐藏陷阱：版本号写法决定项目生死

requirements.txt不是简单的列表，其版本约束语法直接影响可复现性：

写法	含义	风险	推荐场景
requests	安装最新版	高：下次pip install可能装3.0.0，而你的代码只兼容2.x	仅本地开发快速尝试
requests==2.31.0	精确版本	低：完全可复现	生产环境、CI/CD 流水线
requests>=2.28.0,<3.0.0	兼容范围	中：允许小版本升级，但阻止大版本跃迁	需要定期更新依赖的项目
requests~=2.28.0	兼容发布	中：等价于>=2.28.0, ==2.*	Django 等框架常用，平衡稳定性与安全性

最危险的写法是requests>2.0.0，它允许安装3.0.0，而3.x可能有破坏性变更。我在一个客户项目中，requirements.txt用了>2.0.0，CI 流水线某天突然失败，因为requests 3.0.0移除了Session.close()方法，而我们的代码显式调用了它。

4.4 虚拟环境激活失败的 3 个冷门原因

source venv/bin/activate（macOS/Linux）或venv\Scripts\activate.bat（Windows）执行后，提示符没变，which python仍指向系统 Python。常见原因：

• Shell 类型不匹配：你在zsh中创建了虚拟环境，却在bash中尝试激活。检查当前 shell：echo $SHELL。解法：zsh用户用source venv/bin/activate；bash用户确保用bash启动终端。

• PowerShell 权限策略：Windows PowerShell 默认禁止执行脚本。错误信息：File ...activate.ps1 cannot be loaded because running scripts is disabled...。解法：以管理员身份打开 PowerShell，执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser。

• 路径含空格或中文：venv目录路径如/Users/张三/my project/venv，activate脚本会因空格解析失败。解法：路径中避免空格和中文，用my_project替代my project。

4.5pip install后import失败的终极排查清单

当pip install package成功，但import package报错，按此顺序排查：

1. 确认 Python 解释器：which python和python -c "import sys; print(sys.executable)"是否指向虚拟环境？如果不是，你装到了错误的环境。

2. 确认包名与导入名：pip show package_name中的Name:字段是否等于你import时用的名字？例如pip install python-dotenv，但import用dotenv，正确写法是from dotenv import load_dotenv。

3. 检查__init__.py：进入site-packages/package_name/目录，确认存在__init__.py文件。若缺失，包无法被识别为 Python 包。

4. 查看sys.path：python -c "import sys; print('\n'.join(sys.path))"，确认site-packages路径在列表中，且顺序靠前。

5. 检查 C 扩展依赖：某些包（如numpy）的.whl文件包含平台特定的二进制，若你的系统架构（如 Apple Silicon M1）与.whl标签不匹配，会静默失败。此时需pip install --only-binary=all package_name强制用二进制，或--no-binary=all强制源码编译。

4.6 国内用户必知的镜像源配置细节

清华源（https://pypi.tuna.tsinghua.edu.cn/simple）是最常用的，但有两点易被忽略：

• 全局配置 vs 项目配置：pip config set global.index-url是全局的，影响所有虚拟环境。更推荐在项目根目录创建.pip.conf（Linux/macOS）或pip.ini（Windows）文件，内容为：

  [global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn

  这样每个项目可独立配置，且 Git 忽略该文件，不污染协作。

• 镜像源不是万能的：部分包（尤其是大文件如torch）的.whl文件可能未同步到镜像源，或同步延迟。此时pip install会回退到官方源，导致速度骤降。解法：pip install -i https://pypi.tuna.tsinghua.edu.cn/simple --trusted-host pypi.tuna.tsinghua.edu.cn torch，强制本次安装用镜像源。

4.7pip uninstall的“卸载不干净”现象与清理方案

pip uninstall package通常能删除site-packages下的文件，但以下残留物需手动处理：

• .dist-info文件夹：pip uninstall会删掉它，但若中断执行，可能残留。手动删除：rm -rf site-packages/package_name-*.dist-info。

• 可编辑安装的.pth文件：pip install -e会在site-packages下创建package_name.egg-link文件，指向你的源码路径。pip uninstall会删它，但若失败，需手动删除该文件。

• 用户安装的包：pip install --user package会装到~/.local/lib/python3.x/site-packages/，pip uninstall默认不处理这里。需加--user参数：pip uninstall --user package。

我的清理习惯：在项目结束时，先pip list --outdated检查是否有待升级包；再pip freeze > requirements_backup.txt备份；最后pip uninstall -r requirements_backup.txt -y彻底清空环境。虽然多花一分钟，但换来的是干净的起点。

5. 从入门到精通：构建可复现、可协作、可审计的包管理工作流

5.1 项目初始化标准动作：5 步建立黄金基线

每次新建 Python 项目，我严格执行以下流程，已坚持 8 年：

1. 创建项目目录并初始化 Git：mkdir my_project && cd my_project && git init。项目名用snake_case，避免空格和特殊字符。

2. 创建虚拟环境：python -m venv venv。环境名固定为venv，这是行业共识，IDE（如 VS Code、PyCharm）能自动识别。

3. 激活并升级 pip：source venv/bin/activate（macOS/Linux）或venv\Scripts\activate.bat（Windows），然后pip install --upgrade pip。新环境的 pip 可能是旧版，升级可避免后续安装问题。

4. 配置镜像源：pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple。国内开发者这步不能省。

5. 生成初始requirements.txt：pip freeze > requirements.txt。此时文件只含pip、setuptools、wheel三个基础包，作为干净起点。

注意：.gitignore文件必须包含venv/、__pycache__/、*.pyc、.DS_Store。我用 gitignore.io 生成 Python 专用模板，粘贴进去。

5.2 开发中动态更新requirements.txt的两种可靠模式

• 模式一：pipreqs静态分析（推荐）
  安装：pip install pipreqs。
  生成：pipreqs ./ --encoding=utf8 --force。
  --encoding=utf8解决中文路径乱码；--force覆盖已有文件。
  优势：只提取代码中import的包，不含冗余依赖，requirements.txt平均比pip freeze小 40%。

• 模式二：pip-compile锁定全依赖树（企业级）
  安装：pip install pip-tools。
  创建requirements.in：手动编写你直接依赖的包，如：

  django>=4.2.0 requests>=2.28.0

  生成锁定文件：pip-compile requirements.in --output-file=requirements.txt。
  pip-compile会递归解析所有依赖，生成带精确版本号的requirements.txt，并支持--upgrade更新。这是 Django 官方推荐的工作流。

5.3 CI/CD 流水线中的包管理：如何让测试永远通过

在 GitHub Actions 或 GitLab CI 中，pip install -r requirements.txt经常失败，根源在于缓存和环境差异。我的稳定配置：

# .github/workflows/test.yml name: Test on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.9' - name: Install dependencies run: | python -m venv venv source venv/bin/activate pip install --upgrade pip # 关键：指定镜像源，避免超时 pip install -i https://pypi.tuna.tsinghua.edu.cn/simple --trusted-host pypi.tuna.tsinghua.edu.cn -r requirements.txt - name: Run tests run: | source venv/bin/activate pytest tests/

核心要点：每次流水线都新建虚拟环境，不依赖缓存；pip install时显式指定镜像源；pytest前再次source激活，确保路径正确。

5.4 审计与安全：用pip-audit主动发现漏洞

pip install pip-audit后，运行pip-audit，它会扫描requirements.txt中所有包，连接 OSV Database （Google 维护的开源漏洞数据库），报告已知安全漏洞。输出示例：

Found 2 known vulnerabilities in 1 package: > requests<=2.31.0 * GHSA-jqcx-ccjw-5pcq: Requests contains a denial of service vulnerability... * GHSA-q2q7-5pp4-cvrq: Requests contains a server-side request forgery...

解法：pip-audit --fix会自动升级到修复版本。我将pip-audit加入 pre-commit 钩子，每次提交前自动扫描，把安全左移。

最后分享一个小技巧：在团队协作中，我要求所有成员在pip install后，立即运行pip show package_name | grep "Version\|Location"，截图发到群聊。这看似繁琐，但能 100% 避免“在我电脑上好好的”这类扯皮。因为Location字段会暴露是否在正确环境，Version字段确认版本一致——这是最朴素，也最有效的信任建立方式。