Linux下Qt Creator安装与Kit配置深度指南-平芜编程栈

1. 项目概述：为什么一个“安装 Qt Creator”会值得花一整篇来写？

Qt Creator 不是那种点几下就能装好的普通图形软件。它表面看是个 IDE，背后却牵扯到 Linux 系统底层的依赖管理、C++ 工具链协同、GUI 库版本兼容、甚至用户权限模型的微妙博弈。我第一次在某高校嵌入式实验室的 Ubuntu 22.04 服务器上给学生装 Qt Creator，本以为十分钟搞定，结果卡在libgl1-mesa-glx 与 libegl1-mesa 冲突上整整两小时——系统提示“无法满足依赖”，但 apt list 显示两个包明明都已安装。后来才发现，问题出在 Qt Creator 官方二进制包自带的私有 Qt 库试图加载系统级 OpenGL 驱动时，ABI 版本号对不上。这不是 bug，是设计使然：Qt 官方包为保证跨发行版兼容性，刻意剥离了对系统 Qt 的强绑定，转而静态链接部分核心模块，但又没完全隔离图形后端调用路径。

这恰恰是 Linux 下开发工具安装最典型的“表层平静、水下湍流”现象。你搜“Linux 安装 Qt Creator”，前五条结果几乎全是“sudo apt install qtcreator”——这句话本身没错，但它只适用于一种场景：你只要一个能写 .cpp 文件、带基础语法高亮的编辑器，且不打算编译任何 Qt 项目。一旦你要点击“运行”按钮让程序真正跑起来，就会立刻撞上三道墙：Qt 版本缺失、qmake 或 cmake 工具链未注册、桌面环境缺少 X11/Wayland 兼容配置。更现实的是，很多团队用的是 Qt 5.15.2 LTS 或 Qt 6.5.x，而 Ubuntu 22.04 自带的 qtbase5-dev 是 5.15.3，Debian 12 自带的是 5.15.8——小版本差一点，QML 模块的信号槽连接行为就可能不同，调试时莫名其妙断点失效。

所以这篇不是教你怎么“点下一步”，而是带你亲手拆开 Qt Creator 的安装包，看清它和你的系统之间到底在交换什么、妥协什么、隐藏了哪些开关。你会明白：为什么官方离线安装包比 apt 安装多出 372MB；为什么在 CentOS Stream 9 上必须手动 symlinks /usr/lib64/qt5/bin/qmake；为什么 Wayland 会默认禁用 Qt Quick Controls 2 的某些动画效果。这些不是故障，是 Linux 开源生态里“自由选择权”的物理体现——你选了发行版，就等于选了它的 ABI 策略；你选了 Qt 版本，就等于签下了它的构建契约。接下来的内容，就是帮你把这份契约里的每一条小字都读清楚。

2. 安装方案深度对比：三种路径的本质差异与适用边界

2.1 方案一：系统包管理器安装（apt/yum/dnf）

这是最“安全”的方式，也是最容易踩坑的起点。以 Ubuntu/Debian 为例：

sudo apt update && sudo apt install qtcreator qt5-default

这条命令实际做了三件事：

从universe仓库下载qtcreator包（当前 Ubuntu 22.04 版本为 4.15.2+dfsg-3ubuntu1）
同时安装qt5-default，它本质是一个元包（metapackage），作用是创建/usr/lib/x86_64-linux-gnu/qt5/bin/qmake的符号链接，指向/usr/lib/x86_64-linux-gnu/qt5/bin/qmake（即系统 Qt5 的主 qmake）
自动解决libqt5core5a,libqt5gui5,libqt5widgets5等运行时依赖

提示：qt5-default并不安装 Qt 源码或文档，它只确保构建工具链可被 Qt Creator 识别。如果你后续要调试 Qt 源码，需要额外安装qtbase5-dev和qtbase5-doc-html。

优势在于：零依赖冲突风险、自动集成系统主题（GTK+/Adwaita）、更新由系统统一管理。但致命缺陷是版本锁定——Ubuntu 22.04 的 qtcreator 无法原生支持 Qt 6.5，因为其内部插件架构仍基于 Qt5 的 QPluginLoader。实测发现，当你在该版本 Qt Creator 中新建 Qt 6 项目时，.pro文件模板会强制生成QT += core gui widgets，而 Qt 6 已将 widgets 拆分为widgets和legacywidgets，导致编译直接报错module not found。

2.2 方案二：Qt 官方离线安装器（Recommended）

这是 Qt 官网推荐的主流方式，下载地址为https://download.qt.io/official_releases/qtcreator/。截至 2024 年中，最新稳定版为Qt Creator 12.0.2，安装包约 1.2GB（含 Qt 6.5.3 源码和文档）。

这个安装器本质是一个自解压的 Qt 应用（qt-unified-linux-x64-4.10.2-online.run），运行时会启动一个内置的 Qt WebEngine 界面。它真正的价值不在 GUI，而在其动态依赖解析引擎。安装过程中，它会：

扫描/usr/bin/下是否存在gcc,g++,cmake,ninja
检查/usr/lib/x86_64-linux-gnu/中libGL.so,libEGL.so的 SONAME 版本（如libGL.so.1.7.0）
根据检测结果，自动勾选匹配的 Qt 版本组件（例如检测到 Mesa 22.3.6，则推荐 Qt 6.5.3 而非 6.4.2）

注意：安装路径强烈建议避开/opt/或/usr/local/。我曾在一个金融客户现场遇到问题：他们将 Qt Creator 安装到/opt/Qt/Tools/QtCreator，结果因 SELinux 策略限制，Qt Creator 无法访问/home/user/.cache/QtProject/qtcreator/下的符号缓存，导致 QML 调试器始终显示“no symbols loaded”。最终解决方案是改用--root /home/user/Qt参数重装，并在~/.profile中添加export QT_QPA_PLATFORM=wayland。

该方案最大优势是版本自主权。你可以同时安装 Qt 5.15.2、Qt 6.3.2、Qt 6.5.3 三个 Kit，在 Qt Creator 中自由切换。每个 Kit 对应独立的 qmake/cmake 路径、Qt 库路径、调试器路径。这种“Kit 概念”是 Qt Creator 的核心抽象，它把“编译环境”从操作系统层面提升到了项目级别。

2.3 方案三：源码编译安装（极客向）

适用于两类人：一是需要定制 Qt Creator 插件（比如为某国产芯片添加专用烧录插件），二是必须满足等保三级要求（所有二进制需经内部审计）。编译流程如下：

# 1. 克隆源码（注意分支对应） git clone --recursive https://code.qt.io/qt-creator/qt-creator.git cd qt-creator git checkout v12.0.2 # 2. 准备构建环境（关键！） sudo apt install build-essential libgl1-mesa-dev libxcb-xinerama0-dev \ libxcb-xinput0-dev libxcb-xkb-dev libxkbcommon-x11-dev # 3. 配置 CMake（这才是精髓） mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/opt/qtcreator-custom \ -DUSE_SYSTEM_QT=ON \ # 强制使用系统 Qt，避免捆绑 Qt -DENABLE_TESTS=OFF \ .. # 4. 编译（4核机器约需28分钟） make -j4 sudo make install

这里-DUSE_SYSTEM_QT=ON是成败关键。若不加此参数，CMake 会尝试下载并编译 Qt 本身，耗时增加 3 倍且极易失败（Qt 源码超 2GB，网络波动会导致 submodule fetch 中断）。启用后，Qt Creator 会直接链接/usr/lib/x86_64-linux-gnu/libQt5Core.so.5，但代价是失去对 Qt 6 的原生支持——因为系统 Qt 通常只提供 Qt5。

实操心得：在 CentOS Stream 9 上编译时，必须先执行sudo dnf install qt5-qtbase-devel qt5-linguist，否则moc工具缺失，make会在src/plugins/coreplugin/coreplugin.cpp处报错moc: command not found。这不是 Qt Creator 的问题，是 RHEL 系衍生版将 moc 单独打包的策略所致。

三种方案没有绝对优劣，只有场景适配：

教学演示、快速原型 → 用 apt（省心，但别指望它编译复杂项目）
工业级开发、多 Qt 版本共存 → 用官方离线安装器（稍费空间，但掌控力最强）
安全合规、深度定制 → 源码编译（时间成本高，但每个字节都在你掌控中）

3. 核心配置详解：Kit、Debugger、Qt Version 三大支柱的搭建逻辑

3.1 Kit：不只是“编译器+Qt 版本”的简单组合

在 Qt Creator 中，“Kit” 是一个五元组：Device Type + Compiler + Qt Version + Debugger + Sysroot。很多人只关注前三个，却忽略了后两者才是跨平台开发的命门。

以一个典型嵌入式场景为例：你在 x86_64 Ubuntu 主机上开发，目标板是 ARM64 的瑞芯微 RK3399。此时 Kit 配置必须包含：

Device Type：Generic Linux Device（而非 Desktop）
Compiler：/opt/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-g++
Qt Version：/opt/qt-everywhere-src-6.5.3/build-rk3399/qtbase/bin/qmake（交叉编译版 qmake）
Debugger：/opt/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gdb
Sysroot：/opt/rk3399-sysroot（包含目标板的 libc、headers、.so 文件）

关键原理：Sysroot 的存在，让 qmake 在生成 Makefile 时能正确设置-I和-L路径。例如，当你的代码包含#include <sys/socket.h>，qmake 会自动将-I/opt/rk3399-sysroot/usr/include加入编译参数，而非主机的/usr/include。这就是为什么直接复制主机编译的二进制到开发板会报错libstdc++.so.6: version 'GLIBCXX_3.4.29' not found——因为主机 g++ 链接的是新版 libstdc++，而目标板 sysroot 里只有 GLIBCXX_3.4.26。

验证 Kit 是否生效的最简方法：新建空项目 → 右键项目名 → “Properties” → “Build Settings” → 展开 “Build Steps” → 查看 “Make” 命令行。正常情况下，你会看到类似：

/opt/qt-everywhere-src-6.5.3/build-rk3399/qtbase/bin/qmake -makefile -o Makefile ../hello.pro -spec linux-g++ CONFIG+=debug

如果这里显示的是/usr/bin/qmake，说明 Kit 未被正确应用。

3.2 Debugger：GDB 的隐式配置陷阱

Qt Creator 默认使用系统 GDB，但很多发行版的 GDB 缺少 Python 支持（用于解析 Qt 类型）。在 Ubuntu 22.04 上，apt install gdb安装的是gdb 12.1，它默认不启用python3模块。结果就是：当你在 QML 中设置断点，调试器能停住，但变量窗口显示<not accessible>。

解决方案分两步：

确认 GDB Python 支持：

gdb --batch --ex "python print('OK')" 2>/dev/null | grep OK # 若无输出，说明 Python 支持未启用

重新编译 GDB（推荐）或安装带 Python 的版本：

# Ubuntu 用户可直接安装 sudo apt install gdb-multiarch python3-dbg # 然后在 Qt Creator 中：Tools → Options → Kits → Debuggers → Add # Path 设为 /usr/bin/gdb-multiarch

注意：gdb-multiarch是 Debian/Ubuntu 为跨架构调试提供的增强版 GDB，它内置了 ARM/MIPS/RISC-V 的指令集模拟器，比原生 gdb 更适合嵌入式场景。但在 Qt Creator 的 Debugger 设置中，必须勾选 “Load system GDB pretty printers” 和 “Load extra plugins from directory”，否则 Qt 容器类（如 QVector ）仍无法展开。

3.3 Qt Version：qmake 与 cmake 的双轨制真相

Qt Creator 支持两种构建系统：qmake（Qt 原生）和 CMake（行业标准）。但很多人不知道，同一个 Qt 版本可以对应多个 qmake，但只能对应一个 cmake 工具链。

以 Qt 6.5.3 为例：

qtbase/bin/qmake：这是 Qt 自带的构建工具，专为.pro文件设计。它内部硬编码了 Qt 模块路径，比如QT += quick会自动添加-I/opt/qt6.5.3/include/QtQuick。
lib/cmake/Qt6/Qt6Config.cmake：这是 CMake 的导入文件，由cmake命令通过-DCMAKE_PREFIX_PATH=/opt/qt6.5.3加载。它不关心你用什么编译器，只负责导出 Qt6::Core 这样的目标。

因此，在 Qt Creator 中配置 Qt Version 时：

如果你用 qmake 项目，只需指定qmake路径（如/opt/qt6.5.3/bin/qmake）
如果你用 CMake 项目，必须在 Kit 的 “CMake configuration” 中添加：

-DCMAKE_PREFIX_PATH:STRING=/opt/qt6.5.3 -DCMAKE_CXX_STANDARD:STRING=17

否则即使 Qt Version 列表里显示了 6.5.3，CMakeLists.txt 中的find_package(Qt6 REQUIRED COMPONENTS Core Widgets)也会失败。

实操验证：新建 CMake 项目 → 在 CMakeLists.txt 中添加message(STATUS "Qt6_DIR = ${Qt6_DIR}")→ 构建时查看 “General Messages” 输出。若显示为空，说明 CMake 未找到 Qt6，需检查 Kit 的 CMake 配置。

4. 常见问题与排查技巧实录：从界面黑屏到 QML 调试失效的全链路诊断

4.1 界面黑屏/闪退：Wayland 与 X11 的后端战争

在 Ubuntu 22.04+、Fedora 38+ 等默认启用 Wayland 的系统上，Qt Creator 启动后可能出现：

主窗口空白，仅显示菜单栏
点击任意按钮无响应，CPU 占用飙升至 100%
终端输出Could not create EGL surface: Bad Native Window或Failed to initialize EGL display

根本原因：Qt Creator 6.5+ 默认使用xcb平台插件（X11 后端），但 Wayland 会拦截 X11 调用并尝试转换，转换失败则崩溃。解决方案有三：

方案 A（推荐）：强制使用 Wayland 后端

# 启动前设置环境变量 export QT_QPA_PLATFORM=wayland export QT_WAYLAND_DISABLE_WINDOWDECORATION=1 ./qtcreator

QT_WAYLAND_DISABLE_WINDOWDECORATION=1是关键，它禁用服务端窗口装饰，避免 Qt Creator 尝试调用未实现的 wl-decoration 协议。

方案 B：降级到 X11 会话在登录界面选择 “Ubuntu on Xorg”，而非 “Ubuntu”。这是最彻底的方案，但牺牲了 Wayland 的安全性优势（如屏幕录制防护）。

方案 C：修改 Qt Creator 启动脚本编辑~/Qt/Tools/QtCreator/bin/qtcreator.sh，在exec "$DIR"/libexec/qtcreator/qtcreator "$@"前添加：

export QT_QPA_PLATFORM=xcb export QT_XCB_GL_INTEGRATION=xcb_egl

xcb_egl强制使用 EGL 渲染，绕过 Mesa 的 GLX 路径，对 Intel 核显尤其有效。

排查技巧：运行echo $XDG_SESSION_TYPE确认当前会话类型。若输出wayland，则优先尝试方案 A；若输出x11仍黑屏，用glxinfo | grep "OpenGL renderer"检查显卡驱动是否正常。

4.2 QML 调试器连接失败：端口、防火墙与 SELinux 的三重关卡

当点击 “Debug” 按钮后，QML 调试器显示 “Connecting to port 1234…” 但永远不成功，常见于企业内网环境。排查顺序如下：

第一关：端口占用

# Qt Creator 默认使用 1234 端口，但可被其他进程占用 sudo ss -tuln | grep ':1234' # 若有输出，修改 Qt Creator 设置： # Tools → Options → Debugger → GDB → Additional Startup Commands # 添加：set follow-fork-mode child # 并在项目 Build Settings 中，将 “QML debugging port” 改为 1235

第二关：防火墙拦截

# Ubuntu UFW 默认放行 localhost，但某些企业策略会禁用 sudo ufw status verbose | grep 1234 # 临时开放（仅限开发机） sudo ufw allow 1234

第三关：SELinux 策略（CentOS/RHEL）

# 检查是否启用 SELinux sestatus -v | grep "Current mode" # 若为 enforcing，查看拒绝日志 sudo ausearch -m avc -ts recent | grep qtcreator # 临时放宽策略（生产环境慎用） sudo setsebool -P allow_ypbind 1 sudo setsebool -P allow_user_mysql_connect 1

独家技巧：在 Qt Creator 的 “Projects” → “Run Settings” → “Run Environment” 中，添加环境变量QML_DEBUG_PORT=1234和QML_DEBUG_ENABLE=1。这比单纯依赖调试器界面更可靠，因为它是直接注入到被调试进程的环境变量中。

4.3 中文乱码与字体模糊：Fontconfig 的隐式依赖

在 KDE Plasma 或 GNOME 43+ 上，Qt Creator 的中文注释显示为方块，或 UI 字体边缘发虚。这不是 Qt Creator 的 bug，而是 Fontconfig 配置缺失。

根因分析：Qt Creator 使用QFontDatabase加载字体，而QFontDatabase依赖 Fontconfig 的缓存。当系统未生成 font cache 时，Qt 会回退到 bitmap 字体，导致模糊。

解决步骤：

确认中文字体已安装：

fc-list :lang=zh # 应输出类似 /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans CJK SC:style=Regular

重建 font cache：

sudo fc-cache -fv # -f 强制刷新，-v 显示详细过程

在 Qt Creator 中强制重载字体：

Tools → Options → Environment → Interface → Font
临时改为 “DejaVu Sans”，点击 OK
再改回 “Noto Sans CJK SC”，此时字体引擎会重新初始化

注意：不要在~/.fonts.conf中手动添加<alias>规则。Qt 6.5+ 使用 HarfBuzz 进行文本整形，与 Fontconfig 的 alias 机制存在兼容性问题。实测在 Fedora 38 上，手动 alias 会导致 QML Text 元素的font.family属性失效。

4.4 构建失败：“No rule to make target ‘xxx.o’” 的终极溯源

当点击 “Build” 后，构建输出窗口显示：

make: *** No rule to make target 'main.o', needed by 'hello'. Stop.

这通常意味着 Makefile 未正确生成。根源往往在.pro文件的TEMPLATE设置：

TEMPLATE = app：生成可执行文件，要求至少一个SOURCES += main.cpp
TEMPLATE = lib：生成库文件，要求HEADERS += myclass.h且SOURCES += myclass.cpp

但更隐蔽的问题是：Qt Creator 的 shadow build 机制被意外关闭。默认情况下，Qt Creator 会在build-hello-Desktop_Qt_6_5_3_GCC_64bit-Debug/目录下构建，与源码分离。如果误操作关闭了 shadow build（Projects → Build Settings → uncheck “Shadow build”），则构建目录变为源码同级，此时.pro.user文件可能残留旧配置，导致 qmake 读取错误的OBJECTS_DIR。

诊断命令：

# 进入构建目录，手动运行 qmake cd build-hello-* /opt/qt6.5.3/bin/qmake -makefile -o Makefile ../hello.pro # 若报错 “Project ERROR: Cannot run compiler 'g++'”，说明 Kit 的 Compiler 路径错误 # 若报错 “Project ERROR: Unknown module(s) in QT: widgets”，说明 Qt Version 未正确关联

实操心得：每次更换 Qt Version 后，务必点击 “Rebuild Project”。Qt Creator 不会自动触发 qmake 重生成，它只在首次构建或检测到.pro文件变更时才运行 qmake。这是一个反直觉的设计，但符合 Unix “显式优于隐式” 哲学。

5. 进阶技巧与工程实践：从个人开发到团队协作的平滑演进

5.1 Kit 配置的版本化管理：.kit 文件的实战价值

Qt Creator 的 Kit 配置存储在~/.local/share/QtProject/qtcreator/kits.xml，这是一个全局文件。当团队多人共用一台开发机（如实验室服务器），或你需要在多台机器间同步配置时，直接编辑 XML 极易出错。

正确做法：导出为.kit文件

Tools → Options → Kits → 选中目标 Kit → 点击右下角 “Export” 按钮
保存为rk3399-kit.kit，该文件是纯文本 JSON，内容类似：

{ "name": "RK3399-Qt6.5.3", "deviceType": "GenericLinuxDevice", "compiler": "/opt/gcc-linaro-7.5.0/bin/aarch64-linux-gnu-g++", "qtVersion": "/opt/qt6.5.3/build-rk3399/qtbase/bin/qmake", "debugger": "/opt/gcc-linaro-7.5.0/bin/aarch64-linux-gnu-gdb", "sysroot": "/opt/rk3399-sysroot" }

团队协作流程：

主管将rk3399-kit.kit提交到 Git 仓库的docs/kits/目录
新成员克隆仓库后，执行：

# 导入 Kit（无需重启 Qt Creator） qtcreator -import-kits rk3399-kit.kit # 或手动：Tools → Options → Kits → Import

Qt Creator 会自动校验路径有效性，若/opt/rk3399-sysroot不存在，则标记为 “Invalid”，提示用户先部署 sysroot

优势：.kit文件可 diff、可 review、可 CI 验证。我们曾在某汽车电子项目中，用 GitHub Actions 检查.kit文件中的compiler路径是否匹配gcc --version输出，防止工程师误用旧版工具链。

5.2 QML 性能分析：从 “Fps Meter” 到 “QML Profiler”的跃迁

Qt Creator 内置的 “Fps Meter”（按 Ctrl+Shift+F12）只能显示帧率，无法定位瓶颈。真正的性能分析需用 “QML Profiler”。

启用步骤：

Projects → Run Settings → Run → Check “Enable QML profiling”
启动后，打开 “Analyze” → “QML Profiler”
点击 “Start” 按钮，开始记录

关键指标解读：

指标	正常值	危险值	优化方向
JavaScript Execution	< 8ms/frame	> 16ms/frame	将计算移至 C++ 后端，用`Q_INVOKABLE`暴露接口
Binding Evaluation	< 2ms/frame	> 5ms/frame	避免在`onWidthChanged`中调用`forceLayout()`
Rendering	< 10ms/frame	> 20ms/frame	检查`layer.enabled: true`是否滥用，禁用不必要的图层

独家技巧：在 QML 中插入console.time("myTask")和console.timeEnd("myTask")，Profiler 会将其作为自定义事件显示在 “JavaScript” 时间轴上，精度达微秒级。这比Date.now()更准确，因为console.time由 V8 引擎原生支持。

5.3 CI/CD 集成：在 GitLab CI 中复现 Qt Creator 构建环境

很多团队希望将 Qt Creator 的本地构建流程自动化。以下是一个.gitlab-ci.yml片段，可在 Ubuntu 22.04 runner 上复现 Qt Creator 的构建环境：

stages: - build build-qt6: stage: build image: ubuntu:22.04 before_script: - apt-get update && apt-get install -y wget build-essential libgl1-mesa-dev libxcb-xinerama0-dev - wget https://download.qt.io/official_releases/qt/6.5/6.5.3/qt-everywhere-src-6.5.3.tar.xz - tar -xf qt-everywhere-src-6.5.3.tar.xz - cd qt-everywhere-src-6.5.3 - ./configure -prefix /opt/qt6.5.3 -release -opensource -confirm-license -no-opengl -no-vulkan - make -j$(nproc) && sudo make install script: - /opt/qt6.5.3/bin/qmake -v # 验证 qmake 可用 - /opt/qt6.5.3/bin/qmake -makefile -o Makefile hello.pro - make -j$(nproc) artifacts: paths: - hello

关键点说明：

./configure中-no-opengl是为了规避 CI 环境无 GPU 的问题，Qt 会自动 fallback 到libEGL软件渲染
qmake -makefile是 Qt Creator 构建时实际执行的命令，而非qmake hello.pro（后者生成的是 project 文件，非 Makefile）
artifacts将生成的二进制上传，供后续测试 job 使用

注意：GitLab CI 的 runner 默认无图形界面，因此不能运行 Qt Creator GUI，但可完全复现其构建能力。这是 DevOps 团队验证 “本地能跑，CI 也能跑” 的黄金标准。

5.4 安全加固：禁用 Qt Creator 的远程调试与插件自动更新

在金融、政务等高安全要求场景，需禁用 Qt Creator 的潜在风险功能：

禁用远程调试：

Tools → Options → Debugger → GDB → uncheck “Allow remote debugging”
编辑~/.local/share/QtProject/qtcreator/debugger.xml，将<RemoteDebuggingEnabled>true</RemoteDebuggingEnabled>改为false

禁用插件自动更新：

Tools → Options → Environment → System → uncheck “Check for updates automatically”
删除~/.local/share/QtProject/qtcreator/plugins/下所有.so文件（保留libcore.so,libprojectexplorer.so等核心插件）