我个人平时会负责一些技术面试。面试过程中，经常碰到那些针对面试精心准备的人，比如，消息队列方面，候选人差不多都能答上这些标准答案。但是，这些答案不是我想听到的，我甚至曾经告诉面试者：

我不想听你看来的这些东西，我想听你思考的东西，你们具体在什么场景下用的MQ，如果不用MQ，你的项目又怎么设计？你思考一下你的XX项目，中间还有没有哪一块功能可以用上MQ？为什么？如果用了，你猜一下生产上可能出现什么故障？怎么解决？既然你知道他的作用是“解耦、消峰、异步”，那么在你简历中提到的XXX技术中（比如nginx，或者任何知识点），分别可以通过什么手段去做这三个目的？你在Java/Android/IOS中还见过类似的组件或者机制吗？他们怎么做的？为什么？你怎么看如何解决MQ中消息重复的问题？有必要对所有的消费者都做幂等吗？为什么？幂等在你们xx项目中，具体怎么实现。还有哪些情况你碰到过“消息重复”类似的问题？BASE理论里，如果涉及到MQ的场景，怎么设计？除了你说的这种设计，还有哪种设计？在你的xxx项目中应该怎么设计？为什么？

前面说了一大段，其实我想说的是，最好加上一个章节，告诉这些来取面经的人：哪怕你看完了这上面的内容，你仍然需要在工作中时时刻刻去思考和印证。

这些面经可以是你学习的目录，但是不是你学习的终点，对于优秀的公司和面试官来说，仅限于这些内容，收效甚微。