1. 信号与槽到底解决了什么问题1.1 从回调函数说起做过几年Qt开发的人都会有个感受信号与槽Signal Slot这套机制初看有点绕用熟了之后根本离不开。但很多人并没有真正想过Qt当初为什么要设计这么一套东西而不是直接沿用C/C世界里最常见的回调函数。先回忆一下传统回调是什么形态。在C语言时代我们要让一个按钮点击事件触发某个处理逻辑通常是给控件注册一个函数指针事件发生时就调用这个指针指向的函数。代码大概长这样void onButtonClicked() { printf(button clicked\n); } button.onClick onButtonClicked;这套模式在简单的场景下没什么问题。但一旦项目复杂起来痛点非常明显。比如回调函数属于某个类的成员函数你需要用std::bind或者static_cast把this指针塞进去代码一下就变得很丑。更麻烦的是如果同一个事件被多个对象同时监听你需要在事件源里维护一个回调列表手动注册、手动注销稍不留神就会漏掉清理造成悬空指针。在Qt里早期的按钮事件也是通过回调宏实现的那会儿叫QButton::clicked()信号配合connect()写法比现在原始得多。后来在Qt 1.x到2.x的演进过程中TrolltechQt的母公司意识到回调这条路走不远才逐步把信号与槽定位为核心机制并配套设计了元对象系统Meta-Object System来支撑它。说到底信号与槽解决的是三个问题对象间通信的松耦合、成员函数作为事件响应的类型安全、以及多对多关联的可管理性。一个信号可以连接多个槽一个槽可以被多个信号触发而且连接关系可以在运行时动态建立和拆除。对象之间不需要互相知道对方的存在发出信号的对象甚至不知道自己的信号被谁接收这是回调函数很难做到的。1.2 信号与槽的核心思路信号与槽的思路其实可以用一个很生活中的场景来理解你在楼道里按电梯按钮电梯根本不知道你是谁它只是发出了一个有人按了向上按钮的消息。物业接线员接到消息后安排电梯下来接你。整个过程里按钮不关心电梯是谁电梯也不关心按钮是谁中间只靠一个消息来传递意图。对应到Qt里电梯按钮就是一个信号发送者Sender它发出一个clicked()信号物业接线员是Qt的元对象系统负责建立和维护连接电梯的响应行为就是槽函数Slot负责实际执行下楼接人的逻辑。Qt官方文档里明确说过信号就是普通的成员函数只是在类声明里加了signals:关键字声明编译器按照普通函数处理但实际执行的是由mocMeta-Object Compiler生成的分发代码。槽也一样本质上就是普通的成员函数可以被当作普通函数直接调用也可以被connect()绑定成信号接收者。关键的是信号与槽连接建立的时机很灵活。你可以在构造对象的时候连接也可以在用户点击某个按钮之后动态连接甚至可以在运行时断开一个连接然后在别的地方重新建立。这种动态性给UI编程带来了巨大的便利。我见过很多新手问信号和槽是不是只能用在界面程序里我的答案是信号槽从设计上就与界面无关任何继承自QObject的类都可以定义信号和槽。我在做一些底层通信模块时经常让一个串口服务类在收到完整数据帧时发出dataReceived(QByteArray)信号让界面层去连接这个信号做展示底层模块完全不需要知道界面长什么样。2. 信号与槽的内部工作机制2.1 元对象系统在背后做了什么信号与槽看起来像是魔法但拆开看原理其实很朴素C的成员函数指针 一个注册表 一个调度的switch-case。Qt的moc编译器会扫描每个继承QObject的类定义遇到signals:、slots:和Q_OBJECT宏时就自动生成一个额外的C源文件moc_xxx.cpp。这个文件里包含一个静态的元对象实例staticMetaObject用一个字符串表记录类的所有信号、槽、属性名和参数类型名。每个函数在表里都有一个固定的索引信号发射时实际上是调用了QMetaObject::activate这个函数。到这一步activate会做什么说到底就是遍历该信号上的所有连接根据连接类型决定是直接调用槽函数指针还是投递一个QMetaCallEvent事件到接收者的事件队列。这个过程整体就是一个大型的switch-case分发。举个例子你就明白了。假设有这样一个简单的类class Counter : public QObject { Q_OBJECT public: Counter() : m_value(0) {} signals: void valueChanged(int newValue); public slots: void setValue(int value) { if (value ! m_value) { m_value value; emit valueChanged(value); } } private: int m_value; };emit valueChanged(value)这行代码在预处理后其实是调用一个普通的成员方法valueChanged(int)只不过这个方法的定义不是你自己写的而是moc生成在moc_Counter.cpp里的。它内部拿到newValue然后调用QMetaObject::activate(this, Counter::staticMetaObject, 信号索引, newValue)把参数以void **的格式塞进参数数组里。这就是为什么信号的所有参数类型都必须是已知的——元对象系统在运行时并不知道你的C类型它只知道字符串形式的名字参数传递全靠内存地址。如果你在connect时的信号和槽参数类型名字对不上Qt会在运行时打印类似QObject::connect: Cannot queue arguments of type Foo的警告然后拒绝连接。信号槽机制依赖元对象系统所以凡是使用信号槽的类必须在类的声明里加上Q_OBJECT宏并且让头文件参与moc编译。这是新手最常犯的错误——定义了带信号槽的类却忘了加Q_OBJECT结果编译报了各种莫名其妙的错误或者干脆连不上。2.2 三种连接方式怎么选Qt::ConnectionType枚举定义了Qt支持的五种连接方式常用的有三种Qt::DirectConnection、Qt::QueuedConnection和Qt::AutoConnection。剩下的BlockingQueuedConnection和UniqueConnection后文再讲。DirectConnection是直连信号一发出槽函数立即在同一线程、同一调用栈里执行。这就好像你给前台打了个电话接起来就直接对话实时性最好但槽函数会阻塞信号发射者。QueuedConnection是队列连接信号发出后Qt会把调用参数打包成一个QMetaCallEvent投递到接收者所在线程的事件队列里。接收者必须运行着事件循环比如主线程的QCoreApplication::exec()稍后在事件循环里再执行槽函数。这就好比写了一封邮件发出去对方什么时候读到不一定但保证他会读到。AutoConnection是Qt默认的方式它根据发射线程和接收者所在线程的关系自动选择相同线程用直连不同线程用队列连接。这个默认对绝大多数情况是合理的所以大多数代码里你只需要写connect(sender, Sender::sig, receiver, Receiver::slot);什么都不用管。选择连接方式的关键在于你是否需要槽函数立即执行以及当前槽函数的执行会阻塞谁。举个例子如果你在UI线程里点击按钮信号触发后希望在同一个UI线程里立即弹出一个对话框AutoConnection就会选择直连槽立即执行完全符合预期。可如果接收者对象是另一个工作线程的所有者你就得确保用队列连接让槽函数在自己线程里慢慢跑而不是占着UI线程。2.3 连接的本质一个三元组每个信号槽连接在Qt内部其实是一个三元组发送者对象指针、信号索引、接收者对象指针或函数指针槽索引。connect做的事情就是把这三样东西注册到发送者内部的连接列表里。信号被emit时Qt从连接列表里取出所有匹配的连接逐一处理。这带来一个重要推论连接一旦建立它就持有发送者和接收者的指针。如果接收者被销毁而发送者还在连接没有自动清理发射信号时就会去访问一个已经失效的地址——这就是Qt程序莫名其妙的崩溃原因之一。反过来也一样发送者被销毁了连接依然留下接收者的槽函数不会再有调用这倒问题不大但如果你在槽函数里用了发射者的状态也要小心悬空。好在你不用特别担心这个因为QObject析构函数会自动调用disconnect把与这个对象相关的所有连接都拆除。前提是你删除了对象。如果你用了裸指针却忘了delete那谁也救不了你。凡是涉及对象生命周期交叉的地方我都习惯在connect时把this作为Context对象或者显式在接收者析构时disconnect这样才能保证干净退出。开发中连续踩过几次因为删除时序不对导致的崩溃之后我总结出一条铁律谁创建谁销毁销毁前先断连。3. 手写第一个信号槽从建工程到跑通3.1 自定义信号与槽的完整示例说了这么多理论还是得动手写一遍。我用一个最简单的假想场景来演示窗口上放一个按钮点一下下方的标签就显示hello signal slot。第一步创建一个继承QObject的类声明信号和槽。注意信号只需要声明不需要定义定义由moc完成槽就是普通成员函数你要自己写实现。// worker.h #pragma once #include QObject class Worker : public QObject { Q_OBJECT public: explicit Worker(QObject *parent nullptr); public slots: void doWork(const QString message); signals: void workDone(const QString result); };// worker.cpp #include worker.h #include QDebug Worker::Worker(QObject *parent) : QObject(parent) {} void Worker::doWork(const QString message) { qDebug() Worker received: message; emit workDone(done: message); }第二步写一个窗口或者直接用QCoreApplication跑起来。下面的代码展示了一个最简单的连接生命周期#include QCoreApplication #include worker.h int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); Worker sender; Worker receiver; QObject::connect(sender, Worker::workDone, receiver, Worker::doWork); sender.workDone(start); // 直接调用信号函数效果等同于 emit return a.exec(); }在这个例子里sender.workDone(start)会触发信号接收者的doWork被调用打印出Worker received: start然后emit workDone(done:start)又触发另一个信号但这次没有连接了所以什么都不会发生。注意信号的函数名后面直接带括号调用是合法的emit只是一个空宏纯粹给人看代码时标注这里发生了信号发射。第三步跑起来之前在.pro文件里确认包含了QT core然后用qmake或CMake构建。CMake用户需要在target_link_libraries里链上Qt5::Core还有别忘了AUTOMOC要开启CMake的CMAKE_AUTOMOC属性否则moc不会执行。这里有个非常常见的坑如果你新建一个类文件然后手动修改了类定义比如加了Q_OBJECT但没有保存头文件构建工具可能不知道需要重新生成moc文件。遇到明明加了Q_OBJECT却编译报未定义的引用时可以先执行一次qmake make clean再构建。我平时也会在IDE里直接把moc_xxx.cpp文件删掉强制moc重新生成这样能省掉排查时间。3.2 带参数的信号如何传参数传递是信号槽使用中绕不开的环节。先说明一点信号的参数类型必须和槽的参数类型兼容所谓兼容不是完全相同而是槽的参数类型可以是信号参数类型更宽松的版本。举个例信号void sig(int x)可以连接槽void slot(double x)因为int可以隐式转换为double但信号void sig(double x)不能直接连接到void slot(int x)因为反过来会丢失精度。在跨线程队列连接时Qt对参数类型有额外的要求参数类型必须是Qt元系统认识的类型。像int、QString、QListint这些内置类型没问题但如果是自定义结构体比如struct Point { int x; int y; };直接拿来跨线程传参你会收到一条警告QObject::connect: Cannot queue arguments of type Point原因很简单队列连接要把参数值保存起来等接收者线程从事件循环取出时再重建。这个过程Qt不认得Point需要有拷贝构造、析构和类型注册信息。解决办法是在结构体里声明Q_DECLARE_METATYPE宏#include QMetaType Q_DECLARE_METATYPE(Point);然后在main()里或者使用前调用qRegisterMetaTypePoint(Point);这样Qt才能把它当成一个可序列化的元类型来排队处理。做多线程数据通信时qRegisterMetaType几乎必写不过很多人不知道它还接受一个字符串参数来指定类型名这个类型名会用于运行时类型检查。再说一个真正踩过坑的点信号参数最好用引用还是值跨线程队列连接时Qt会自动拷贝一份参数无论你写const QString 还是QString效果一样因为队列连接在事件里保存的是值。但同线程直连时如果你用引用等于直接把地址传给了槽函数槽函数里执行时间长了发送者那边的变量可能已经被修改——不过这只是设计层面上需要小心实际使用中大多数推荐用值类型或const引用均可保持一致就行。3.3 信号连接信号与槽函数重载信号参数可以少槽参数可以多吗不行方向是反的。信号必须有足够的参数供槽使用。换句话说信号是发起方槽是消费方消费方可以只消费一部分信息。举个例子QSpinBox::valueChanged(int)信号可以连接到QLabel::setNum(int)槽参数一一对应也可以连接到QLabel::clear()槽这个槽不要参数它对信号携带的值毫不关心这完全合法。反过来如果信号只有一个参数而槽需要两个参数那就是超卖Qt会在连接时给出警告并拒绝。信号连接信号也是一种常见需求。比如你想在某个进度条发生变化时顺带让另一个对象进入忙碌状态。你可以定义busyChanged(bool)信号然后在构造函数里connect(progress, QProgressBar::valueChanged, this, MainWindow::busyChanged);这样当进度条值变化时内部逻辑自动把busyChanged这层信号转发出去。这样做的意义在于解耦——MainWindow可以同时监听多个控件的状态而不必在每个控件的事件处理里重复调用操作方法。槽函数还存在重载的情况。比如QComboBox::currentIndexChanged有两个重载版本void currentIndexChanged(int)和void currentIndexChanged(const QString )。直接写connect(combo, QComboBox::currentIndexChanged, this, onIndexChanged)会报编译错误因为编译器不知道你要取哪个指针。需要显式强转这个语法是Qt开发中最常见的重载坑之一connect(combo, QOverloadint::of(QComboBox::currentIndexChanged), this, MainWindow::onIndexChanged);如果项目用的编译器支持C14也可以换成qOverloadint(QComboBox::currentIndexChanged)。说实话写多了你会发现QOverload这套语法看着别扭但一旦养成习惯以后再遇到其他重载信号也就不会卡顿。唯一要留意的是连接函数里的信号函数指针如果带重载接收槽的重载也会同时面临这个问题都要用QOverload显式指定。4. 多线程场景下的信号槽实战4.1 线程、事件循环与连接方式的关系很多网上教程讲到多线程信号槽时只会教你在线程里发信号在主线程连接却没说清楚为什么信号能跨线程安全地传递参数。理解这个关键是搞清楚线程和事件循环的关系。每个QThread对象有一个run()方法默认实现会调用exec()启动事件循环。但注意QThread对象本身属于创建它的线程——通常是主线程。真正跑新代码的是线程执行体也就是你在run()里写的那些函数或者通过moveToThread移动过去的工作对象。信号槽的接收者执行槽函数时看的是接收者对象所属的线程不是信号发射者的线程。举例Worker对象被moveToThread(thread)移到了子线程thread.start()后Worker的槽函数doWork()虽然在代码层面是由主线程的信号触发的但Qt会投递事件到Worker所在线程的事件循环由子线程执行。这就是队列连接的逻辑。连接类型的选择上我一般遵循一个原则如果发送者对象和接收者对象的所属线程不同且你需要数据完整传递请强制使用QueuedConnection或者依赖AutoConnection的默认跨线程判断不要使用DirectConnection否则槽函数会在发送线程执行相当于在子线程里直接调用UI方法轻则数据竞争重则直接崩溃。4.2 跨线程传参数最容易踩的坑热词里专门有qt 信号槽多线程传参数实例说明这是很多人关心的点。我挑一个最有代表性的坑来拆在循环里用lambda捕获循环变量传参数。看下面这段代码for (int i 0; i 10; i) { QThread *t new QThread; Worker *w new Worker; w-moveToThread(t); connect(t, QThread::started, w, [this, i]() { w-process(i); }); t-start(); }看起来每种循环变量i都被lambda捕获了应该没问题。但如果你用引用捕获[]循环变量i在lambda真正执行时可能已经被修改因为lambda是在另一个线程执行的执行时机远晚于捕获时机。这就是经典的传出引用导致数据竞态问题。另一个容易踩的坑是跨线程传递QString参数时发送者在线程里使用的QString对象可能在排队过程中被销毁因为队列连接要求参数可以拷贝构造。如果你传的是一个裸指针、或者一个未注册的元类型就会触发前面说的Cannot queue arguments of type Foo警告连接直接失效。再有一种情况你想跨线程传一个容器比如QListMyStruct。队列连接事件在投递时需要对整个列表做深拷贝如果MyStruct里含有指针成员Qt只拷贝指针地址两个线程就会共享同一块内存。这时候表面上看信号也发射了槽函数也执行了但实际上数据已经被另一个线程改乱了。这类野指针式数据竞争很难定位我用过的排查方法是在槽函数里加一段数据校验或者在发送前后打印指针地址看是否一致。4.3 队列连接的原理与线程安全队列连接之所以能在不同线程之间安全地传递参数是因为它在信号发射时拷贝一份参数数据存进一个QMetaCallEvent对象里然后通过QCoreApplication::postEvent发送到接收者线程的事件队列。等待接收者线程的事件循环从队列里取出这个事件再解析出参数并调用槽函数。所以从数据安全的角度看槽函数拿到的参数是一份独立副本正常情况下与发送线程中的数据无关。很多人会问那这样参数拷贝的性能开销是不是很大对int、double这种基础类型开销可以忽略不计对象内含容器比如QStringList时一次跨线程信号发射等于做了一次深层拷贝频繁发射大体积对象要小心性能恶化。我之前做过一个低频遥测数据上报功能每帧携带一个几百KB的字节数组跨线程发信号时明显感觉UI卡顿。后来改成发送共享指针或者把数据存到内存池、只发索引才把延迟降下来。再提一点线程安全设计接收者对象的槽函数在哪个线程执行就应该只访问那个线程的资源。比如UI线程的槽函数里可以放心操作控件但子线程对象里的槽函数里不能直接去改UI标签文字——即便编译不报错也可能造成未知的崩溃或闪烁。正确做法是子线程发信号到UI线程让UI自己更新自己。5. 常见问题与排查技巧实录5.1 信号发出但槽没执行这是信号槽开发中最经典的神问题emit也执行了连接看着也对可槽就是不执行。我自己排查这类问题时固定按下面五个步骤走通常很快定位。第一检查两个对象是否都活着。连接建立后如果接收者或发送者被delete了信号照样发射但槽不会执行因为Qt在信号发射时会检查接收者是否还在。这时候用调试器在信号函数上打断点、观察接收者指针一眼就能看出问题。第二检查类型是否注册。跨线程传自定义类型时请求头文件里是否有Q_DECLARE_METATYPE运行时是否qRegisterMetaType。少一个Qt都不会报参数错误只会悄悄把连接断掉。第三检查信号和槽的参数是否匹配。匹配规则前面说过了信号参数数量 槽参数数量且对应位置类型可转换。这里有个容易忽略的细节QString和const char *在连接层面并不是自动转换的connect的参数检查是严格的元类型匹配不是C隐式转换。第四检查是否用对了线程上下文。我遇到过一次信号发射者在子线程接收者也在子线程但接收者线程没有启动事件循环——run()里直接执行完就返回了队列事件根本处理不了槽自然永远不会执行。解决方法就是确保线程事件循环跑起来或者在run()末尾调用exec()保持循环。第五实在找不到原因时把连接类型显式改成Qt::DirectConnection试一下。如果改成直连后槽函数立即执行说明就是事件循环或跨线程投递的问题如果改成直连后槽函数还是不执行那就要回到前面的检查项从对象生命周期、连接是否建立成功connect布尔返回值去查了。5.2 编译报错和unknown module信号槽相关的编译错误通常分两类一类是未定义的引用moc生成的文件没有参与编译另一类是unknown module(s) in qt: webenginewidgets这种属于qmake工程里模块引用错误。未定义的引用出现最多的情况就是Q_OBJECT宏忘写了或者头文件没有在编译列表里。在qmake工程里所有包含Q_OBJECT的头文件必须出现在HEADERS变量、源文件必须出现在SOURCES变量中这样qmake才会为它们生成moc规则。CMake工程则务必确认AUTOMOC开启并且头文件加入了target的源文件列表。unknown module这类错误就简单了它说的是.pro文件里写的QT webenginewidgets在当前Qt版本不存在。Qt 5.15里WebEngine相关模块有可能没被安装默认Qt安装器不勾选后面可以通过Qt Maintenance Tool补装对应模块或者在.pro里去掉多余的引用。同理cannot find -lpublic这种链接错误常见于某个库路径没配好、库文件名写错。检查库名大小写和.a/.so/.dll后缀也要注意Linux下库名一般libxxx.so链接参数写成-lxxx。5.3 lambda表达式的生命周期陷阱Qt 5之后的connect支持lambda作为槽写起来确实舒服但有两个生命周期陷阱必须提醒。第一个是捕获了栈变量却在事件循环里延迟执行。比如你在函数里声明一个局部变量然后connect一个信号、赋上lambda去捕获这个局部变量而这个信号是在很久以后发出的跨线程事件或者定时器触发此时局部变量早已离开作用域。如果lambda是值捕获还好副本还在如果是引用捕获[]那访问到的就是一个悬空引用。第二个陷阱是连接上下文。如果lambda连接时只传给了发送者和lambda没有指定Context对象那么发送者析构时连接会消失但如果发送者存活而接收方的this先被销毁lambda内的this就失效了。解决方法是使用带Context的connect重载版本connect(sender, Sender::sig, this, [this]() { callMember(); });这里的this就是Context当this被销毁时连接会自动断开lambda不会再执行。我用这个模式来给子线程注册回调时特别顺手彻底杜绝了对象销毁后回调触发崩溃的问题。6. 进阶性能优化与实用建议6.1 连接开销与精细控制信号与槽机制最常被吐槽的是性能问题。诚然一个信号发射比直接调用函数慢通常慢几十纳秒到几微秒级别。原因在于要查连接表、按类型处理参数、可能做拷贝和投递事件。但大量实测表明这种开销在大多数桌面应用里完全不是瓶颈。真正的性能杀手是频繁跨线程发射携带大对象的信号这时候数据拷贝才是开销大头。如果你想压榨性能可以考虑用Qt::DirectConnection配合Qt::UniqueConnection来避免重复连接。Qt::UniqueConnection是ConnectionType的一个标志位加在连接类型上之后如果同样的发送者、信号和接收者、槽之间已经存在连接新的connect不会生效。这个对那种在运行时反复设置UI状态的逻辑很有用避免同一逻辑被触发多次。另一个优化点QObject的连接在建立时默认有较细的校验。如果你确定连接参数不合法可以让connect返回false但实际开发中很少人去检查这个返回值。我的建议是在调试模式下写一个辅助宏凡connect返回假就打印警告或者直接qFatal能尽早暴露写错的类名或信号名。6.2 高级用法速查表整理一份平时用的信号槽高级用法速查表方便参考需求推荐做法说明动态断开连接disconnect(sender, Sender::sig, receiver, Receiver::slot)断开前先确认参数匹配否则匹配失败不影响现有连接信号转发信号连接信号在类构造里连接适合做事件聚合层在任意线程安全调用槽函数QMetaObject::invokeMethod(obj, slotName, Qt::QueuedConnection)不需要建立连接直接投递一个槽调用事件临时屏蔽某个连接用bool标志位在槽函数内提前返回不推荐频繁connect/disconnect状态切换成本高lambda捕获this时自动断开connect(sender, Sender::sig, this, [...]{...})用接收者作为Context安全可靠自定义类型跨线程Q_DECLARE_METATYPE qRegisterMetaType必须在信号发射前完成注册全工程应只注册一次避免重复连接connect(..., Qt::UniqueConnection)也可以自己用布尔标志记录连接状态QMetaObject::invokeMethod是个容易被忽视的宝贝。有时候你并不需要一个真正的信号只是想在另一个线程的某个对象上执行一段代码用它就行。它同样遵循队列连接的事件投递原理且不需要预先connect很适合做一次性任务调度。6.3 我的几条实操心得做Qt开发的这十来年里信号槽是踩坑最多、收益也最大的机制。最后分享几条碎片化的经验算是我个人的土办法。第一信号命名用过去时态或事件语义比如dataReceived、fileSaved、connectionClosed。这样读代码的时候信号代表的是已经发生了什么槽函数代表的是要做什么语义清楚不容易把触发逻辑和处理逻辑搞混。第二槽函数内部一定要考虑重复触发。一个信号可能在一次状态变化中被触发多次比如QSpinBox拖动时值连续变化。如果你的槽函数里做了大量耗时操作建议加一个防抖计时器或者去重标志避免界面卡顿。第三把连接逻辑集中放在构造函数里不要散落在各个方法里。工程一大了哪里连了什么信号链接关系极易混乱集中管理以后排查方便得多。第四永远不要在信号函数里写复杂的逻辑。信号天生就是广播消息你没法也不应该控制谁接收它。如果需要在发射前做条件判断把这些判断放到调用emit之前的业务代码里让信号保持纯净。第五多线程场景下能用moveToThread就用它尽量少用继承QThread重写run()的方式。继承QThread会让线程对象与业务代码耦合而moveToThread可以让工作对象专注于业务逻辑与线程的启动、退出完全解耦。按这个套路来使用Qt做复杂界面也好、做后台服务也好信号槽这套机制都能成为你手里的稳定抓手。每次遇到莫名其妙不触发的玄学问题先回到连接三元组、线程上下文和元类型注册这三个基本点绝大多数问题都能快速定位。