博维智航（彭州）——面试

技术文档

文章目录

一、公司背景
二、问题
- 2.1 图像学相关问题
- 2.2 静态库，动态库
- - 2.2.1 核心概念与本质
  - 2.2.2 静态库（Static Library）
  - 2.2.3 动态库（Dynamic/Shared Library）
  - 2.2.4 静态库 vs 动态库：关键区别对比
  - 2.2.5 适用场景选择
  - 2.2.6 跨平台差异补充
  - 2.2.7 动态库依赖问题：DLL 地狱
  - 2.2.8 总结
- 2.3 Qt的元系统机制
- - 2.3.1 元对象系统的核心组成
  - 2.3.2 元对象系统的核心功能
  - 2.3.3 元系统的实现原理简析
  - 2.3.4 元系统的典型应用场景
  - 2.3.5 总结
- 2.4 Qt撤销功能如何做的
- - 2.4.1 核心组件与工作原理
  - 2.4.2 高级特性
  - 2.4.3 适用场景
  - 2.4.4 总结
- 2.5 Qt用了那些控件
- - 2.5.1 基础交互控件（用户输入与展示）
  - 2.5.2 容器控件（布局与分组）
  - 2.5.3 高级功能控件（复杂交互）
  - 2.5.4 回答技巧
- 2.6 Qt子对象销毁了父对象如何销毁呢
- 2.7 多态机制有啥优势呢
- - 2.7.1 **代码复用与扩展性**
  - 2.7.2 **简化代码逻辑**
  - 2.7.3 **接口与实现分离**
  - 2.7.4 **增强代码灵活性**
  - 2.7.5 **便于单元测试与模块替换**
  - 2.7.6 总结
- 2.8 动态库有几种方式
- - 2.8.1 按操作系统分类
  - 2.8.2 按加载时机分类
  - 2.8.3 其他分类方式
  - 2.8.4 总结
- 2.9 Qt的内存管理机制
- - 2.9.1 对象树（Object Tree）机制
  - 2.9.2 手动管理与自动管理的协同
  - 2.9.3 `deleteLater()` 延迟销毁
  - 2.9.4 无父对象的情况
  - 2.9.5 特殊注意事项
  - 2.9.6 总结
- 2.10 重写和重载有啥区别
- - 2.10.1 重写（Override）：父子类间的方法覆盖
  - 2.10.2 重载（Overload）：同一类中的方法多态
  - 2.10.3 关键区别总结
  - 2.10.4 常见误区
- 2.11 Qt什么时候安装过滤器
- - 2.11.1 初始化阶段安装（最常见）
  - 2.11.2 动态安装（根据业务逻辑触发）
  - 2.11.3 Qt 的事件过滤器（Event Filter）
- 2.12 对CAD有啥理解？几何和网格的区别？
- - 2.12.1 对 CAD 的核心理解
  - 2.12.3 几何（Geometry）与网格（Mesh）的核心区别
  - 2.12.3关键总结（帮你快速记忆）

一、公司背景

主要是做渲染，计算机图形学，航空背景方向的吧！
提了一嘴计算机图形学，然后被吊打了！不会的一定不要说！

二、问题

2.1 图像学相关问题

着色器、渲染中间的缓存机制、曲面法相矢量

没答上来

2.2 静态库，动态库

在软件开发中，静态库（Static Library）和动态库（Dynamic Library，也称共享库 Shared Library）是两种核心的代码复用与模块化工具，它们的核心区别在于链接时机、文件依赖、内存占用等特性，适用于不同的开发场景。下面从定义、原理、区别、优缺点及适用场景等方面进行全面解析。

2.2.1 核心概念与本质

无论是静态库还是动态库，本质都是预编译好的二进制代码集合，包含函数、类、变量等可复用逻辑，目的是：
实现代码复用（避免重复编写相同逻辑）；
简化项目结构（将复杂模块拆分到库中，主程序只需调用接口）；
隐藏实现细节（只暴露接口，不公开源代码）。

2.2.2 静态库（Static Library）

1. 定义与工作原理
静态库是在编译阶段（更准确地说是 “链接阶段”）被完整 “复制” 到主程序中的库。
编译流程：主程序源代码 → 编译为目标文件（.o/.obj）→ 链接器（Linker）将目标文件与静态库合并 → 生成独立的可执行文件（无需依赖外部库即可运行）。
常见文件格式：
Windows：.lib（注意：Windows 中 .lib 可能是静态库，也可能是动态库的 “导入库”，需区分）；
Linux/macOS：.a（Linux 静态库后缀）、.framework（macOS 静态 / 动态库容器，默认静态）。
2. 核心特性
编译后 “嵌入” 主程序：链接完成后，静态库的代码会被完整复制到可执行文件中，主程序运行时不再依赖静态库文件。
可执行文件体积较大：因为包含了静态库的完整代码，若依赖多个静态库，可执行文件会显著变大。
版本独立性差：若静态库更新（如修复 bug），主程序必须重新编译链接才能使用新库；否则始终使用旧版本的库代码。
加载速度快：运行时无需额外加载外部库，直接从自身代码中执行，启动速度略快。
3. 优缺点
博维智航（彭州）——面试

2.2.3 动态库（Dynamic/Shared Library）

1. 定义与工作原理
动态库是在程序运行时（或加载时）才被 “动态加载” 到内存中供主程序调用的库，不会被复制到主程序中。
编译流程：主程序源代码 → 编译为目标文件 → 链接器只在主程序中记录 “动态库的接口地址”（而非复制库代码）→ 生成可执行文件；
运行流程：可执行文件启动 → 操作系统加载器（Loader）检测到依赖动态库 → 加载动态库到内存 → 主程序通过接口地址调用库中的逻辑。
常见文件格式：
Windows：.dll（Dynamic Link Library），配套的 “导入库” 为 .lib（主程序编译时需链接此 .lib，运行时依赖 .dll）；
Linux：.so（Shared Object）；
macOS：.dylib 或 .framework（默认动态）。
2. 核心特性
运行时依赖外部库文件：可执行文件体积小（仅包含自身代码和库接口引用），但运行时必须确保动态库存在于指定路径（如系统目录、程序同级目录）。
内存共享：若多个程序依赖同一动态库，操作系统只需加载一次库到内存，供所有程序共享使用（避免冗余加载，节省内存）。
版本灵活性：若动态库更新（如修复 bug、新增功能），只要接口兼容（函数名、参数列表不变），主程序无需重新编译，直接替换动态库即可生效。
延迟加载：支持 “按需加载”（如 Windows 的 LoadLibrary、Linux 的 dlopen），主程序可在运行中动态加载 / 卸载库，灵活控制资源。
3. 优缺点
博维智航（彭州）——面试

2.2.4 静态库 vs 动态库：关键区别对比

博维智航（彭州）——面试

2.2.5 适用场景选择

1. 优先选静态库的场景
轻量级依赖：库体积小（如工具类、简单算法库），复制到主程序后对体积影响小；
独立部署需求：需生成 “单文件可执行程序”（如命令行工具、离线工具），避免用户额外安装库；
版本稳定性优先：不希望库更新影响主程序（如医疗、工业控制等对稳定性要求极高的场景）；
避免依赖冲突：项目依赖的库版本特殊，担心与系统中其他库版本冲突。

2. 优先选动态库的场景
多程序共享同一库：如系统级库（Windows 的 user32.dll、Linux 的 libc.so），供无数程序共享，节省内存；
库体积大且更新频繁：如 UI 库、数据库驱动库（更新时无需重新编译所有依赖程序）；
按需加载需求：主程序仅在特定功能触发时才需要加载库（如插件化架构、动态功能扩展）；
减少可执行文件体积：大型项目依赖多个库（如游戏、复杂客户端），用动态库可显著减小主程序体积。

2.2.6 跨平台差异补充

不同操作系统对静态库 / 动态库的命名、编译方式、加载逻辑有细节差异，需特别注意：
平台静态库格式动态库格式编译工具示例（GCC/Clang）
Windows .lib（静态库） .dll + .lib（导入库） MinGW: 静态库 ar rcs libxxx.a xxx.o；动态库 gcc -shared -o xxx.dll xxx.o -Wl,–out-implib=xxx.lib
Linux .a .so 静态库 ar rcs libxxx.a xxx.o；动态库 gcc -shared -fPIC -o libxxx.so xxx.o（-fPIC 生成位置无关代码）
macOS .a / .framework .dylib / .framework 静态库 ar rcs libxxx.a xxx.o；动态库 clang -shared -fPIC -o libxxx.dylib xxx.o

2.2.7 动态库依赖问题：DLL 地狱

多个程序可能依赖同一动态库的不同版本，容易导致冲突：

例如：程序 1 需要libxxx.so.1，程序 2 需要libxxx.so.2，但系统中只能存在一个版本的库文件，可能导致其中一个程序运行失败；
Windows 中经典的 “DLL 地狱”（DLL Hell）就是由此产生，多个应用争夺系统目录中同一 DLL 的不同版本。

2.2.8 总结

静态库和动态库没有绝对的 “优劣”，核心是匹配项目的部署需求、性能需求和维护需求：
想 “简单独立”，选静态库；想 “灵活共享”，选动态库；
小工具、离线程序优先静态库；大型项目、多程序共享模块优先动态库。
理解两者的差异，是构建高效、可维护的软件系统的基础（如插件化架构、跨平台开发、性能优化等场景都会用到）。

2.3 Qt的元系统机制

Qt 的元对象系统（Meta-Object System）是 Qt 框架的核心机制之一，它为 C++ 扩展了动态特性（如反射、动态方法调用等），是 Qt 信号与槽（Signals & Slots）、属性系统、动态类型识别等功能的底层支撑。其核心目标是在静态类型的 C++ 中引入一定程度的 “动态性”，让 Qt 应用能更灵活地处理对象交互、类型信息和属性访问。

2.3.1 元对象系统的核心组成

元对象系统由三个关键部分协同工作：

1. QObject 基类

QObject 是 Qt 中几乎所有对象的基类（类似 Java 的Object），它提供了元系统的基础接口，例如：

动态对象生命周期管理（父子对象机制）；
元对象指针（metaObject() 方法），用于获取类的元信息；
动态方法调用（QMetaObject::invokeMethod()）；
信号与槽的连接（connect() 方法）。

只有继承自QObject的类，才能启用元系统功能。

2. Q_OBJECT 宏

要让QObject子类真正拥有元系统特性，需在类定义中添加Q_OBJECT宏（通常放在类声明的私有部分）。该宏的作用是：

声明元对象相关的成员函数（如metaObject()、qt_metacall()等）；
触发 Qt 元对象编译器（moc）对类进行处理，生成元信息代码。

#include class MyObject : public QObject { Q_OBJECT // 启用元系统功能public: explicit MyObject(QObject *parent = nullptr); signals: void valueChanged(int newValue); // 信号（元系统管理） public slots: void setValue(int value); // 槽函数（元系统管理）};

3. 元对象编译器（moc，Meta-Object Compiler）

moc 是 Qt 的预处理器，它会扫描包含Q_OBJECT宏的头文件，自动生成元信息代码（通常生成moc_xxx.cpp文件）。这些代码包含：

类的元数据（类名、父类名、方法列表、信号 / 槽列表、属性列表等）；
实现信号发射、槽函数调用、元信息查询的底层逻辑；
连接信号与槽的中间代码。

moc 生成的代码会被编译到最终的二进制文件中，使得程序运行时可以通过QMetaObject类访问这些元信息。

2.3.2 元对象系统的核心功能

元对象系统通过QMetaObject类（每个QObject子类都有一个QMetaObject实例）提供以下核心能力：

1. 动态类型识别

通过元对象可以在运行时获取对象的类型信息，无需依赖 C++ 的dynamic_cast（但 Qt 也支持qobject_cast，基于元系统实现）。

const char *className()：返回类名（字符串形式）；
bool inherits(const char *className)：判断当前类是否继承自指定类；
QMetaObject::className(obj)：通过对象指针直接获取类名。

QObject *obj = new MyObject();qDebug() << obj->metaObject()->className(); // 输出 \"MyObject\"qDebug() << obj->inherits(\"QObject\"); // 输出 true（MyObject继承自QObject）

2. 信号与槽机制

信号与槽是 Qt 最具特色的功能，其底层完全依赖元对象系统：

信号：由 moc 生成的emit代码触发，本质是通过元对象查找并调用关联的槽函数；
槽：被元系统注册为可调用的方法，可通过元对象动态调用；
连接：QObject::connect() 本质是通过元对象记录信号与槽的关联关系，在信号发射时通过元信息找到并执行槽函数。

元系统使得信号与槽的连接可以在运行时动态建立 / 断开，且不依赖编译时的静态绑定（甚至支持跨线程连接）。

3. 动态属性系统

Qt 允许通过Q_PROPERTY宏定义 “动态属性”，这些属性可以在运行时被查询、修改，无需在类中显式定义成员变量。元系统会管理这些属性的元信息（名称、类型、读写权限等）。

class MyObject : public QObject { Q_OBJECT Q_PROPERTY(int value READ getValue WRITE setValue NOTIFY valueChanged) // 定义动态属性public: int getValue() const { return m_value; } void setValue(int value) { if (m_value != value) { m_value = value; emit valueChanged(value); // 属性变化时发射信号 } }signals: void valueChanged(int newValue);private: int m_value = 0;};

通过元系统访问属性：

MyObject obj;obj.setProperty(\"value\", 42); // 动态设置属性（无需直接调用setValue）qDebug() << obj.property(\"value\").toInt(); // 动态获取属性值（输出42）

4. 动态方法调用

元系统支持通过方法名（字符串）在运行时动态调用对象的方法（包括槽函数、普通成员函数），无需编译时知道方法的具体类型。

关键方法：QMetaObject::invokeMethod()

MyObject obj;// 动态调用setValue方法，参数为100bool success = QMetaObject::invokeMethod(&obj, \"setValue\", Q_ARG(int, 100));if (success) { qDebug() << obj.getValue(); // 输出100}

这种机制在跨线程通信、脚本交互（如 Qt 与 QML/JavaScript 交互）中非常有用。

2.3.3 元系统的实现原理简析

预编译阶段：moc 扫描Q_OBJECT宏，解析类中的信号、槽、属性等信息，生成包含元数据的代码（如moc_MyObject.cpp）。这些代码会定义类的QMetaObject实例，包含类名、方法列表、属性列表等静态信息。
运行时阶段：
- 每个QObject对象通过metaObject()方法获取其类的QMetaObject实例；
- 当需要调用信号、槽或属性时，通过QMetaObject中的元数据查找方法 / 属性的索引，再通过qt_metacall()等底层函数执行实际逻辑；
- 信号的发射本质是通过元对象找到所有关联的槽函数，并逐一调用（跨线程时会通过事件循环转发）。

2.3.4 元系统的典型应用场景

信号与槽通信：Qt 对象间的核心交互方式（替代传统回调）；
Qt Designer/Qt Creator 集成：设计工具通过元系统识别控件的属性和信号 / 槽，实现可视化编辑；
QML 与 C++ 交互：QML 引擎通过元系统访问 C++ 对象的属性和方法；
序列化与反序列化：利用动态属性实现对象数据的通用读写；
插件系统：通过元信息动态识别插件提供的接口和功能。

2.3.5 总结

Qt 的元对象系统是对 C++ 的 “动态扩展”，它通过QObject基类、Q_OBJECT宏和 moc 编译器的协同，为静态类型的 C++ 添加了反射、动态方法调用、信号与槽等动态特性。这一机制是 Qt 框架灵活性和易用性的核心保障，也是 Qt 区别于其他 C++ 库的关键特征。

理解元系统的工作原理，有助于更深入地掌握 Qt 的信号与槽、属性系统等核心功能，并在复杂场景（如跨语言交互、插件开发）中灵活应用。

2.4 Qt撤销功能如何做的

Qt 提供了一套完整的撤销 / 重做（Undo/Redo）框架，基于命令模式设计，核心类包括 QUndoCommand、QUndoStack 和 QUndoView，能轻松实现复杂的撤销功能。下面从核心组件、实现步骤、高级特性三个方面具体说明：

2.4.1 核心组件与工作原理

Qt 撤销框架的核心是通过三个组件协同实现 “记录操作 - 撤销 / 重做” 的逻辑，各组件作用如下：

类名作用 QUndoCommand 封装单个操作的 “执行” 和 “撤销” 逻辑（命令对象），是撤销功能的最小单元 QUndoStack 管理命令的栈结构，负责执行、撤销、重做命令，维护操作历史，是命令的 “管理者” QUndoView 可选的可视化组件，能显示操作历史列表，允许用户直接跳转到某一历史状态

核心流程：

把用户的每个操作（比如修改文本、删除元素）封装成 QUndoCommand 子类，重写 redo()（执行操作）和 undo()（撤销操作）方法；
将命令对象压入 QUndoStack，栈会自动调用 redo() 执行当前操作；
撤销时，QUndoStack 从栈顶弹出命令并调用其 undo() 方法，恢复到操作前状态；
重做时，QUndoStack 从 “已撤销命令” 中取出并调用其 redo() 方法，重新执行操作。

具体实现步骤

以 “文本编辑的撤销功能” 为例，展示完整实现流程：

1. 定义命令类（继承 QUndoCommand）

每个可撤销的操作都需要对应一个命令类，必须重写 undo() 和 redo() 方法，记录操作前后的状态（比如文本修改的 “旧文本” 和 “新文本”）。

#include #include // 封装“修改文本”的命令class ChangeTextCommand : public QUndoCommand {public: // 构造函数：传入操作前后的文本、目标控件、父命令（可选） ChangeTextCommand(const QString& oldText, const QString& newText, QLineEdit* edit, QUndoCommand* parent = nullptr) : QUndoCommand(parent), m_oldText(oldText), m_newText(newText), m_edit(edit) { // 设置命令描述（会显示在 QUndoView 中，方便用户识别操作） setText(\"修改文本\"); } // 执行操作（redo：应用新文本，即完成用户的修改） void redo() override { m_edit->setText(m_newText); } // 撤销操作（undo：恢复旧文本，回到修改前状态） void undo() override { m_edit->setText(m_oldText); }private: QString m_oldText; // 操作前的文本（用于撤销时恢复） QString m_newText; // 操作后的文本（用于重做时执行） QLineEdit* m_edit; // 目标控件（比如文本输入框）};

2. 用 QUndoStack 管理命令

QUndoStack 是命令的 “容器”，负责压入命令、执行撤销 / 重做。在主窗口或业务类中初始化 QUndoStack，并关联用户操作（比如文本修改、按钮点击）。

#include #include #include #include #include #include class MainWindow : public QMainWindow { Q_OBJECTpublic: MainWindow(QWidget* parent = nullptr) : QMainWindow(parent) { // 1. 初始化撤销栈 m_undoStack = new QUndoStack(this); // 2. 创建 UI 控件 m_edit = new QLineEdit(this); QPushButton* undoBtn = new QPushButton(\"撤销\", this); QPushButton* redoBtn = new QPushButton(\"重做\", this); // 3. 布局（用垂直布局整理控件，避免手动调整位置） QWidget* centralWidget = new QWidget(this); QVBoxLayout* layout = new QVBoxLayout(centralWidget); layout->addWidget(m_edit); layout->addWidget(undoBtn); layout->addWidget(redoBtn); setCentralWidget(centralWidget); // 4. 关联文本修改事件：创建命令并压入栈 connect(m_edit, &QLineEdit::textEdited, this, [this](const QString& newText) { // 记录修改前的文本（操作前状态） QString oldText = m_edit->text(); // 创建命令对象（传入旧文本、新文本、目标控件） QUndoCommand* cmd = new ChangeTextCommand(oldText, newText, m_edit); // 压入撤销栈：栈会自动调用 cmd->redo() 执行操作 m_undoStack->push(cmd); }); // 5. 关联撤销/重做按钮：触发栈的对应操作 connect(undoBtn, &QPushButton::clicked, m_undoStack, &QUndoStack::undo); connect(redoBtn, &QPushButton::clicked, m_undoStack, &QUndoStack::redo); }private: QUndoStack* m_undoStack; // 撤销栈：管理所有命令 QLineEdit* m_edit; // 文本编辑控件：用户操作的目标};

3. 可选：用 QUndoView 可视化操作历史

如果需要让用户看到所有操作历史（比如 “操作 1：修改文本”“操作 2：删除内容”），可以用 QUndoView 组件，它会以列表形式展示命令历史，用户点击某条记录就能直接跳转到对应状态。

#include // 在 MainWindow 的构造函数中添加：QUndoView* undoView = new QUndoView(m_undoStack, this);undoView->setWindowTitle(\"操作历史\");undoView->resize(300, 400);undoView->show(); // 显示独立窗口，列出所有操作命令

2.4.2 高级特性

Qt 撤销框架支持一些复杂场景的需求，比如合并命令、动态启用 / 禁用按钮等，下面介绍常用的两个特性：

1. 命令合并（Macro Commands）

对于连续的小操作（比如连续输入多个字符），如果每次输入都生成一个命令，撤销时会逐字符回退，体验不好。此时可以用 “命令合并”，把多个连续操作合并成一个命令，撤销时一次回退。

// 在需要合并命令的地方（比如连续输入文本时）：// 1. 开始合并：创建一个“宏命令”，后续压入的命令会成为它的子命令m_undoStack->beginMacro(\"连续输入文本\");// 2. 压入多个子命令（比如多次修改文本）m_undoStack->push(new ChangeTextCommand(oldText1, newText1, m_edit));m_undoStack->push(new ChangeTextCommand(oldText2, newText2, m_edit));// 3. 结束合并：此时所有子命令会被当作一个整体，显示为“连续输入文本”m_undoStack->endMacro();

合并后，撤销 / 重做时会把所有子命令作为一个整体处理，比如点击一次 “撤销” 就能回退所有连续输入的字符。

2. 动态启用 / 禁用撤销 / 重做按钮

当没有操作历史时（比如刚打开程序），“撤销” 按钮应该禁用；当没有已撤销的命令时，“重做” 按钮应该禁用。可以通过 QUndoStack 的信号实现自动控制：

// 在 MainWindow 的构造函数中添加：// 撤销按钮：栈有可撤销命令时启用，否则禁用connect(m_undoStack, &QUndoStack::canUndoChanged, undoBtn, &QPushButton::setEnabled);// 重做按钮：栈有可重做命令时启用，否则禁用connect(m_undoStack, &QUndoStack::canRedoChanged, redoBtn, &QPushButton::setEnabled);

这样，按钮状态会随操作历史自动更新，无需手动判断。

2.4.3 适用场景

Qt 的撤销框架适用范围很广，几乎所有需要 “回退操作” 的场景都能用到：

文本编辑器（撤销输入、删除、替换文本）；
图形工具（撤销绘制、移动、删除图形元素）；
表单操作（撤销修改表单内容、添加 / 删除列表项）；
业务系统（撤销订单提交、数据修改、状态变更）。

2.4.4 总结

Qt 撤销功能的核心是 “命令模式”，关键步骤可以概括为：

用 QUndoCommand 封装操作的 “执行” 和 “撤销” 逻辑；
用 QUndoStack 管理命令的历史和执行流程；
可选 QUndoView 可视化操作历史。

这种设计避免了 “快照模式”（保存整个数据状态）的内存浪费，能精准控制每个操作的撤销 / 重做，适合从简单到复杂的各种场景。实际开发中，只需根据具体操作（比如修改文本、删除文件）实现对应的 QUndoCommand 子类即可。

2.5 Qt用了那些控件

在 Qt 面试中回答常用控件时，可以按 “基础控件”“容器控件”“高级控件” 分类说明，突出常用控件及其典型场景，体现对 Qt 界面开发的理解。以下是清晰的回答思路：

2.5.1 基础交互控件（用户输入与展示）

按钮类：QPushButton（普通按钮）、QToolButton（工具按钮，常配图标）、QRadioButton（单选按钮，互斥选择）、QCheckBox（复选框，多选）。
例：表单中的 “提交” 按钮用QPushButton，性别选择用QRadioButton。
输入类：QLineEdit（单行文本输入，如账号密码）、QTextEdit（多行文本编辑，支持富文本）、QComboBox（下拉选择框，节省空间）、QSpinBox/QDoubleSpinBox（数字增减输入，如数量调整）、QSlider（滑动条，用于音量、亮度等连续值调节）。
显示类：QLabel（文本 / 图片展示，支持 HTML 格式）、QProgressBar（进度条，显示任务进度）、QStatusBar（状态栏，底部显示临时信息）。

2.5.2 容器控件（布局与分组）

布局容器：QWidget（基础容器，所有控件的父类）、QFrame（带边框的容器，用于视觉分组）、QGroupBox（带标题的分组容器，常包含互斥控件）。
例：用QGroupBox包裹一组QRadioButton，明确分组含义。
多页面容器：QTabWidget（标签页容器，如浏览器标签页）、QStackedWidget（堆叠窗口，通过按钮切换页面，节省空间）、QDockWidget（可停靠窗口，如 IDE 的侧边栏）。

2.5.3 高级功能控件（复杂交互）

列表与表格：QListWidget（列表项展示，支持单选 / 多选）、QTableWidget（表格展示，直接操作单元格）、QTreeWidget（树形结构，如文件目录展示）。
进阶：结合QAbstractItemModel使用QListView/QTableView（Model-View 架构，高效处理大量数据）。
对话框：QDialog（基础对话框）、QMessageBox（消息提示框，如警告、确认）、QFileDialog（文件选择对话框）、QInputDialog（简单输入对话框）。
其他常用：QMenuBar（菜单栏）、QToolBar（工具栏，快速访问功能）、QScrollArea（滚动区域，显示超出界面的内容）、QCalendarWidget（日历选择控件）。

2.5.4 回答技巧

结合场景：提到控件时简要说明典型用法（如 “QLineEdit用于单行输入，比如登录界面的用户名输入框”），体现实际应用能力。
突出层次：先讲最基础、最常用的（如按钮、输入框），再讲容器和高级控件，逻辑清晰。
适当延伸：若面试官深入问，可提 “自定义控件”（通过继承QWidget实现特定功能）或 “Model-View 架构”（高效处理数据展示），展示深度。

这样回答既全面又有重点，能体现对 Qt 控件体系的掌握。

2.6 Qt子对象销毁了父对象如何销毁呢

在 Qt 中，对象的父子关系是管理对象生命周期的核心机制，子对象与父对象的销毁遵循以下规则：

当父对象被销毁时，Qt 会自动销毁其所有子对象，无需手动调用 delete。这是通过 QObject 的析构函数实现的：父对象销毁时，会遍历其内部维护的子对象列表，逐个调用子对象的析构函数，确保所有子对象被正确释放。

具体细节：

父子关系的建立
当通过以下方式建立父子关系时，子对象会被加入父对象的子列表：
- 构造函数传参：QObject *child = new QObject(parent);
- 调用 setParent() 方法：child->setParent(parent);
父对象销毁触发子对象销毁
当父对象被销毁（如 delete parent;），QObject 的析构函数会执行：
```
QObject::~QObject() { // 遍历子对象列表，销毁所有子对象 while (!children.isEmpty()) { delete children.takeFirst(); }}
```
因此，销毁父对象后，所有子对象会被自动销毁，无需额外处理。
子对象销毁不影响父对象
反之，若先销毁子对象（delete child;），子对象会先从父对象的子列表中移除，再执行自身析构，父对象不受影响。

示例验证

#include #include class MyObject : public QObject { Q_OBJECTpublic: MyObject(const QString& name, QObject* parent = nullptr) : QObject(parent), m_name(name) { qDebug() << m_name << \"创建\"; } ~MyObject() { qDebug() << m_name << \"销毁\"; }private: QString m_name;};int main() { // 创建父对象 MyObject* parent = new MyObject(\"父对象\"); // 创建子对象，指定父对象 MyObject* child1 = new MyObject(\"子对象1\", parent); MyObject* child2 = new MyObject(\"子对象2\", parent); // 销毁父对象 delete parent; // 父对象销毁时，会自动销毁 child1 和 child2 return 0;}

输出结果：

父对象 创建子对象1 创建子对象2 创建父对象 销毁子对象1 销毁子对象2 销毁

可见，销毁父对象后，子对象会被自动销毁，且销毁顺序是 “父对象开始销毁 → 子对象销毁 → 父对象销毁完成”。

注意事项

避免重复销毁：若子对象已被父对象销毁，切勿再次手动 delete（会导致双重释放错误）。
动态对象需指定父类：在 Qt 中，动态分配的 QObject 子类对象（如 QWidget、QTimer）应尽量指定父对象，避免内存泄漏。
非 QObject 子类不适用：此机制仅适用于 QObject 及其子类，普通 C++ 对象需手动管理生命周期。

通过这种父子关系机制，Qt 实现了对象生命周期的自动管理，尤其在 GUI 开发中（如窗口、控件的层级关系），大幅简化了内存管理逻辑。

2.7 多态机制有啥优势呢

多态是面向对象编程（OOP）的核心特性之一，其核心优势在于 “同一接口，不同实现”，能够显著提升代码的灵活性、可扩展性和可维护性。具体优势如下：

2.7.1 代码复用与扩展性

多态允许通过基类接口操作不同的派生类对象，无需修改现有代码即可添加新功能。
例如，定义一个基类 Shape 和派生类 Circle、Rectangle，通过统一的 draw() 方法即可调用不同形状的绘制逻辑：

class Shape {public: virtual void draw() = 0; // 纯虚函数，定义接口};class Circle : public Shape {public: void draw() override { /* 绘制圆形 */ }};class Rectangle : public Shape {public: void draw() override { /* 绘制矩形 */ }};// 统一接口操作不同对象void render(Shape* shape) { shape->draw(); // 多态调用：根据实际对象类型执行对应实现}// 新增三角形时，只需派生Shape并实现draw()，无需修改render()class Triangle : public Shape {public: void draw() override { /* 绘制三角形 */ }};

新增功能（如 Triangle）时，只需扩展派生类，无需修改原有接口或调用逻辑，符合 “开闭原则”（对扩展开放，对修改关闭）。

2.7.2 简化代码逻辑

多态避免了大量的 if-else 或 switch 判断，通过统一接口直接调用具体实现，使代码更简洁、逻辑更清晰。
例如，不使用多态时可能需要这样的代码：

// 无多态：需手动判断类型void render(Object* obj) { if (obj->type() == CIRCLE) { drawCircle(obj); } else if (obj->type() == RECTANGLE) { drawRectangle(obj); } // 新增类型需修改此处逻辑}

而多态通过动态绑定自动匹配实现，消除了类型判断，降低了代码复杂度。

2.7.3 接口与实现分离

多态通过抽象基类定义接口，派生类负责具体实现，实现了接口与实现的解耦。
这使得：

调用者只需关注接口（基类），无需了解具体实现细节；
不同开发者可分别负责接口设计和实现，提高协作效率；
可替换不同的实现（如从 MySQL 切换到 PostgreSQL 数据库），而不影响调用层代码。

2.7.4 增强代码灵活性

多态允许在运行时动态决定调用哪个实现（动态绑定），使程序能根据实际场景灵活调整行为。
例如，一个游戏中，Enemy 基类有 attack() 方法，派生类 Boss、Minion 有不同攻击逻辑，战斗系统可统一调用 attack()，根据当前敌人类型自动执行对应逻辑。

2.7.5 便于单元测试与模块替换

多态支持 “依赖注入”，可在测试中用 mock 对象（模拟实现）替代真实对象，方便隔离测试。
例如，测试网络模块时，可用 MockNetwork 替代真实网络请求，验证业务逻辑而不依赖实际网络环境。

2.7.6 总结

多态的核心价值在于通过抽象接口统一行为，通过派生类实现具体差异，最终实现代码的 “高内聚、低耦合”。它是构建可扩展、可维护大型系统的关键机制，广泛应用于框架设计（如 Qt 的信号槽、Java 的集合框架）、设计模式（如策略模式、工厂模式）等场景。

2.8 动态库有几种方式

在不同操作系统中，动态库（Dynamic Link Library，简称 DLL）的实现和加载方式有差异，但核心是将代码封装为程序运行时可动态加载的模块。以下是动态库的主要分类和加载方式：

2.8.1 按操作系统分类

动态库的文件格式因系统不同而不同：

Windows：.dll（Dynamic Link Library）
Linux/Unix：.so（Shared Object）
macOS：.dylib（Dynamic Library）或 .framework（框架，本质是动态库的封装形式）

2.8.2 按加载时机分类

根据程序加载动态库的时机，核心分为两种方式：

1. 静态加载（隐式链接）

特点：程序启动时，由操作系统自动加载动态库；编译阶段需要链接库的导入库（比如 Windows 的 .lib、Linux 的 .a）。
适用场景：已知动态库的名称和接口，且需要程序启动后就能直接使用该库功能。

实现步骤：

编译时指定动态库的导入库（例如 Windows 用 /link 选项关联 .lib，Linux 用 -l 选项指定 .a）；
程序中包含动态库的头文件，直接调用导出的函数 / 类；
程序启动时，操作系统会自动查找并加载依赖的动态库，若找不到则程序启动失败。

// 包含动态库的头文件，声明导出函数#include \"mylib.h\"int main() { mylib_func(); // 直接调用动态库的函数（静态加载无需手动处理加载逻辑） return 0;}

优点：使用简单，无需手动管理库的加载和卸载，代码逻辑直观。
缺点：程序启动依赖动态库，若库缺失或版本不匹配会导致启动失败；无法在运行中切换动态库版本。

2. 动态加载（显式链接）

特点：程序运行过程中，通过系统提供的 API 手动加载动态库，获取函数 / 类的地址后再调用；编译阶段不需要依赖导入库。
适用场景：需要在运行时决定是否加载库（比如可选功能）、动态切换库版本，或实现插件系统（如软件的扩展插件）。

核心系统 API：

Windows：用 LoadLibrary() 加载库，GetProcAddress() 获取函数地址，FreeLibrary() 卸载库；
Linux/Unix：用 dlopen() 加载库，dlsym() 获取函数地址，dlclose() 卸载库；
macOS：与 Linux 类似，使用 dlopen 系列函数。

示例（C++，跨平台伪代码）：

#include #ifdef _WIN32#include #else#include #endifint main() { // 1. 手动加载动态库#ifdef _WIN32 HMODULE lib = LoadLibrary(\"mylib.dll\"); // Windows 加载 .dll#else void* lib = dlopen(\"./libmylib.so\", RTLD_LAZY); // Linux 加载 .so#endif if (!lib) { // 检查加载是否成功 std::cout << \"动态库加载失败\" << std::endl; return 1; } // 2. 获取动态库中函数的地址（假设函数原型为 void mylib_func()）#ifdef _WIN32 using FuncType = void (*)(); FuncType func = (FuncType)GetProcAddress(lib, \"mylib_func\");#else using FuncType = void (*)(); FuncType func = (FuncType)dlsym(lib, \"mylib_func\");#endif // 3. 调用函数（需先判断函数地址是否有效） if (func) { func(); } // 4. 手动卸载动态库（避免内存泄漏）#ifdef _WIN32 FreeLibrary(lib);#else dlclose(lib);#endif return 0;}

优点：灵活性高，可控制加载 / 卸载时机，支持插件化架构，避免程序启动时依赖动态库；
缺点：需要手动管理库的生命周期和函数地址，代码逻辑比静态加载复杂，且容易因函数地址获取错误导致崩溃。

2.8.3 其他分类方式

按链接方式：
- 位置无关代码（PIC，Position-Independent Code）：动态库的代码可加载到内存任意位置，支持多进程共享（Linux、macOS 等系统默认采用这种方式）；
- 非位置无关代码：依赖固定的内存地址，无法实现多进程共享，目前已很少使用。
按用途：
- 系统动态库：操作系统自带的库（比如 Windows 的 kernel32.dll、Linux 的 libc.so），提供基础系统功能（如内存管理、文件操作）；
- 应用动态库：用户自定义的库，用于封装业务逻辑（比如将工具类、核心算法封装为动态库，供多个程序复用）。

2.8.4 总结

动态库的核心加载方式是静态加载（隐式链接）和动态加载（显式链接）：前者简单但灵活性低，适合基础依赖场景；后者复杂但支持动态控制，适合插件、可选功能等场景。实际开发中需根据功能需求选择合适的方式。

2.9 Qt的内存管理机制

Qt 的内存管理机制是其核心特性之一，主要基于对象树（Object Tree） 设计，极大简化了内存管理复杂度，减少了内存泄漏风险。以下是其核心机制的详细说明：

2.9.1 对象树（Object Tree）机制

Qt 中，QObject 及其派生类（如窗口、控件等）可以形成父子关系：

当一个对象（子对象）被创建时指定了父对象，它会被自动加入父对象的子对象列表
父对象销毁时，会自动销毁所有仍在列表中的子对象，无需手动 delete

QWidget* parent = new QWidget; // 父对象QPushButton* child = new QPushButton(\"按钮\", parent); // 指定parent为父对象delete parent; // 销毁父对象时，会自动销毁child，无需单独delete child

2.9.2 手动管理与自动管理的协同

即使手动销毁子对象，也不会导致冲突：

手动调用 delete child 时，子对象会先从父对象的列表中移除
父对象销毁时，不会重复销毁已手动删除的子对象

这避免了双重释放问题，确保内存操作安全。

2.9.3 `deleteLater()` 延迟销毁

Qt 提供 QObject::deleteLater() 方法，用于安全地延迟销毁对象：

该方法会在当前事件循环结束后，自动销毁对象
适用于在信号槽中销毁对象（避免销毁正在处理事件的对象）

示例：

// 安全销毁对象，避免在信号处理中引发问题child->deleteLater(); // 不会立即销毁，而是在事件循环空闲时执行

2.9.4 无父对象的情况

如果对象没有父对象（创建时未指定父指针），则需要手动销毁：

QWidget* widget = new QWidget; // 无父对象// ... 使用后 ...delete widget; // 必须手动销毁，否则内存泄漏

2.9.5 特殊注意事项

父对象必须是 QObject 派生类：只有 QObject 及其子类才支持对象树机制
不要在栈上创建父对象、堆上创建子对象：可能导致子对象被析构两次（栈对象销毁时触发子对象销毁，之后堆对象再被手动删除）
避免循环引用：若 A 是 B 的父对象，同时 B 又是 A 的父对象，会导致销毁时逻辑混乱（需手动打破循环）

2.9.6 总结

Qt 的内存管理核心是对象树自动销毁 + 手动管理补充：

大多数情况下，通过设置父子关系，只需管理顶层对象的生命周期
特殊场景（如无父对象、延迟销毁）需手动干预，但机制本身已处理大部分边缘情况

这种设计大幅降低了内存管理难度，是 Qt 开发高效、稳定的重要保障。

2.10 重写和重载有啥区别

重写（Override）和重载（Overload）是面向对象编程中两个容易混淆的概念，它们的核心区别体现在目的、实现方式和作用场景上。以下是具体对比：

2.10.1 重写（Override）：父子类间的方法覆盖

定义：在继承关系中，子类重新实现父类中已有的同名、同参数列表、同返回值类型的方法（通常是虚函数），以改变或扩展父类方法的行为。

核心特点：

发生场景：必须存在继承关系（子类 → 父类）
方法签名：方法名、参数列表、返回值类型完全相同（C++ 中协变返回类型除外）
访问权限：子类重写方法的访问权限不能比父类更严格（如父类是public，子类不能是private）
关键字：C++ 中用override显式标识（推荐），Java 中用@Override注解
绑定方式：运行时动态绑定（多态的基础）

示例（C++）：

class Animal {public: virtual void makeSound() { // 父类虚方法 cout << \"动物叫\" << endl; }};class Dog : public Animal {public: void makeSound() override { // 重写父类方法 cout << \"汪汪叫\" << endl; }};// 多态调用：运行时根据对象实际类型执行重写后的方法Animal* animal = new Dog();animal->makeSound(); // 输出：汪汪叫

2.10.2 重载（Overload）：同一类中的方法多态

定义：在同一类中，定义多个同名但参数列表不同的方法，以实现 “同一操作，不同输入” 的灵活调用。

核心特点：

发生场景：同一类中（或子类对父类非重写方法的重载）
方法签名：方法名相同，但参数列表不同（参数类型、个数、顺序不同）
返回值：返回值类型可以不同（但不能仅通过返回值区分重载）
绑定方式：编译时静态绑定（根据调用时的参数类型 / 个数确定调用哪个方法）

示例（C++）：

class Calculator {public: // 重载：同名不同参数 int add(int a, int b) { return a + b; } double add(double a, double b) { return a + b; } // 参数类型不同 int add(int a, int b, int c) { return a + b + c; } // 参数个数不同};// 调用时根据参数自动匹配Calculator calc;calc.add(1, 2); // 调用int add(int, int)calc.add(1.5, 2.5); // 调用double add(double, double)

2.10.3 关键区别总结

概念场景方法签名要求绑定方式核心目的重写父子类，父类有虚函数同名、同参数、同返回值运行时绑定多态：子类改写父类实现重载同一类中同名、不同参数（类型 / 个数）编译时绑定同一操作适配不同输入重定义父子类同名、参数不同；或参数相同但父类非虚函数编译时绑定子类方法隐藏父

2.10.4 常见误区

子类中定义与父类同名但参数不同的方法，不是重写，而是对父类方法的重载（此时父类方法在子类中被隐藏）。
仅返回值不同的方法不能构成重载（编译时无法区分）。
重写依赖继承和虚函数机制，而重载不依赖继承。

理解两者的区别，有助于正确设计类的接口和利用多态特性，写出更灵活、可维护的代码。

2.11 Qt什么时候安装过滤器

在 Qt 中，安装事件过滤器（Event Filter）的时机主要取决于需要监控或拦截哪个对象的事件，核心原则是：在目标对象的事件处理流程开始前安装，确保过滤器能有效捕获事件。

具体场景和时机如下：

2.11.1 初始化阶段安装（最常见）

通常在窗口或对象的构造函数中，或初始化方法（如 setupUi 之后）安装过滤器。
此时目标对象已创建，且尚未进入事件循环，能确保过滤器从对象生命周期初期就生效。
示例：

MyWidget::MyWidget(QWidget *parent) : QWidget(parent) { // 初始化子控件 lineEdit = new QLineEdit(this); // 给 lineEdit 安装过滤器，当前窗口作为过滤器对象 lineEdit->installEventFilter(this);}// 重写事件过滤函数bool MyWidget::eventFilter(QObject *watched, QEvent *event) { if (watched == lineEdit && event->type() == QEvent::KeyPress) { // 处理 lineEdit 的键盘事件 return true; // 拦截事件，不再向下传递 } return QWidget::eventFilter(watched, event);}

2.11.2 动态安装（根据业务逻辑触发）

当需要在特定条件下临时监控对象事件时，可在业务逻辑中动态安装。
例如：点击按钮后开始监控某个控件的事件，完成操作后移除过滤器。
示例：

void MyWidget::on_startMonitorBtn_clicked() { // 动态给目标对象安装过滤器 targetWidget->installEventFilter(this);}void MyWidget::on_stopMonitorBtn_clicked() { // 移除过滤器 targetWidget->removeEventFilter(this);}

注意事项
- 过滤器对象（安装者）的生命周期必须长于目标对象，否则过滤器失效可能导致崩溃。
- 若要监控多个对象，可在 eventFilter 中通过 watched 参数区分不同目标。
- 事件过滤器可多层嵌套（A 给 B 安装，B 给 C 安装），事件会先经过上层过滤器。

总结：大多数情况下，在目标对象创建后、进入事件循环前（如构造函数中）安装过滤器是最稳妥的方式，能保证事件从一开始就被监控；特殊场景下可根据业务逻辑动态安装 / 移除。

2.11.3 Qt 的事件过滤器（Event Filter）

Qt 的事件过滤器（Event Filter）是一种强大的事件处理机制，允许一个对象（过滤器）监控另一个对象（目标对象）的事件，并在事件到达目标对象前进行拦截、修改或处理。它是 Qt 事件系统中灵活扩展事件处理的重要方式。

核心原理:

事件过滤器的工作流程：

过滤器对象通过 installEventFilter(QObject *filterObj) 为目标对象安装过滤
当目标对象有事件发生时，事件会先发送到过滤器的 eventFilter() 函数
在eventFilter()中，可选择：
- 处理事件并返回 true：事件被拦截，不再传递给目标对象
- 不处理事件并返回 false：事件继续传递给目标对象的事件处理函数

2.12 对CAD有啥理解？几何和网格的区别？

要回答对 CAD 的理解以及几何与网格的区别，需要从 CAD 的核心定位、技术逻辑切入，再聚焦 “几何” 和 “网格” 这两个 CAD 中最基础的图形表示载体，通过定义、用途、特性、典型场景的对比讲清差异。以下是结构化的梳理，适合面试或技术沟通场景：

2.12.1 对 CAD 的核心理解

CAD（Computer-Aided Design，计算机辅助设计）本质是用计算机技术替代 / 辅助人工绘图与设计的工具体系，核心价值是 “提升设计效率、保证精度、支持协同与下游衔接”，而非单纯 “画图纸”。

从技术和应用维度，可拆解为 3 个核心点：

设计载体：以 “数字模型” 为核心
CAD 不只是生成 2D 工程图（如零件尺寸标注、装配图），更核心是构建 3D 数字模型 —— 包含零件的几何形状、材料属性、装配约束（如螺栓与孔的配合间隙）、工艺信息（如倒角、公差），是 “全信息模型”（而非单纯图形）。
技术逻辑：覆盖 “设计 - 验证 - 协同 - 下游衔接” 全流程

不是孤立的绘图工具：
- 设计阶段：支持参数化建模（如修改一个尺寸，关联特征自动更新）、拓扑优化（按受力需求自动简化结构）；
- 验证阶段：嵌入仿真功能（如 CAD 模型直接导入有限元软件做强度分析，无需重新建模）；
- 下游衔接：模型可直接对接 CAM（计算机辅助制造，生成机床加工代码）、BOM（物料清单自动生成）、3D 打印（导出 STL 文件），实现 “设计 - 制造” 数据无缝流转。
行业适配：分领域定制化

不同行业的 CAD 工具侧重不同：
- 机械设计：如 AutoCAD（2D）、SolidWorks/UG（3D 参数化，侧重零件 / 装配）；
- 建筑设计：如 Revit（侧重建筑构件的 BIM 模型，关联施工、成本信息）；
- 工业设计：如 Rhino（侧重自由曲面建模，如汽车外观、家电造型）；
- 电子设计：如 Altium Designer（PCB 板设计，本质是 “电子元器件的 CAD 布局”）。

2.12.3 几何（Geometry）与网格（Mesh）的核心区别

在 CAD（尤其 3D 设计）中，“几何” 和 “网格” 是两种完全不同的模型表示方式，核心差异源于 “是否精确描述形状” 和 “用途场景”，具体可通过下表对比：

对比维度几何（Geometry）网格（Mesh）核心定义用数学公式 / 参数精确描述物体形状的 “精确模型” 用离散的多边形（2D）/ 多面体（3D） 逼近物体形状的 “近似模型” 表示方式 - 2D：直线（y=kx+b）、圆（x²+y²=r²）、贝塞尔曲线（参数方程）； - 3D：平面、球面（x²+y²+z²=r²）、NURBS 曲面（非均匀有理 B 样条，工业设计核心） - 2D：由三角形、四边形组成的 “面集合”； - 3D：由四面体、六面体（最常见）、三角形面片组成的 “单元集合”（每个单元有顶点、边、面的拓扑关系）精度特性 绝对精确：形状由数学关系定义，无论放大多少倍，细节（如圆弧的曲率）始终准确，无误差 近似逼近：多边形 / 多面体数量越多（网格越密），越接近真实形状，但始终是 “离散拟合”，存在误差（如用 100 个三角形逼近一个圆，放大后能看到棱角）数据量小：仅存储数学参数（如圆只需存储圆心坐标 + 半径）大：需存储所有顶点的坐标、单元的拓扑关系（如 “哪个顶点属于哪个单元”），网格越密，数据量呈指数级增长核心用途 1. 设计阶段：构建精确的零件 / 装配模型（如机械零件的尺寸、公差需精确传递）； 2. 工程图生成：从几何模型导出带精确尺寸的 2D 图纸； 3. 参数化修改：直接修改数学参数（如将圆半径从 5mm 改为 8mm），模型实时更新 1. 仿真分析：有限元分析（FEA）、流体仿真（CFD）的核心载体 —— 网格单元是 “计算单元”，软件通过对每个单元求解物理方程（如应力、流速）得到整体结果； 2. 可视化渲染：游戏、动画、3D 展示中快速渲染（网格越密，渲染越细腻，但速度越慢）； 3. 快速制造：3D 打印导出的 STL 文件本质是 “三角形网格” 典型工具关联所有 CAD 的 “建模核心”（如 SolidWorks 画的零件是几何模型） CAD 的 “导出 / 转换结果”（如将 SolidWorks 零件导出为 STL 网格）、仿真软件的 “输入文件”（如 ANSYS 导入网格模型计算）

2.12.3关键总结（帮你快速记忆）

对 CAD：不只是 “画图”，是 “数字模型驱动的设计全流程工具”，核心是 “精确、协同、对接下游”；
几何 vs 网格：几何是 “精确的数学定义”（用于设计），网格是 “离散的多边形逼近”（用于仿真 / 渲染） —— 前者是 “设计的源头”，后者是 “设计的应用转化”。

博维智航（彭州）——面试

文章目录

一、公司背景

二、问题

2.1 图像学相关问题

2.2 静态库，动态库

2.2.1 核心概念与本质

2.2.2 静态库（Static Library）

2.2.3 动态库（Dynamic/Shared Library）

2.2.4 静态库 vs 动态库：关键区别对比

2.2.5 适用场景选择

2.2.6 跨平台差异补充

2.2.7 动态库依赖问题：DLL 地狱

2.2.8 总结

2.3 Qt的元系统机制

2.3.1 元对象系统的核心组成

2.3.2 元对象系统的核心功能

2.3.3 元系统的实现原理简析

2.3.4 元系统的典型应用场景

2.3.5 总结

2.4 Qt撤销功能如何做的

2.4.1 核心组件与工作原理

2.4.2 高级特性

2.4.3 适用场景

2.4.4 总结

2.5 Qt用了那些控件

2.5.1 基础交互控件（用户输入与展示）

2.5.2 容器控件（布局与分组）

2.5.3 高级功能控件（复杂交互）

2.5.4 回答技巧

2.6 Qt子对象销毁了父对象如何销毁呢

2.7 多态机制有啥优势呢

2.7.1 代码复用与扩展性

2.7.2 简化代码逻辑

2.7.3 接口与实现分离

2.7.4 增强代码灵活性

2.7.5 便于单元测试与模块替换

2.7.6 总结

2.8 动态库有几种方式

2.8.1 按操作系统分类

2.8.2 按加载时机分类

2.8.3 其他分类方式

2.8.4 总结

2.9 Qt的内存管理机制

2.9.1 对象树（Object Tree）机制

2.9.2 手动管理与自动管理的协同

2.9.3 deleteLater() 延迟销毁

2.9.4 无父对象的情况

2.9.5 特殊注意事项

2.9.6 总结

2.10 重写和重载有啥区别

2.10.1 重写（Override）：父子类间的方法覆盖

2.10.2 重载（Overload）：同一类中的方法多态

2.10.3 关键区别总结

2.10.4 常见误区

2.11 Qt什么时候安装过滤器

2.11.1 初始化阶段安装（最常见）

2.11.2 动态安装（根据业务逻辑触发）

2.11.3 Qt 的事件过滤器（Event Filter）

2.12 对CAD有啥理解？几何和网格的区别？

2.12.1 对 CAD 的核心理解

2.12.3 几何（Geometry）与网格（Mesh）的核心区别

2.12.3关键总结（帮你快速记忆）

相关问题

公告

DeepSeek全套部署资料免费下载

免费可商用字体批量下载

标签

2.9.3 `deleteLater()` 延迟销毁