此文章2332字，预计花费时间7-11分钟。

一、聊聊工作氛围 & 个人成长

1. 这是我的期许

“所谓前途，不过是以后生活的归途。”

这是我人生中的第一段技术实习，之前并不是一心做技术的，所以为了探索自己喜欢的事情在某小公司做过翻译实习，并且在交行做过金融实习（其实就是纯打杂）。

我很喜欢这样一段话： “我曾以为我的23岁会手提皮包西装革履，但我还是穿着休闲裤，带着十几岁的意气行事，幼稚又成熟；我曾以为我的23岁会性格外向，做事圆滑，但我连最简单的亲情都处理不好；我曾以为我的23岁会和喜欢的人看山河大海落日余晖，但没想道周围的人谈婚论嫁都近在眼前，我还在路上找自己。”

我一直在探索着自己的边界，在能闯能疯的年纪反复横跳，寻找着自己的热爱与期许。在真正从事这个行业之后，我发现了我对于这个岗位的喜爱，当你看着一个个实际的视图出现于自己的手中，你会有一种莫名其妙的成就感，这种感觉难以描述的程度就好像你要向一个完全不看vtuber的人描述你对嘉然的喜爱。

2. 工作氛围：这里是一个乌托邦（适合摸鱼学习的好地方！）

说实话，我最开始预期是每天九点来上班，九点下班的（因为看学长们实习都好辛苦的样子）。

来了之后发现完全不是，每天十点上班，六点下班（我当然是准点跑路）

实习两个月左右的时候接的一个需求，第一天是另一个前端实习生来搞，后来他要跑路，leader就把活给我了。

周四，后端六点把接口给另一个前端实习生。

另一个前端实习生：“明天再说”

周五我来接这个活，我边画页面边让他加字段。

然后提完了，六点他给我改好的接口，让我看看有没问题

我：“下周再说”。

后端：“前端是不是，都很快乐啊[流泪]”

最开始因为我对 react 不是特别熟悉，leader 让我看着组内文档学了半个月，才开始了第一个需求。

leader 没有给我指定 mentor，所以当我有问题的时候，我看组内谁没开会（或者有时间）就会去问，都能得到很耐心的解答，这点来说还是很有安全感的。

然后每天都会跟着老板和大老板一起去吃饭，有时听他们说说自己的事情，有时听听他们对某个语言的看法，也算有不少收获。

值得一提的是刚入职三天部门就开始团建了，从周五下午五点玩到了第二天凌晨两点，炫了一只烤全羊，然后就开始电玩篮球各种 happy，后面玩狼人杀我次次狼人，大老板也总觉得我是狼人，我次次和他对着刚（乐）

马上就要第二次团建了，可惜参加不了呜呜呜

在团建上 leader 说我是从五个面试感觉都 ok 的人里面选出来的（当时我超惊喜的）

还有几件有趣的事情值得一提

第一件事情是中午和 leader 散步，他说：“你干了两个月这里的情况也看到，很难接触到同龄的小姐姐的，找对象的优先级应该要提高了。”

我：“说的对说的对。”

当时我心里就暗暗想着，这是我不想找吗？这tm是我找不到啊（悲）

第二件事情是我有事开了自己的热点，热点的名字叫：“要失业了咋办呐。”

被同事发到了前端大群里。

同事：“这是谁的啊？”

我：“是实习生的（悲）”

3. 个人成长：“不卑不亢，低调务实”

最开始入职当然会担心一些七的八的，诸如这样说会不会不太客气，这样搞会不会让老板不爽，后来和老板还有大老板一起吃饭之后发现他们人都挺随和的，没什么架子，他们更多的关心的是这件事情做的怎么样。

大老板曾经在周会上说：“这个事情可以做的慢一些，这是能力上的问题，这个可以商量，但是如果到了约定的日期没有交付，这就有问题了。 ”这个是说的务实。

然后就是为人处事方面了，自己有时候挺跳脱的，没有什么边界感，在实习和他们一起吃饭的时候我就回默默的听着，有些问题大家都不会问，算是看着看着就成长了。

回校远程的时候我写了这样一段话：

去打工吧，去打上海冬夜准时下班，踩雪走回家的工。

去打工吧，去打一边聊天一边发现，这个产品也是清华✌️的工。

去打工吧，去打测试前一天，人都走光了，mentor陪我赶工到半夜的工。

去打工吧，去打部门团建，大leader带我们玩狼人杀到凌晨两点，超级尽兴的工。

冴羽曾在一次读书会上分享：“开眼界就像开荤一样，只有见过了才会产生饥饿感。”

打工虽然让我变成了稍不注意就会摆烂的成年人，但大平台汇聚了很多丰富有趣的同事，让我看到了截然不同的经历与一波三折的人生。

不知道是不是部门的原因，我这边总是十六五准点上下班。

我现在依然处于打工真香的阶段，不用早起，不用日复一日的和同龄人卷同一件事，身边的人年岁不同，人生阶段也不相同，卷不到一起去。

我还在路上～

4. 代码方面 learning

说实话看到组内项目的时候体会到了不少的震撼，看着组内的项目之后真的就感觉自己写的东西和玩具一样，每次写完项目，都会兴冲冲的找组内的哥哥姐姐帮忙 CR，然后 CR 出一堆问题，自己在一个一个的修改，把这些规范点记周报上，总之就是学到了很多很多。

timeLine 大概是这样的

• 前两周熟悉 react 写小 demo


• 然后以两周一个需求的速度给咱活干～

记得第二次写完一个稍微有点复杂的需求，带着我做这个需求的 mentor 还夸了我一波（骄傲）

5. 对于技术和业务的想法

大leader组织组内 vau 对齐的时候我仔细的听了听，我们的很多东西都需要落地，相比来说技术只是一个实现的手段，并不是做这个的目的。

但怎么说呢，我个人还是对技术本身抱有很大的期许的，希望自己能够变得很厉害，参与到很多的开源项目中，我坚信代码可以改变世界。

二、展望未来

实习不去字节，就像读四大名著不看红楼梦，基督徒不看圣经，学相对论不知道爱因斯坦，看vtuber不看嘉然今天吃什么，这个人的素养与精神追求不足，成了无源之水，无本之木。他的格局就卡在这里了，只能度过一个相对失败的人生!

• 话是这么说啦，但最后还是没有成功去到字节，但是我是字节不折不扣的舔狗，后面再看吧。


• 字节给我发面试一定是喜欢我（普信）

下面这段是之前写的

离开的契机也很简单，我在小红书实习的同学跑路了，然后要找继任，顺手把我的简历投过去了，然后我顺手面了一下小红书，小红书顺手给我发了个Offer(bushi，然后就去小红书了。

小红书确实Offer了，但是老板和我约谈了很久，我决定继续远程实习，在这篇文章发布的当天，我已经实习了 一百四十天，我相信，我的旅途还在继续。

三、写在最后

不知不觉就实习快半年了啊

我真的非常感谢遇到的leader和同事，感恩遇到的每一位愿意拉我一把的人。

在这段时间里学到了好多一个人学习学不到的东西啊。

那么这就是我在蔚来的实习小结啦！

感谢阅读～

蛮久没更新了，本次我想聊聊找工作的事情，相信大家都能感受到从去年开始到现在市场是一天比一天差，特别是在我们互联网 IT 行业。
已经过了 18 年之前的高速发展的红利期，能做的互联网应用几乎已经被各大公司做了个遍，现在已经进入稳定的存量市场，所以在这样的大背景下再加上全世界范围内的经济不景气我想每个人都能感受到寒意。

我还记得大约在 20 年的时候看到网上经常说的一句话：今年将是未来十年最好的一年。

由于当时我所在的公司业务发展还比较顺利，丝毫没有危机意识，对这种言论总是嗤之以鼻，直到去年国庆节附近。

虽然我们做的是海外业务，但是当时受到各方面的原因公司的业务也极速收缩（被收购，资本不看好），所以公司不得不进行裁员；
其实到我这里的时候前面已经大概有 2～3 波的优化，我们是最后一波，几乎等于是全军覆没，只留下少数的人维护现有系统。

这家公司也是我工作这么多年来少数能感受到人情味的公司，虽有不舍，但现实的残酷并不是由我们个人所决定的。

之后便开始漫长的找工作之旅，到现在也已经入职半年多了；最近看到身边朋友以及网上的一些信息，往往是坏消息多于好消息。

市场经历半年多的时间，裁员的公司反而增多，岗位也越来越少，所以到现在不管是在职还是离职的朋友或多或少都有所焦虑，我也觉得有必要分享一下我的经历。

我的预期目标

下面重点聊聊找工作的事情；其实刚开始得知要找工作的时候我并不是特别慌，因为当时手上有部分积蓄加上公司有 N+1 的赔偿，同时去年 10 月份的时候岗位相对于现在还是要多一些。

所以我当时的目标是花一个月的时间找一个我觉得靠谱的工作，至少能长期稳定的工作 3 年以上。

工作性质可以是纯研发或者是偏管理岗都可以，结合我个人的兴趣纯研发岗的话我希望是可以做纯技术性质的工作，相信大部分做业务研发的朋友都希望能做一些看似“高大上”的内容。
这一点我也不例外，所以中间件就和云相关的内容就是我的目标。

不过这点在重庆这个大洼地中很难找到对口工作，所以我的第二目标是技术 leader，或者说是核心主程之类的，毕竟考虑到 3 年后我也 30+ 了，如果能再积累几年的管理经验后续的路会更好走一些。

当然还有第三个选项就是远程，不过远程的岗位更少，大部分都是和 web3，区块链相关的工作；我对这块一直比较谨慎所以也没深入了解。

找工作流水账

因为我从入职这家公司到现在其实还没出来面试过，也不太知道市场行情，所以我的想法是先找几家自己不是非去不可的公司练练手。

有一个我个人的偏好忘记讲到，因为最近的一段时间写 Go 会多一些，所以我优先看的是 Go 相关的岗位。

第一家

首先第一家是一个 ToB 教育行业的公司，大概的背景是在重庆新成立的研发中心，技术栈也是 Go；

我现在还记得最后一轮我问研发负责人当初为啥选 Go，他的回答是：

Java 那种臃肿的语言我们首先就不考虑，PHP 也日落西山，未来一定会是 Go 的天下。

由于是新成立的团队，对方发现我之前有管理相关的经验，加上面试印象，所以是期望我过去能做重庆研发 Leader。

为此还特地帮我申请了薪资调整，因为我之前干过 ToB 业务，所以我大概清楚其中的流程，这种确实得领导特批，所以最后虽然没成但依然很感谢当时的 HR 帮我去沟通。

第二家

第二家主要是偏年轻人的 C 端产品，技术栈也是 Go；给我印象比较深的是，去到公司怎么按电梯都不知道🤣

他们办公室在我们这里的 CBD，我长期在政府赞助的产业园里工作确实受到了小小的震撼，办公环境比较好。

当然面试过程给我留下的印象依然非常深刻，我现在依然记得我坐下后面试官也就是 CTO 给我说的第一句话：

我看过你的简历后就决定今天咱们不聊技术话题了，直接聊聊公司层面和业务上是否感兴趣，以及解答我的疑虑，因为我已经看过你写的很多博客和 GitHub，技术能力方面比较放心。

之后就是常规流程，聊聊公司情况个人意愿等。

最后我也问了为什么选 Go，这位 CTO 给我的回答和上一家差不多😂

虽然最终也没能去成，但也非常感谢这位 CTO，他是我碰到为数不多会在面试前认真看你的简历，博客和 GitHub 都会真的点进去仔细阅读👍🏼。

其实这两家我都没怎么讲技术细节，因为确实没怎么聊这部分内容；这时就突出维护自己的技术博客和 GitHub 的优势了，技术博客我从 16 年到现在写了大约 170 篇，GitHub 上开源过一些高 star 项目，也参与过一些开源项目，这些都是没有大厂经历的背书，对招聘者来说也是节约他的时间。

当然有好处自然也有“坏处”，这个后续会讲到。

第三家

第三家是找朋友推荐的，在业界算是知名的云原生服务提供商，主要做 ToB 业务；因为主要是围绕着 k8s 社区生态做研发，所以就是纯技术的工作，面试的时候也会问一些技术细节。

我还记得有一轮 leader 面，他说你入职后工作内容和之前完全不同，甚至数据库都不需要安装了。

整体大概 5、6 轮，后面两轮都是 BOSS 面，几乎没有问技术问题，主要是聊聊我的个人项目。

我大概记得一些技术问题：

• k8s 相关的一些组件、Operator


• Go 相关的放射、接口、如何动态修改类实现等等。


• Java 相关就是一些常规的，主要是一些常用特性和 Go 做比较，看看对这两门语言的理解。

其实这家公司是比较吸引我的，几乎就是围绕着开源社区做研发，工作中大部分时间也是在做开源项目，所以可以说是把我之前的业余爱好和工作结合起来了。

在贡献开源社区的同时还能收到公司的现金奖励，不可谓是双赢。

对我不太友好的是工作地在成都，入职后得成渝两地跑；而且在最终发 offer 的前两小时，公司突然停止 HC 了，这点确实没想到，所以阴差阳错的我也没有去成。

第四家

第四家也就是我现在入职的公司，当时是我在招聘网站上看到的唯一一家做中间件的岗位，抱着试一试的态度我就投了。
面试过程也比较顺利，一轮同事面，一轮 Leader 面。

技术上也没有聊太多，后来我自己猜测大概率也和我的博客和 Github 有关。

当然整个过程也有不太友好的经历，比如有一家成都的“知名”旅游公司；面试的时候那个面试官给我的感觉是压根没有看我的简历，所有的问题都是在读他的稿子，根本没有上下文联系。

还有一家更离谱，直接在招聘软件上发了一个加密相关的算法，让我解释下；因为当时我在外边逛街，所以没有注意到消息；后来加上微信后说我为什么没有回复，然后整个面试就在微信上打字进行。

其中问了一个很具体的问题，我记得好像是 MD5 的具体实现，说实话我不知道，从字里行间我感觉对方的态度并不友好，也就没有必要再聊下去；最后给我说之所以问这些，是因为看了我的博客后觉得我技术实力不错，所以对我期待较高；我只能是地铁老人看手机。

最终看来八股文确实是绕不开的，我也花了几天时间整理了 Java 和 Go 的相关资料；不过我觉得也有应对的方法。

首先得看你面试的岗位，如果是常见的业务研发，从招聘的 JD 描述其实是可以看出来的，比如有提到什么 Java 并发、锁、Spring等等，大概率是要问八股的；这个没办法，别人都在背你不背就落后一截了。

之后我建议自己平时在博客里多记录八股相关的内容，并且在简历上着重标明博客的地址，尽量让面试官先看到；这样先发制人，你想问的我已经总结好了😂。

但这个的前提是要自己长期记录，不能等到面试的时候才想起去更新，长期维护也能加深自己的印象，按照 “艾宾浩斯遗忘曲线” 进行复习。

选择

这是我当时记录的面试情况，最终根据喜好程度选择了现在这家公司。

不过也有一点我现在觉得但是考虑漏了，那就是行业前景。

现在的 C 端业务真的不好做，相对好做的是一些 B 端，回款周期长，同时不太吃现金流；这样的业务相对来说活的会久一些，我现在所在的公司就是纯做 C 端，在我看来也没有形成自己的护城河，只要有人愿意砸钱随时可以把你干下去。

加上现在的资本也不敢随意投钱，公司哪天不挣钱的话首先就是考虑缩减产研的成本，所以裁员指不定就会在哪一天到来。

现在庆幸的是入职现在这家公司也没有选错，至少短期内看来不会再裁员，同时我做的事情也是比较感兴趣的；和第三家有些许类似，只是做得是内部的基础架构，也需要经常和开源社区交流。

面对裁员能做的事情

说到裁员，这也是我第一次碰上，只能分享为数不多的经验。

避免裁员

当然第一条是尽量避免进入裁员名单，这个我最近在播客 作为曾经的老板，我们眼中的裁员和那些建议 讲到在当下的市场情况下哪些人更容易进入裁员名单：

• 年纪大的，这类收入不低，同时收益也没年轻人高，确实更容易进入名单。


• 未婚女性，这点确实有点政治不正确，但确实就是现在的事实，这个需要整个社会，政府来一起解决。


• 做事本本分分，没有贡献也没出啥事故。


• 边缘业务，也容易被优化缩减成本。

那如何避免裁员呢，当然首先尽量别和以上特征重合，一些客观情况避免不了，但我们可以在第三点上主动“卷”一下，当然这个的前提是你还想在这家公司干。

还有一个方法是提前向公司告知降薪，这点可能很多人不理解，因为我们大部分人的收入都是随着跳槽越来越高的；但这些好处是否是受到前些年互联网过于热门的影响呢？

当然个人待遇是由市场决定的，现在互联网不可否认的降温了，如果你觉得各方面呆在这家公司都比出去再找一个更好，那这也不失为一个方法；除非你有信心能找到一个更好的，那就另说了。

未来计划

我觉得只要一家公司只要有裁员的风声传出来后，即便是没被裁，你也会处于焦虑之中；要想避免这种焦虑确实也很简单，只要有稳定的被动收入那就无所谓了。

这个确实也是说起来轻松做起来难，我最近也一直在思考能不能在工作之余做一些小的 side project，这话题就大了，只是我觉得我们程序员先天就有自己做一个产品的机会和能力，与其把生杀大权给别人，不如握在自己手里。

当然这里得提醒下，在国内的企业，大部分老板都认为签了合同你的 24 小时都是他的，所以这些业务项目最好是保持低调，同时不能影响到本职工作。

欢迎关注作者公众号于我交流🤗。

① 自动打断点（抛异常时自动断点）

偶然一次可能不小心打开某个设置选项，可能设置了英文又不知道是打开了什么，只知道当每次打开F11打开控制台调试看数据的时候，就是不会自动停在某个位置，又不知道怎么停掉，怀疑会不会是安装了什么谷歌插件或者是油猴哪个脚本代码写错写了什么。

不小心打钩了断点调试的遇到未捕获的异常时暂停，或者在遇到异常时暂停这两个选项其中一个。就有可能导致了谷歌的调试器暂停，取决于这个网站有没有一些异常触发到这一点，勾选上每次异常浏览器会帮我们打断点。

所以解决办法就是把谷歌浏览器中的这两个勾去掉，如果不是你本意打开想要调试网站中一些异常的报错。

② 一键重发请求（不用每次重新请求就刷新页面）

排查接口的时候，需要重新请求该接口，不必要每次重新刷新页面去请求试接口里面传参对不对返回来的数据对不对。重发请求很简单，右击该接口重发xhr即可。

③ 断点调试+debugger+console+try...catch

(1) console.log

找bug解决bug是很重要滴。console.log-输出某个变量值是非常非常常用的，只要做码农一定得会各种语言的输出消息和变量的语句，方便我们查看和调试。

(2) debugger（不用每次都console）

在代码某个语句后面或者前面输debugger

在我入行到在学校生涯那段时间都不知道debugger;这玩意，有一次项目有一个比较棘手不知道怎么解决的问题，甲方公司项目负责人开会重点讲了那个问题，就见他这里输一下dubugger，那里输一个debugger，当时就觉得那玩意很神（反正意识上只要我们不懂的东西刚开始接触都是这样，这里神那里神的，接触久了就觉的也就那样不过如此，很平常），最后也没看出什么来。

debugger就是在某个状态下，用这个debugger;语句在那里断一下点，然后当下，上下文的状态和值都可以在查看，哪个分支导致变量状态错误。

使用debugger可以查看:

• 作用域变量


• 函数参数


• 函数调用堆栈


• 代码整个执行过程（从哪一句到哪一句的）


• 如果是异步promise async...await 等这种的话就需要在then和catch里面debugger去调试

(3) try...catch 捕获异常

try {

    // 可能会抛出异常的代码

} catch {

    // 处理所有异常的代码

}

用try...catch捕获异常，包括运行时错误和自定义以及语法错误。

在try...catch中还可以在某些情况下用throw在代码中主动抛出异常。

try {

    // 可能会抛出异常的代码

    

    if (某某情况下) throw '某某错误提示信息'

    

} catch {

    // 处理所有异常的代码

} finally {

    // 结束处理用于清理操作

}

④ 联调查看接口数据

如上图这个接口，如果想要复制接口preview里面的数据，

除了去Responese里面去找我们需要的某个值去选择复制之外（这个有个缺点就是要找值不直观），还可以右击某个值，然后通过点击store object as global variable(存储为全局变量) 获取。

当我们点击了之后，控制台就会出现tempXX这个变量。

我们就只需要在控制台输入copy(temp3)copy(要复制的json名)，在粘贴板上就有这个json数据了。

💡
全局方法copy()在console里copy任何你能拿到的数据资源。

⑤ 后端接口数据返回json

这个有时候有的同学有可能碰到类似这种的JSON数据{\"name\":\"John\",\"address\":\"123 Main St, City\"}

解决方法

直接打开控制台console，输入 JSON.parse("{"name":"John","address":"123 Main St, City"}")，这样

如果你想复制下来用，直接跟上面我们用copy这好碰上，赋值加上一个copy就可以了。

这样这个值就在粘贴板上了。

总结

报错和bug，多多少少会贯穿我们的职业生涯中，如何定位问题、解决问题，加以调试，是我们必须也是不能不必备的技能。

☎️ 希望对大家有所帮助，如有错误，望不吝赐教，欢迎评论区留言互相学习。

封面图

学生时代的照片，想来已是十几年前的事情了

学生时代

从2009年9月开始读大学，当然也不是什么好大学，位于中原腹地的一所三流大学，所学专业是经济学中的《审计》。

上学的时候其实也不知道审计这个专业到底是做什么的，当时只是根据大学老师的讲述，大抵是可以到企业中做个会计师什么的，当然我们的专业课除了《审计》之外，《会计》《成本会计》《经济法》《税法》《财务管理》之类的都有。

学生时代对于我这种普通家庭的学生，大部分时候都是比较迷茫的，虽然每天都去上课，也很努力的去学习，识记老师讲课的内容，然后参加各种专业考试，会计证，助理会计师之类的考试，但是其实对于自己将来到底想要成为什么样的人，将来做什么样的工作，过怎样的生活，都没有一个完整的概念，只是随着日子一天一天的逝去，随波逐流而已，对于这种状态，我现在通常用一个词来概括：局限性。

局限性我给它的定义是：在个人所处的时代，环境以及个人认知水平有限的情况下，个人所能做事情的极限。简而言之，就是所有的事情都是命里注定的一个圈，超出了这个圈的范围，别的事情就做不了，这就是局限。

在这种局限下浑浑噩噩的度过了三年的时光，除了和班里同学一同度过这三年时光能够留下一些快乐的回忆之外。还有一件事情我觉得值得聊一下，就是我对英语比较感兴趣，这种兴趣表现在我喜欢在没课的时候去蹭英语系的外教课，喜欢听那个胖胖的外交讲课，有时候也到讲台上和他们一起做一些互动，讲一些英文，练习一下自己的口语。

等他们下课了，clay，那个外教的名字叫clay,是一个胖胖的60多岁的老头，我喜欢在他等班车的的时候跟他聊会儿天，内容我也记不得是什么了，大抵是些怎么学好英语之类的话，他也非常和蔼，只是说：dont warry，you need more pritice之类的，也有些是他在中国收养了很多孩子，住在大学路上什么的。

外语系的姑娘都很漂亮，当然，这可能也是我去蹭英语课的一个原因。

日子就这么一天一天的过去，上课，逃课，上课，逃课，逃课去蹭课。逃课出去玩，忽然有一天发现，自己马上就要毕业了，然后发现大家都开始准备找工作了，于是自己也开始准备简历，去人才市场，去各种招聘会～

那里能有什么好工作呢～

工作

好在是2012年的8月份吧，被一家单位录取了，名义上是做财务，其实是被派到外地做出纳去了，地址在东莞分理处。

彼时的想法是，好好工作两年，然后混个分理处的主管什么的，其实自己非常清楚自己本身也不适合做主管，好在分理处的同时都是年轻人，比较好相处。

于是在这里待了有一年多，分理处的其他人主要是做销售工作，基于工作性质的不稳定性，人员流失率很大，后来我就也离职了。

进京

从那里离职之后，去了四川的一家建筑单位，驻扎在项目部，职务是会计，主要工作内容是帮忙做些单位的内账，负责企业的报税及项目部的部分出纳工作。

彼时已经是2014年了，淘宝等线上购物平台已经非常流行了，听说当时的美工等工作也非常吃香，于是打算自学photoshop，将来转成美工，做些淘宝店铺的装修等工作。

可惜美工没有做成，恰逢建筑项目上需要进行融资，跟银行进行贷款，所以当时有一项工作是用photoshop伪造发票，将金额10万的发票，改成100万，甚至更大的金额。修改以后用打印机打印出来，公司用于向银行贷款等。

说是项目部，其实就是旁边就是工地，工地的生活非常艰苦，管理人员还好一些，一线工人每天干的都是体力活，确实挺辛苦的，于是到了2014年底，就提出了离职。

离职之后，辗转就到了北京。

到了北京之后，找了一个主要做供应链的单位，对接的是外企，职位名称忘了，主要负责回复一些英文文件，偶尔也需要通过电话和老外做些沟通，问他们要一些文件什么的。

幸运的是认识了一个做前端的同事。这时候是2015年，这个同事高中没毕业，做前端，薪资当时是12000，让我很是羡慕，有时候开玩笑跟我说你也转前端吧。

2015年，当时正是前端市场非常火的时候，移动互联网正在兴头上，于是下定决心开始学习前端，从最简单的html标签，css样式，Javascript开始，一点一点的去背，去学习相关的知识，也从简单的仿站开始练习，各种布局，样式属性之类的，写完了就拿给他看，虽然写的不怎么样～

就这么持续了大概有一年吧～

转前端

好在功夫不负有心人，2016年开始试着找一些前端相关的工作，最终还是找到了一份工作，那时候还没有现在的各种框架。

记得第一份前端工作的项目是一个javaweb的项目，然后还有一个用appcan做的混合开发的移动端项目。

就这样从看别人的代码，到自己写一些代码，从纯粹的前端三剑客html+css+js,慢慢的写到了前端三大框架vue+react+ng 。

转眼间从事前端工作也这么些年了，越写越觉得自己对前端的兴趣越浓，因为它有很多新的东西，虽然我不一定每个知识点都能弄的明白，但是当你思考时，那种沉浸其中的感觉是妙不可言的。

我也感谢这个行业，虽然它不能让我大富大贵，但是它起码做到了这些年让我衣食无忧。

最后

单纯的从技术方向出发，前端的方向很多，web，小程序，客户端，移动端，每个领域都有很多值得探索的东西。

虽然我不是科班出身，但是在这些年的学习和探索中，它教会了我很多东西。

最后更多的想说的可能只有两个字：感谢。

感谢那些帮助过我的人；

感谢那些年遇到的苦难；

也感谢自己的坚持～

希望每个人在自己的人生中都能得偿所愿～

谢谢～

最近遇到一个问题，计算滚动距离，滚动比例达到某界定值时，显示mask，很常见吧^ _ ^

这里讲的不是这个需求的实现，是其中遇到了一个比较有意思的bug，靠这个bug才达到了正确效果，以及这个bug是如何暴露的（很重要）。

下面是演示代码和动图

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>Document</title>

    <style>

        .container {

            width: 300px;

            max-height: 300px;

            background-color: black;

            position: absolute;

            top: 60px;

            left: 50%;

            transform: translateX(-50%);

            overflow-y: auto;

        }

        .child {

            width: 260px;

            height: 600px;

            margin: 0px 20px;

            background-color: pink;

            position: relative;

        }

        .flag {

            position: absolute;

            width: 100%;

            height: 25px;

            background-color: blueviolet;

            color: aliceblue;

            text-align: center;

            line-height: 25px;

            font-size: 14px;

            left: 0;

            right: 0;

        }

        .top {

            top: 0;

        }

        .bottom {

            bottom: 0px;

        }

    </style>

</head>



<body>

    <div class="container">

        <div class="child">

            <div class="flag top">top</div>

            <div class="flag bottom">bottom</div>

        </div>

    </div>

</body>

</html>

开始计算啦，公式：滚动比例 = 滚动距离 / 可滚动距离

滚动距离: $0.scrollTop

可滚动距离: $0.scrollHeight - $0.offsetHeight

即：scrollRatio = scrollTop / (scrollHeight - offsetHeight)

滚动到底部，计算结果是 300 / (600 - 300) = 1

我们需要拿scrollRatio和某界定值（比如0.1）作大小的比较，计算是true还是false（用isShow = scrollRatio < 某界定值来保存）。

这里一切正常。

不正常的情况出现了

就是没有出现滚动条的情况，即.child的高度没有超过.container的高度时，把.child的高度设成.container的max-height，就没有滚动条了（下面讲的情景也都是没有滚动条的情况）。

这个时候再去计算，得到了NaN，以至于 NaN < 0.1 = false。

因为isShow的预期就是false，所以一直都没有发现这个bug。

那么它是如何暴露的呢？

后来新的需求给.container加了border。演示一下加border，然后再去计算：

发现没，这时候$0.offsetHeight的高度把border的高度也算进去了，结果就成了true，这不是想要的结果 ❌。

然后就是一番查验

offsetHeight是一个元素的总高度，包括可见内容的高度、内边距（padding）、滚动条的高度（如果存在）以及边框（border）的高度。

而我们这里只需要可见的高度，就可以用到另一个属性了clientHeight。

clientHeight是指元素的可见内容区域的高度，不包括滚动条的高度和边框的高度。它仅包括元素的内部空间，即内容加上内边距。

当然这也只是继续使除数为0，然后得到结果为NaN，不过bug已经暴露出来了，后面就是一些其他的优化啦～

总结 + 复习（盒模型 box-sizing）

发现没有，offsetHeight和clientHeight的区别，就像盒模型中的标准盒模型和怪异盒模型的区别:

box-sizing: content-box(默认，标准盒模型)：宽度和高度的计算值都 不包含 内容的边框（border）和内边距（padding）。添加padding和border时， 会 使整个div的宽高变大。

box-sizing: border-box（怪异盒模型）：宽度和高度的计算值都 包含 内容的边框（border）和内边距（padding）。添加padding和border时， 不会 使整个div的宽高变大。

这样讲是不是加深一下对这两种属性的印象

^ - ^

在此之前我是自由职业者，满打满算一年空窗期，在被动收入不稳定，心想还是需要一份收入来维持日常生活开销，再去考虑打造自己的额外收入。

前前后后从准备到上岸历时一个半月，今天从三个方面分享这个过程我做了什么？

心态

做事情之前，心态很重要，我遇事很少否定自己，在我看来，别人可以做到的，自己也可以，虽然一年空窗，基本上不接触技术，写代码量远不如以前，但又不是要上天或者造原子弹，取决于谁执行力强，谁付出的时间多，仅此而已。

换作以前，相信大部分的同学去找半个月都可以入职自己期望的岗位，看了一下网上的情绪，行情在这个环境下的确蛮消极的，很多人找了几个月都没有上岸的，当然我自己也有感受到，简历丢出去之后没有声音，并且在各大招聘网站上坑位也减少了，相比两三年前如日中天的行情，难免会有这类情绪。

但我没有那么焦虑，为什么呢？其一是我心态比较好，其二是跟我的定位有关。

定位

第一个是我要找的岗位定位为中高级开发，而这类人在市场上来看一直都是稀缺资源，其他行业也如此。

第二个是薪酬范围定位在20k-25k范围，给不到我会觉得工作没劲，累点没关系，主要还是相信自己可以胜任。

第三个是前期投几个低于期望值的试试水，了解一下目前行情顺便找找感觉。

所以，接下来我只需要把目标定位在寻找中高级开发岗位即可，完善自己达到这个能力要求，下面是行动计划，细看下来你会发现这又是个PDCA。

计划

我把计划分为这几个模块：

1. 简历优化

我一开始是不会写简历的，因为中间没有跳过槽，也没定时更新，所以就随便拿了以前的模板改了改时间和项目就开始投了，简历回复少不说，即使有机会面试了也没有把简历提到的讲清楚，结果可想而知。

后面想想不行，虽然没写过，但是我会看简历啊，之前带团队有时候一天要看上百份简历，大概知道面试官青睐哪些人才，优化之后断断续续才有面试。

其次是我在面试过程结束时问面试官哪些地方还需要提升的，不少也会反馈简历问题，诸如：

• 管理工作内容太笼统了，看不出具体做了什么


• 没有说清楚空窗期做了什么


• 没有体现出你在项目中做了什么


• ......

知道自己问题之后，前后迭代了大概十几个版本，越到后面的质量越高，直至我入职之后，还有一个目标企业发来邀请。

2. 技能要求

前端领域涉及到这么多技能，需要有方向进行准备，分享一下我是如何分类：

基础：

• 前端三大件：HTML、CSS、JS


• 主流框架：Vue2/Vue3、React


• 状态管理：Vuex、redux、mobox


• 构建工具：webpack、Vue-cli、Vite、gulp


• 前端安全：xss、csrf、cors 常见问题和防御措施

进阶：

• JS运行机制、事件轮询机制、浏览器运行原理


• 前端性能监控、前端异常监控如何做？


• 前端工程化体系包含哪些


• 前端性能优化手段：页面性能、构建性能、代码性能


• Vue、React核心原理


• 基础算法数据结构


• Http协议

面对上面的技术基础类，主要是刷官方文档+常见面试题，这些更多是概念性的东西，在这里就不多说了，相信大家手上多少都有八股文资料，如果没有可以私信我。

而面对进阶类，首先总结自己项目中用到了哪些，吃透它。其次，面对不太熟悉的板块如HTTP网络，我会通过专栏学习或者一些讲得好的课程来弥补。

除了上面的方法，还有一种我常用的技巧来覆盖知识盲区，就是下面要说的模拟面试，几乎适用于任何技能面试。

3. 模拟面试

这里要说的模拟面试并不是找一些大佬一对一模拟训练，而是换位思考（当然能够模拟面试效果更好啦~）。

即把自己想象成面试官，在考察某一个知识点的时候，你会问自己什么问题呢？

举2个栗子🌰

对于用Vue的同学，我会问：

• vue diff 与 react diff有什么区别？


• 为什么v-for中建议带:key，有什么情况下是可以不带的？


• 写过组件或者插件吗，有什么注意点？


• vue-router原理是什么

结合一些热门的话题，我会问：

• vue2与vue3对比，你觉得主要区别是什么？


• vue2与vue3在性能优化做了什么？两者的构建产物有什么区别？


• 如果你去学vue3，你会从哪里开始，怎么学？

除了以上我给自己虚构的问题之外，还有诸如vue生命周期啊、组件通信啊等等基础肯定是要会的，我会刷文档或虚构题目，这些比较简单，搞懂就行了。

对于设计模式，我也问了自己几个问题：

• 你知道的设计模式有哪些，知道他们的应用场景吗（解决了什么问题）？


• 在工作中用到的设计模式有哪些？说说它们的优劣势


• Vue中用了哪些设计模式?


• 观察者和发布订阅有什么不同？

基本上这个薪酬范围的设计模式，搞懂了以上问题大差不差。

再来说说这种方式有什么优势？

首先，问题是通过我们自身思考提出并主动寻求解决的，这本身已经存在闭环了，有利于我们理解一个知识点。其次，我们思考提出某个问题，意味着大脑🧠的神经元网络中有存在某些游离神经节点，它没有被连接到一起，随着提出并解决的问题越多，连接起来的网络就越大，这就形成了所谓的知识网络，相比没有目的刷题，它的持久性更强，更能抗遗忘。

总结

结束之前，再分享面试过程中的一个小插曲，当时面了一家小企业，终面的时候面试官问我期望薪酬，就报了18k，但是面试官说给不到，17k考不考虑？我当时没有回绝，就说回去考虑一下。

回去考虑一番之后，我根据当时岗位给到的薪资范围，加上当时家里事情比较多，想先稳定下来再考虑其他的，打算接了这个offer准备上班，突然闹了个乌龙，HR说老板那边重新定了价，只能给到16k，我说还能这么操作？这不明摆着欺负老实人嘛？

想了想如果接了这个offer，岂不是比之前离职时更低，更别说对比以前的同事了。心里忍不下这口气，以至于那两周，每天都撸到一点钟，功夫不负有心人，最后顺利上岸了！

分享几点个人觉得比较关键的：

• 永远相信自己，心态很重要，不仅仅面试，它贯穿人的一生


• 简历真实，不玩心思，例如空窗期这种，如实说明


• 吃透简历内容，不留疑点


• 面试过程中不着急回答问题，可以先澄清问题动机，不要为了回答而拼凑答案


• 前面几次不通过没关系，但一次要比一次好

以至于如何备战高级开发，等我升级了再来分享~

最后，祝愿所有航海者都能够顺利靠岸！！！

注：由于最近比较多朋友私信我咨询简历优化建议或者八股文，可以加我的微信followJavaScript，丢简历过来即可，备注“掘金”。

把两个月前 钱江边的聚会小酌 成功移到余杭塘河。三巡五味后，一行三人在偌大的校园走着聊着。在滨江某知名支付公司的测试经理，感叹管理层间人浮于事站队排位;在阿里的前端程序员，困顿于今年未能升P竞争压力山大。而我，定位为服务端却在走全栈路线，也在纠结更换技术栈，看不清寻不到一个更满意充满想象力的未来。

似乎吐槽和患得患失，多过幸福和豪气干云。而回想这一切刚开始时的忐忑不安踌躇满志，绝没想到，会在一个雨过方晴的深夜，有这样一番对话。

4年前的今天，我离开家乡，从济南坐上一节南下的橙皮车。当慢慢悠悠走过十余个小时，从微山湖夕阳落下到寒山寺晨钟响彻，我来到了曾一见倾心风云际会的魔都，一只怯怯什么也不会的菜鸟，正式开启了必将色彩斑斓的职业生涯。

此前几天，第一次用58找房，还不知有那么多套路。我发了100多条短信，大多如泥牛入海不见回声。偶有的几条，也是中介答复:“便宜的前几天租出去了，还有套价格贵一些的”。我终在豆瓣小组，在车来到济宁时收到了这条回复。满是欣喜打开，充满失望关闭。

此前几个月，我放弃割舍许多，不曾随我的相当多数同学，去那几家中字头央企，也不曾青眼相向，可以一辈子安稳无虞的公务员事业编，而选择了一家未曾听闻的“互联网”公司。我知道，当我听到这三个字，郁结于胸口怏怏不乐的大石顿被粉碎，我知道，我的第一家公司，不会再有其他。然而回宿舍后我做的第一件事，是查证这家公司是否为诈骗组织皮包公司。我也在暗暗忧心，空有一腔热爱，就真能做得好吗？兴趣真的可以打败科班无视专业？

我在仙霞路工程技术大学的国家级创业园，度过了终生难忘的两年，也完美回答了上面的疑惑。又在两年前魔都落户安家周折太巨，选择如候鸟，随潮离沪来杭。

四年里，我以平均一年一家的频率，换过四家公司，薪资较最初翻转500%。四年前，创新创业之风荡涤全国，o2o风云乍起，p2p方兴未艾。而今，内外部趋势交织，猪从风口跌落，独角沦为毒角。我也面临职业和薪资门卡:我是否还能心平静气在一家单位多呆几年，沉淀而不颓废？我如何还能保持在基数较大的情况下，使薪资以较高速率增长？我有哪些要学哪些要放，我要走哪条职业路线？…

实在有太多要学，我给自己的目标是:除去工作所用，还要试图从数学和物理角度，理解背后机理;要紧跟潮流，对新出现的技术和事物保有热切好奇;要外语足够优秀，能无障碍阅读英语文档。…

从没想过，有一天“学习”也会成为甜蜜负担。但我清楚，并不是所有的职业，所有的从业者，都有我们这样可以不断学习不断提高，如果愿意可以练就一身本事的机会。我会在无边学海中偶尔迷失，但却清楚，一样技能可以一陈不变从生到死，那会让我因无成就感和提高的满足而生不如死。

我的感触是，从毕业到30岁，真的太短太短了。只有夜以继日只有目不见睫。几年里，太多的熬夜让我皮肤不复当年紧致滑腻，太多的久坐让我发福增重，或许还有双眼疲劳颈椎酸痛。…我会注意保重，但当解决一个问题，当当搞懂一样东西，那种感觉，像一个木匠做出一件工艺品，抖落浑身木屑站起时的满足。所有的疲乏，所有的周折劳累，都将烟消云散。

回瞰这几年，我总会在他们看不见的地方，感谢B哥L哥H哥，但我还想感谢并告诫自己:我很勇敢，也因而幸运，在一个几百年不遇的信息时代，如果我还因循守旧患得患失，畏葸不前混吃等死，那既是对自己得辜负，也是对时代得辜负。

自我介绍

我的家乡是浙江-宁波-余姚，是一名就读于一所位于宁波-慈溪（学校：笑死，这就我一所大学，你直接报我名字得了）的双非独立学院的软件工程专业的23年应届生，7到10月有在南京实习，现在是孤身一人在杭州实习的社恐前端实习生，前端练习时长一年半，擅长唱、跳、rap... 还只擅长Vue的渣渣前端程序猿，有兴趣可以关注我的公众号程序猿青空，23年开始我会时不时分享各种优秀文章、学习资源、学习课程，探索初期，还请多多关照。这篇文章会是我公众号的第一篇文章，主要对我这一年来的经历做一个简单的流水账总结，涉及到恋爱、租房、学习、工作等各方面内容，希望这份经验对你也能有所帮助。

学习

大二下半年的时候分流，自主报名到了我们学校的产业学院——企业和学校联合创办的培养应用型人才的学院。我文科相当薄弱，埋头考研会相当痛苦，也很清楚自己做不来官僚主义那一套，公职也不是适合我的职业（没错我对公职有偏见），很坚定就业这条路。因为还没有毕业，我的身份归根结底就是一个双非下流本科的一名大学生，为了避免自己毕业即失业，看当时产业学院的宣传也不错就去了。

事实上因为产业学院刚创办不久，而且并不是所有人来到这里都是为了就业的，也有可能是为了学分、助学金等其他方面的原因，课程设计、师资力量、同学质量等各方面都良莠不齐、鱼龙混杂。每门课程的期末大作业基本都是一个小项目，大三一年里两个期末都有为了大作业通宵的几天，再加上1500💰凑活过的生活费，死贵的电费和食堂伙食费，在这里学习和生活有时候还蛮辛苦的。好在我很清楚自己应该做什么，天赋不够，努力来凑，本来起跑线就低，更应该比别人卷一点。当然我也不是那种能够没日没夜卷的人（👀），关注了鱼皮，加入了他的知识星球，在星球天天学习健身（没错我还健身💪）打卡的flag没两个礼拜就立不住了，知识付费的事咱也没少干，就是说能一直坚持下来的着实不多，咱也明白咱就是个普通人，逆袭这种事确实还是很难做到的，我这人还是比较佛系的。

大三这一年我用一年的时间从零学前端，自认为还算是没有辜负自己，这一年时间的学习也还算有成果，虽然没法和卷王们争第一，也能跟在他们后面做个万年老二（😭呜呜呜）。下半年开始实习后更别说了，新的技术栈的学习基本就停滞了。实习前我还天真的以为能有更多的时间学习，正相反，比在学校学的更少，因为下班到家七八点，生活琐事会比在学校里多得多，而且我下班后还要花一个多钟头健身，再加上忙碌一天后更无心学习，只想躺平。

下半年做过的最卷的事也就参与了字节青训营，课题选择了前端监控平台，可惜的就是没能在青训营期间完成（😭呜呜呜，队友都摆烂了），当然也就没有结营证书。但我也不甘心就这样算罢，这个项目我就自己拉出来，作为我的毕业设计去完成它。解决实习期间学习效率低的最好办法就是在公司学习一些对公司业务有关或者优化公司项目的知识，名正言顺地摸鱼。我是Vue入门的，这一年里也一直守着Vue，来年第一季度目标就是学习React和Nest，开发一个自己的数据聚合的网站，能变现就最好了（😎欸嘿）。

生活&实习

大三下，也就是今年上半年，为了冲刺暑期实习，也就没去做兼职了，感叹本就艰难的生活的同时，殊不知这是为数不多还能自己自由掌控的日子了（😥我哭死）。其实我开始准备实习还是挺晚了，再加上期末没有太多时间，准备并不是太充分，没有太多自信心，投了几家大厂，不是没回应，就是笔试挂，就有点望而却步。

在我一个大佬同学的介绍下，面试了一家南京的小厂，过程很顺利，实习薪资给的也很可观，当时就没考虑那么多，就选择接受offer了（后来在杭州实习认识了几个小伙伴，才学了没几个月，暑假就面试进了独角兽企业，我那个时候确实应该再多投一投的）。刚开始的想法是第一次出门实习，有份经验就可以，在什么城市没关系，然而事实是工作上确实没什么关系，生活上关系可大了。7月13日第一次一个人拎上行李，义无反顾地去了南京，以为自己终于能够大展拳脚，再不济也能够在公司有所贡献，然而现实总是没那么理想。

因为一个人前往外地工作，第一件事情便是租房，为了省点钱就托南京实习公司的一个同事看房子，因为他的房租到期也要找房子就顺便可以租在一起，有个照应。然而实际上因为是第一次出远门工作和生活，一切和自己的理想差距显然大了许多：因为不是自己实地看的房，而且也是第一次租房，虽然房租只有850💰，但是也可能因为是夏季大家都开空调，差不多50多💰一个礼拜的电费和其他乱七八糟的费用，一个月光租房子就差不多得1200💰，并不算贵，但是性价比极低；我的房间没地方晒衣服，只能晒在那个同事的房间的阳台，作为一个社恐患者，每次去都要做很多心理斗争（他会不会睡了，他会不会在忙....🙃）；桌上只能堪堪放下我的显示器和笔记本，鼠标活动范围极小；床应该是睡过好几个租客了，明显的不舒服；吃的方面因为有点水土不服不能随便乱吃，同时也是为了省钱所以选择自己做饭，因此还得购置很多厨具调味品等等，一次性的开销💰不小；回学校的频率比我想象的高，因此来回车费也成为一大负担；当时租房合同是同事代签的，他签了一年，我那时候也不懂也没问，再加上当时换工作离开的比较急，没时间找转租，违约金直接血亏1700💰。

生活的种种问题都还能接受或者解决，然而工作方面，因为进入公司的时间段比较特殊再加上疫情影响，在南京实习的三个月里，我始终没有能够在技术上得到足够的提升，再加上与公司和领导的气场不合，使得我在公司整天如坐针毡，甚至有点无所事事（总之就是过的很不开心），虽然有不低的实习薪资，但是我始终没法在那里躺平。因此在中秋决定参与秋招，开始寻找第二份实习工作。

然而今年找工作并不简单，因为频繁发作的疫情，再加上互联网行业这些年的发展，行业的形势非常的严峻，各大公司都削减了HC（head count，人头数，就是最终录用的人数，肯定有小伙伴不懂这个词，我一开始就不懂🤏），作为一个民本23年应届生，在今年的秋招着实很难找到一份理想的工作。那段时间的想法就是尽快找到下一份工作（急急急急急急，我是急急国王），找到一份离家近、工资高、平台大至少满足两个的工作。从9月10日中秋就开始投出第一份简历，到10月19日确定来到杭州的一家四五百人的SaaS公司，这期间投出过几百份简历，得到的回应却寥寥无几，这是一段非常难忘的经历。

这一个月里每一天都在为找工作烦恼，一开始专注于线上面试，却始终的得不到理想工作的认可，持续的碰壁使得开始怀疑自己这些年的学习，自己的选择是不是错了，是不是自己能力确实没法满足他们的要求（被ktv了），后来也决定不放过线下面试的机会，顶着疫情在南京、杭州、家、学校几地频繁奔波，在杭州线下面试的那一天还是顶着自己身体上的各种不适（持续拉肚子，全身酸痛，萎靡不振），仍然要拿出饱满的精神去面对面试，好在当时就获得了面试官也是现在的leader的认可，简直就是久旱逢甘霖，虽然并不是直接发的offer，但是也是十分有信心。杭州比起南京的工作，实习薪资低了很多，但是因为线下面试，对于当时感受到的公司的氛围十分的心动，也就放弃了其他小公司更高薪资的offer，决定了自己的第二份实习工作。

换工作又是换城市，所以又需要租房搬家，购置各种必需品，又是一大笔开销，在还没进公司前始终在担忧自己先择了薪资更低的工作，到时候会不会付出了这么多，结果又远不如预期让自己更痛苦。不过在经过了一个月左右实习后，我在杭州的公司工作的感受让我相信自己的选择没有错。

10月23日我再一次拖着一大堆行李开始了迁徙，本来打算先简单看房子，先回家住几天再自驾，拖着行李回来看房子签合同，所以我把被子等一些大件的行李都寄回家了，但是这次进入杭州后就黄🐎了（之前几地来回跑黄都没黄一下），只能多看几套房子然后就签下来，好在当天就看到一个自己满意的，10几平，押一付一，一个月算上水电差不多也就1300💰，不至于睡大街，但是我没有被子，当时杭州刚开始降温，温度也就个位数，但是买被子太亏了，之后用不上，就买了床毛毯，多盖几件衣服，凑活过了两天（真的凑活，冷的雅痞）。

11月1日正式入职，正式开启了在杭州的工作生活，有条不紊的入职手续，时长1周的实习生培训，认识了许多和我一起实习的小伙伴，刚进来还赶上公司的双十一活动，让我对未来的工作生活充满希望。

第一月开始接触了一些简单的业务，重新开始了健身，第二个月就参与开发了一个简单的项目，还封装了公共组件、开发了简单的提高开发效率的脚手架工具，我终于能够继续有条不紊运转了。

在南京实习的期间除了参加了字节青训营和准备面试而巩固基础外，专业上可以说是没有丝毫提升，不过生活经验确实收获满满，坚定了自己的目标，职业生涯规划更加清晰，为了达到目标去学会自律。这几个月的开销给自己和父母都增添了不小得负担，好在现在稳定下来勉强能够在杭州自给自足，生活重新步入正轨，比起在南京，杭州的生活更加得心应手。但是并不是说南京不好，南京是一个非常优雅的城市，这里有他躺在超市里超乖的猫猫，超治愈

离开南京前我也花时间去好好游玩了两天（去了一些免费的博物馆，景点）。

比起杭州，我认为南京更适合生活，我只是去到了一个不适合我的公司和因为经验不足吃了不少亏才离开了这个城市。我很珍惜在杭州的这份工作，也非常享受现在忙碌充实的生活，我也希望自己的能力能够不断得到认可，继续探索自己的人生价值。

感情

呜呜呜，鼠鼠该死啊，鼠鼠长了个恋爱脑，但是好在现在穷的雅痞，我还社恐，可以心无旁骛地工作学习（搞💰）。出来实习没几个礼拜就跟在一起一年的女孩子分手了，其实在上半年因为我们对未来规划的分歧就吵过架，她想留在慈溪，而我更向往大城市（当然不止这一点原因啦），那个时候我就很清楚这段感情肯定没法坚持很久，下半年又异地，在各自的城市实习，天天吵架，自然而然就吵分了，累觉不爱。我深知自己不是啥好男人（男人没一个好东西），还没有资本，毕业前绝对要水泥封心（做杭州第一深情）。

其实我家离学校很近，但是从念大学开始还是很少回家了，在学校里没有什么感觉，直到独自出门在外工作才知道在家真好，爸爸妈妈真好（我是妈宝男，呜呜呜😭），看这篇文章的小伙伴不要再随便跟爸爸妈妈撒气了哦。家里的老人只剩下奶奶独自在乡下了，以后一定要多打电话。

展望

在未来的一年中，希望自己能够吸收已经犯过的错误的经验，保质保量地完成未来的各项工作，作为一名程序员最重要的最重要的就是自我驱动，持续学习，通过不断学习才能够在未来的工作中创造更多的价值，以下是我23年的一些计划

学习

• 这个月先抓紧时间把自己的毕设解决，写复盘的分享博客，之后顺利毕业


• 上半年学习React，Nest，开发一个数据聚合分享平台，同样做分享


• 运营自己的博客和各平台账号，不说多少粉丝，能坚持不凉就行，争取每周一个博客


• 每季至少阅读一本书，学习一个技术栈


• 坚持自己的每日计划和每月复盘总结（包含年中和年终总结）

工作

• 因为现在常态化了，不知道今年的就业形势会是什么样的，着实不想再像去年那样被支配了，所以还是希望得到自己满意的薪资的前提下在这里转正，但愿不要出什么幺蛾子吧


• 继续卷进部门更深层业务，目标负责6个项目


• 学习更多优化开发效率和质量的技术栈，明年就简单定个两个的目标吧，要求不高

生活

• 我真的超级想买机车的，但是杭州主城区禁摩，所以先23年下半年花时间考个D照，看情况决定买个机车还是电驴


• 3月份房租到期了，看房肯定又要放进日程了，看看到时候有没有合租的小伙伴吧，如果有人有兴趣到时候可以分享一下杭州租房经验


• 健身肯定是要继续的，有一说一我肉体确实没啥天赋（也可能是吃得不够多），健身更多的是一种生活态度吧


• 我是一个很不喜欢打电话的人，尤其是和长辈，感觉没话聊，但是老人家接到自己孩子的电话，知道孩子过得不错，真的会很开心。明年定个小目标，一个月给奶奶打一通电话。

2022年好像所有人都过的很艰难，或许所有人都想离开浪浪山，但是也不要忘记看看浪浪山的风景，让我们一起加油吧。最后再打个广告，关注公众号程序猿青空，免费领取191本计算机领域黑皮书电子书，更有集赞活动免费挑选精品课程（各个领域的都有），不定期分享各种优秀文章、学习资源、学习课程，能在未来（因为现在还没啥东西）享受更多福利。

我是一个容易焦虑的人，工作时候想着跳槽，辞职休息时候想着工作，休息久了又觉得自己每天在虚度光阴毫无意义，似乎陷入了一个自我怀疑自我焦虑的死循环了。我想我该做的点什么去跳出这个循环。。。

自我叙述

我相信，每个人都有一个自命不凡的梦，总觉得自己应该和别人不一样，我不可能如此普通，自己的一生不应该泯然众生，平凡平庸的度过。尤其是干我们it这一行业的，都有一个自己的程序员梦，梦想着，真的能够用 “代码改变世界”

入行回顾

你们还记得自己是什么时候，入行it行业的吗

我今年已经28岁了，想起来入行，还挺久远的，应该是2016入行的，我也算是半路出家的，中间有过武术梦 歌唱梦 但是电脑什么上学那会就喜欢玩，当然是指游戏，

武术梦

来讲讲我得第一个·梦，武术梦，可能是从小受到武打演员动作电视剧的影响，尤其那个时候，成龙大哥的电影，一直再放，我觉得学武术是很酷的一件事情，尤其那会上小学，还是初中我的体育还是非常好的，

然后我们家那个时候电视还是黑白的，电视机。哈哈哈😀电视台就那么几个，放来放去，有一个台一直重复放成龙电影，还有广告， 都是 学武术就到 xxxx学校， 我被洗脑了吧

于是真的让我爸，打电话质询了一下，可是好像他们这种武术学校都是托管式的，封闭式学习，听说很苦，，，，当然这不是重点，重点每年学费非常的贵，en~，于是乎我的这个梦想终止了，。。

歌唱梦

为啥会有唱歌想法，你猜对了，是被那个时候的好声音给影响了，那个时候好声音是真的很火，看的时候我一度以为我也可以上好声音，去当歌手然后出道，当明星，什么的。

不过不经历打击，怎么会知道自己的下线在哪里呢

我小学换了两到三个学校，到初中，再到高中，你们还记得自己读高中那会吗，高中是有专业选择的，入学军训完以后。

我们代班主任，和我们说有三个专业方向可以选择，艺术类，分美术，和唱歌，然后是文化类，然后艺术类就业考大学分数会低很多，然后一系列原因，哈哈哈，我就选择了歌唱班。

我最好伙伴他选择了，美术类就是素描。这里我挺后悔没有选择 美术类。

到了歌唱班，第一课就是到专业课有钢琴的教室，老是要测试每个同学的，音色和音高，音域
然后各自上台表演自己的拿手的一首歌，。我当时测试时候就是跟着老师的弹的钢琴键瞎唱，

表演的歌曲是张雨生《大海》 也就唱了高潮那么几句。。 😀现在想起来还很羞耻，那是我第一次在那么多人面前唱歌，

后面开始上课老师说我当时分班时候音色什么还不错，但学到后面，我是音准不太行，我发现。再加上我自己的从小感觉好像有点自卑敏感人格，到现在把，我唱歌，就越来越差，

当然我们也有乐理。和钢琴课，我就想主助攻乐理和钢琴，

但是我很天真

乐理很难学习，都是文科知识需要背诵，但是他也要有视唱，也就是唱谱子，duo，re，mi，fa，suo，la，xi，duo。。等，我发现我也学不进去

后面我又开始去学钢琴，但是钢琴好像需要一定童子功，不然可能很难学出来，于是我每天早上6点钟起来，晚上吃完饭就去钢琴教师抢占位置， 还得把门堵着怕人笑话，打扰我，

结果你们也猜到了，音乐方面天赋很重要，然后就是性格上面表演上面，要放得开，可是我第一年勉强撑过去了，后面第二年，专业课越来越多了，我感觉我越来越自卑~，然后成绩就越来越差，老师也就没太重视，嗯~好不容撑到了第二年下半年，放暑假，

但是老师布置任务暑假要自己去外面练钢琴，来了之后要考试，我还花钱去外面上了声乐课和钢琴课，哎，我感觉就是浪费钱，，，，，因为没什么效果，性格缺陷加上天赋不行，基本没效果，那段时间我也很痛苦的，因为越来越感觉根本容入不进去班级体，尤其是后面高二，了专业课很多大部分是前面老师带着发生开嗓，后面自由练习，我也不好意思，不想练习，所以
到后面，高二下学习我就转学了，，，，

当然我们班转学的，不止我一个，还有一个转学的 和我一个寝室的，他是因为音高上不去，转到了文科班， 还有一个是挺有天赋，我挺羡慕的，但是人家挺喜欢学习，不喜欢唱歌什么，就申请转到了，文科班。 不过她转到文科班，没多久也不太好，后面好像退学了，，我一直想打听他的消息，都在也没打听到了

玩电脑

我对电脑的组装非常感兴趣，喜欢研究电脑系统怎么装，笔记本拆装，台式机拆装，我会拿我自己的的笔记本来做实验，自己给自己配台式机，自己给自己笔记本增加配置，哈哈哈哈。对这些都爱不释手。

这还是我很早时候，自己一点一点比价，然后去那种太平洋电脑城，电脑一条街，那种地去找人配置的。想想那时候配置这个电脑还挺激动，这是人生的第一台自己全部从零开始组装配的电脑，

本来打算，后面去电脑城上班，开一个笔记本维修，电脑装配的门面的，（因为自己研究了很多笔记本系统，电脑组装），可是好像听电脑城的人说，电脑组装什么的已经不赚钱了，没什么价格利润，都是透明的而且更新迭代非常的快，电脑城这种店铺也越来越少了，都不干了，没有新人再去干这个了，于是乎我的第一份工作失业 半道崩殂了，哈哈哈哈还没有开始就结束了。

学it

后面我又报名自学了，it编程，《xxx鸟》 但是学it我学起来，好像挺快的，挺有感觉的，入学前一个星期，要等班人数到齐才能开班，我们先来的就自己学习打字了，我每天都和寝室人，一起去打字，我感觉那段时间我过得挺开心和充实的，

后面我们觉得自带寝室不好，环境差，于是就几个人一起，搬出去住了，一起学习时候有一个年级26了，我和他关系还蛮好的，不过现在也没什么联系了，，，

学习时候，每次做项目时候我都是组长，那个时候原来是有成就感的，嗯，学习it好像改变了，我学唱歌那个时候，一些自卑性格，可能是遇到了一个好的老师吧

当然后面就顺利毕业，然后找到了工作了，，，

直到现在我还在it行业里

嗯~还想往下面写一点什么，，，下一篇分享一下我入门感受和经历吧

【随想录】我尽然突然焦虑，并且迷茫了

「随想录」

这是师叔对自我现状的剖析和寻找了一些 “新的方向” “新的视角” 来重新审视自我的思想录，希望我的家银们在文章中得到思想启发或以我为鉴，不去做无谓思想内耗！

最近是怎么了

最近几个朋友，突然询问我，现在应该怎么学习，将来才会更好的找工作，怕毕业以后没有饭吃，我说我其实也不太清楚，我目前三段实习我都没有找到一份真正意义的好工作，就是那种我喜欢这门领域，并且喜欢公司的氛围，并且到老了还能保持竞争力（莫有35岁危机）。

所以说我真的没有一个准确的答案回复。但是我以为目前的眼光来看一份好工作必备的条件就是，我在这个领域学的越多，我的工资和个人发展瓶颈越高，这份工作是一个持续学习的过程，并且回报和提高是肉眼可见的！

回忆那个时候

其实说实话，这个疑惑我上大一就开始有，但是那个时候是从高考的失落中寻找升学的路径，开始无脑的刷那种考研短视频

（看过可能都知道真的一下子励志的心就有了，但是回到现实生活中，看到身边人的状态~~~没错人就是一个从众的种群，你可能会问你会不会因为大一没有那么努力学习而后悔，但是其实我不会，因为那一年我的经历也是我最开心大学生活，虽然也干了很多被室友做成梗的糗事，但是想一想那不就是青春嘛，要是从小就会很有尺度的为人处世，想一想活着也很累嘛，害，浅浅致敬一下充满快乐和遗憾的青春呀！）

个人看法

哈哈，跑题了。给大家点力量把！前面满满的焦虑。其实我感觉我们都应该感谢我们来到计算机类的专业，从事这方面的学习和研究。

因为计算机的扩展性，不得不说各行各业都开始越来越喜欢我们计算机毕业的大学生（就业方向更加广），我也因为自己会计算机，成功进入一个一本高校以上的教育类公司实习（同时也是这个时候知道了更多优秀学校的毕业年轻人，真正认识到学校的层次带给人的很多东西真正的有差距）；

虽然我是二本的学生，但是在亲戚朋友眼里，虽然学校比不上他们的孩子，但是计算机专业也能获得浅浅的也是唯一一点可以骄傲的东西（活在别人嘴这种思考方式肯定不是对的，但是现实就是在父母那里，我们考上什么大学和进入了哪里工作真的是他们在外人的脸面，这种比较情况在大家族或者说农村尤为严重）；

技术论打败学校论，计算机专业是在“广义”上为数不多能打破学校出身论的学科，在公司上只要你能干活，公司就愿意要你，这个时候肯定有人diss我，现在培训班出来的很多都找不到工作呀，我的回答只能是：的确，因为这个行业的红利期展示达到了瓶颈期，加上大环境的不理想，会受到一些影响，但是我还是相信会好的，一切都会好的。

做技术既然这样了

关于最近论坛上说“前段已死”“后端当牛做马”“公司磨刀霍霍向测试”......

这个东西怎么说，我想大部分人看到这个都会被这个方向劝退，我从两个角度分析一下，上面说了，真滴卷，简历真滴多，存在过饱和；第二点，希望这个领域新人就不要来了，就是直接劝退，被让人来卷，狭义上少卷一些......

现在就是导致我也不敢给朋友做建议了，因为当他看到这些的时候，和进入工作环境真的不好，我真的怕被喷死

包括现在我的实习，大家看我的朋友圈看出工作环境不错很好，但是和工作的另一面，是不能发的呀，有时候我都笑称自己是“产业工人”（这个词是一个朋友调侃我的）

不行了，在传播焦虑思想，我该被喷死了，现在我给建议都变得很含蓄，因为时代红利期真的看不透，我也不敢说能维持多少年，而且我工作也一般，我不敢耽误大家（哈哈哈，突然想起一句话，一生清贫怎敢入繁华，二袖清风怎敢误佳人，又是emo小文案，都给我开E）

个人总结

本文就是调侃一下现在的环境啊，下面才是重点，只有干活和真话放在后面（印证一个道理：看到最后的才是真朋友才敢给真建议，我也不怕被骂）

心态方面：我们这个年纪就是迷茫的年纪，迷茫是一种正常的状态，因为作为一名成年人你真正在思考你的个人发展的状态，所以请把心放大，放轻松，你迷茫了已经比身边的人强太多了，如果真正焦虑的不能去学习了，去找个朋友聊一聊，实在不行，drink个两三瓶，好好睡一觉，第二天继续干，这摸想，这些都算个啥，没事你还有我，实在不行微我聊一聊，我永远都在，我的朋友！

工作方面：俗话说：女怕入错行，男怕娶错人！（突然发现引用没什么用，哈哈）我们可以多去实践，没错就是去实习，比如你想做前端的工作，你就可以直接去所在的城市（推荐省会去找实习）但是朋友其实实习很难，作为过来人，我能理解你，一个人在陌生的城市而且薪资很可怜，面对大城市的租房和吃饭有很多大坑，你要一一面对，但是在外面我们真要学会保护自己，而且实习生活中经济方面肯定要父母支持，所以一定要和父母好好沟通，其实你会发现我们越长大，和父母相处的时光越短。（我今年小年和十五都没在家过，害，那种心理苦的滋味很不好受）

升学方面：不是每一个都适合考研，不要盲从考研。但是这句话又是矛盾的，在我的实习生涯中，学历问题是一个很重要的问题，我们的工作类型真的不同，还是那句话，学历只是一个门槛，只要你迈入以后看的是你的个人能力。说一句悄悄话，我每天工作，最想的事情就是上学，心想老子考上研，不在干这活了，比你们都强。所以你要想考研，请此刻拿出你的笔，在纸上写下你要考研主要三个理由，你会更好的认识自己，更好选择。

好吧，今天的随想录就这摸多，只是对最近看文章有了灵感写下自己的看法，仅供参考哦！

回答问题

回应个问题：很多朋友问我为什么给这摸无私的建议，这是你经历了很多才得到的，要是分享出去，不是很亏？

（你要这摸问，的确你有卷到我的可能性，快给我爬。哈哈哈）可能是博客圈给的思想把，其实我说不上开源的思想，但是我遇到的人对我都是无私分享自己的经验和自己走过的坑，就是你懂吗，他们对我帮助都很大，他们在我眼里就是伟大的人，所以我也想要跟随他们，做追光的人！（上价值了哦，哈哈）

写在最后

最后一句话，迷茫这个东西，走着走着就清晰了，迷茫的时候，搞一点学习总是没错的。

前言

哈喽~还在纠结是继续一线城市干着，还是回老家发展吗？先带大家回顾一下我工作的经历

19年还在大四的时候，我就去了上海，干起了前端，敲起了代码，刚开始干啥啥不行，整个流程一脸懵逼，过需求、开发、对接口、提测……

• 过需求嘛，不就是听一听pm怎么讲；


• 开发嘛，就自己慢慢开发；


• 对接口嘛，等着后端给呗，慢慢对；


• 过测试用例嘛，就听听测试怎么讲呗；


• 提测嘛，主要测试干，有bug我改改呗~

no！现在回想起当时的这些心里所想，简直是大错特错啦！经历过很多事情后，我来给你们整理个干货：

• 过需求，很重要，不只是听pm说，自己还要审视需求，从技术的角度，让技术实现起来简单，又能满足产品需求，否则最后坑的还是自己，吭哧吭哧的去实现pm提出来的奇奇怪怪的需求~


• 开发，不单单要开发，还要提前预估好时间，安排好自己的计划，有什么问题，要 delay了，都要提前跟pm说，否则 最后难办的还是你自己，熬大夜的还是自己。。提前跟他们说，提前要时间，提前规划好，我就是不加班的那个崽！


• 对接口，也不仅仅是对接口，要提前跟后端要接口文档，否则你都不会想到你的后端怎么能给你跟你开发差别这么大的数据格式，尤其是陌生的后端，别问我咋知道的，说多了都是泪o(╥﹏╥)o


• 过测试用例也要给我好好听，谁知道测试那个货看完需求文档后，理解的跟你开发的有啥区别，没准完全不一样，这时候你要给予反驳，问pm到底是啥，否则你会收到很多奇奇怪怪，每个字都认识，但是结合起来无法理解的bug。。一样也别问我咋知道的0.0


• 提测，一定一定要自测，确保主体流程通顺，否则被打下来的话，是piapia的被测试打脸

从摆烂到涨知识

经历过初期的摧残之后，我进入到了摆烂期，因为什么都熟悉了，给东西也能做出来了，就日常摆烂了，直到跳槽去了另一家比较新型的互联网公司，接触了好多之前没接触的，干一天学到的东西是上家公司干一年也可能学不到的。

之前每次发包，是自己吭哧吭哧远程服务器，贴个包，现在是Jenkins自动化部署，一点就好；

之前没开发过微信小程序、没用react写过项目，现在天天是uniapp开发的微小和react+hooks的后管……

总之，就感觉学了好多东西，每天都在学习。

2022 放飞

直到2022年三月，上海疫情的到来，开启了在家办公，身边同事也被辞了好多。

2022年6月复工，又开始了正常去公司上班，但是任务很少，几乎没再学到东西了，每天上班就是再跟同事扯皮子。

2022年9月我也被辞了，公司因自己发展原因，辞退了我，然后就计划回老家了，给外面也干了三年了，决定在走之前玩一把，就去了杭州、去了好多之前想去的的地方

回老家安安稳稳

因为自己还养了两只猫，我自己还晕车，总之就很艰难的在2022年九月中旬回了老家，又休息了半个多月，开始找工作，老家的工作真的很不好找，boss、智联都被翻烂了，全聊过了，而且薪资也很低，简直是比之前的一半都低，面试也根本不像一线城市一样那么难，好多还不是双休，就这样艰难的挑挑拣拣，在十月中旬，我入职了，过起了躺平的日子，从来不加班，九点到，六点跑，双休，技术上有很多之前没接触过的，但不怕，慢慢整呗，而且我身兼数职，虽然是前端，但可以帮忙做icon图标，还可以当当测试。

跟之前比，难免有技术上和管理规范上的落差感，但是回老家后的生活相当充实和真实，每天都能吃的爸爸妈妈做的饭，走从小走过的路，虽然钱不多，但是真的幸福感+真实感上升了好多。

2023年我就希望可以安安稳稳，平平安安过着简单的小日子，只要自己觉得快乐就好。

还在犹豫在一线城市打拼还是回老家的友友们，你们也可以看看我的经历，来判断哟，我个人觉得如果不打算在一线城市买房安家的，早点回老家挺好的，安安稳稳，愿大家也可以过自己觉得舒服的日子哟~

翻车现场

5年前的一个晚上，我接到数据组同事的消息，要求将A用户的磁盘快照共享给B用户。我对这个线上运维工作早已轻车熟路，登录线上服务器仅用了2分钟就完成了。

我继续忙着其他事情，3分钟后，我正要打开新的控制台页面，猛然发现控制台上的“ public = true”。我惊慌地查看磁盘快照状态，发现磁盘快照已经共享给了所有用户。任何用户都可以在自己的快照列表中看到这个快照，并用快照创建新的磁盘，这意味着这些快照数据已经泄露了。这可是公司重要客户的磁盘数据啊！！！！

我心里明白，对于云计算行业，数据安全问题比线上bug还要严重！

我立刻就慌了，心脏砰砰的跳，手也开始颤抖。我心里很忐忑，一开始试图偷偷回滚，纠结之后，最终选择告诉了组长。

我倒吸一口气，一边进行回滚，一边试图平静的说，“我把刚才的快照共享给了所有租户”。瞬间，组长瞪大眼睛了看着我，“回滚了吗，赶紧回滚……”。 我颤抖地编辑SQL，手都麻木了，心脏还在怦怦跳个不停，开始担心这件事的后果。

领导边看我回滚，边小声对我说，“赶紧回滚，下次小心点”，看的出来，组长不想声张，他想先看看影响。

”嗯，好“，我努力嗯了一声，组长没大声骂我，我很感动。本以为回滚了，就没事了。

（后来这家小公司黄了，这是被我干黄的第二家公司，你们干黄了几家？）

然而，这远远没有结束。

原本宁静的办公室突然变得热闹起来，周围的同事们纷纷接到了报警通知。他们“兴高采烈”地讨论着报警的原因，我的注意力也被吸引了过去，听起来似乎与我有关，但我却没有心情去理会他们。

最终，快照被共享 5 分钟后，回滚完成，我长舒一口气，心想幸好我多看了一眼控制台，否则不知道被泄露多久。

与此同时，邻居组的成员钱哥找到了我，问道：“刚才快照计费数据暴涨了，你们这边有做过什么操作吗？”

随后，邻居组的组长王哥也过来了，询问情况如何。

我的组长苦笑着告诉他们：“刚才一个磁盘快照错误地被共享给了所有租户，不过现在已经回滚了。”

邻居组的王哥听后惊愕地说道：“卧槽，谁干的？”他的脸上露出了一丝微笑，似乎是看热闹的微笑。

我实在不知道该怎么说了，苦着脸问他们：“计费数据能回滚吗？”

邻居组的王哥没有回答我的问题，看了我一眼，说：“我叫上老板，先找个会议室讨论一下吧。”

万幸的是这 5分钟里没有用户使用此快照创建磁盘，这意味快照数据没有发生实质性泄露。

至暗时刻

接下来的两天里，我只做了两件事，参加复盘会议和去会议室的路上。这两天是我人生中最难忘的时刻，我尴尬得连脚丫子都能拧成麻花。

我真希望能立刻辞职离开这个地方。”别再鞭尸了，老子不干了，行不行。md，不就是共享个快照嘛！“ 我的心理状态从忐忑变得暴躁~

（每次造成线上故障，我都有类似的想法，我不想干了，不就是个bug吗，不干了，还不行吗？你们有类似想法吗？）

后来我开始后悔 ，为什么不早点下班，九点多还帮同事进行高危的线上操作，我图个啥

对，我图个啥。我脑子被驴踢了，才提出这个人肉运维方案，一周运维十几次，自己坑自己……

背景

2个月前，组长接到一个大客户需求，要求在两个租户之间共享云磁盘数据，当时提出很多个方案，其中包括分布式存储系统提供工具共享两个云磁盘数据等非常复杂的方案。 我当时听到这个需求，就立马想到， 我们的云管理系统可以实现两个租户的资源共享啊，通过给云磁盘打快照、共享快照等，就实现两个云磁盘的数据共享。

当时我非常得意，虽然我对存储并不是很了解，但是我相信我的方案比存储团队的底层方案更加简单且可行性更高。经过与客户的沟通，确定了这个方案能够满足他们的诉求，于是我们定下了这个方案。

由于大客户要的比较急，我改了代码就急匆匆上线，这个需求甚至没有产品参与，当客户需要共享数据时，需要我构造请求参数，在线上服务器上命令行执行共享操作。第一版方案在线上验证非常顺利，客户对这样快速的交付速度非常满意

因为我们使用了开源的框架，资源共享能力是现成的，所以改动起来很快。只不过有一个核弹级feature，我忽略了它的风险。

public = true时，资源将共享给全部用户。“只要不设置这个参数就不会有什么问题。” 这是我的想法，我没有考虑误操作的可能，更没有想到自己会犯下这个错误。

本以为只是低频的一次性操作，没想到后来客户经常性使用。我不得不一次次在线上执行高危操作，刚开始我非常小心谨慎，仔细的检查每个参数，反复确认后才执行命令。

然而，后来我感到这个工作太过枯燥乏味，于是开始集中处理，一次性执行一批操作。随着时间的推移，我越来越熟悉这件事。这种运维操作我两分钟就能完成……之所以这么快，是因为我不再仔细检查参数，只是机械地构造参数，随手执行。正是我松懈的态度导致闯下了大祸，在那个日常性加班的晚上。

后来我开始反思，从需求提出到故障发生前，我有哪些做的不对的地方。我认为有如下问题。

1. 
   

   技术方案不能仅限于提供基本的资源共享能力，还要提供可视页面，提供产品化能力。

   
   


2. 
   

   高危接口，一定要严格隔离成 单独的接口，不能和其他接口混合在一起，即使功能类似

   
   


3. 
   

   线上重要操作要提供审核能力！或者有double check 的机制！

   
   

深刻的反思

任何工作都是有风险的，尤其是程序员无时无刻都在担心发生线上问题，如果不学会保护自己，那么多干一件事就多增加很多风险，增加背锅的风险。

拿我来说，本来这个需求不需要我参与，我提出了一个更简单的方案，高效的响应了大客户需求，是给自己长脸的事情。然而，我犯了一个巨大的错误，之前所做的努力都付之一炬。大领导根本不知道我提出的方案更简洁高效，他只认为我办事不可靠。在复盘会议上，我给大领导留下了非常糟糕的印象。

话说回来，在这个事情上如何保护自己呢？

1. 
   

   技术方案一定要避免人肉运维，对于高危运维操作要求产品提供可视化页面运维。一定要尽全力争取，虽然很多时候，因为排期不足，前端资源不足等原因无法做到。

   
   


2. 
   

   如果没有运维页面，等基础能力上线后，继续寻求组长帮助，协调产品提供操作页面，避免一直依赖自己人肉运维去执行高危操作。

   
   


3. 
   

   在还没有产品化之前，要求客户或上游同事将所有的需求整理到文档上，使用文档进行沟通交流，记录自己的工作量，留存一份自己的”苦劳“。

   
   


4. 
   

   在低频操作，变为高频操作时，不应该压迫自己更加“高效运维”，而是将压力和风险再次传达给产品和组长，让他们意识到我的人肉运维存在极大危险，需要要尽快提供产品化能力。让他们明白：“如果不尽快排期，他们也会承担风险！”

   
   


5. 
   

   任何时候，对于线上高危操作，一定要小心谨慎。万万不可麻痹大意！

   
   

总之，千万不要独自承担所有的压力和风险。在工作中，我们可以付出辛勤努力，承受一定的风险，但是必须得到相应的回报。

风浪越大，鱼越贵。但是如果大风大浪，鱼还是很便宜，就不要出海了！风险收益要对等

就这个事情来说，每天我都要执行高风险的运维操作，是一种辛苦而不太受重视的工作。尽管如此，我却必须承担着巨大的风险，并自愿地让自己不断追求更高效的人工运维方式。然而结果却让人啼笑皆非，我终究翻车了。实在是可笑。

挣着卖白菜的钱，操着卖白粉的心，这是我的真实写照。

吾日三省吾身、这事能不能不干、这事能不能明天干、这事能不能推给别人干。

程序员不善于沟通，往往通过加班、忍一忍等方式默默地承担了很多苦活、脏活、累活。但是我们要明白，苦活可以，脏活等高风险的活 千万不要自己扛。

你干好十件事不一定传到大领导耳朵里，但是你出了一次线上大事故，他肯定第一时间知道。

好事不出门，坏事传千里。

我们一定要对 高危的人工运维，勇敢说不！

早晨收到了HR助手的提醒，今天是白牙入职腾讯的两周年，两年前选择offer的纠结与入职腾讯时的兴奋还历历在目北漂7年程序猿回看工作选择，但也许因为历经新冠的原因，这两年的时间黏稠而缓慢，仿佛流体，乏味得可怕

今天带小白牙去国际鲜花港玩了一天，小白牙很开心，收拾完，想记录些什么，给时间留下一点记忆，就写一些在腾讯两年收获与感受吧

• 
  

  收获了自信，「出身不好」的白牙也能凭努力跻身头部大厂，原来自己并不是很差，但同样也很清醒，公司确实起了背书的作用，但不能错把平台的能力当自身的能力，时刻保持清醒

  
  


• 
  

  经历了一个系统从0到1的建设，见证了系统的不断迭代，虽说是内部系统，但还是有一些用户量的。这种机会挺难得，很多时候都是在现有系统上做一些修修补补

  
  


• 
  

  扩展了自己的见识，身边的同事背景都很优秀，我们组13人，2个清华的，2个北邮的，1个中科院的，1个是复旦还是浙大的记不清了，还有一个兰大，其他的没问，但应该都不错。平时工作交集中，可以从他们身上学到很多

  
  


• 
  

  更加明白了「主动原则」的重要性，越主动的人收获越多，包括但不限于技术、业务理解、被认可以及自我认可等。以前比较被动，不太想主动去做一些边界模糊或没人要求但做了收益很大的事儿，但总觉得缺少点什么，所以在工作中主动找一些需求外的事做，比如一些提效的事情。在日常的繁忙工作中，我们需要偶尔抬头，想想哪些问题困扰着我们，也许这就是一个工具的出发点

  
  


• 
  

  一次性晋升成功，赶上了公司晋升制度调整，由之前的一年两次到一年一次，且考核重点由之前的「武功」到现在的「战功」，也就是「提效创收」，是否解决了业务的痛点。这可能和大家理解的晋升有点不一样，晋升不应该看技术多牛逼吗？之前确实是这样，但当想不明白时，换个角度，站在老板的角度就懂了

  
  

  
  

  关于晋升，还是有一些感触的，后面再单独分享一下，关注白牙，后续更新不迷路

  
  

  
  


• 
  

  在做业务开发外，接触了一些简单的大数据开发，比如用 Scala 写 SparkSql，扩展了技术边界

  
  


• 
  

  及时找领导反馈与沟通，这算向上管理吧，让领导知道事情的进展以及是否有问题需要他帮忙，别一个憋着。如果和领导有误解或矛盾，一定要及时私下找他沟通，不要一个人"意淫"

  
  


• 
  

  逐渐理解领导了，当他的言行或企微上的话让你产生不爽的情绪时，尝试站在他的角度想想，可能就理解了，领导压力很大的，压力都是一层一层往下传递的。比如领导突然把你拉到了一个群，艾特你跟进，别慌，可能他比你进群早不了几分钟，他也很懵。这个时候应该庆幸，领导还能想到你

  
  


• 
  

  绩效是比较出来的，可能你也挺优秀的，但在团队不是最优秀的那个，所以5星不是你，也就没必要怀疑自己了

  
  

除了一些正面的，也有一些"负面"的

• 大厂的基建不一定都好用，加入之前，白牙以为大厂的基建肯定很牛逼，用着非常丝滑，确实有这样的系统，但也有用着很烂的系统。整体好，不一定都好。谈恋爱一样适用


• 部门壁垒很高，白牙所在大团队是腾讯广告，下面拆分很多部门、中心、组，很多事都需要部门合作，广告部门又分在深圳、北京、上海，即使在同一个城市，座位也是分散的，大家大多数的沟通都是线上，有时沟通推动一件事儿真的很难，已读不回、艾特不回，这些都是有的，但其他公司应该也有吧？！记住，已读不回，必有苦衷，如果真的是急事，打电话吧或者工位近直接当面聊吧（在我们这不太现实，不同城市的沟通太多了）

今天小白牙玩了一天，白天没睡觉，这不趁着小白牙睡觉的时间赶紧写的，比较仓促，也比较混乱，想起来就写啥了，如果白牙写的都忘记了也没啥，但白牙希望记住两个字「主动」越主动收获越多，明白这两个字并在工作中践行时，真的挺有魔力的，不信，你试试？

今年已经是我从事软件开发行业的第七个年头，我觉得现在是一个好的时机向一些新入行的软件工程师分享一些我认为越早知道越好的知识。希望能对您有所启发。

1. 需求总是会变

也许您已经和团队成员评估了需求的合理性，并且达成了共识。您胸有成竹的认为产品需求不会再发生改变。但真相是残酷的，需求总是会因为各种各样的原因发生变化，例如：

• 您或您的上司有了一个新的想法；


• 产品的目标群体发生了变化；


• 攻克某项技术的成本超出了预期；

您需要意识到，正是因为这残酷的真相，我们才会有一个对于软件工程师重要的专业性评判标准：您是否能够编写有更好组织性的代码。

这就引出了我们下一个主题。

2. 始终以编写更好组织性代码为目标

新手工程师有时候会执着于快速的实现功能，从而编写出「面条式」的代码，面条式代码是指代码一段段连接在一起，然后当代码规模到达一定程度后，会突然发现无法移动任何代码。任何对代码的改动，都将是一场噩梦。

因此新手工程师要比有经验的工程师更加厌恶需求变动，因为他们需要花更多时间理解和修改代码，有时甚至是需要重写整个模块。

所以，为了节省宝贵的时间，所有的工程师都应该站在更高的层次上，在编写代码前思考代码组织问题，我知道一些优秀的框架已经在语法层面上解决这个问题，但您应该在此基础上做的更好。

更好的代码组织意味着：

• 更稳定的应用；


• 更少的 Bug；


• 更清晰的代码结构；


• 代码能够更加灵活的变通与扩展；

您可以学习一些 MVC 思想，并将其应用在您的软件开发中。要知道「谋定而后动」在软件开发领域也是适用的。

3. 代码有保质期

相信我，您的代码总会过时，随着您技术水平的增长，功能的不断迭代，总有一天，您会发现有更好的方式可以组织您现有的代码。对于需要长期迭代的产品，放任代码过期，就是我们常说的「技术债务」。

优秀的工程师不会给未来的自己或接手的下一任工作者留下太多债务，这事关开发者的责任心和声誉，需要引起重视。

而且清除技术债务并非只是对产品有好处，在此过程中，您的技术水平也会不断提高。当您意识到代码临近过期，需要改动时，说明您的技术水平相较于以前已经大大提高了。

处理过期代码有两种方式：

1. 重构：即保障功能接口输入/输出稳定，但内部结构优化的更加易读，易维护；


2. 完全删了，重头写：您很少有机会这么做，不过当一段代码已经没有人能够理解，维护成本过于高昂时，这么做是必要的；

大多数工程师不重视代码重构工作，他们不了解或不愿意为代码添加单元测试并定期重构代码，这使得他们错失了宝贵的进步机会。作为新手工程师，您应该尽早意识到代码重构的重要性，并尽力劝说您的上级和合作伙伴，在开发计划中预留代码重构的时间。

4. 不要重复造轮子

新手工程师由于在工作初期认领不到有挑战性的工作，于是倾向于在实现功能模块时，即使有第三方库或框架可以使用，也会选择自己去实现。

这一行为的出发点值得肯定，作为工程师，我们都想证明自己的实力，但是优秀工程师的核心能力之一是在于充分调动现有的成熟资源。

很多时候，自己 DIY 的功能模块在健壮性和可靠性上都无法媲美社区成熟的功能模块，贸然使用自己 DIY 的功能模块会为产品添加风险，成熟的开发者应该极力避免。

我建议新手工程师不妨换一种思路，我们都是站在巨人的肩膀上才能看的更远，与其在工作中花大把时间重复造轮子，不如利用业余时间研究成熟轮子的优势，并在工作中发现新的挑战。

5. 文档是非常重要的

这包含了两层意思：

1. 查阅文档非常重要；


2. 撰写文档非常重要；

新手工程师有时会出于种种原因不愿意查阅官方文档，但事实是，查阅官方文档是工程师经常要做的事情。优秀工程师的核心职责是构思如何组织代码实现目标功能，并将其付诸实践，而查阅文档的过程，使我们准确挑选合适「建材」的必备途径。通过经常查阅文档，某个 API 最终会成为您的长期记忆，您的工作效率也会大大提升。

与查阅文档同样重要的是撰写文档，很可惜大多数工程师要么是重视不足，要么是无法撰写易读的文档。而这两者对于一份好文档而言是十分重要的。

文档的阅读者将会是所有对您当下工作感兴趣的人，包括未来的自己。对于一个没有文档或文档没有及时更新的大型项目而言，下场只有死亡。

请积极撰写产品或技术文档吧！

6. 如何面对陌生代码库

无论是刚入职一家公司，还是换了一个项目组，我们总是无法避免接手一个陌生的代码库，新手程序员往往在此时手足无措，不知道如何开始。

对此我的建议是：

1. 运行该应用，尝试修改一些代码，看看程序是如何运作的；


2. 分析目录结构，理解代码的组织方式；


3. 查看项目引入的第三方库，了解它们的作用是什么；


4. 对于要修改的核心逻辑，试着画一个流程图，搞清楚整个程序的逻辑是什么；

请务必确保您已经基本掌握了代码逻辑，再着手进行改动，否则无疑将增加代码的坏味道，您很有可能会在将来某个意料之外的时刻不得不偿还债务。

当您打算进入一个代码库，着手添加代码时，请务必确保您与原代码库的编码风格保持一致，即使您认为您的代码风格更加合理和优雅。

这么做的好处在于：

1. 您的代码风格可能并非是最佳的，您在未来可能会对代码风格有新的想法；


2. 当每个项目的参与者都把自己个性化的代码风格带入代码中时，代码就会变得越发难以阅读，也容易让下一个接手的开发者感到迷惑；

具备一定规模的开发团队，都会考虑统一代码风格，请您务必确保与团队要求的代码风格保持一致。如果您的团队没有统一的代码风格，那么就由您来主导建设吧，这正是您表现的好机会！

除此之外，新手开发者应该坚定「我一定能做到」的信念，我可以坦率的告诉您，在 Web 开发世界里，没有什么神秘的魔法，所有的问题最终都可以被解决，无论是软件开发的新手还是老手，区别只在于解决问题的思路和时间。

这正是软件开发行业的魅力所在，通过自己的努力解决一个棘手的问题，不仅会为所服务的企业解决问题，还能提升自己的专业水平，让心灵得到满足。所以请享受您当下的工作，并勇于解决任何问题。

7. 始终学习，永不止步

软件开发行业的特点之一便是，您需要通过不断学习提升自己在市场的竞争力，而编程世界也总是会有学不完的思想，技术和产品。

您需要清楚地认识到一个残酷的事实，在大多数工作环境中，您获得进步的动力只能来源于自己。很多团队都没有完善的培训机制，也不会为您制定职业发展规划，团队成员疲于奔命完成自己的业绩或是不感兴趣与您讨论前沿的技术话题，所以您更需要保持警惕，寻求不断进步。

请确保您的技术水平总是高于，至少是配的上您的工作年限。否则工作的时间越久，您的市场竞争力会越低。请勇敢的踏出当前的舒适圈。

8. 总结

在本篇文章中，我向您分享了我认为值得刚步入软件开发行业的新手们需要注意的 7 件事。这些事一些是我希望我在刚入行时有人告诉我的，一些是我从事本行业以来的一些经验之谈，感谢您的阅读，也期待您在评论区补充您的经验，让更多人受益。

我是09年参加的安徽高考，14年光阴白驹过隙似在昨天，从安徽农村一路求学经历了多个城市，也有幸去国外见到了世界的繁华，最后定居杭州，总之是通过“知识改变命运”。最近恰好又是一年一度的高考，随着年龄和阅历的增长，对高考又多了一些理解，遂行文以记之，希望也能给大家在读书方面带来一些启发

一次公平的机会

这里我们需要认清一个事实，世界本身就不是公平的，虽说“条条大路通罗马”，但是有人就出生在罗马。也没有什么可抱怨的，客观的认清现实，努力就好。

高考也就2天，在人生长河里面真的是小事一桩，但是它的影响却又是那么的深远。

高考，搁在古代也叫科举，“学而优则仕”,其实本质上是上层人为设计出来的让基层通往中层的一种相对公平的通道。 上层的份额占比比较有限，中间隔着中层，上层对基层是比较友好的，“水能载舟亦能覆舟”，上层是知道基层的实际能量的可怕，因此上层需要给到基层切实能跃迁到中层的通道，并且每年切实有一定比例的基层能够跻身中层的行列；让基层感受到有个机会是公平的，是让人能够看到希望的，比如通过教育改变下一代的命运，将来去大城市做个白领；自己能过上电视里的幸福生活等。这种希望简而言之就是 让基层感受到“公平”，能够让所有人站在同一个起跑线，然后通过这个机会给到我们一个相对高一点的起点，然后去竞争下一个希望，这样整个社会才能减少戾气，保持和谐。 在改革开放的同时搭配了一个关键动作恢复高考。“自愿报考，严格考试，择优录取”让最广大的基层群众有机会流动起来，给了大众希望与公平以及机会，最早那批大学生在短时间内相当一部分一路冲到了上层，这属于时代的红利，后来又是教育和高考的内容逐渐规范化，国家开始打造出一个相对公平的学习考核体系。 国家要你学习那些知识是为什么呢？第一、通过学习这些知识的过程，培养你独自思考和解决问题的思维能力。第二、筛选，把孩子们分层筛选出来。除了选拔人才，还能减少社会矛盾，比如孩子们走入社会后，会发现很多岗位明明是个人就能干，但凭什么你去干？人家是博士生，你是高中生，你有啥话可说的？这样最公平，社会矛盾更小。 对待高考，国家应试教育阶段最本质的核心是公平，在国家能够提供的有限高的教育资源下，通过分数，将369等所有家庭当中不差的孩子筛选出来，给予一个更高的平台。国家是需要给基层一个途径，能够最大程度上的接近中层门槛儿。如果说人生分十层，考上985、211，意味着从一层坐电梯到四层，考上普通的一本，意味着做到了三层，这是国家给予的。别的你啥都不用考虑，生而平等的一次努力得来的。总有鼓吹上学无用论的，看明白这层逻辑推导，就明白高考的红利有多大。一个孩子去985，哪怕玩了的四年，将来的朋友圈儿和这四年的见识，都不是一个特别在家自主创业的孩子能比的。总会有那些天赋异禀的孩子不上学也能冒出来，这在今天这个幸存者偏差越来越强烈的社交媒体时代，确实容易被炒作出来。但你知道而且这种人要是上了大学大概率会混的比现在更好。

有限博弈和无限博弈

在高考前的教育属于有限博弈，局限在国家设定好的一个公平的筛选机制里，本质上是为了维护社会的长久运转，防止社会固化分层，全都是拿分数说话，这套规则是专门儿设定出来的，给予基层一次机会，尽可能缩短进入中层的门槛儿。因为种种原因没有考上大学的孩子或者孩子家长，如果你看到今天这个，我建议不要放弃，再辛苦一点，因为这种阶层跃迁的轻松机会未来不会再有了。但是当我们跨过高考这个门槛儿后，就要端正一个态度，所有的规则全变了，因为国家给你这个机会，是帮你达到门槛儿的，后面你要靠自己了。就像游戏一样，前面的大部分积分都被清零了，所有的孩子都需要端正好自己的态度去迎接后面的人生。 进入大学乃至工作之后，开始到了无限博弈阶段，这个阶段主要考察你的三种能力，不再是解题了

1. 终身持续学习的兴趣和能力

没有一个牛人是不擅长学习的，没有一个牛人是停止终身学习的。大多数的失败和停滞不前，本质上都是放弃了终身学习和提高。很多草根出身，后面做成大事都是离不开这个阶段的持续学习。

2. 妥善处理各种各样的人际关系的能力

你将来会面对大量的竞争者、协作者、执法者、帮助者，需要慢慢整理明白他们的社会身份，然后妥善应对，从而趋利避害的让自己利益最大化，借助大家的力量合作共赢

3. 能抗压，面对失败能勇敢站起来的能力

人生不如意之事十之有八九，利用自身的努力，调集多方的资源去将这个成功的概率提高，然后尽人力，听天命。

比较麻烦的是有限博弈和无限博弈 这两个阶段在教育上其实是背到相驰的。这需要孩子们慢慢转变心态。高考因为有它的具体指正意义，这条赛道对设计的是有限博弈的算法，每道题都有解，有限博弈是在有限的赛道上给你考出无懈可击的分数，有限博弈会让你对每一次的得与失相当看重，对分数产生执念，一考定终身的可怕结果会让孩子们在年少时就会产生输不起的感觉。考不上就觉得人生完蛋了，其实还有下半场。然后在切换到无限博弈赛道里包括考上和考不上的，从此再没有规定的解题动作和规定答案了，这就会导致有很多在应试教育中如鱼得水的孩子不适应。不清楚社会运行的本质，其实把一个事业做成功的复杂度可比解题难度大多了，这玩意儿没有标准答案，没有指定路径，更可怕的是，除此之外，别人家家族可以拉伸手甚至火箭助推的，人家无论是工作支持还是小目标的支持，本质上都是可以祖孙三代齐上阵的，八仙过海各显神通的，这也没啥抱怨的，毕竟人家有着好几代人的积累，哪能被你这一代轻易超越，抱怨是最没用的，得努力改变现状，心态要稳住。

考后人生

高考后的人生通常有两种模式。

1. 一种是跟着已经成熟的、规则明确的赛道往前走.

这个环节即便是同时起跑，那也开始八仙过海，各显神通。有的孩子一年顶别人十年，有的孩子起点就是别人一辈子终点，这都很正常，因为赛道已经成熟了，规则已经定好了，在规定赛道上按部就班好好走，通常也会收获一个还算不错的人生。不过这种规则已经设定了相当明确的赛道更多是为优势者设定的，是为了秩序和稳定，越是这种赛道，越意味着稳定，越意味着没啥运气可言。更重要的是，这种规则和赛道明确的行业，通常不会对人造成太大的负担，更多的是把人变成平台或者组织的零件儿，时间越长，你越离不开他，到时候就会越被这个平台的控制。

2. 另一种模式是在那些规则不成熟、不明确的赛道上切换.

只有规则和秩序还没有明确形成的时候，或者说机会还都没有被看懂的时候，布局还没形成的时候，才是后来者的机会所在。这条规则适用于创业等等大多领域。比如前十年的刚刚兴起的互联网领域，产生了大量高收入群体，本质上还是因为写代码这事儿，别的家族和既得利群体帮不上忙，所谓的人与人的距离迅速拉开，其实也就是因为变了赛道，要么他机缘巧合的得到了上层相助，跑到了上层赛道上，要么就是找到了时代的风口，提前搭了进去，然后成为了第一波儿吃肉的人，更多的都是能力、眼光、运气三位一体的时势造英雄。 这也是我们基层群众为什么要去北京、上海、深圳这样的城市去呢？只有最大的城市，最多的人口，才会产生出最多的碰撞，从而创造出最多的不对等，然后才有一些新的规则不成熟、不明确的赛道出现。越是小的城镇，越是固化，越是熟人，里面全都是按部就班的人，你如果是个既得利益的群体还好，不是的话，那就真的一眼望到头了。越大的城市，就算他活的有千般辛苦，即便会变成干电池，但最起码不确定性和碰运气的成分更大，能给你提供最大的新赛道，可能见个世面也比小城镇要大的多。

写在最后

我们考虑正常教育和军备竞赛的最关键点就是两者如何达到平衡的同时，让孩子们赢在无限活力的起跑线上，这是最关键的。如果辅导班儿在家庭条件允许的情况下，能够帮助孩子们培养兴趣。还有个抗挫折的能力，增加社交密度，上那种辅导班是一个挺好的选择。如果孩子对于那些班有其他的抵触。或者家长让孩子上辅导班就是教育焦虑，害怕孩子掉队，就没有一丁点儿意义，更不要说如果那堆辅导班儿影响了家庭的生活质量，那就更是本末倒置。每周带孩子看整个电影，就在外面儿吃顿高质量的饭，在这个过程中呢，孩子感觉到你有多爱他，远远比让他上他不感兴趣的辅导班儿要重要的多。实际上，父母对于子女的教育应该是源源不断的，我们要把我们人生的理解和经验薪火相传，对孩子最好的教育是你成功的榜样，你通过一辈子的言传身教，让他知道成功与幸福的意义。我们让孩子重新学习，我们让孩子对事物充满兴趣和探索。我们自己做的又怎么样呢？我们现在还对啥有兴趣？我们每年都在提高吗？我们希望孩子在人际关系上成为大家能受欢迎的人，但我们自己呢？是哪儿都喜欢我们呢？是不是每天看好多人都不顺眼呢？我们希望孩子不担心失败，勇敢面对挫折，我们自己做又怎么样呢？我们在面对困难的时候就那么一点儿不怂吗？当我们自己找到了生活的兴趣，我们的生活就会璀璨发光，孩子就会知道追逐兴趣终身学习有多么美好，你也能够指导孩子将来如何更好的保持兴趣终身学习，当我们有了温暖的气场和得体的谈吐，有了尊重他人的同理心，孩子自然而然就耳濡目染了。总之，道理都想明白后，人生就不会活的那么拧巴了。

前言

最近，政府为了刺激消费，发放了大量的消费券，大家应该参与了抢券大军吧。但是如果你是一个前端程序员，你有没有想过，这个消费券样式我能实现吗？今天给大家分享一下，常用的票券的样式实现。

抽象一下

对我们常用的票券进行抽象后，大概就是下面几种样式了，我们来看看怎么实现吧

实现方案

对于内凹圆角或者镂空的这类样式，我们一般实现方案是使用mask(遮罩)；mask语法很简单，我们就当成background来用就好了，可以是PNG图片、SVG图片、也可以是渐变绘制的图片，同时也支持多图片叠加。然后我们了解一下他的遮罩原理：最终效果只显示不透明的部分，透明部分将不可见，半透明类推。

<1>实现一个内凹圆角

class="content">
 

.content {     

   width: 300px;     

   height: 150px;     

   margin: auto;     

   -webkit-mask: radial-gradient(circle at left center, transparent 20px, red 0);     

   background: red; } 

   ellipse

当前（2016.10.19）mask 处于 候选标准阶段（CR），还不是正式标准（REC），webkit/blink 内核加前缀 -webkit- 可使用。

<2>实现两个内凹圆角之遮罩合成

  .content{           

    width:300px;           

    height:150px;           

    background:red ;           

   -webkit-mask:radial-gradient(circle at left center,transparent 20px,red 20px)  ,     radial-gradient(circle at right center,transparent 20px,red 20px) ;           

    }

上面的写法是没有效果的，此时使用为两个重合后，整个区域都是不透明的，导致没有效果，这个时候我们需要使用遮罩合成；我们通过ps了解一下遮罩合成

遮罩合成mask-composite

-webkit-mask-composite: destination-in; /只显示重合的地方/

<3>实现两个内凹圆角之平铺

 .content{           

         width:300px;           

         height:150px;           

         background:red ;           

          -webkit-mask:radial-gradient(circle at 20px center,transparent 20px,red 20px);           

         -webkit-mask-position: -20px;       

}

<4>实现四个内凹圆角

 .content{           

       width:300px;           

       height:150px;           

       background:red ;           

       -webkit-mask:radial-gradient(circle at 20px 20px,transparent 20px,red 20px);           

      -webkit-mask-position: -20px -20px;       

}

<5>实现六个内凹圆角

 .content{           

     width:300px;           

     height:150px;           

     background:red ;           

     -webkit-mask:radial-gradient(circle at 20px 20px,transparent 20px,red 20px);           

     -webkit-mask-position: -20px -20px;           

     -webkit-mask-size:50% 100%;       

}

<6>实现中间一排的镂空

.content{           

       width:300px;           

       height:150px;           

       background:red;           

        -webkit-mask:           

            radial-gradient(circle at 20px 20px,transparent 20px,red 20px) -20px -20px/50% 100% ,           

            radial-gradient(circle at center 5px,transparent 5px,red 5px) 0px -5px/100% 30px;           

      -webkit-mask-composite: destination-in;        }

<7>实现两边多个内凹圆角

其实很简单:只需把遮罩的高度，变小，让他们平铺就可以了

 .content{           

       width:300px;           

      height:150px;           

       background:red ;           

      -webkit-mask:radial-gradient(circle at 10px 10px,transparent 10px,red 10px);           

     -webkit-mask-position: -10px 5px;           

     -webkit-mask-size:100% 30px;       

}

引言

事情起源还得从一个需求讲起, 需求内容如下:

1. 假设有串字符串如下:

const str = `Pharmaceuticals progress events.



JSON output:

{

  "name": "moyuanjun",

  "age": 28

}`

2. 现需要从字符串中, 提取到 JSON output: 后面的所有字符串, 后面还需要将其解析为对象(当然这不是本文的重点)

需求本身很简单, 实现起来也容易, 具体方案如下, 那么请问以下实现方法有啥问题呢?

const jsonStr = str.replace(/^(\s|\S|.)*?JSON output:/, '')

由于字符串是 gpt 返回的, 它是不可控的, 这里当字符串为 No, this text is not a transaction event. Therefore, the requested entities cannot be extracted. 时, 通过上文的正则进行匹配时就会导致页面卡住, 这里如果大家好奇的话, 可以尝试将下面代码复制到 浏览器控制台 并执行

'No, this text is not a transaction event. Therefore, the requested entities cannot be extracted.'.replace(/^(\s|\S|.)*?JSON output:/, '')

上面主要问题还是出在正则上, 执行上面正则匹配, 会陷入 回溯 陷阱, 我们可以看下上面正则在 regex101 的测试结果, 从测试结果来看正则的匹配次数是有点夸张的

下面我们来针对 回溯 问题进行展开....

一、正则引擎

传统正则引擎分为 NFA (非确定性有限状态自动机) 和 DFA(确定性有限状态自动机), 那么, 什么是确定型、非确定型、有限状态以及自动机呢?

确定型与非确定型: 假设有一个字符串 abc 需要匹配, 在没有编写正则表达式的前提下, 就能够确定 字符匹配顺序 的就是确定型, 不能确定字符匹配顺序的则为非确定型

有限状态: 所谓有限, 指的是在有限次数内能够得到结果

自动机: 自动机即自动完成, 在我们设置好匹配规则后由引擎自动完成, 不需要人为干预即为自动

根据上面的解释我们可得知 NFA 引擎和 DFA 引擎的主要区别就在于: 在没有编写正则表达式的前提下, 是否能确定字符执行顺序;, 下面我们来简单介绍下这两种引擎:

1.1 NFA 引擎

NFA(Nondeterministic finite automaton)又名 非确定性有限状态自动机, 主要特点如下:

1. 
   

   表达式驱动: 由要执行的正则表达式进行驱动的算法, 正则引擎从正则表达式起始位置开始, 尝试与文本进行匹配, 如果匹配成功, 都前进一步, 否则文本一直前进到下一个字符, 直到匹配成功

   
   


2. 
   

   会记录位置: 当正则表达式需要进行选择时, 它会 选择 一个 路径 进行匹配, 同时会 记录 当前的 位置, 如果选择的路径匹配不成功则需要回退回去, 重新选择一个路径进行尝试, 直到匹配完成, 如果所有可能情况全部匹配不成功, 则本次匹配失败

   
   


3. 
   

   单个字符可能会检查多次: 从👆🏻可以看出, 字符串中一个字符可能会被多次匹配到, 因为当一条正则路径不通时, 会进行回退

   
   


4. 
   

   支持零宽断言: 因为具有回退功能, 所以可以很容易实现零宽、断言、捕获、反向引用等功能

   
   

最后借用 猪哥 制作的一个小动画, 方便大家理解:

1.2 DFA

DFA(Deterministic finite automaton) 又名 确定性有限自动机, 主要特点如下:

1. 
   

   文本驱动: 由要搜索的文本驱动的算法, 文本中的每个字符 DFA 引擎只会查看一次, 简单理解就是对字符串进行一次循环, 每次循环都和正则进行一次匹配, 匹配成功字符串和正则指针都相应的向下移动

   
   


2. 
   

   DFA 引擎会记得所有的匹配可能, 并且每次匹配都会返回其中 最长的匹配, 这么做的目的是为了让后面的匹配能够更加轻松, 正因为如此字符串 nfa not 在 (nfa|nfa not) 中匹配结果为: nfa not

   
   


3. 
   

   优点: 优点很明显, 由于只会会循环一直字符串、并且会提前记住所有可能情况, 所以相对来说匹配效率是很高的

   
   


4. 
   

   缺点:

   
   

• 它始终将返回最长匹配结果, 无法控制表达式来改变这个规则


• 因为需要记住所以可能情况, 所以正则表达式预编译时间会更长, 占用更多内存


• 没有回退, 所有重复的运算符 都是贪婪 的, 会尽可能匹配更多的内容


• 因为不存在回退, 所以自然不支持零宽断言、捕获、反向引用等功能

最后借用 猪哥 制作的一个小动画, 方便大家理解:

补充说明: 上面只是对传统的两个正则引擎进行简单介绍, 在 JS 中正则引擎使用的则是 NFA 下面我们也只是对 JS 中的正则、以及 回溯 进行简单介绍, 同时在 regex101 中我们选用的语言则是 PHP, 主要是因为在 PHP 用的也是 NFA 引擎并且在 regex101 下会多一个 Regex Debugger 功能(不知道为什么 JS 没有 😭)

二、回溯

我们知道, NFA 引擎是用表达式去匹配文本, 而表达式又有若干 分支 和 范围, 一个分支或者范围匹配失败并不意味着最终匹配失败, 正则引擎会进行回退去尝试 下一个 分支或者范围, 这种行为就被称之为 回溯

类比于迷宫, 想象一下, 面前有两条路, 我们选择了一条, 走到尽头发现是条死路, 只好原路返回尝试另一条路, 则这个原路返回的过程就被称之为 回溯, 它在正则中的含义是 吐出已经匹配过的文本, 同时 正则匹配位置也会进行回退

一般的, NFA,如果匹配失败, 会尝试进行 回溯, 因为它并不知道后面还有没有可能匹配成功, 他是蒙在鼓里的, 但是 DFA 从一开始就知道所有的可能匹配, 因为在预编译时就它就已经存储了所以可能情况, 所以正则编写的好坏对 NFA 来说是特别的重要的

引擎会真正按照正则表达式进行匹配, 让你选择达到完全匹配所需的每个步骤, 所以我们必须很谨慎地告诉它, 首先检查哪种选择才能达到您的期望, 你也有机会调整正则表达式, 以最大程度地减少回溯并尽早进行匹配

三、量词

3.1 在 JS 中量词表示要匹配的字符或表达式的数量, 常见的量词有:

3.2 贪婪 与 非贪婪

3.3 贪婪模式下的回溯

现在我们看一个简单例子, 有如下正则 .*c 以及待匹配字符串 bbbcaaaaaaaaa, 下面我们使用 regex101 来进行测试

这里选择 Debugger 查看整个正则匹配流程(重点看 回溯)

从图中可以看出, .* 会优先匹配到所有内容, 然后在匹配字符串 c 时, 只要匹配失败, 字符串匹配位置就会进行回退(吐出一个字符), 然后再次进行匹配, 如此反复直到匹配到字符串 c

3.4 解决办法

针对上文回溯问题, 下面我们来简单优化下正则, 来避免 回溯

1. 使用非贪婪模式: .*?c

2. 使用反向字符集: [^c]*c

3.5 绝对不用「量词嵌套」

特别特别需要注意的是, 嵌套的量词 将会制造指数级的回溯, 下面我们就以 .*c 以及 (.+)*c 为例, 从 regex101 测试结果来看, 相同匹配字符串 .*c 需要 13 个步骤, (.+)*c 则直接飚到 61144 了, 但最终这两个表达式匹配到的结果却是一样的

四、多选分支

已知在 JS 中正则可使用 | 定义多个分支, 例如: x|y 可匹配 x 或者 y,

那么正则在匹配过程中如果遇到多选分支时, 引擎则会按照 从左到右 的顺序检查表达式中的多选分支, 如果某个分支匹配失败, 表达式和字符串都会进行回退(回溯), 然后选择另一个分支进行尝试... 这个过程会不断重复, 直到完成全局匹配，或所有的分支都尝试穷尽为止

4.1 回溯现象

假设有正则表达式 num(1234567890|1234567891) 待匹配字符串如下 num1234567891, 下面我们使用 regex101 来进行测试

这里选择 Debugger 查看整个正则匹配流程(重点看 回溯)

4.2 优化手段

1. 提取多选分支中的必须元素: num123456789(0|1)

2. 高优先级分支提前: num123456789(1|0)

由于正则引擎遇到分支是按照 从左到右 的顺序, 来选择分支进行匹配的, 所以我们可以通过调整分支的顺序来提高匹配效率

3. 使用字符组: num123456789[01]

这里我们还可以使用字符组 [], 和 | 不同的是它不存在分支选择问题, 本质上分支越多, 可能的回溯次数越多, 所以如果可以我们需要尽可能减少分支

五、其他正则优化手段

• 使用非捕获型括号 (): 如果不需要引用括号内的文本, 请使用非捕获括号, 不但能节省捕获的时间, 而且会减少回溯使用的状态的数量, 从两方面提高速度


• 不要滥用字符组 []: 不使用只包含一个字符的字符组, 需要付出处理字符组的代价


• 分析待匹配字符串, 将最可能匹配的分支放在前面


• 正则进行适当拆分: /最明确的规则/.test() && /更细的规则/.test(str)


• 必要时可以考虑更换正则引擎, 比如使用 DFA


• 使用检测工具进行测试, 比如: regex101


• 使用有明显确定的特征的具体字符、字符组代替通配符, 说白了尽可能描述清楚你的正则

六、回到正文

回到我们最开始的那个正则, 可以优化如下

'No, this text is not a transaction event. Therefore, the requested entities cannot be extracted.'.replace(/^[\s\S]*?JSON output:/, '')

在 regex101 的测试结果如下, 从测试结果来看前后性能提升可不是一点两点

七、参考:

• 正则表达式是如何让你的网页卡住的


• 一个正则导致浏览器页面卡死


• 正则表达式优化 - 避免灾难性回溯


• 正则引擎的几种分类


• 正则表达式引擎执行原理——从未如此清晰!


• 深入正则表达式(3):正则表达式工作引擎流程分析与原理释义...

背景

使用低代码接入了一个移动端老系统，新增页面（以及部分旧页面）使用低代码体系搭建。功能开发完成后才发现性能问题比较严重，所以进行了一次移动端的性能优化。本文就优化过程进行一个记录。

问题分析

为什么一接入低代码体系性能（主要是加载性能）就出现明显的下降，如果首屏访问的是低代码页面则更加明显

• 最主要的原因是比之前额外加载了大量的 js 和 css，初步统计有 10 个 css 和 15 个 js


• 老系统自身 js 资源过大，依赖包 vendor.js 有 8M 多


• 低代码体系下，非静态资源的接口请求也成为影响页面渲染的因素。页面必须等待接口获取到 schema 后才由低代码渲染器进行渲染

低代码体系接入

有必要简单说明下低代码体系是如何接入的，这对后面的优化是有直接影响的

• 低代码体系资源大概分为三方依赖、渲染引擎和组件库资源，都是独立的 npm 库，发布单独的 CDN


• 三方依赖就是像 react、moment、lodash 等最基础的依赖资源


• 渲染引擎要想渲染页面，又直接依赖于两个资源
  
  
  
  • 页面 schema：服务端接口返回，schema 本质上是一个 json，描述了一个组件树
  
  
  • 组件集合：由 CDN 引入的各个组件库集合，它需要先于页面 schema 加载
  
  
  
  

静态资源为何影响加载性能

静态资源加载如何影响性能，简单分析下，详细的原理可以参考 MDN

• HTML 自上而下解析，遇到 script 标签（不带 defer 和 async 属性）就会暂停解析，等待 script 加载和执行完毕后才会继续


• HTML 解析时如果遇到 css 资源，解析会继续进行。但是在 css 资源加载完成前，页面是不会渲染的，并且如果此时有 JavaScript 正在执行，也会被阻塞


• 所以 js 或 css 体积越大，则在网络传输、下载、浏览器解析和执行上所花的时间就会相应的增加，而这些时间都是会阻塞页面渲染的


• js 或者 css 的个数对于渲染的影响，很大程度上取决于项目和浏览器是否支持 http2
  
  
  
  • 如果使用了 http2，则静态资源个数对于加载性能影响不大，除非多到几百个资源
  
  
  • 如果还是 http1.1，静态资源个数对于加载有明显影响，因为此时浏览器存在并发限制，大概在 4-6 个左右，即一批次只能发送几个请求，等到请求完成后，再发下一批，是个同步的过程
  
  
  • 本项目已经支持 http2，所以优化加载性能的重点还是在减小总的资源体积上
  
  
  
  

优化指标

用户对于页面性能的感受是主观的，而优化工作则需要客观的数据。
更重要的是，有些优化措施是否有效果，有多少效果是需要数据说明的。举例来说，去除冗余资源几乎是可以预见性能提升。但是做 CDN 合并在移动端能够有多少优化效果，事前其实并不清楚
这里采用 2 种方式作为优化指标

• 旧版本 chrome(69)的 perfomance
  
  
  
  • 使用这个版本是因为后台数据显示该引擎访问量较多
  
  
  • chrome 的 performance 不仅能获取性能数据，也有助于我们分析，找出具体问题
  
  
  
  


• 使用 web-vitals 库获得具体的性能数据，主要关注
  
  
  
  • FCP，白屏时间
  
  
  • LCP，页面可视区域渲染完成时间
  
  
  
  

现状

• 点击 performance 的刷新按钮，就会自动进行一次页面的加载
  
  
  
  • 建议使用无痕模式，排除其他干扰
  
  
  • network 中勾选 Disable cache，虽然最终用户会用到缓存，但在优化非缓存项时，建议先禁用缓存，获取最真实的数据
  
  
  
  


• 静态资源的加载大概花了 3.5s


• 而后续静态资源的解析则一直持续到页面加载完成，大概在 9 秒多


• 使用 web-vitals 测量的平均数据
  
  
  
  • FCP: 5.5s
  
  
  • LCP: 9s
  
  
  
  

目标

• performance 页面渲染完成：4s 以内


• web-vitals 平均数据
  
  
  
  • FCP：3s 以内
  
  
  • LCP：4s 以内
  
  
  
  

如果从绝对性能看，这个目标只能是个中下水平。主要基于以下几点考虑

• 策略上不会对原系统或者低代码体系进行大刀阔斧的改动


• 老系统大概就是这么个性能情况，维持这个水平起码不会降低用户体验。作为内部系统，对性能没有极致的要求


• 考虑到时间成本，性能优化是一项持续性的工作，而实际项目是有时间限制和上线压力的

优化措施

根据以上分析，最重要的就是要减小总的关键资源体积。
低代码体系所需要的直接资源都属于关键资源。因为用户是可能首次直接进入一个低代码页面的（也是本次主要的优化场景）

优化前包分析

CDN 三方库资源直接就能看出哪些是冗余的，或者是公共资源加载了多遍等问题，但是自己的仓库打包后就需要借助 webpack-bundle-analyzer 插件分析了
该项目中有多个 npm 仓库需要分析，这里就举老系统自己的例子，优化前的 bundle 分析图

三方依赖 vendor.min.js 8MB 左右，项目 JS 800 多 KB，下面分析下最严重的几点

• 标 ① 部分， @ali_4ever 开头的是富文本依赖，有接近 2M 左右的大小，优化为懒加载


• 标 ② 部分，echarts5 全量引入了，1M 左右大小，计划优化为按需加载


• 标 ③ 部分，ali-oss，500 多 KB，ali-oss 不支持按需引入。这里因为多个低代码组件库中也用到了该依赖，所以计划提取为 CDN 作为公共依赖，但是大小还是 500 多 KB，只是去掉了重复加载部分


• 标 ④ 部分，antd-mobile 加载了两个版本的全量仓库，按照官方推荐，考虑将 antd-mobile-v2 按需加载

一、移除冗余资源

• 排查 CDN，是否引用了多余的 CDN，比如项目中移动端引用了 PC 端的组件库，引用了已经废弃（迁移）的工具库等等


• 排查项目 bundle，正常情况下是不可能有冗余资源的，因为如果一点没用到这个库，webpack 也不会将其打包进去
  
  
  
  • 可能存在使用到了一小部分，却打包了整个库的情况，这个属于下一部分按需引入
  
  
  
  


• 排查下线上 CDN 是否都使用生产版本或者压缩版本，这点事先没有想到，是在优化过程中意外发现存在非压缩版本

二、按需引入

按需引入即只引入三方库中项目用到的部分。现代的大部分三方库都已经支持 TreeShaking，正常打包即是按需引入。特殊情况在于 CDN、懒加载和一些老的库，这些刚好在项目中都有所实践

按需引入 和 CDN

项目中只用到了 ahooks 中的个别方法，却将整个包作为 CDN 引入，显然是不合理的

• 需要按需引入的库，是不能使用 CDN 引入的，它们之间是互斥的
  
  
  
  • 因为 CDN 需要配置 external 才能在项目里使用，external 一般是将一个三方库作为整体配置的
  
  
  
  


• CDN 自身作为一种优化手段，那是和将静态资源放置在业务服务器对比的。
  
  
  
  • 在该场景下，引入 ahooks CDN 导致 TreeShaking 失效，引入了全量包，同时增加了一次 http 请求，总的来看肯定是得不偿失的
  
  
  • 并且最终项目的 bundle 也会发布 CDN
  
  
  
  


• 因此去掉了 ahooks 的 CDN，改为直接打进项目 bundle 就行了

按需引入 和 懒加载

在该项目中，echarts 也按需引入了，echarts 的按需引入总体效果就没有 ahooks 那么好了

• echarts 无论绘制哪种类型图表，都需要引入核心库，就有 100 多 KB 的大小了


• 所以 echarts 也可以选择懒加载，懒加载会让没有使用 echarts 的页面加载速度变快，但是最终浏览器解析的资源是全量的，可以根据实际情况选择


• 懒加载 和 按需引入也无法并存。因为懒加载需要动态导入，动态导入 webpack 就没法做静态分析，这是 TreeShaking 的基础，所以就没法按需引入了

利用 babel-import-plugin

有一些老版本的库，可能还不支持按需引入，比方说 antd-mobile-v2，对于这种仓库，可以利用 babel-import-plugin 做按需引入
只需要做一下 babel 配置就行

{

  "plugins": [

    [

      "import",

      {

        "libraryName": "antd-mobile-v2",

        "style": "css"

      },

      "antd-mobile-v2"

    ]

  ]

}

• 本项目最终没有那么做，因为体积几乎没有减小。对于一个完整的项目，需要使用到的组件是非常多的


• 对于 antd-mobile 多个版本的问题，最终的优化方案还是合并为最新版，只是开发和测试的工作量大了点


• 注意点：babel-import-plugin 插件并不能让所有仓库都支持按需。本质上还是三方库做了分包才行

三、懒加载

懒加载的资源不同，也可以分为多种类型

• 三方库资源懒加载：比如之前说的，某个组件依赖于 echarts，那么就可以懒加载 echarts，只有页面中使用了该组件时才去请求和加载 echarts 依赖


• 组件懒加载：将整个组件都懒加载，在本项目中没有做组件懒加载
  
  
  
  • 低代码体系下，组件本身不能懒加载，否则 schema 解析到这个组件时找不到会报错
  
  
  • 解决方案也可以给组件套一层，实际内容懒加载，导出的组件不懒加载
  
  
  • 更重要的原因是组件库本身不大，不是影响性能的关键因素
  
  
  • 另外低代码页面本身就是由各个组件拼凑而成，如果将组件都懒加载了，那么页面各个部分都会有 Loading 的中间态，效果不好把控
  
  
  
  


• 路由懒加载：本质上它就是组件懒加载的一种，一个组件就是一个路由页面，项目中对于系统不太访问的页面做了路由懒加载

三方库资源懒加载

懒加载依赖也需要分析具体情况，比方说移动端使用了 antd-mobile 作为组件库，这个依赖就完全没必要等使用的时候再加载。因为几乎进入任意一个页面，都需要用到这个资源。什么情况下合适

• 依赖资源比较大


• 使用的频率较低，只在个别地方使用了

并且这个三方资源也是分两种情况引入，第一种是以 CDN 的形式外部引入，第二种是直接打包入库，这两种引入方式的懒加载处理是不同的，下面分别举例

CDN 引入的三方资源懒加载

比如低代码组件库中存在一个富文本组件，比较特殊，比较适合使用 CDN 的方式懒加载依赖资源

• 富文本组件依赖于公司内部的一个富文本编辑器。鉴于富文本的复杂性，所以它的依赖很大，JS+css 将近有 3M 左右。


• 但是其实只有极少的页面使用到了富文本，对于大多数用户来说，是不需要这个富文本的

下面介绍下具体实现，利用 ahooks 的 useExternal，动态注入 js 或 css 资源（也可以原生实现），封装一个高阶组件，方便调用

type LoadStatus = 'loading' | 'ready' | 'error';

interface LoadOptions {

  url: string;

  libraryName: string;

  cssUrl?: string;

  LoadingRender?: () => React.ReactNode;

  errorRender?: () => React.ReactNode;

}

export const LazyLoad = (Component, { url, libraryName, cssUrl, LoadingRender, errorRender }: LoadOptions) => {

  const LazyCom = (props) => {

    const initStatus = typeof window[libraryName] === 'undefined' ? 'loading' : 'ready';

    const [loadStatus, setStatus] = useState<LoadStatus>(initStatus);

    const jsStatus = useExternal(url, {

      keepWhenUnused: true,

    });

    const cssStatus = useExternal(cssUrl, {

      keepWhenUnused: true,

    });



    useEffect(() => {

      if (loadStatus === 'ready' || loadStatus === 'error') {

        return;

      }

      if (jsStatus === 'error' || cssStatus === 'error') {

        setStatus('error');

      }

      if (jsStatus === 'ready' && (cssStatus === 'ready' || cssStatus === 'unset')) {

        setStatus('ready');

      }

    }, [jsStatus, cssStatus, loadStatus]);



    const content = useMemo(() => {

      switch (loadStatus) {

        case 'loading':

          return typeof LoadingRender === 'function' ? LoadingRender() : <div>加载中...</div>;

        case 'ready':

          return <Component {...props} />;

        case 'error':

          return typeof errorRender === 'function' ? errorRender() : <div>加载失败</div>;

        default:

          return null;

      }

    }, [loadStatus]);



    return content;

  };

  return LazyCom;

};



// 使用示例，BaseEditor即需要懒加载的原组件，BaseEditor组件内部直接通过window取相应依赖

export const FormEditor = LazyLoad(BaseEditor, {

  url: 'xxxx',

  cssUrl: 'xxxxx',

  libraryName: 'xxxxxx',

});

打包入 bundle 依赖懒加载

总体思路是一样的，只是这类资源利用 webpack 的 import 动态导入能力，import 动态导入的资源打包时会单独分包，只在使用到时才会加载
具体实现：

export const InnerLazyLoad = (Component, loadResource, LoadingRender?) => {

  const LazyCom = (props) => {

    const [loaded, setLoaded] = useState(false);

    const [LazyResource, setResource] = useState({});



    useEffect(() => {

      if (loaded) {

        return;

      }

      loadResource().then((resource) => {

        setResource(resource);

        setLoaded(true);

      });

    }, [loaded]);

    const LoadingNode = typeof LoadingRender === 'function' ? LoadingRender() : <div>...加载中</div>;

    return loaded ? <Component {...props} LazyResource={LazyResource} /> : LoadingNode;

  };

  return LazyCom;

};



// 具体使用

const loadResource = async () => {

  // 动态导入的资源会单独分包，在使用到时才会加载

  const echarts = await import('echarts/core');

  const { PieChart } = await import('echarts/charts');

  const { TitleComponent } = await import('echarts/components');

  const { CanvasRenderer } = await import('echarts/renderers');

  return {

    echarts,

    PieChart,

    TitleComponent,

    CanvasRenderer,

  };

};



const AgentWork = InnerLazyLoad(BaseAgentWork, loadResource);

路由懒加载

路由懒加载原理和内部资源懒加载类似，分包然后首次进入该页面时才请求页面资源
本项目没有把所有页面都懒加载

• 页面懒加载后，进入页面前会有一个短暂的加载过程，需要评估影响


• 还是和通用懒加载一样，使用频率较低、页面 js 又比较大的比较适合懒加载

比如在该项目中

• 应用上存在部分页面是给第三方使用的，不能通过导航点击到达，直接分享地址给第三方


• 这些页面使用频率低，而且基本不影响本应用，因为无法通过导航点击切换到达，是通过 url 的形式直接访问，所以加载中的中间态和页面加载一起

路由懒加载的实现，不同框架都有些差异。本项目中只需在路由配置中增加配置项即可开启，就不再阐述具体代码实现

四、合并公共资源

合并公共资源，即不要重复加载相同资源
一般来说打包工具都会做依赖分析，只会打包一份相同路径的引用依赖。但是如果相同依赖分散在多个仓库中就有可能出现重复资源了
比如该项目中，老系统自身和多个组件库都使用了 ali-oss 库实现上传功能，并且还有一些条件使得将其提取为公共 CDN 是利益最大化的

• ali-oss 打包后 500 多 KB 的大小，已经算是一个不小的包了


• ali-oss 不支持按需引入，所以引用到它的多个仓库，无论引用了什么功能，都将全量打包入 ali-oss


• 如果 ali-oss 支持按需引入，就需要计算是提取为公共 CDN 划算，还是将其按需打入各个仓库中划算

实现步骤比较简单

• 在引用 ali-oss 的仓库配置 external，使仓库本身打包时不打入 ali-oss 依赖


• 在项目 HTML 中提前引入 ali-oss CDN

五、缓存

静态资源缓存

• 该项目静态资源使用 CDN+版本号，本身已经支持了缓存。CDN 的缓存时间是通过 Cache-Control 的 s-maxage 字段控制，这是 CDN 特有的字段


• 如果静态资源是放置在自己的服务器上，需要考虑 http 缓存和缓存更新的事项，这个也是老生常谈的话题，这里不再赘述

如果想要详细了解 http 缓存，推荐看下这篇文章

options 请求缓存

在实际优化过程中发现，该项目的大部分 ajax 请求，都是跨域请求，所以伴随着大量的 options 请求
推动服务端做了这些预检请求的缓存，其原理就是通过 access-control-max-age 响应头设置预检请求的缓存时间

Service Worker

Service Worker 是一项很强大的技术，它能够对网络请求进行缓存和处理，它的最大应用场景是在弱网甚至离线环境下
一旦使用了 Service Worker 技术，用户在首次安装完成后，后续的访问相当于直接在本地读取静态资源，访问速度自然能够得到提升
虽然能够提升使用体验，但是使用 Service Worker 是存在一定限制和风险的

• 必须运行在 https 协议下，调试时允许在 localhost、127.0.0.1


• Service Worker 自身不能跨越，即主线程上注册的 Service Worker 必须在当前域名下


• 一旦被安装成功就永远存在，除非线程被程序主动解除


• Service Worker 的更新是比较复杂的，如果对其了解不深，建议还是只将不常更新的资源使用 Service Worker 缓存，降低风险

项目中直接使用 workbox（对 Service Worker 做了封装，并提供一些插件），以下为示例代码

主线程上注册 Service Worker

if ('serviceWorker' in navigator) {

  navigator.serviceWorker

    .register('./sw.js')

    .then((reg) => {

      navigator.serviceWorker.addEventListener('message', (event) => {

        // 处理Worker传递的消息逻辑

      });

      console.log('注册成功：', reg);

    })

    .catch((err) => {

      console.log('注册成功：', err);

    });

}

Service Worker 线程处理缓存逻辑

//首先是异常处理

self.addEventListener('error', function (e) {

  self.clients.matchAll().then(function (clients) {

    if (clients && clients.length) {

      clients[0].postMessage({

        type: 'ERROR',

        msg: e.message || null,

        stack: e.error ? e.error.stack : null,

      });

    }

  });

});



self.addEventListener('unhandledrejection', function (e) {

  self.clients.matchAll().then(function (clients) {

    if (clients && clients.length) {

      clients[0].postMessage({

        type: 'REJECTION',

        msg: e.reason ? e.reason.message : null,

        stack: e.reason ? e.reason.stack : null,

      });

    }

  });

});



//然后引入workbox

importScripts('https://g.alicdn.com/kg/workbox/3.3.0/workbox-sw.js');



// 预缓存资源示例，不更新的资源使用预缓存

const resources = ['https://g.alicdn.com/dingding/dingtalk-jsapi/2.10.3/dingtalk.open.js'];



// 预缓存功能

workbox.precaching.precacheAndRoute(resources);



// 图片缓存 使用CacheFirst策略

workbox.routing.registerRoute(

  /\.(jpe?g|png)/,

  new workbox.strategies.CacheFirst({

    cacheName: 'image-runtime-cache',

    plugins: [

      new workbox.expiration.Plugin({

        // 对图片资源缓存 1 天

        maxAgeSeconds: 24 * 60 * 60,

        // 匹配该策略的图片最多缓存 20 张

        maxEntries: 20,

      }),

    ],

  })

);



// 需要更新的js和css资源使用staleWhileRevalidate策略

workbox.routing.registerRoute(

  new RegExp('https://g.alicdn.com/'),

  workbox.strategies.staleWhileRevalidate({

    cacheName: 'static-runtime-cache',

    plugins: [

      new workbox.expiration.Plugin({

        maxEntries: 20,

      }),

    ],

  })

);

• 预缓存功能：
  
  
  
  • 正常情况下，Service Worker 是在主程序首次请求时将资源拦截，在之后的请求中根据缓存策略处理
  
  
  • 预缓存功能是在 Service Worker 在安装阶段主动发起资源请求，并将其缓存下来
  
  
  • 当页面真正发起预缓存当中的资源请求时，资源已经被缓存了，就可以直接使用了
  
  
  • 预缓存是使用 Cache Only 策略，即在预缓存主动发起请求并获取缓存后，就只会在缓存中读取资源，不在进行缓存更新，所以适合项目中不更新的静态资源
  
  
  
  


• 图片缓存：
  
  
  
  • 图片一般情况下是不更新的，所以采用 Cache First 缓存优先策略
  
  
  • 当有缓存时会优先读取缓存，读取成功直接使用本地缓存，不再发起请求
  
  
  • 读取失败时再发起网络请求，并将结果更新到缓存中
  
  
  
  


• 对于需要更新的 JS 和 CSS
  
  
  
  • 使用 Stale While Revalidate 策略
  
  
  • 跟 Cache First 策略比较类似，都是优先返回本地缓存的资源
  
  
  • 区别在于 Stale While Revalidate 策略无论在缓存读取是否成功的时候都会发送网络请求更新本地缓存
  
  
  • 这是兼顾页面加载速度和缓存更新的策略，相对安全一些
  
  
  
  

六、其他

以下措施不具备通用性，但是在项目中用到了还是记录下来，仅供参考

• 页面 schema 接口优化：低代码体系存在页面嵌套，每个页面单独请求自己的 schema，所以在嵌套层级较多的情况下，是以同步解析的顺序请求接口，页面渲染速度较慢，优化为服务端拼装完毕后直接返回


• 部分接口的请求合并


• 去除运行时 babel，低代码设计器中存在手写的代码，这部分代码最初在运行时由 babel 转化为 ES5（设计问题），优化为保存时转换

七、项目已经存在的措施

• 静态资源放在 CDN


• 启用 http2，并且浏览器支持，这一步很重要，是否使用 http2 对优化措施有直接的影响


• js 和 css 的代码压缩，并且开启 gzip 压缩


• 使用字体图标 iconfont 代替图片图标


• CDN 合并：利用 CDN 的 combo 技术将多个 CDN 合并成一个发送（在 http2 中无明显效果）

最终优化效果

• performance 表现：页面渲染完成在 3 秒以内

• web-vitals 平均数据
  
  
  
  • FCP：2100
  
  
  • LCP：2400
  
  
  
  

参考文章

• 前端性能优化之缓存


• WEB 性能


• 11s 到 ⚡1s，性能优化之首屏加载

写在前面

最近v2ex上一个话题火了，大概内容是有一个 好奇 摸鱼的程序员，在分析了拼夕夕发出的砍一刀短链接后，惊呼不可能。

微信落地页防封

谈到拼多多的短链分享，就不得不提一个很关键的名词微信落地页防封 ，说到微信落地页防封，那就需要知道，在什么情况下，会触发微信的域名拦截机制，一般来说，触发域名拦截有以下几个原因

• 
  

  域名是新购入的老域名，在微信内之前有过违规记录，上过黑名单。

  
  


• 
  

  网站流量太大，微信内同一域名被大量分享，比如分享赚类的平台某拼。

  
  


• 
  

  诱导分享传播，即便是合法营销活动，也会触发拦截。

  
  


• 
  

  网站内容违规，这个不必多说。

  
  


• 
  

  被同行恶意举报。

  
  

为了让域名活的久一些，微信落地页防封这样的技术就应运而生，主要通过以下几点，来逃避微信的域名拦截机制

• 大站域名【美团、京东...】


• 不同主体各自备案域名【鸡蛋不放在一个篮子内】


• 多级跳转+前置防火墙【通过前置防火墙中转页识别是否是机器扫描】


• 随机Ip【cdn分发】


• 图床 + 短链


• 短链 + 自定义跳转 【稍后详细分析一下这种方式】

拼夕夕的防封技术猜测

经过测试，拼夕夕的防封应该采用的是图床+短链+自定义跳转的方式，接下来就听我一一道来

• 图床
  图床是oss对象存储的昵称，通常是用来存放图片的，如果是用在防封里，那他其实是将一个html页面上传进了图床内，至于是怎么上传进去的。很简单啊，你只需要有一个阿里云，京东云，腾讯云的账号，购买了oss对象存储服务，设置公共读私有写，就可以访问了，这些不重要，你只需要知道图床所存储的是html就可以了。

我通过chrome的控制台抓取了通过短链转换而来地址，然后抓到了如下请求

• 短链重定向

注意看第一个请求，第一个请求就是短链的自定义跳转，短链自定义跳转我们下一节详细去说，通过301重定向，将我们重定向到了图床的地址

• 图床ua、地域、等判断
  图床内的html包含了对ua、地域、设备类型等的判断，不同的环境所打开的内容是不同的，通过对环境的判断，展示不同的内容去屏蔽微信的扫描，拼夕夕就是通过这样的方式来实现落地页防封的
  下面是我从落地页中拿到的一个函数，虽然我们很难完全还原这个函数，但是通过里面没被混淆的常量比如ke.HUAWEI、ke.OPPO等不难看出来，这是一个判断当前手机品牌的函数，针对不同的品牌下的浏览器，会做一些特殊的处理。

 const t = e(u().mark(function t (e) {

  let r, n, o, i, c, s

  return u().wrap(function (t) {

    for (; ;) {

      switch (t.prev = t.next) {

        case 0:

          if (r = e.brand,

          n = e.payload,

          o = a()(n, 'data', {}),

          i = a()(n, 'isThirdBrowser'),

          c = a()(n, 'data.fastAppDomains', ''),

          s = Te(o),

          Pe(o),

          !i) {

            t.next = 8

            break

          }

          return t.abrupt('return')

        case 8:

          if (r !== ke.HUAWEI) {

            t.next = 11

            break

          }

          return t.next = 11,

          R(c, {

            cTime: s,

            data: o

          }).catch(fn)

        case 11:

          if (r !== ke.OPPO) {

            t.next = 27

            break

          }

          if (!j(A.OppoLeftScreen, o)) {

            t.next = 17

            break

          }

          return t.next = 15,

          R(c, {

            cTime: s,

            data: o

          }).catch(fn)

        case 15:

        case 20:

          t.next = 27

          break

        case 17:

          return t.prev = 17,

          t.next = 20,

          sn(c, {

            cTime: s,

            data: o

          })

        case 22:

          if (t.prev = 22,

          t.t0 = t.catch(17),

          !j(A.banBrowserV2, o) && !j(A.oppoQAppPriority, o)) {

            t.next = 27

            break

          }

          return t.next = 27,

          R(c, {

            cTime: s,

            data: o

          }).catch(fn)

        case 27:

          if (r !== ke.VIVO) {

            t.next = 30

            break

          }

          return t.next = 30,

          sn(c, {

            cTime: s,

            data: o

          }).catch(fn)

        case 30:

        case 'end':

          return t.stop()

      }

    }

  }

  , t, null, [[17, 22]])

}

))

再注意看接下来的一段代码片段，很明显针对上面获取到的手机品牌，会生成不同的图片,注意看下面混淆过的c函数，x.brandType, brand有品牌的意思，也就是上面函数获取到的手机品牌

o = new Promise((function(t) {

var r, o = document.createElement("img"), i = k(n), c = (f(r = {}, x.brandType, 1),

f(r, E.funcParams, i),

r), u = a()(e.split(","), "0");

o.onload = function(e) {

    var r = a()(e, "path[0]") || a()(e, "target")

      , n = gn(r);

    t({

        brand: n,

        img: r

    })

}

,

o.onerror = function() {

    t({

        brand: ke.OTHERS

    })

}

;

var s = S(u).href;

o.src = m(c, s)

}

)),

得益于落地页开发者优秀的代码命名习惯，通过下面的片段，isWeChatPlatform,isIOSWeChatPlatform这两个字符串让我们知道落地页里面还有针对微信的一些判断，会判断是安卓还是ios微信

n = a()(r, "data", {}),

i = a()(r, "isWeChatPlatform"),

c = a()(r, "isIOSWeChatPlatform"),

f = a()(r, "data.mqCodeKey", ""),

l = a()(r, "data.websiteDomain", "").replace(/\/$/, ""),

p = a()(r, "data.fastAppDomains", ""),

d = v("image_url"),

h = v(f) || location.href,

!d) {

    t.next = 15;

    break

}

还有落地页内针对UA的判断的实现

((w = t.document),

  (x = w ? w.title : ''),

  (_ = navigator.userAgent.toLowerCase()),

  (S = navigator.platform.toLowerCase()),

  (O = !(!S.match('mac') && !S.match('win'))),

  (A = _.indexOf('wxdebugger') != -1),

  (E = _.indexOf('micromessenger') != -1),

  (I = _.indexOf('android') != -1),

  (T = _.indexOf('iphone') != -1 || _.indexOf('ipad') != -1),

  (P = function () {

    const t = _.match(/micromessenger\/(\d+\.\d+\.\d+)/) || _.match(/micromessenger\/(\d+\.\d+)/)

    return t ? t[1] : ''

通过上面的代码片段，我们得以窥见拼夕夕落地页的逻辑设计，落地页内，至少实现了下面的能力

• 针对手机品牌的处理


• 针对安卓与ios系统的处理


• 针对是否微信的处理

这些代码进一步的验证了我们的猜想，拼夕夕的确是通过oss内的html动态创建元素来规避微信拦截的！下面是短链智能跳转的一个例子，可以帮助大家更好的理解短链推广的内在逻辑

短链与智能跳转

我们以某平台的功能为例，演示如何通过短链实现自定义的跳转

• 创建短链接

• 配置智能跳转

• 智能跳转的规则

可以看到，本身规则就支持按平台，按访问环境，按地域去进行智能跳转了，这也是为什么谷歌会想要将UA的信息进行加密或减少所提供的的信息。

• 按地域的实现
  服务器可以看到当前访问的ip，通过ip去反向推断地域


• 操作系统、访问环境 是通过判断UA来实现

console.log(navigator.userAgent)

// ua内会包含设备的关键信息，如果是微信浏览器内打开的，会携带微信浏览器特有的ua信息

'Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1'

结语

技术本身都是为了解决现实存在的问题，技术没有好坏黑白，但是作为一个技术人，我们能做的就是做任何事情的时候，要坚守心中的底线。君子不立危墙之下，尽量少游走在黑白间的灰色地带。

大家好，本篇文章会继续给大家分享一些Android常见的开发技巧，希望能对读者有所帮助。

一. 通过堆栈快速定位系统版本

这个地方主要分享大家两个个技巧，通过问题堆栈简快速定位当前系统版本：

1. 快速区分当前系统版本是Android10以下，还是Android10及以上；

首先Android10及以上引入了一个新的服务Service：ActivityTaskManagerService，将原本ActivityMangerService原本负责的一些职能拆分给了前者，所以当你的问题堆栈中出现了ActivityTaskManagerService相关的字眼，那肯定是Android10及以上了。

大家在Android9及以下的源码中是找不到这个类的。

2. 快速区分当前系统版本是Android12以下，还是Android12及以上；

这个就得借助Looper了，给大家看下Android12上Looper的源码：

Looper分发消息的核心方法loop()，现在会转发给loopOnce()进行处理，这个可是Android12及以上特有的，而Looper又是Android处理消息必要的一环，是咱们问题堆栈的源头祖宗，类似于下面的：

所以这个技巧相信还是非常有必要的：当你从问题堆栈中一看有loopOnce() 这个方法，那必定是Android12无疑了。

二. 实现按钮间距的一种奇特方式

最近看了一个新的项目代码，发现该项目实现按钮之间、按钮与顶部底部之间间距实现了，用了一种我之前没了解过的方式，于是这里分享给大家瞧瞧。

这里就以TextView和屏幕顶部间设置间距为例，初始的效果如下：

接下来我们来进行一步步改造：

1. 首先TextView是有一个自定义的xml背景：

<?xml version="1.0" encoding="utf-8"?>

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">

    <item

        android:height="70dp"

        android:gravity="center_vertical">

        <shape>

            <solid android:color="#ff0000" />

        </shape>

    </item>

</layer-list>

核心就是定义了android:height和android:gravity这两个属性，来确保我们自定义背景在组件中的高度及居中位置。

2. 其次将布局中TextView的属性调整下：

1. 首先height属性一定要调整为wrap_content，保证最后TextView按钮的高度的测量最终取minHeight设置的属性值和背景设置的高度这两者的最大值；

2. 其次还要设置minHeight最小高度属性，注意一定要比背景设置的高度值大，保证能和屏幕顶部产生边距效果；

3. 最后要设置字体的位置为垂直居中，保证字体位置和背景不发生错位；

经过上面处理，效果就出来了：

其实上下空白的部分都是属于TextView，设置点击事件也会被响应，这算是其中的缺点之一，当前也可能在业务场景中认为这是一种合理表现。

上面实现的逻辑和TextView的测量逻辑密不可分，感兴趣的同学可以看下这块代码，这里就不带大家进行一一分析了：

三. logcat快速查看当前跳转的Activity类信息

忘了是在哪里看到的了，只要日志过滤start u0，就可以看到每次跳转的Activity信息，非常的有帮助，既不需要改动业务层，也不需要麻烦的安装一些插件啥的。

使用时记得将logcat右边的过滤条件置为，否则你就只能在左边切换到系统进程去看了：

这里我们演示下效果：

1. 跳转到Google浏览器

logcat界面会输出：

会打印一些跳转到包名类名等相关信息。

2. 跳转到系统设置界面

logcat输出：

可以说start u0还是相当好用的。

四. 项目gradle配置最好指向同一本地路径

最近开发中经常存在需要一次性检索多个项目的场景，而这样项目的gradle版本都是相同的，没啥区别。但每打开一个项目就得重新走一遍gradle下载流程，下载速度又是蜗牛一样的慢。

所以强烈建议大家，本地提前准备好几个gradle版本，然后通过设置将项目的gradle指向本地已存在好的gradle：

这样项目第一次打开的速度将是非常快的，而且按道理来说相同gradle版本的项目指向同一本地路径，也可以实现缓存共享。猜的。

如果项目好好的编译运行着，突然没网了，可能会提示一些找不到依赖库资源啥的，其实你本地都已经缓存好依赖库资源了，只需要设置下off-mode，不走网络直接通过本地资源编译运行即可：

总结

本篇文章主要是介绍了Android开发一些技巧，感觉都是项目中挺常用到的，算是我最近一个月收获的吧，后续准备研究研究compose了，毕竟看到大家们都在搞这个，羡慕的口水都流了一地了哈哈。

历史文章

两个Kotlin优化小技巧，你绝对用的上

Kotlin1.9.0-Beta，它来了！！

Kotlin1.8新增特性，进来了解一下

聊聊Kotlin1.7.0版本提供的一些特性

聊聊kotlin1.5和1.6版本提供的一些新特性

优化@BuilderInference注解，Kotlin高版本下了这些“毒手”！

@JvmDefaultWithCompatibility优化小技巧，了解一下~

读本文，可以收获什么？

字数：2494 花费时间：5min

if(x)中的x为各种类型的数据或者值的时候会发生什么？x为各种数据类型、表达式、特殊值、位运算、函数等值的时，这些在if语句都充当了什么，实现了什么？

总结== === ≠三种情况特殊值的比较，如下图所示：

作为一个程序员的我们，相信我们写代码用的最多逻辑应该就是if语句了吧，其实我们真的了解if(x)究竟发生了什么？其实很简单，我们可能都知道中文有这样一个模板："如果是什么,就会做什么"，也就是说符合条件的某件事，才会去做某件事。同样的道理if(x)的意思就是如果符合x条件，我们就可以执行if语句块的代码了。而我们JavaScript中的哪个数据类型是涉及是否意思的？当然是Boolean类型啦，其实if内的x非布尔值都会做一次Boolean类型的转换的。

1 x为一个值时

1.1 x为字符串：

x为一个空字符串时，这是一个假值，if语句会转换为false。

if ("") {

    console.log("Hello World！");

}

console.log(Boolean(""));// false

x为一个非空字符串是，这是一个真值。if语句会转换为true。

if (!"") {

    console.log("Hello World！");// Hello World！

}

console.log(Boolean(!""));// true

x为一个空格字符串，这是一个真值。if语句会转换为true。否则会转换为false

if (" ") {

    console.log("Hello World！");// Hello World！

}

console.log(Boolean(" "));// true

if (!" ") {

    console.log("Hello World！");

}

console.log(Boolean(!" "));// false

x为一个字符串，这是一个真值。if语句会转换为true。否则会转换为false

if ("JavaScript") {

    console.log("Hello World！");// Hello World！

}

console.log(Boolean("JavaScript"));// true



if (!"JavaScript") {

    console.log("Hello World！");

}

console.log(Boolean(!"JavaScript"));// false

1.2 x为数字

x为一个数字0时，这是一个假值，if语句会转换为false。x为一个数字!0时，这是一个真值，if语句会转换为true。

if (0) {

    console.log("Hello World")

}

console.log(Boolean(0));// fasle



if (!0) {

    console.log("Hello World");// Hello World

}

console.log(Boolean(!0));// true

if (1) {

    console.log("Hello World") // Hello World

}

console.log(Boolean(1));// true



if (!1) {

    console.log("Hello World")

}

console.log(Boolean(!1));// false

if (-0) {

    console.log("Hello World")

}

console.log(Boolean(-0));// fasle

if (!-0) {

    console.log("Hello World");// Hello World

}

console.log(Boolean(!-0));// true

1.3 x为数组

x为一个空数组，这是一个真值，if语句会转换为true。

if ([]) {

    console.log("Hello World");// Hello World

}

console.log(Boolean([]));// true

if (![]) {

    console.log("Hello World");

}

console.log(Boolean(![]));// false

x为一个嵌套空数组时，这是一个真值，if语句会转换为true。否则是假值。if语句会转换为false

if ([[]]) {

    console.log("Hello World");// Hello World

}

console.log(Boolean([[]]));// true

if (![[]]) {

    console.log("Hello World");

}

console.log(Boolean(![[]]));// false

x为一个有空字符串的数组时，这是一个真值，if语句会转换为true。否则是假值。if语句会转换为false。

if ([""]) {

    console.log("Hello World");// Hello World

}

console.log(Boolean([""]));// true

if (![""]) {

    console.log("Hello World");

}

console.log(Boolean(![""]));// false

x为一个有数字0的数组时，这是一个真值，if语句会转换为true。否则是假值。if语句会转换为false。

if ([0]) {

    console.log("Hello World");// Hello World

}

console.log(Boolean([0]));// true

if (![0]) {

    console.log("Hello World");

}

console.log(Boolean(![0]));// false

1.4 x为对象：

if ({}) {

    console.log("Hello World") // Hello World

}

console.log(Boolean({}));// true

2 x为特殊值时

if (null) {

    console.log("Hello World");

}

console.log(Boolean(null));// false

if (undefined) {

    console.log("Hello World");

}

console.log(Boolean(undefined));// false

if (NaN) {

    console.log("Hello World");

}

console.log(Boolean(NaN));// false

3 x为位运算时

if (true | false) {

    // 按位或，只要有一个成立就为true

    console.log("Hello World");

}

console.log(Boolean(true | false));// true

4 x为表达式时

比较的相方首先调用ToPrimitive（内部函数，不能自行调用）转换为原始值，如果出现非字符串，就根据ToNumber规则将双方强制转换为数字来进行比较。

const a = [42];

const b = ["43"];

console.log(a < b);// true

5 x为等式时

5.1 一个等号（=）

=： 一个等号代表的是赋值，即使x的值为a=2，也就是说变量的声明操作放在if判断位置上了，其实它还是一个变量并不是一个操作。

let a;

if (a = 2) {

    console.log("条件成立！");// 条件成立！

}

console.log(a);// 2

let a;

if (a = 2) {

    console.log("条件成立！");// 条件成立！

}

console.log(typeof (a = 2));// number

console.log(Boolean(a = 2));// true

let a;

if (a = 2 && (a = 3)) {

    console.log("条件成立！");// 条件成立！

}



console.log(typeof (a = 2 && (a = 3)));// number;

5.2 两个等号（==）

==：宽松相等，我们可能都会这样想，==检查值是否相等，听起来蛮有道理，但不准确，真正的含义是==允许相等比较重进行强制类型转换。

对于==符号尽量遵守两个原则：

如果两边的值中有true或者false，千万不要使用==；

如果两边的值中有[]、""、0，尽量不要使用==。

• 
  

  两个值类型相同，则执行严格相等变量。

  
  

  🍟 都是字符串类型：

  
  

  const a = "";
  
  const b = "12";
  
  console.log(a == b);// false
  
  

  
  

  🍟 都是NaN类型：全称为not a number，理解为不是一个数值。JavaScript的规定, NaN表示的是非数字, 那么这个非数字可以是不同的数字,因此 NaN 不等于 NaN。

  
  

  const a = NaN;
  
  const b = NaN;
  
  console.log(a == b);// false
  
  

  
  

  🍟 都是Symbol类型：Symbol命名的属性都是独 一无二的，可以唯一标识变量值，不受是否相同变量值。

  
  

  const a = Symbol("1");
  
  const b = Symbol("1");
  
  console.log(a == b);// false
  
  

  
  

  🍟 都是对象类型。对象的比较是内存地址，因为对象是存储在堆中，当堆中有对象时，它会相对应内存中有一个存储的地址，在栈中其存储了其在堆中数据的地址，当调用数据时，去堆中调取对应堆中的数据的地址获取出来。也就是相同对象比较的是内存地址，变量不一样存储位置不一样。

  
  

  const a = { a: 1 };
  
  const b = {};
  
  console.log(a == b);// false
  
  

  
  

  const a = {};
  
  const b = {};
  
  console.log(a == b);// false
  
  console.log(Boolean(a));// true
  
  

  
  


• 
  

  两个值类型不相同。

  
  

  🍟 一个值是null，一个是undefind。

  
  

  const a = undefined;
  
  const b = null;
  
  console.log(a == b);// true
  
  

  
  

  🍟 一个值是数字，一个值是字符串。字符串强制转换为数字在比较。

  
  

  const a = 12;
  
  const b = "12";
  
  console.log(a == b);// true
  
  

  
  

  🍟 一个值是布尔值，一个是其他类型的值。这种做法是不安全，不建议去使用，在开发中尽量不要这样使用。

  
  

  console.log("0" == false);// true
  
  console.log("" == false);// true
  
  console.log(0 == false);// true
  
  console.log([] == false);// true
  
  

  
  

  🍟 一个值是对象，一个值是字符串或数字。对象与非对象的比较，对象会被强制转换原始值（通过内部函数 ToPrimitive自动执行，这个是内部函数不能直接调用）再比较。

  
  

  const a = {};
  
  const b = "";
  
  console.log(a == b);// false