资深DBA万字箴言：如何消除油腻的技术焦虑？

有一天走在路上，脑袋里突然冒出一个词：三十而立，可我的诗依旧还在远方。

三十岁左右，是一个让人焦虑的年纪，而抬头看看，全世界都在焦虑，所以本文我将先对焦虑做减法，再来看看技术焦虑的解法。

对于焦虑，美国著名心理学家罗洛•梅在他的代表作《焦虑的意义》这样形容：

简单来说，感觉到威胁、找不到突破口，内心空洞，这就是焦虑。技术生活何尝不是如此？

我简单问了几个朋友，他们对于技术焦虑的看法如下，我简单做了标注：

• 怕自己学到的不是有用的，或者说会很快被淘汰的技术，又或者是不值得花费大量时间学习的技术。—找不到突破口

• 年龄大了，职业发展是个焦虑点。—感觉到威胁，内心空洞

• 刚毕业时想学各种各样的新技术并进行实践，有段时间突然静下来发现几乎一无所成，只是知道一些名词和方案，如何落地推进都没真正实践。—找不到突破口，内心空洞

• 33 岁的人了，还是丢不下技术。—感受到威胁，内心空洞

• 一直有个担忧，看到大家分享了很多技术方案，但这众多的技术方案也容易让一些同学迷失自我，不知道该从哪入手，如何选择。—找不到突破口

• 目前没有一个清晰的技术规划，很容易在繁华技术方案中迷失自我。都知道适合自己的是最好的，适合自己未来 2~3 年规划的是最佳，但实际上还是东一榔头西一棒槌。—内心空洞

如果一定要给这三点一个更通俗的解释，可以归纳为焦虑的三个阶段：认知、认怂、认命。

有时发现，我们很多人更愿意去说去想，而不是去做。那怎么解？下面从问题入手，来看看对策。

凡事预则立，不预则废，制定计划是给自己的一个心理暗示，给自己一个阶段性目标，然后把它做分解，拆分成为自己能够实现的一些任务。

规划做多久？短则一周，多则两年。我们都是心智成熟的人了，就不用再灌什么鸡汤了。

去新公司面试时，一般也会问一下你的职业规划，但我觉得很多人都没想明白，我们做了计划都很难保证达成目标，但如果没有计划，结果更可想而知。

就好比数据库中执行 SQL 都需要有执行计划，执行计划也有很多的性能差别，比如下面的 3 个表关联，就有这么多的执行路径可供选择。

计划制定了，还要有一个规划和章法，哪些是优先的，哪些可以排后。

如果你毕业有五年了，会明显发现有规划和无规划的身边同学差别还是蛮大的。

所以有些同学一边刷着段子和电影，一边感慨世事不公、怀才不遇，你缺的是一个规划并付诸实施。

在《我也可以是流浪诗人》中有几段话，很有意思，摘录一些分享给大家：

我觉得很受用，自己似曾想过但没想通的问题，好像有了一些答案。

联系一下我自身，我希望找到一个能够施展拳脚的舞台，有考虑大厂，毕竟有光环效应。

不需要从 0 开始，如果以 10 分来估算，直接可以从 7、8 分到达 9 分，而如果是一个新的公司，那么很有可能就是从 3 分甚至从 0 分开始。

我已经厌倦了大厂光环效应，也厌倦了只说不做的浮躁，如果有时做事总是隔靴搔痒，我就会有一种感觉，所谓的技术焦虑和公司的关系不大，而是自己在职业发展的道路上存在困惑和问题。

我在给 DBAplus 社群的 MVP 获奖感言这样写道：“所谓迷茫就是懒，多做点实事就有目标和方向”，那么问题来了，该做哪些事情，该怎么做，一系列的 3W 问题，先画个图说明一下：

我之前从事的工作中 Oracle 方面较多，但因为工作还是有不少的机会来巩固 MySQL 方向，所以从技术栈上来说，数据库方向也算是站稳脚跟了，这可以说是成长。

但从一个整体的角度来说，我只是做了其中的一小部分，下面是两个大圆圈，分别代表数据库技术和开发技术。

数据库技术中目前的工作中能够直接拿过来复用的就是一些规范和架构设计的东西，而且这里面还有很多对我来说是新的思考方向和挑战。

MySQL 纯技术栈的内容其实算是常规，如果目前的工作业务量还远未达到瓶颈点，性能优化的部分少一些，那么我们首要巩固的就是开发自动化平台。

新问题来了，数据库开发方向目前很清晰的一个点就是自动化运维，确切的说，是 DB 自动化运维平台，说是重构也好、重建也好，不是完全从零开始，但基本是从零开始的节奏。

要做这个事情，得有人来带路，大家都不知道怎么走，站在原地讨论 plan A、plan B，问题肯定是解决不了的。

得有人迈出来，大家都不会，你就得冲在前面，大家没考虑的问题，你考虑到了；考虑的问题，你已经心中有数了，这事情就可以干了，这就是改变。

我做事喜欢结果导向，喜欢快速迭代，能 10 分钟搞定，绝对不愿意花 15 分钟。

但是技术行当，还得耐得住寂寞，因为很多事情 10 分钟搞不定，可能 100 分钟，1000 分钟也搞不定。

但这不代表我们真搞不定，需要花一些时间，花一些额外的代价来补课。水到渠成的时候，自己也得到了成长，这就是突破。

对很多同学来说，做技术的核心竞争力，除了丰富的业务经验（这个需要时间的积累），技术层面的积累也是需要一个体系的。

比如一个工作 10 多年的老司机和刚工作的新手，处理一个简单问题的时候，大家的表现都差不多。

很可能新手精力更充沛，做得更快，但一旦有了一些紧急的情况时，新手就会手足无措，这就是经验的价值。

经验的价值在现在的大环境下空间也在不断压榨，以前的独门秘籍和攻略随着知识积累和痛点的积累，都会逐步解决。

所以要去做更有难度和价值的事情，这些都是经验的积累和铺垫，时间是个好东西，它会不断证明你有多幼稚。

我眼中的工程师模型是这样的，简单三个特征：鹰眼（眼光犀利），狮心（内心强大），绣花手（做事认真细致）。

还有一个方向就是技术积累，在学习计算机的时候，我们知道：程序=算法+数据结构，但这一点在如今的时代，大家好像都忽略了。

我举一个例子，编译原理想必大家在大学都学过，但包括我还有很多同学，应该都在大学完美地绕过了这个学习的痛点，有很多人在想，学习编译原理有什么用，这里答案我都给你找好了。

来自知乎的一个不错的解答，关于编译原理我一直最喜欢类比的就是人体解剖 。

在欧洲教会还不允许做尸体解剖时就有两类人在一起偷偷摸摸搞人体解剖：

• 一类是医生，从外科手术的角度来说应该比较容易理解，不解剖根本不可能知道如何做外科手术。

• 还有一类则是画家，他们只是为了可以更好地在描绘皮肤时体现肌肉的质感，就愿意冒着被教会处罚的危险来参与人体解剖。

  而且即使是现在，所有的现代绘画的教育虽然不会再像医生那样实际操作解剖，但肌肉层的解剖图仍然是必修课。

在我看来，完全不懂编译原理的程序员，就好像是完全没有学过人体解剖图的画家一样。

当然不会说一定就无法成功，不过如果有更好的基础可以提高成功的几率，在知道底层的情况下，对上层的描绘会更加写实，更加生动。

抛开比喻，从现实的方面来说，编译原理学过之后的益处（不考虑最后都没有入门的情况）包括：

• 可以更加容易地理解在一个语言中哪些写法是等价的，哪些是有差异的。

• 可以更加客观地比较不同语言的差异。

• 更不容易被某个特定语言的宣扬者忽悠。

• 学习新的语言时，效率也会更高。

• 从语言 a 转换到语言 b 是一个通用的需求，学好编译原理处理此类需求时会更加游刃有余。

  另外还有一点，就是一直有人说不用重复造轮子，所以不需要学习编译原理这样的课程。

大学里面几门非常核心的课程，比如操作系统原理、数据结构、计算机组成原理、算法，这些在你工作的一些年头可能不会排上用场。

但等到了一定的阶段之后，这些就是你思维的沉淀，计算机技术就是在前仆后继的贡献中不断积累起来的，沉淀下来的很多理论和问题处理方法，光想肯定是想不出来的，我们得抓住几个点或者面深入下去。

有些同学说现在的大数据学起来好难，深度学习也很难，因为理论层次上升了一个台阶，会明显感觉到压力。

很多年前大家都会提到一个短板理论，把技术做得很纯粹的同学会有一个很明显的天花板。

很多做技术的同学会在一定的年龄之后纠结是做技术还是做管理，会有一个技术线和管理线。

如果可以，我还是建议以技术为主线做一些管理工作，不要偏离一线，让能听见炮声的人来指挥这句话还是有道理的，技术圈的人比较执拧，基本都是以技术服人，纯靠管理很难推进。

三十年河东，三十年河西，技术不断的发展，解决了很多痛点，这些年来短板理论也受到了挑战，在这种需求之下，不温不火的算法工程师这些年来真是大红大紫，不乏一些百万年薪的高级职位。

但如果细细看下面的图，你会发现只是某一方面够强，需要付出更多。换句话说，要突破短板瓶颈，你得在某一方面已经非常强大，要不就很容易被鸡汤。

三十岁后，人生逆袭的天花板开始收窄；其他赛道也会收紧闭合，很多时候我们只看得到自己眼前的那条。

技术圈内也有不少朋友，现在大都成了行业内的中流砥柱，会时不时有招人需求，我也会帮忙推荐一些朋友。

每每想起招聘需求，很多时候的 JD 都是他们得自己根据一些需要来临时补充。说简单一些，那就是技术过硬，人要靠谱。

技术过硬这一点无可置疑，但我也有一些不同的意见。从我的感受来看，现在的公司面试已有了非常大的变化，早期的面试可能还有笔试、若干流程，还有些公司有一些辩论会之类的，说白了是一些辅助——加分。

现在的很多公司对待新人也不会有一个相对平滑的培训周期、逐步的角色替换过程，有些加急的场景中，可能今天入职，这周或者下一周就直接上手。

所以招人都是要直接上来就能用的，都不愿意去培训新人。换做另外一个极端，那就是很多新人还经不起培养就离职了，对公司来说更加得不偿失，所以这是一个伪命题，重重矛盾但又相对合理。

在这一点上，除了薪资，求职者更需要明白公司的文化（比如加班文化）是否适合你。

Business is business，人靠不靠谱还是很难面试出来的，我们只能根据聊天来判断他的性格，通过一些细节来看他是否诚实，通过几分钟几十分钟确实是很难的，这些都是偏主观的判断了。

市场行情都会变化，看到别人很滋润，不心动是假的，所以焦虑也会时不时冒出来，让人上火。

不管外面是金三银四，对于自己，你得清楚自己的一个基本规划，向钱看 or 向前看，都要看。

但是不要轻易迷失，千万不要因为逃避而离职，那么问题可能就是一种复制和延续而不是解决，哪个公司都有大大小小的问题，我们工作的本质就是要不断解决问题。

什么是份内的事情？就是你的本职工作。什么是份外的事情？一种是把本职工作做得更好，或者是协调团队产生更大的价值。

份外的事情最大的特点就是你做了没人喝彩，不做也没人指责你，所以事情说小了是份内的，说大了是份外的。

以至于我们在工作里面做事情会分得很清楚，有了流程控制，至少出问题不会甩锅甩到我这里，要不就怪流程不完善。

但对于个人来说，份外的事情变成份内，是一种成长，比如你只会数据库，去尝试了解一些系统层面、存储层面、内核层面的东西，也不是坏事。

在这个基础上去深入理解业务，能够让自己的眼界更加宽广，考虑问题的角度更加全面，而不是一些孤立的点，还是需要用一个整体的眼光来看待分析和解决。

所以我们有时候叫全栈，有时候叫做转型。当然从技术角度来说，技术问题都不是问题，但是实际解决的时候，会有一些出入，很多问题到最后发现已经完全偏离了原来的方向，就是我们看待问题的角度不对。

业内份外的事情变为份内，Devops 就算一个比较典型的，原本风光无限的 DBA 需要掌握一些其他技能：系统运维、系统开发等，敏捷运维在这个时候提出来不是凭空想出来的。

很多重复性的工作需要得到简化，很多复杂的工作若替代不了的，可能要么直接被废弃，要不推翻重来。

这个过程有点类似于行业洗牌，能够坚持在最后的，始终是那些拥抱变化的人。

份内、份外的事情都是解决问题，解决了问题大家相安无事，其乐融融；解决不好，也是能够把伤害和影响降到最低的一把标尺。

哪些事情我是本着人情来做的，哪些事情不能因公徇私，可能就是这么个理吧。

如果你觉得目前很舒服，不妨做些你不愿意做的事情，做些改变，做些你不敢做的事情，来突破一下你自己。因为机会不会等着你，也不会问你准备好了没。

有很多人向我取经，说职业生涯如何规划，技术方向如何选择，坚持了一段时间之后我们就失去了联系。

因为我知道，做一件事情，能坚持下来的都是少数。你去面试，说我很专注，但这一点很难证明，如果扪心自问，这些年来自己坚持了哪些事情，好与不好，每个人心里都会有一杆秤来衡量。

上面这个图怎么理解呢？它是知乎一个有名的游戏，即 100 个人每个人手里有 1 块钱，大家随机交换，看最后每个人手里剩下多少钱。

经过真实的模拟，发现了一套理论：如果通过 SQL 来模拟，也是分分钟搞定的，可以看到，绝大多数人都是原地踏步，只有极少数的人能够走出这个圈子来。

左边的图是 1000 人的样本，100 次测试之后，手里剩下 0 块，1 块的占绝大多数，基本是 70% 的比例，而能够突破的人（有 2 块，3 块）是少数（15%），卓越的人更少（5%）。

右边的图是允许你来透支，样本是 100 人，得到结果和左边是相似的。不知大家看到这个图，内心是怎样的感受，我个人觉得这些数字给我上了生动的一课。

工作生活都是如此，我们身边有很多锦上添花的人，但雪中送炭的很少，做一件事情，要达到专注，不能钻牛角尖，按照既定的目标来实现，方为上策。

技术圈的更新是极其快的，基本上不到半年就会有一些工具和方案出来。

如果让一个开发工程师写一下自己接触过的技术，估计能写满一页 A4 纸。有了动力和方向，面对纷繁复杂的技术和方案，该怎么选择？

在混乱之中，我们要理清下面的几个问题：

• 你了解自己的行业吗，比如数据库行业，技术的发展趋势怎么样？

• 你关注的技术领域里，有哪些好的解决方案可供参考，比如数据库的高可用方案。

• 这些领域中，有哪些行业先锋，他们有没有分享，博客或者文章可供参考。

• 那些方案你用了吗，自己做过测试或者生产实践吗？

• 新技术总是会滞后于实际的应用，稳中求进，不能一味大跃进。

欲事之无繁，则必劳于始而逸于终。实际落实下去时，发现碰到的问题很多，都需要一一克服，稍不注意就会成为瓶颈点。

而且 Web 开发类的应用有非常多的框架，开源技术方向的技术变化很快，要熟悉这种文化，要适用新的技术思想，这些都是一个过程。

那这个怎么来解？当然我也不会给自己太多时间，拿到一个结束时间点来反推这个过程的进展，这样不一定可靠，但方向和动力是足的。王阳明说：想，都是问题，做，才是答案，道理说得已经很透了。

我们大体都会碰到很多技术问题，有些是通用的，有些是具体的。他们之间的关系和区别就很重要了，要不然总是很凌乱。

他们大体的关系如下图所示：

很快就会发现，我们能够很快做出一个应用来，但如果分析一下核心的点，似乎很难 get 到。

对于学习效果，可以参考下面的学习金字塔，这是美国缅因州的国家训练实验室的研究成果。

它用数字形式形象显示了，采用不同的学习方式，学习者在两周以后还能记住内容（平均学习保持率）的多少：

• 第一种学习方式——“听讲”，这种是我们最熟悉最常用的方式，学习效果却是最低的，两周以后学习的内容只能留下 5%。

• 第二种，通过“阅读”方式学到的内容，可以保留 10%。

• 第三种，用“声音、图片”的方式学习，可以达到 20%。

• 第四种，是“示范”，采用这种学习方式，可以记住 30%。

• 第五种，“小组讨论”，可以记住 50% 的内容。

• 第六种，“实际演练”，可以达到 75%。

• 最后一种在金字塔基座位置的学习方式，是“教别人”或者“马上使用”，可以记住 90% 的学习内容。

所以说我们的学习方式可能平时用得也不一定很科学。就我个人实践来说，这几种方法都有其适用的场景，不能一概而论。

如果可以，我比较喜欢主动学习的方式，尤其是技术分享的方式，比如你现在正在看我的分享。

有句话说，若起不得法，则杂乱浮泛，所以我们还是要讲究一些章法和技巧的。

技术是有热度的

我是 DBA、做数据库技术多一些，先来说说数据库内核技术。Oracle 内核技术 2000 年左右如火如荼。

随着时间的推移还有技术热度，这种情况不多见了，一来是坚持技术研究的人少了，二来是热度没以前那么高了，或者说钱途没以前那么好了。

现在的 MySQL 技术依旧如火如荼，技术终究会越来越成熟，我可以想到几年后，某些攻略不再是攻略，而是集成在数据库里很自然的优化方法，被诟病的问题也逐步被修复，那么我们工作的意义和岗位存在的价值在哪里？

都说有了云计算，有了虚拟化，但事在人为，别指望能一劳永逸地解决所有的技术痛点，需求总是随着时代的发展在不断改进，对于我们自身而言，就是积累的行业经验和过硬的技术能力了。

抓住重点

数据库技术那么多，该怎么学？我们看问题的时候瞻前顾后，想踏踏实实研究些技术总是被打断，而有了时间钻研技术有时候发现又不得要领。

记得 Oracle 大神 Jonathan Lewis 说过：Oracle 数据库中 x$kcbsw 结构包含了 Oracle 处理一个“会话逻辑 I/O”所需的所有命名函数。

在 11.2.0.3 版本，我曾指出有 1164 个命名函数，但看看运行在 64 位 OEL（Oracle 企业版 Linux 操作系统）上的 12.1.0.1 版本，这个数字是 1300。

这一变化对本书内容来说有多大区别？对普通Oracle专业人士呢？答案是“没有区别”！

把这个回答继续下钻，就是一个核心的点：

这个态度和思想普适所有技术方向的学习。所以对于我们来说一定是往前走，往上走，那个时候就不是改变了，而是突破。

使用通俗的方式来理解技术

技术和生活是不分家的，有很多技术问题可以用生活的场景来描述，而很多技术牛人的魅力就在于能够化繁为简，能够通俗或者用简单的几句话把一个复杂的事情描述出来。

比如 TCP/IP 的三次握手，很多人都有这样的想法，这到底是什么含义，为什么要三次，两次不行吗，一次行不行。

我们设定个场景，在地铁站里，手机信号不好，快没电了，两个人走散了，这样打电话：

• “喂，能听得到吗？”

• “我听得到呀，你听得到我吗？”

• “我能听到。”

如果想快速学习一门技术，一种方式是通过代码来理解它的实现，来反推它的逻辑，这种方式的难度极大，而且能够沉浸其中的人非常少，过程相对来说是苦闷的。

但如果能够沉下心来，看代码看到一种程度之后，有了感觉相信就会融会贯通了。身边这种大神也有，但确实不多。

第二种方式算是捷径，就是去听听作者怎么说，通过他的分享来从整体对一个项目有一个基本的认识和了解。

好比你去拜访一个朋友，他热情地把你领进门，带着你走走客厅，走走卧室，给你介绍房子的装修风格、里面的家具和电器。

为什么要这么设计，很快你就能够对这一切熟悉起来，这种方式很好，而且最省事，但可遇不可求。

第三种是我比较喜欢的方式，就是通过对比的方式来学习，比如学习 MySQL 和 Oracle 的学习，有了 Oracle 的基础学起来会容易很多。

但越是深入学习，发现两者的差别越来越大，不断通过对比来完善自己的认知，从差异化中找到学习的重点和方向，也能够对技术的发展有一个相对理性的认识。

如果什么都学，但都是浅尝辄止，会浪费你很多的精力和时间，而且对公司来说也是浪费。

有句话说得好，“提问”在认知上的过程，就像射向未知空间的一支手电筒，至于是不是好问题，可以理解为有没有指向问题本质的角度。

对于提问，我大体总结有下面的一些不恰当的姿势：

• 盲目提问，没有日志和说明，无法判断。

• 自己不思考，不看错误信息。

• 自己不分析问题，完全想依赖别人。

• 问题描述不清楚，或舍弃了重要的细节。

所以大家提问时，也最好能够注意到这些，不是不解答，而是有些问题压根没法回答，自己先消化一下，或者换个角度来反问自己。

喜欢答案的人很痛苦，因为他的世界观不断崩塌；喜欢问题的人很欢乐，因为手中的慧剑越来越锋利。总之，被问题拍肩膀，总比被现实抽嘴巴子好。

况且，人往往是这样的：在解决别人的问题时，会有各种说辞，但在解决自己的问题时，就只有写诗和远方了。

对于技术焦虑中的矛盾和困扰，有时很难理得清，我用自己画的一张图来解释。

在这里想聊聊对于版权的理解，我以前也喜欢破解版，但在 2016 年写了一本书《Oracle DBA 工作笔记》后，我开始焦虑起来，也收到过很多有意思的反馈。

有的同学上来就问我要电子版；还有的说出书能赚很多钱，让我随便送他几本，还有的同学在网上的大店下单，没收到货质问我……

当然也算吐槽吧，可以看到大家对于版权的认识还是不足的，所以我对版权的认识真是刻骨铭心，我现在也愿意去花钱去买一些产品的服务。

《大话数据结构》中的编者栾大成说过这样一句话：

所以我想说，IT 同行，请不要相轻。而我们再看看开源领域也是类似的，开源的理念不光是免费，还有开放。

一收费很多人就受不了，别人也忙，别人也有事情，所以没有什么是应该的，别人不帮你也不会有道德绑架的嫌疑。

可以看到有些开源项目现在很尴尬，技术方向都不错，但没有一个良好的模式来支撑发展。

有精力和时间就参与一些项目吧，这个是突破自己，我敢肯定的说，会有不一样的收获。

在我的认知里，我们很多人都是沉默的大多数，许多人不觉得自己在学习这件事情上值得分享，或者是讨论，都在默默的看，默默的听，认为这是自己的私事。

而我的经验告诉我，我给新手和老手做分享，总是会有收获。

分享不光是技术大会分享、技术博客，技术讨论都是分享。所以无论何种形式，听别人讲道理，还不如看看别人走过的路和正在走的路，多看看同行们都在做什么，对自己未来的选择，有时候会有意想不到的帮助。

对此，我有以下几个建议：

如果你认准了一件事，就不要轻言放弃，拿我自己的例子来说，自己坚持写博客到现在已经有 1300 多天了，风风火火进行到了现在的第 14 轮，这个过程本身没有什么可以值得炫耀的。

但对我来说，好记性不如烂笔头，我抽空把每天的工作中碰到的一些问题做了总结，以后碰到同样的问题可以缩短问题处理的周期。

这个话听起来很功利，但从务实的角度来说还是中肯的，毕竟这个学习的过程首先是对自己有利，你可以从中学到很多东西，把自己的基本要求满足了，自己的要求都达不到，又何谈和别人分享、帮助别人呢？

当然自己动机也是简单的，兴趣所占的成分居多，要不还是很难坚持的。如果一味朝钱看，也不一定能够那么有钱途。积累的过程中会有很多的诱惑，你需要去平衡，不要迷失自我。

如果你对某种技术感兴趣，刚好也有钱途，可以做个短期实践，自己可以多做一些练习来巩固巩固，很多时候纸上谈兵的东西在实际操作时会有很大的差距。

可以用自己熟悉的技术和相关的技术做一个关联，看看能给自己的工作带来哪些方便和好处。

我自己以前对 Shell 也是很生疏的，基本不会，但学习 Oracle 之后，在数据库管理中发现脚本管理很方便，慢慢地借鉴别人的、自己写的，现在也积累了几百个脚本了，在工作中使用这些脚本感觉还是非常方便和快捷的。

很多人对于技术分享还是有所顾虑，怕出丑，怕迈出这一步；有些人有分享的意愿，但不够主动；有些人是觉得没啥可分享的，但如果适当引导还是能出一些大作的；还有些人很配合，会主动反馈，主动分享，我欣赏这样的人。

回到最开始说到的焦虑现象，为什么罗洛梅要研究焦虑？因为50年代的美国人集体焦虑，大家都觉得自己有病。

对此罗洛梅举出两个很闪亮的观点：

• 焦虑是人类面对威胁，希望创造自我的正常状态。

• 这种时代，每个正常人都会有焦虑，你不焦虑，就是麻木、冷漠。

从下面的图可以看出来，焦虑和表现呈现倒 U 字型。一定的焦虑让你表现更好，但一旦超过某个阶段，过高的焦虑会让你彻底崩溃，而太低的焦虑会让人觉得空洞无聊。

最后用王泓人的一句话献给大家：对于我来说，最勇敢的事情不是辞职，而是趁着年轻用所有的精力来充实自己的人生！