大家好，作为今年刚毕业的大聪明（小🐂🐎），知道今年不好就业，费心费力的面试终于进了个小公司，然后我的奇妙之旅开始了。

叮！闹钟响了！牙都不刷了，直接起床出门去上班，身为🐂🐎就要有早起吃草干活的觉悟，所以我是个很合格的食草动物。只不过，下面的信息，让我一天当动物的好心情都没了。

部署？因为该公司人数比较少，也没有自动化部署操作，只能让前端build一下dist包然后丢给后端，让后端部署，然后该项目也比较急，我刚来，也不好意思@后端，恰巧跟我对接的后端也是刚来不熟悉，所以我就跟负责人继续扯皮拖延时间了。（真是不好意思，假的）↓↓↓

终于经过不断努力（后端），部署好了，但是，我的样式乱了，为什么呢？看了一下网络和源代码，样式文件都请求到了，问了后端，一致说是我前端的问题，我懵了，然后快马加鞭查找问题

解决

ok，那我先看打包的dist文件有样式有问题吗，使用npm安装个 http-server 运行打包后的index.html，运行打开运行后的地址，欧克样式没乱，文件引用也没问题，那到底是什么鬼影响的呢？

在我百思不得其解的时候，我打开了神器--csdn，搜索打包dist部署后样式文件不生效，就遇到了这个神文t.csdnimg.cn/WbQyq
欧克，按照博主说的Nginx没有配置这两个东西而导致的，我有点不确定是不是，有点犹犹豫豫的找到后端说帮我在Nginx配置文件的http加下这两个配置，然后样式就好了，完美！后端由于疏忽，没加上就把问题推给我，结果被我扳回一城。

include   mime.types;

default_type  application/octet-stream;

总之，添加 include mime.types; 和 default_type application/octet-stream; 配置后，Nginx能够正确地识别和处理CSS文件的MIME类型，从而确保浏览器能够正确加载和应用CSS样式。

所以，前端仔不能只当前端仔，还是要好好学点服务端的知识，不然锅给你，你还认为这是你该背的锅。

以上是开玩笑的描述，只是为了吸引增加阅读量

一、和解

人的一生就是不断地与世界和解，以及与自己和解。

今天提离职了，相比于四年前的离职，更加的从容和淡定。所谓，心无外物，云淡风轻。

图：云卷云舒，心随境转

二、当下

今天晚上和一个刚来三周的应届生跑步，聊着聊着就说到了要是回到十八岁就好了的话题。

当然我也谈了我的一些想法， 如果是以前的我也会像你这样，要是回到以前就好了。 但是，现在的我更加从容、更加淡定、更加坚定，以及对事情的理解、看法、态度是那个时候没有的，同时懂得了筛选，也懂得舍弃，对社会的理解，对世界的理解也是那个时候没有的，甚至对自己的看法也更加立体，对自己也更宽容，现在反而会更加欣赏自己。

人生不必时时往过去看，"既往不恋，当下不杂，未来不迎"

图：操场跑步，有时候也会坐在最高的台阶上，享受这自然的风。

三、接纳

我们还谈到了失恋的话题，我说很多人是没有办法放下的，也没办法抹去，不管是事还是人都一样。

人的一生就像是石块不断垒起来的玛尼堆，有一些人会在特定时间段参与进来，帮你加一块，可能它的颜色、大小、形状、好看程度都不一样，但你不得不承认，那个时间点，那个高度就只有那么一块，无可替代。

与其不见，不如接纳！

图：某次户外徒步

四、选择

大学时的第一部课外读物 ，路遥的《人生》，开篇来自柳青的一段话，至今影响着我。

刚好昨天生日，有感而发，也时刻警醒着自己。

图：朋友圈，31岁的记录

五、感受

人这一生就是不断地给自己的感受积累素材

不知什么时候，我开始静下来，用心去感受这个世界。

在吃午餐的时候，变得专心，放下了手机，端起了饭碗，开始用舌头去感受食物原本的味道，就像《小森林》中的女主一样。静下来，都是收获。

图：午餐，三菜一汤

用心去感受，用心去体会，从容和淡然。享受生活，感恩生活。

你所看到的，就是你内心的一种投射，你看到了美好，那么你的内心就是美好的。你看到了恶，那么你的内心就是恶。 内心这块三分宝地，就不要装上一些乱七八糟的东西了。

六、经历

生命的厚度在于去经历一些不一样的事情。

人需要不断去经历一些不一样的事情，而不是将365天过成1天。

“人不是活一辈子，不是活几年几月几天，而是活那么几个瞬间。”——鲍利斯·帕斯捷尔纳克。

希望多一些这样怦然心动、与众不同的时刻， 看到黄山的日出、云海，觉得这个世界真的很酷，继续热爱。

图：黄山风景图

不要等到八十岁了才去做二十岁想做的事情。

七、自己

青年人要有青年人的样子，朝气、热血。

如罗曼罗兰说过：
“世界上只有一种真正的英雄主义，那就是在认清生活的真相后依然热爱生活”。

人不要给自己设限，勇敢地做自己，不要被这个世界迷失了自我。

在这个满是焦虑、满是浮躁的社会，更要做到正心正念。

就像我在 500px 网站上说过的一句话：“这个世界没有标准答案，活出自己，不受羁绊”。

今年春节在家里呆的时间比往年都要久一些，就算离家不远也会这样感觉，随着年龄的增加，越发思念故土以及父母。

以往回家都比较晚，待着待着就想着回工作的城市。因为回家总会伴随着和二老的争论，而且我那时也很戾气，合不到一块就气，或者进房间睡觉。

要说啥事能值得争论，我的确忘了，大概是思想观念以及家里生意的问题产生的。以至于身处异乡也要离开家里不愿意喋喋不休。

随着时间流逝，心态已经发生变化。我内心深处逐渐向着故土，和家里二老的关系也潜移默化，彼此心照不宣的拉近了很多。

二老也不过多问责一些，也不再以长者的心态和我对质。

事实也觉得普通家的孩子成年后就该放权干他自己的事，父母少些干预，有些做法和观念已经帮不上忙。父母与孩子之间往往都会产生很大分歧，尤其是思想观念的矛盾。

每一代都有可能推翻上一代的思想意识。父母与子女和谐，一般父母的思想观念足够前卫能够传承给子女，或者子女的思想观念没有很大差异，认可父母的思想体系。

我们会一起坐下来交谈家里的事情，想好对策处理外事，规划老家祠堂以及屋子的安排；参与布置家里，代替老爹出席各项习俗礼节活动。

从读大学开始到现在就没再给它们制造任何的麻烦和搞砸事情。只见他坐在店里抽着烟，沉默着望向我，迟迟不再发话，只在最后说了一句婚姻的问题。

这个话题别说他了，老家众多的亲戚都会抛出这个尖锐的问题，我说我回家只想休息，逢年过节和老朋友叙旧，去亲戚家串串门，一起乐呵乐呵聊聊家常，聊聊八卦。

95‘ 后教师彭老师

小学同学彭老师，现在是一名县城重点中学的高中老师。她是一名 90 后老师，我在她身上看到了很多老师的缩影。她毕业后第一份工作就是任高一班主任兼任课老师。

▲图/ 学生：？？？

彭老师很是焦虑很迷茫，害怕自己不能胜任；害怕自己教不好；害怕自己耽误学生的前途。

每一个担心都很沉重，责任肩负在身上，没日没夜的备课，改作业，演练怎么让学生听懂。

▲图/ 在最无能为力的学科遇到了最不想辜负的老师

小城市义务教育向来重视成绩不太注重心理建设，导致问题学生很多。彭老师经常 solo 学生和家长，试图说服他们把重心放在当前阶段要做的事。

尽管生病，喉咙发炎也坚持做着这些事情。

▲图/ 除夕夜，彭老师回学校，顺道提零食带红包给她

▲图/ 她赠了一罐饮料，握着只觉比当时天气还冷

▲图/ 彭老师收到开工红包请吃饭，还给了红包，呜呜呜感动

有时煎熬的对着同事和朋友说，看着自己的希望学生开始堕落真的很难受，说也说不通；面对自己的学生读着读着因家里或者各种的问题而辍学时更无语。

▲图/ 00 后学生在 95 后老师教案涂鸦

忍不住会直接联系家长 solo，开导家长有时候如同开山凿石一样，只有坚持不懈才使得那位学生继续读下去，尽管读大专，也改变了不少走向。

有一天她苦笑的跟我们说，她自己都没怎么谈过恋爱却还要开导失恋的学生，甚至被失恋学生反问：“老师，你谈过恋爱吗？”

？？？

彭老师所带的班级在 23 年第一批结业。上本率超额完成上面给的任务，这一路上面临学生堕落、早恋、辍学、逃课、网瘾...

彭老师有时候很想放弃摆烂，像那些老道的老师一样，风清云淡，看开一点，上课就上课，喝茶就喝茶，晒太阳就晒太阳。

后来她骑着小电瓶，向我重申了她那坚定的信念，绝不可能摆烂，我要对我的学生负责，要为他们的前途着想，就这么决定了。

我看着她感觉头上出现了一顶为人师表的光环。

实话说，老师的行为无论是怎样的，都会被学生刻在记忆深处，尽管有时不会联系，也会在某一刻回想起，念其良莠。

▲图/ 念大学的学生探望彭老师

她性格一直都很逗比很乐观，走路也喜欢蹦蹦跳跳，还被她的老师和学生嘲笑她走路蹦蹦跳跳，和她玩王者鲁班的走姿如出一辙。

在她学生毕业之后，彭老师回归万年鲁班，但技术依然停留在四五年前大学生时期，经常遭截杀一路“啊”，开疾跑徒走回水晶，也经常被我们和她的学生给护着。

现在见她时还是很逗比，嘴硬心软。脸上刻印出一副班主任的形象，坚定严肃而又亲和。

她说她带完一届之后不当班主任了，太辛苦太累了。后面她又被安排带复读班班主任。

阿姨，你来真的啊？

老家的天气很不错，逢年过节我们经常互串亲戚的门，晒晒太阳，欺负欺负小朋友，欺负过头了说送给他们一份《三年高考五年模拟卷》礼物，他们哭的更厉害。

▲图/帮人带孩子真好玩

春节假期充电的时间正在倒计时，最后赶着串堂弟的门，也就是大叔家，那时他们家里很忙，家族里的会做饭打点的都来帮忙了。

原来是堂弟未来丈母娘查家环节，家里上上下下忙活。

我等闲杂人在巷子里晒着太阳，准备迎接他们。堂弟我和同岁，月份比我小，在温州工作，这几年他老爹操够了心，费了不少钱。龙年又长了一岁，他父母更是着急。

▲图/ 回家路途中天色很震撼，大家都不想说话

闲聊之际，只见一列车齐刷刷地开到门口，不知道的还以为是迎亲来了。

二叔见状连忙赶上去打招呼并指挥停车泊位。只见那丈母娘下车后整理着装，望着周边的房屋装饰，一脸严肃对着二叔说位置有些偏远，绕来绕去的，二叔连忙解释可能走的道不一样，走国道会很顺。

亲友团齐刷刷招呼张罗着进去喝茶，握手，递烟，倒茶。摆了三桌才能坐下，我们自己人在旁边站着观望或帮忙。两方互相寒暄之后，不到十分钟对方便开始切入主题，商量儿女婚姻问题。

丈母娘吐露堂弟家位置偏僻，路道不好走，绕了很多弯才抵达，彩礼需要增加 3w 到 5w，作为她女儿的嫁衣钱。

阿姨，你这是来真的啊？

大叔一边忙着圆场有不同的道路可以走，镇与镇之间来往有很多路可走也方便，一边递烟倒茶使其思量再三。

丈母娘依然坚定不移，重申了一遍，对方亲戚应声附和。

大叔脸色像是喝酒上了头一样，随后陷入沉思，见其态度坚硬，且事已至此，作出退步可以增加 1w - 2w，给到对方女儿身上。

前些天，大叔带着堂弟相亲到女方家，据说对方开价 35.8w 彩礼，回礼是购买房之后支援 10w+，不知其是否商量后的价格。

只见那天大叔来我家喝茶水时带着儿子和未来儿媳去了县城买了“五金”， 4w 左右。

见此事既成，并不买二叔的帐，坚持需要增加 3w，并声称给女儿做嫁衣。

大叔又陷入了思考，心里计算着账面，上个月女儿刚嫁出去，彩礼还没捂热，就要付之东流，是为不甘且又无奈。

场面陷入了安静，对方只管握着茶杯吃着果子等待结果，势必做好了撤离的打算。

姑舅们遂即递烟倒茶聊家常。

堂弟陪同坐着喝茶望着对象低下了头，儿媳妇安静得陪在身边，挽着堂弟的手。

掂量之后大叔同意了对方的要求，双方态度方能缓和很多，继续喝茶，商量事宜，聊家常，聊孩子幸福。

饭后，互相道了别，每人随了红包礼。只觉得对方结婚习俗没有讲明白有点遗憾，但愿不会阻碍他两组建一个幸福的小家庭。

我和表弟坐在沙滩上，对着河扔石子打水漂，谁都不想再提，心里比谁都清楚。却和群里的伙伴嘲笑着自己家的那位是否也要几十个 w。

不久前开源圈子里的一则消息在网上引起了一阵关注和讨论。

一个由国人开发者所打造的开源项目被 Redis 公司官方给收购了，作者自己也发了动态，表示感谢项目9年以来的陪伴，同时也希望她未来一切都好。

这个开源项目的名字叫做：ioredis，相信不少小伙伴也用过。

目前在GitHub上我们可以看到，ioredis项目的开源地址已经被迁移至 Redis 官方旗下了。

iosredis是国人开发者所打造的一个Redis客户端，基于TypeScript所编写，以健壮性、高性能以及功能强大为特色，并且被很多大公司所使用。

截止到目前，该项目在GitHub上已累计获得超过 13000 个 Star标星和 1000+ Fork。

作者自己曾表示，自己创建这个开源项目的初衷也很简单，那就是当年在这方面并没有找到一个令自己满意的开源库，于是决定自己动手来打造一个，于是就利用闲暇时间，自己从零开发并开源了 ioredis 。

直到2022 年 8 月 30 日，历时整整7年，ioredis 成为了 Node.js 最流行的 Redis 客户端。

而直到如今，这个项目从个人的 side project 到被开源公司官方收购，作者9 年的坚持属实令人佩服，吾辈楷模啊！

而拜访了这位开发者的GitHub后我们会发现，作者非常热衷于创造工具，除了刚被收购的名作ioredis之外，主页还有非常多的开源项目，并且关注量都不低。

而且从作者发的一些动态来看，这也是一个热爱生活的有趣灵魂。

有一说一，个人开源作者真的挺不容易的，像上面这样的个人开源项目被官方收购的毕竟是个例，其实好多个人的开源项目到后期由于各种主客观原因，渐渐都停止更新和维护了。

大家都知道，伴随着这两年互联网行业的寒意，软件产业里的不少环节也受到了波动。行业不景气，连开源项目的主动维护也变得越来越少了。

毕竟连企业也要降本增效，而开源往往并不能带来快速直接的实际效益。付出了如果没有回报，便会很难坚持下去。

而对于一名学习者而言，参与开源项目的意义是不言而喻的，之前咱们这里也曾多次提及。

参与开源项目除了可以提升自身技术能力，收获项目开发经验之外，还可以让自己保持与开源社区其他优秀开发者之间的联系与沟通，并建立自己的技术影响力，另外参与优秀开源项目的经历也会成为自己求职简历上的一大亮点。

所以如果精力允许，利用业余时间来参与或维护一些开源项目，这对技术开发者来说，也是一段难得的经历！

我的博客原文

@author: 郭瑞峰

@createTime: 2024/06/03

@updateTime: 2024/06/20

心血来潮

25号考完了，非常不理想，果然700页的东西不是一个月能搞完的。不对，我今儿写日志是为了纪念一下我的第一家公司，咋扯到别的了......言归正传，我在第一家公司待了仨年，可能是年纪到了(26岁咋还不退休啊)，也可能是留了点感情在，离开前有些百感交集，思来想去还是写一个懒人日志吧，纪念一下我打工的三年光阴吧。
(:з」∠)

初说公司

先说一下俺的第一家公司，咱从学校出来就来这儿报道了，公司是国企控股，领导层全是国企员工，其他进公司的员工就是合同工，或者说是国企合同工，能吃公司东西，不是人力外包。
(:з」∠)

成都这边的开发都是围绕着云服务的，包括云操作系统、云桌面系统、云运维系统以及多云系统(我个人喜欢把他称为多个云集成系统)，当然全是定制化项目。对，忘说了，公司主要业务是轨道交通行业，做云相关的产品是将轨道行业的运维放在云上面，算是相应国家的两化融合（信息化和工业化）。

对了，得说一下公司待遇，公司给的工资都在平均水平以下，尤其是对应届生而言，社保基数是工资八折(试用期)交的，公积金是12%，没有餐补但自带食堂以及饭卡补助，有些节假日有礼品，至少基础福利还好。

项目与业务

我所在的项目组就是多云系统，也算是我认为公司能拿得出手的项目。虽然是集成项目，但它只能集成。好像说了跟没说一样，那说具体点吧，比如说业主那边需要云，但怕私有云厂商垄断坐地起价，所以说一般配额划分为“7/3”、“4/3/3”、“6/4”，这样就有两套云系统，为了用起来顺心就需要一个集成系统，所以说我这个项目组的业务来源就是这样，至于你说的我们集成系统会不会垄断坐地起价，拜托，我们系统只会集成，没有底层设备控制权，坐地起价就直接禁用就行了，就不用这个系统呗，反正资源在另外的云操作系统中。

好了，话题回来，说说项目组开发相关的吧，项目开发受阻有三：与三方厂商沟通、项目代码老旧、随时随地变更的需求。

先说第一点吧，集成系统最大的麻烦就是跟三方厂商沟通，当然测试环境、测试数据获取这类的细节也算三方厂商沟通。因为地铁行业算是智能中国建设的一部分，所以说不光是我，连三方厂商的软件都必须是定制的。开发时候就要等着厂商环境稳定了，有数据了再联调，联调有bug了，再走一轮上面的流程，极大地增加了沟通成本以及开发成本。

其二就是和很多工业软件公司一样，软件项目时间跨度很大，里面东西不知道转手了好多次，缝缝补补式的开发，开发要考虑很多兼容性问题以及自己想办法写补丁。比如说node@6.x.x不支持Object.entries，你就要手动在webpack.base.conf.js写的兼容，问我为啥不配置babel呢，上次改babel配置都是2016年的事儿了。代码要写兼容，久而久之就会忘记什么事封装、抽象，全部遗失在兼容的漩涡中。

其三就是随时随地变更的需求，这里我叠个甲，这个我不是甩锅给产品，虽然是产品改的需求，但产品不是想改就改，一定是业主/客户/上级/领导指示要改的。有需求变动谁都不会安逸，谁都烦，但请把炮火对准，不要误伤友军。频繁调整的需求会不断地消磨激情和热情，模糊项目方向，当然还有临时变卦导致的加班。

心态变化

三年工作时间虽然很短，但足以改变心态。原来有些迷茫到彻底迷茫；原来想要搞出一番事业到慢慢得过且过；原来想努力改变世界走到只想躺平加速世界毁灭。

公司的缝缝补补，工作的缝缝补补，项目的缝缝补补，这样的缝缝补补渐渐地缝补在人身伤，人心里。原来就算只有940的显卡也要努力熬夜玩游戏，现在用上3060ti后却只想打开直播看看，就只看看，重新上手玩太耗精力了。至于脱单嘛，自己都这么累了，为啥带着另一个一起累呢？

尾声

本来6月3号说写完的，忙着离职交接以及新公司入职，再加上拖延症又犯了，所以说一直到20号才写完，不过至少咱写完了，能发。

这篇算是自己里程记录，同时也是发牢骚，大家就当笑话看看吧。

Google 于 2023 年 5 月 10 日全面开放了以 .zip 结尾的域名，这一举动引起了安全研究人员和社区的警惕，他们担心该通用顶级域名（gTLD，Generic top-level domains）会被用于创建足以迷惑计算机高手的恶意 URL。

2023 年 5 月 3 日，Google 宣布了包括 .zip 和 .mov 在内的 8 个全新的通用顶级域名：

• .dad


• .phd


• .prof


• .esq


• .foo


• .zip


• .mov


• .nexus

并于 5 月 10 日通过 Google Domains 向公众开放注册。

Google Domains 是 Google 提供的一项域名注册和管理服务，支持用户搜索和注册域名

小心！含有 .zip 的恶意 URL

安全研究员 Bobby Rauch 指出（The Dangers of Google’s .zip TLD），要警惕含有 .zip、Unicode 字符（特别是 U+2044、U+2215 等）以及 @ 符号的恶意 URL。这类恶意 URL 迷惑性极强，甚至能欺骗十分有经验的用户。

若点击 https://google.com@bing.com 这个 URL，实际访问的是 https://bing.com。这是因为根据 RFC 3986 Uniform Resource Identifier (URI): Generic Syntax 的规定，@ 符号之前的 google.com 应识别为用户信息，其后的 bing.com 才是主机名（域名）。我们可以借助常用的编程语言来确认这一点，如利用 PHP 的 parse_url() 函数：

<?php

var_dump(parse_url("https://google.com@bing.com"));

array(3) {

  ["scheme"]=>

  string(5) "https"

  ["host"]=>

  string(8) "bing.com"

  ["user"]=>

  string(10) "google.com"

}

然而，若 @ 之前有正斜杠 /，如 https://google.com/search@bing.com，则浏览器会将 /search@bing.com 部分识别为路径，最终访问的是 https://google.com/ 下的文件 search@bing.com。由于没有这个文件，结果自然是 404。

<?php

var_dump(parse_url("https://google.com/search@bing.com"));

array(3) {

  ["scheme"]=>

  string(5) "https"

  ["host"]=>

  string(10) "google.com"

  ["path"]=>

  string(16) "/search@bing.com"

}

Bobby Rauch 就是利用了上述规则，创建了一个恶意 URL，

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip

乍看之下，这个 URL 似乎是用于从 GitHub 上下载 v1271 这个特定版本的 Kubernetes 的链接。但实际上 parse_url() 函数的解析结果显示，真正要访问的域名却是 v1271.zip 而不是 github.com：

<?php

var_dump(parse_url("https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip"));

array(3) {

  ["scheme"]=>

  string(5) "https"

  ["host"]=>

  string(9) "v1271.zip"

  ["user"]=>

  string(63) "github.com?__kubernetes?__kubernetes?__archive?__refs?__tags?__"

}

若你不小心点击了这类域名，那么恭喜你，很可能喜提一个 evil.exe（请注意动画演示中的左下角）。

仅凭肉眼可能难以分辨以下两个 URL 的区别吧：

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕

https://github.com/kubernetes/kubernetes/archive/refs/tags/

但若调整一下字体，则可以发现端倪，

恶意 URL 中的正斜杠 / 根本不是真正的 /（U+002F），

而是下面这个看起来很像 / 的 Unicode 字符：

由于恶意 URL 中并没有使用真正的 /，因此根据 RFC 3986 的规定，@ 之前的部分github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕ 尽管看似域名与路径，但实际上却是用户信息（真够长的）。

在刚刚的动画演示中，Bobby Rauch 其实还使用了另一个迷惑人的小伎俩——在电子邮件客户端上，将 @ 的字号大小更改为 1，让这个特殊字符几乎看不到，从而更隐秘地伪装了恶意 URL。

对于由以 .zip 结尾的域名带来的安全隐患，Bobby Rauch 给出的建议是，在单击 URL 之前，先将鼠标悬停在该 URL 上并检查浏览器底部显示真正要访问的 URL。

感谢你阅读本文！

这段时间在校友群里看到一些“混得比较好的”同学发言，类似于“5w的月薪很高吗？”，“我身边年薪六七十w的人不少”之类的话，加上偶尔看到一些“年薪百万很简单”的标题党文章或者视频，其实对于我来说，我根本懒得去考证这些是真是假！

但是我觉得有必要去聊一聊！

一、知识的贫乏

首先在说这个问题之前，我想引用罗翔老师的一句话。

一个知识越贫乏的人，就越有莫名的优越感！

一年多以前，我回老家，和以前的高中女同学出来聊天，彼此聊了聊自己现在的工作，然后他问我，“你现在一个月能赚三四万吧！”，我当时惊呆了，我回她：“瞧你说的，捡黄树叶也要赶上秋天呢”，我反问她你现在多少呢，她说两千八，我继续问，“你觉得工资多少才算高？”，她说最起码5万以上吧！我苦笑答：“我的妈呀，怎么都这么厉害呀！”。

事实是怎样的呢？

我们先不把事情说得太远，“脉脉上人均年薪百万”，“抖音上人手一台劳斯莱斯”这些不在叙述范围内，感情咱也不会那么不要脸去吹！

二、大众才是真相

像我们这种普通二本学校的学生现状应该最能接近真相了，往上不谈双一流，往下不谈专科，据我所知，我校2021毕业的学生，如果继续做软件工程的话，现在一个月能拿两万以上的人没几个，还得是一线城市，在一线城市的大多都是一万多，所以一万多就是一个中位数。

不过要注意，软件工程专业毕业后从事本专业的人是很少的，就拿我们班来说，班上50人，但是从事软件的不超过20个，20个还是比较理想的。

那么就有一部分从事其它职业，一部分待业，一部分考公考编。

软件行业在整个市场来说工资高一点，就业相对来说简单一点，虽然近几年来行情越来越差，但是相比于其他行业来说，还是稍微好一点！

从事其他行业的人来说，如果家里有点关系的人，条件好一点的人，可能去到一个单位里面暂时上班，条件不好的，那就出来随便找一个班上，对于销售型的，在广州深圳，大多都是六七千，小城市的话，五千基本上已经很高了。对于待业的，那基本上没收入，考公考编的一般都回到了小县城，随便找个单位临时上班，一个月也就两千来块！

我们就不去分析双一流，专科，中职这些了，所以整体算下来，我们现在的年轻人的收入是很低的。

三、时代特征

努力在这个社会貌似已经不是一个正能量的词了，仿佛已经是一个调侃的词了，就像现在大多女孩子，他现在不会选择一个很努力的男孩子作为伴侣，因为努力后得到回报是一个概率事件，大多会选择有“存货”的人！当然，并不是人人都这样！

社会的发展就是这样，就像森林里面的狼越来越多，那么捕获到猎物的概率就越来越小，这和努力没多大的关系，这是时代特征！

八九十年代别说考上大学，考上中专谋个职位都不难，而现在一砖头下去都能打中几个研究生已经不是什么稀奇事了。

还有现在的经济形势如此严峻，企业和单位的寒冬一直在降临，无数的人蜂拥而至，导致形势更加紧张，本来在夹缝中已经难以生存了，现在变成了针眼！

所以前段时间网红带货主播李佳琦在网上说：“找找自己的原因，工资涨了没涨，有没有认真工作”，是因为的认知出现了谬误，所以才说出了这种言论，而他的成功完全靠努力吗？你怎么看！

四、这和你有鸡毛关系！

浮躁来自于你的认知水平，在这个信息爆炸的时代，如果不能分辨真假是非，那么就很容易陷入浮躁的状态！

网络上和现实中总是充斥着一股“赚钱很容易”的妖风，他们去编造一些故事，制造一些假象来迷惑人的双眼，如果你的甄别能力不够，那么你就会觉得为啥别人那么厉害，自己为啥混成这样，从而陷入浮躁和迷茫之中，当你进入这个状态后，等待你的要么是镰刀，要么是内耗！

做人过程中的一大蠢事就是自己啥也不是的时候，总是去炫耀自己拥有的那些八竿子打不着的人脉和资源，被那些不知真假的事物去影响，去自我否定，当一个人不能独立去思考问题，不站在现实角度去看待问题的时候，那么是永远不可能获得成长的。

五、最后

现实中，很多人都是很窘迫的，赚到钱的人永远在少数，这是时代特征和个人运气所决定的，努力只占了很小一部分，所以别被互联网上的一些妖风所影响！

这个时代我们虽然能决定的东西很少，事物都充满不确定性，但是依然要如罗曼罗兰说的那样“世界上只有一种英雄主义,看清生活的真相依然热爱生活”，正因为充满不确定性，所以才有“赌”的意义！

写掘金博客有一小段时间了，我发现了一个秘密。文章阅读量小了吧，很心烦，阅读量大了吧，更心烦。很多特别懂特别会的大哥们就会来“指点”我。感谢这些大哥们的“指点”，使我进步。后来我和群里的小伙伴们讨论了一下，为什么掘金文章会有那么多大哥们来“开心指点”呢？大概是这么几种情况：

1 他们爱学习，爱分享，但是即将要被裁员了，所以心情不是太好，怎么办呢？去掘金上指点他们去，让他们知道自己很会很懂；

2 他们在团队中就是翘楚，指点完了团队的人，然后不放心，怕世界不足够完美，反正自己也要被裁员了，有时间，然后补偿没拿够，心情不太好，去给他们指点指点去；

3 他们一直觉得自己不太懂，但是看见文章又想指点指点，所以呢，在家找了3个月工作这段时间，一边学习，然后看大家的文章，学习过程中呢，看哪里觉得不太合适，指点指点，希望趁着阅读量高的文章，好希望有人能发现他们，直接邀约他们入职；

这种人呢，我们总结了一下，他们可以叫“黑哥会”，意思就是黑哥们，比较会，啥都会那种，嗯，希望黑哥会的成员们早日找到心仪的工作，在家闲着不好的。

好啦，在文章正式开始之前呢，告诉大家个好消息，本文点赞，友善评论，友善建议的大哥大姐们，2024年的后半年，一定能够心想事成，工作顺利，家庭和睦，一直到永久。

321... 文本正式开始。

1 未排序的数据

今天早上来了公司，我赶紧喊老张，问：新来的前端妹子这么快就被你搞定啦？听说昨晚你俩10点一起出的公司？是不是，快说。 老张，猛地抬头，问：你咋知道的？我保密工作做这么好。 我说：门口的李大爷说的。你快说说什么情况啊。

老张说：别瞎说，昨天后端下班早，把接口就给妹子了，妹子本来以为调一调接口，传几个参数完事，结果发现后端给的数据没有排序，但看了产品文档，发现，又要根据学生姓名按字母排序，又要根据分数排序，又要根据年龄排序，又要根据日期排序，直接把妹子气的快哭了，所以我就帮他弄了弄。然后就弄到10点了呗，一起出的公司而已，别瞎想。

但是妹子为了感谢我，告诉了我一个好消息，过会儿和你说。我说：你快点说。老张说：你先听我把功能说完，我再告诉你。

你看，后端就一个接口，给的数据大概是这样子：

const users = [

      {"name": "小张伟", "age": 19, "score": 55, "dateTime": '2021-03-03 15:33:10'},

      {"name": "张三", "age": 22, "score": 65, "dateTime": '2023-03-03 10:10:10'},

      {"name": "李四", "age": 30, "score": 87, "dateTime": '2024-04-03 10:10:10'},

      {"name": "阿斌", "age": 50, "score": 90, "dateTime": '2021-03-03 10:10:10'},

      {"name": "曹小操", "age": 1300, "score": 23, "dateTime": '1021-05-08 10:10:10'},

      {"name": "小张灰", "age": 31, "score": 15, "dateTime": '1994-03-04 08:33:10'},

];

2 根据属性排序

这是一个杂乱的json型数组，但是要根据属性进行排序。我们目前做了3种类型的实现

2.1 引入工具库

这里说一个高效便捷功能丰富的前端JS库，首先引入js-tool-big-box工具库。

执行安装命令：

npm install js-tool-big-box

引入dataBox对象，排序的这些公共方法被放到了这个对象下面：

import { dataBox } from 'js-tool-big-box';

2.2 数值型排序

数值型排序呢，就是，你看，age 和 score 都是数值型的，我们把这些归结为一类进行排序。

2.2.1 根据age从小到大的排序

代码如下：

const ageResult1 = dataBox.sortByNumber(users, 'age');

console.log('age是数值型，从小到大，排序后的值为：', ageResult1);

结果如下：

2.2.2 根据age从大到小的排序

代码如下：

const ageResult2 = dataBox.sortByNumber(users, 'age', 1);

console.log('age是数值型，从大到小，排序后的值为：', ageResult2);

结果如下：

2.2.3 根据score从低到高的排序

代码如下：

const ageResult3 = dataBox.sortByNumber(users, 'score');

console.log('score是数值型，从低到高，排序后的值为：', ageResult3);

结果如下：

2.2.4 根据score从高到低的排序

代码如下：

const ageResult4 = dataBox.sortByNumber(users, 'score', 1);

console.log('score是数值型，从大到小，排序后的值为：', ageResult4);

结果如下：

2.3 中文按字母排序

比如我们的姓名，很多时候需要按字母从A到Z来展示，这个时候就可以用下面这个方法来快速实现：

2.3.1 按字母从A到Z排序

代码如下：

const nameResult1 = dataBox.sortByletter(users, 'name');

console.log('比如name，我们按照字母顺序排序后为：', nameResult1);

结果如下：

2.3.2 按字母从Z到A排序

代码如下：

const nameResult2 = dataBox.sortByletter(users, 'name', 1);

console.log('比如name，我们按照字母顺序倒序排序后为：', nameResult2);

结果如下：

2.3.3 注意

需要注意的是，我们这里只是传入了name的属性，如果这个json中有其他中文属性，也是可以使用这个方法进行按字母排序的，很灵活。

2.4 按日期时间排序

比如我们例子中的时间，按时间排序也是非常实用且常见的需求，

2.4.1 按时间从早到晚排序

代码如下：

const timeResult1 = dataBox.sortByTime(users, 'dateTime');

console.log('以时间从早到晚排序后的值为：', timeResult1);

结果如下：

2.4.2 按时间从晚到早排序

代码如下：

const timeResult2 = dataBox.sortByTime(users, 'dateTime', 1);

console.log('以时间从晚到早排序后的值为：', timeResult2);

结果如下：

2.4.3 注意

需要注意的是，我们例子中只是传入了dateTime属性，如果json对象中有其他的是时间格式的属性值，也可以把属性传入，就可以进行字段的属性排序啦，很便捷。

3 最后

把效果展示完了，我赶紧催促老张说：你刚才跟我说的好消息呢？老张悄声说：妹子和门口老大爷，还有咱们公司老板都姓李，你品去吧。妹子跟我说了，她跟她爸爸说：这个季度的优秀就是我。我一听也跟着高兴起来，希望看到这篇文章的大哥大姐们，也都能像老张一样，升职加薪，变得越来越优秀。

最后告诉你个消息：
js-tool-big-box的npm地址是(js-tool-big-box 的npm地址)

js-tool-big-box的git仓库地址(js-tool-big-box的代码仓库地址)

MySQL 和 Elasticsearch 是两种不同的数据管理系统，它们各有优劣，适用于不同的场景。本文将从以下几个方面对它们进行比较和分析：

• 数据模型


• 查询语言


• 索引和搜索


• 分布式和高可用


• 性能和扩展性


• 使用场景

数据模型

MySQL 是一个关系型数据库管理系统（RDBMS），它使用表（table）来存储结构化的数据，每个表由多个行（row）和列（column）组成，每个列有一个预定义的数据类型，例如整数、字符串、日期等。MySQL 支持主键、外键、约束、触发器等关系型数据库的特性，以保证数据的完整性和一致性。

Elasticsearch 是一个基于 Lucene 的搜索引擎，它使用文档（document）来存储半结构化或非结构化的数据，每个文档由多个字段（field）组成，每个字段可以有不同的数据类型，例如文本、数字、布尔、数组等。Elasticsearch 支持动态映射（dynamic mapping），可以根据数据自动推断字段的类型和索引方式。

MySQL 和 Elasticsearch 的数据模型有以下几点区别：

• MySQL 的数据模型是严格的，需要事先定义好表的结构和约束，而 Elasticsearch 的数据模型是灵活的，可以随时添加或修改字段。


• MySQL 的数据模型是二维的，每个表只有行和列两个维度，而 Elasticsearch 的数据模型是多维的，每个文档可以有嵌套的对象或数组。


• MySQL 的数据模型是关系型的，可以通过连接（join）多个表来查询相关的数据，而 Elasticsearch 的数据模型是非关系型的，不支持连接操作，需要通过嵌套文档或父子文档来实现关联查询。

推荐博主开源的 H5 商城项目waynboot-mall，这是一套全部开源的微商城项目，包含三个项目：运营后台、H5 商城前台和服务端接口。实现了商城所需的首页展示、商品分类、商品详情、商品 sku、分词搜索、购物车、结算下单、支付宝/微信支付、收单评论以及完善的后台管理等一系列功能。 技术上基于最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等常用中间件。分模块设计、简洁易维护，欢迎大家点个 star、关注博主。

github 地址：github.com/wayn111/way…

查询语言

MySQL 使用标准的 SQL 语言来查询和操作数据，SQL 语言是一种声明式的语言，可以通过简洁的语法来表达复杂的逻辑。SQL 语言支持多种查询类型，例如选择（select）、插入（insert）、更新（update）、删除（delete）、聚合（aggregate）、排序（order by）、分组（gr0up by）、过滤（where）、连接（join）等。

Elasticsearch 使用 JSON 格式的查询 DSL（Domain Specific Language）来查询和操作数据，查询 DSL 是一种基于 Lucene 查询语法的语言，可以通过嵌套的 JSON 对象来构建复杂的查询。查询 DSL 支持多种查询类型，例如全文检索（full-text search）、结构化检索（structured search）、地理位置检索（geo search）、度量检索（metric search）等。

MySQL 和 Elasticsearch 的查询语言有以下几点区别：

• MySQL 的查询语言是通用的，可以用于任何关系型数据库系统，而 Elasticsearch 的查询语言是专用的，只能用于 Elasticsearch 系统。


• MySQL 的查询语言是字符串形式的，需要拼接或转义特殊字符，而 Elasticsearch 的查询语言是 JSON 形式的，可以直接使用对象或数组表示。


• MySQL 的查询语言是基于集合论和代数运算的，可以进行集合操作和数学运算，而 Elasticsearch 的查询语言是基于倒排索引和相关度评分的，可以进行全文匹配和相似度计算。

索引和搜索

MySQL 使用 B+树作为主要的索引结构，B+树是一种平衡多路搜索树，它可以有效地存储和检索有序的数据。MySQL 支持主键索引、唯一索引、普通索引、全文索引等多种索引类型，以加速不同类型的查询。MySQL 也支持外部存储引擎，例如 InnoDB、MyISAM、Memory 等，不同的存储引擎有不同的索引和锁机制。

Elasticsearch 使用倒排索引作为主要的索引结构，倒排索引是一种将文档中的词和文档的映射关系存储的数据结构，它可以有效地支持全文检索。Elasticsearch 支持多种分词器（analyzer）和分词过滤器（token filter），以对不同语言和场景的文本进行分词和处理。Elasticsearch 也支持多种搜索类型，例如布尔搜索（boolean search）、短语搜索（phrase search）、模糊搜索（fuzzy search）、通配符搜索（wildcard search）等，以实现不同精度和召回率的检索。

MySQL 和 Elasticsearch 的索引和搜索有以下几点区别：

• MySQL 的索引是基于数据的值的，可以精确地定位数据的位置，而 Elasticsearch 的索引是基于数据的内容的，可以近似地匹配数据的含义。


• MySQL 的索引是辅助的，需要手动创建和维护，而 Elasticsearch 的索引是主要的，自动创建和更新。


• MySQL 的索引是局部的，只针对单个表或列，而 Elasticsearch 的索引是全局的，涵盖所有文档和字段。

分布式和高可用

MySQL 是一个单机数据库系统，它只能运行在一台服务器上，如果服务器出现故障或负载过高，就会影响数据库的可用性和性能。为了解决这个问题，MySQL 提供了多种复制（replication）和集群（cluster）方案，例如主从复制（master-slave replication）、双主复制（master-master replication）、MySQL Cluster、MySQL Fabric 等，以实现数据的冗余和负载均衡。

Elasticsearch 是一个分布式数据库系统，它可以运行在多台服务器上，形成一个集群（cluster）。每个集群由多个节点（node）组成，每个节点可以承担不同的角色，例如主节点（master node）、数据节点（data node）、协调节点（coordinating node）等。每个节点可以存储多个索引（index），每个索引可以划分为多个分片（shard），每个分片可以有多个副本（replica）。Elasticsearch 通过一致性哈希算法（consistent hashing algorithm）来分配分片到不同的节点上，并通过心跳检测（heartbeat check）来监控节点的状态。如果某个节点出现故障或加入集群，Elasticsearch 会自动进行分片的重新分配和平衡。

MySQL 和 Elasticsearch 的分布式和高可用有以下几点区别：

• MySQL 的分布式和高可用是可选的，需要额外配置和管理，而 Elasticsearch 的分布式和高可用是内置的，无需额外操作。


• MySQL 的分布式和高可用是基于复制或共享存储的，需要保证数据一致性或可用性之间的权衡，而 Elasticsearch 的分布式和高可用是基于分片和副本的，可以根据需求调整数据冗余度或容错能力。


• MySQL 的分布式和高可用是静态的，需要手动扩展或缩容集群规模，而 Elasticsearch 的分布式和高可用是动态的，可以自动适应集群变化。

性能和扩展性

MySQL 是一个面向事务（transaction）的数据库系统，它支持 ACID 特性（原子性、一致性、隔离性、持久性），以保证数据操作的正确性和完整性。MySQL 使用锁机制来实现事务隔离级别（isolation level），不同的隔离级别有不同的并发性能和一致性保证。MySQL 也使用缓冲池（buffer pool）来缓存数据和索引，以提高查询效率。MySQL 的性能主要取决于硬件资源、存储引擎、索引设计、查询优化等因素。

Elasticsearch 是一个面向搜索（search）的数据库系统，它支持近实时（near real-time）的索引和查询，以保证数据操作的及时性和灵活性。Elasticsearch 使用分片和副本来实现数据的分布式存储和并行处理，不同的分片数和副本数有不同的写入吞吐量和读取延迟。Elasticsearch 也使用缓存（cache）和内存映射文件（memory-mapped file）来加速数据和索引的访问，以提高搜索效率。Elasticsearch 的性能主要取决于集群规模、分片策略、文档结构、查询复杂度等因素。

MySQL 和 Elasticsearch 的性能和扩展性有以下几点区别：

• MySQL 的性能和扩展性是有限的，它受到单机资源、锁竞争、复制延迟等因素的限制，而 Elasticsearch 的性能和扩展性是无限的，它可以通过增加节点、分片、副本等方式来水平扩展集群。


• MySQL 的性能和扩展性是以牺牲搜索能力为代价的，它不能支持复杂的全文检索和相关度评分，而 Elasticsearch 的性能和扩展性是以牺牲事务能力为代价的，它不能保证数据操作的原子性和一致性。


• MySQL 的性能和扩展性是以提高写入速度为目标的，它优化了数据插入和更新的效率，而 Elasticsearch 的性能和扩展性是以提高读取速度为目标的，它优化了数据检索和分析的效率。

使用场景

MySQL 和 Elasticsearch 适用于不同的使用场景，根据不同的业务需求，可以选择合适的数据库系统或组合使用两者。以下是一些常见的使用场景：

• 如果需要存储结构化或半结构化的数据，并且需要保证数据操作的正确性和完整性，可以选择 MySQL 作为主要数据库系统。例如，电商网站、社交网络、博客平台等。


• 如果需要存储非结构化或多样化的数据，并且需要支持复杂的全文检索和相关度评分，可以选择 Elasticsearch 作为主要数据库系统。例如搜索引擎、日志分析、推荐系统等。


• 如果需要存储和分析大量的时序数据，并且需要支持实时的聚合和可视化，可以选择Elasticsearch作为主要数据库系统。例如，物联网、监控系统、金融市场等。


• 如果需要同时满足上述两种需求，并且可以容忍一定程度的数据不一致或延迟，可以将 MySQL 作为主数据库系统，并将部分数据同步到 Elasticsearch 作为辅助数据库系统。例如新闻网站、电影网站、招聘网站等。

自此本文讲解内容到此结束，感谢您的阅读，希望本文对您有所帮助。

效果

预览地址 code.juejin.cn/pen/7272286…

前言

刚好看到这么一个东西，甘特图，然后又发现好像echarts 里面没有这个图形渲染，也去找了一下插件，都不符合我的要求，然后自己就想着看能不能实现一个，然后说干就干，过程还挺复杂的，不过一想清楚了，也就还行。

逻辑

刚开始看着这个图，想到肯定是用表格来实现的，后面开始渲染的时候，发现是我想简单了，这表格是渲染不出来的，也或者是我技术还没够，反正我找了很多相关的插件，都不是用表格去实现的，后面就改变了一些思路，用div去渲染，然后去定位，这么一想，发现事情就简单了许多。

为什么不用表格实现

每点击一个视图切换，表头就需要重新渲染，表头有索引，名称，负责人，如果是表格实现的话，就是如下代码，一看就知道了id=“tableYear”的不好渲染，因为上面有可能是年，也有可能是月，所以肯定是有循环的，但如果一循环，它们没有共同的父容器，怎么渲染呢，也想过表格里面套表格，但那样，样式又实现不了我要的效果。

 <table>

    <thead>

        <tr>

            <th rowspan="2">id</th>

            <th rowspan="2">任务名称</th>

            <th rowspan="2">负责人</th>

            <th colspan="4" id="tableYear">2023-8</th>

        </tr>

        <tr id="tableDay">

            <th>1</th>

            <th>2</th>

            <th>3</th>

            <th>4</th>

        </tr>

    </thead>

</table>

第一个难点

日期渲染，因为我这表头是动态的，所以要复杂一些，有天数，月数，季度和年度显示的

点击日视图，就是按天去显示任务，月视图就是按月去显示任务，季视图和年视图同理，
比如说日视图，
先获取当前日期，年月日，然后是想渲染前后几年的

var currentDate=new Date;//当前日期

var currentYear = currentDate.getFullYear();//当前年份



var yearRange = 1; // 前后1年

var startDate = currentYear - yearRange;//前1年

var endDate = currentYear + yearRange;//后1年

var today = currentDate.getDate(); // 获取今天是几号

var currentYear = currentDate.getFullYear();//年

var currentMonth = currentDate.getMonth();//月

var displayedYears = {}; // 用于记录已显示的年份

开始渲染第一排是年月，一年的月份是固定的，所以都是可以写死的，这里有要注意一下的是，就是年月的宽度，因为要根据当月有多少天去计算宽度，所以我要知道，这一年这一月是多少天然后乘以40 下面是相关代码

for (var year = startDate; year <= endDate; year++) {

    for (var month = 0; month < 12; month++) {

        var lastDay = new Date(year, month + 1, 0).getDate();

        var monthElement = $("<p>" + (month + 1) + "月: </p>"); // 创建表示月份的 <p> 元素



        for (var day = 1; day <= lastDay; day++) {

            dateRange.push(new Date(year, month, day));

        }

        // 在 .tableYear 中添加年份和月份信息

        var yearMonthStr = year + "-" + (month + 1 < 10 ? "0" : "") + (month + 1);

        var width = (lastDay * 40)-1 + "px"; // 计算宽度

        $(".tableYear").append($("<p class='Gantt-table_header' style='width: " + width + "'>" + yearMonthStr + "</p>"));

    }

}

渲染完成，年月以后就是日，我这里也做了一些小的显示，比如说周末深颜色表示，今天也深颜色表示，并且视图要显示在当前，而不是在2022-1-1号这里。

天数渲染

for (var i = 0; i < dateRange.length; i++) {

    var currentDate = dateRange[i];

    var dayNumber = currentDate.getDay(); // 获取星期几 (0 = 星期日, 1 = 星期一, ...)

    var isWeekend = dayNumber === 0 || dayNumber === 6;

    var dayText = currentDate.getDate();//获取日

    var dayYear = currentDate.getFullYear(); // 获取年份

    var dayMonth = currentDate.getMonth(); // 获取月份（注意：月份是从 0 到 11，0 表示一月，11 表示十二月）

    var tableCell = $("<p>" + dayText + "</p>");

    if (isWeekend) {

        tableCell = $("<p class='Gantt-table_weekend'>" + dayText + "</p>");

    }

    //获取当前时间的年月日，与循环出来的年月日进行循环匹配，

    if (dayText === today && dayYear === currentYear && dayMonth === currentMonth ) {

        tableCell.addClass("today");

    }

    $(".tableDay").append(tableCell);

}

视口显示代码

 // 将视口滚动到今天所在的位置

var todayElement = $(".today");

if (todayElement.length > 0) {

    var viewportHeight = window.innerHeight || document.documentElement.clientHeight;

    var elementHeight = todayElement[0].clientHeight;



    var offset = (viewportHeight - elementHeight) / 2;

    //平滑滚动参数 smooth  auto不滚动

    todayElement[0].scrollIntoView({ behavior: 'auto', block: 'center', inline: 'center' });

}   

第二个难点

如果不用表格，怎么去实现这个网格呢，刚开始是想着去渲染，表格对应有多少天，就渲染有多少个p标签，但一想这怎么行，如果任务很多，一条任务就要渲染上千个p标签，太浪费资源了，任务一多，那不直接挂壁。
后面在css里面找到了解决办法

background: repeating-linear-gradient(to right, rgb(221, 221, 221), rgb(221, 221, 221) 

1px, transparent 1px, transparent 40px) 0% 0% / 40px 100%;

ChatGPT是这样解释的

然后完美解决问题，不用渲染这么多，一个任务一个div就可以了。

第三个难点

甘特图的核心，那个柱状图的东西。

柱状图渲染，比如说我提了一个任务，是2023年8月20号开始的，然后到2023年8月25号要完成，那这样就只有五天时间，那渲染肯定是从2023年8月20号开始的，然后到8月25号结束。

我的思路是这样的，显示的宽度是五天，然后一天的宽度是40px，那么这个任务的总宽度就是200px，然后定位，获取到这个任务开始的时候，我这里显示是前后一年的也就是2022-1-1号开始的，然后相减，知道中间相差了多少天，然后再乘以40，得到left的距离，就实现了这个效果。后面的描述也是类似的效果，这样甘特图差不多就完成了。下面是日期相减代码

 function getOffsetDays(startDate, endDate){

    var startDateArr = startDate.split("-");

    var checkStartDate = new Date();

    checkStartDate.setFullYear(startDateArr[0], startDateArr[1], startDateArr[2]);

    var endDateArr = endDate.split("-");

    var checkEndDate = new Date();

    checkEndDate.setFullYear(endDateArr[0], endDateArr[1], endDateArr[2]);

    var days = (checkEndDate.getTime() - checkStartDate.getTime())/ 3600000 / 24;

    if(startDateArr[0]!=endDateArr[0]){

        flag = true;

    }

    return days;

}

结语

虽然三言两语就讲解完了，但其中还是有很多逻辑的问题，我只是讲解了一下我的一个实现的思路，居体代码请看这。

以上就是本篇文章的全部内容，希望对大家的学习有所帮助，以上就是关于无插件实现一个好看的甘特图的详细介绍，如果有什么问题，也希望各位大佬们能提出宝贵的意见。当然也有很多需要优化的地方，我这只是给了一个思路，你们可以去实现很多的功能。

最近快过年了，和还留在成都的一些研究生同学吃了顿饭，其中博士姐姐因为今年刚刚毕业，所以在饭局里面还跟我们谈了一下今年的师弟师妹们的去向。

她说今年虽然就业挺难的，但是师弟师妹们的工作还都挺好的，有去成飞的，有去选调的还有去了一些大国企研究所的。然后我就问今年没有去互联网的吗？她说有哇，有学弟去了美团，钱还开得挺多的，有学弟去了个独角兽做算法，但是也就这两个人去了互联网相关的了。

其实听到这个我还是蛮感慨的，在我毕业的时候互联网还是如日中天，大多数计算机毕业的孩子首选的就是去互联网狠狠的大赚一笔。短短3年间，去互联网的应届生就屈指可数了，一方面是这两年互联网大厂缩招严重，进互联网没有我们当年那么容易。另一方面是，在大环境不容乐观的今天，以及互联网增长见顶的背景下，互联网的工作其实已经不是应届生的首选工作了。

实际上，即使在今年你能过千军万马杀出重围拿到互联网的offer，作为一个过来人我也不是很建议你再去趟互联网这趟浑水。因为，作为一个新人在一个注定下行的行业当中，你可能搭上的不是通往财富自由的快车道，很快你需要考虑的可能就是你还能不能保住你手头的这份工作的问题。

说一个老生常谈的事情，互联网的增长确实见底了，阿里、腾讯、网易的股票最近狂跌，阿里都跌回2014年了，只有抖音还依然坚挺一些但是依然看不到未来成长的空间。从2014年到2024年，正好十年的时间，互联网员工们加班加点996，熬夜爆肝的奋斗，最终的结果尽然是回到了原点。

其实，这个事情也并不奇怪，这些互联网大厂只是坐在电梯里面的人，他们都觉得自己能够取得成功是因为自己在电梯里面做俯卧撑。实际上，跟你在电梯上做啥没有关系，你之所以能够成功只是因为你恰好赶上了这班电梯而已，跟你在里面睡觉还是瞎折腾关系都不大。如今风停了，电梯开始往下走了，作为个体你非要去搭上这个末班车并且期待在踩在早就已经上电梯的这群人的头上的话，那么我只能跟你说，祝你好运了。

其实，作为一名应届生的时候我对职场也没有清醒的认识，以为职场上的同事和学校的同学一样大家和和气气不争不抢的。但是，正是抱着这样的心态我入职了互联网之后的短短一年时间内，才深刻感受到了社会的毒打和职场真实的样貌。所以，我不知道在学校的应届生们有没有做好准备在互联网面对全方位的竞争，这种竞争不仅仅是技术，不仅仅是加班，更是向上管理和领导处理好关系。和国企、外企、体制内不一样，互联网的大多数公司是有强制末尾淘汰的，有些公司甚至连新人保护期都没有，那么你觉得你作为一个活蹦乱跳的应届生，这个名额是老油条扛呢还是你呢？

另外，以前的人扎堆朝互联网冲是因为真的有财富自由的机会的，那时候啥app都没有，张小龙找几个应届生关小黑屋都能写出未来的国民级app微信。16年的字节也还是个小公司，那时候往互联网里面冲的话搞不好真的可以一年能够赚到别人一辈子赚不到的钱，所以去互联网真是一点儿问题都没有。你那时候不去互联网我都会拿着鞭子抽你，劝你上进一点儿！但是都2024年了，市场永远比个人知道一个方向的未来，还是那句话你想创业互联网都拉不到风投的年代，你还能奢望能够实现财富自由吗？

The End

其实作为一名程序员还是挺享受写有趣代码的过程的，也希望做一点儿东西能够被大家认可，所以我劝退互联网但是并不是劝退计算机。

即使是Chatgpt大行其道的今天，我也不认为未来某一天机器能够真正意义上取代程序员，要取代也是从另外一个维度上取代，比如说根据需求直接生成机器码而不是生成代码的这种形式。虽然互联网是一片红海，但是像新的技术VR、物联网、工业软件、芯片和智能机器人等行业，在我们国家还是蕴含着无限机会的。但是，我并不认为去到我上面所说的这些行业工资收入上能够超过现在的互联网大厂给出的工资，我的意思真的有想法的人可以尝试在这些领域去找到自己的一席之地，尤其是在校学生。

你去卷一个注定下山的行业无论它钱给多少都是毫无意义的，因为入职就可能就是你职业生涯的巅峰。相比起来，我觉得华子未来比这些靠着广告赚钱的公司都更有前景，因为是真的有一些核心技术在的。

所以，选择一个还没有走过巅峰的行业，提前布局才是更有未来的职业选择。

人在江湖身不由己，无论是领导的亲信还是团队的边缘，都可能遇到这种情况———不得不干一件特别难以推进的事情，茫然无措，不知如何推进。每天陷入焦虑和自我怀疑中……

这种事情一般有一些共同特点。

领导往往是拍脑袋提想法，他们也不知道具体如何执行。反过来说，如果领导明确知道怎么做，能亲自指导技术方案、亲自解决关键问题，那问题就好办了，只要跟着领导冲锋陷阵就好了，就不存在烦恼了。

遇到这种棘手的事情，如果自己被夹在中间，真的非常难受啊！

今天重点聊聊领导拍脑袋、心血来潮想做的那些大事 如果让你摊上了，你该怎么做！

1、提高警惕！逆风局翻盘难！

互联网行业目前处于稳定发展期，很少会出现突然迅猛增长的业务，也很少有公司能够迅速崛起。这是整个行业的大背景。因此，我们应该对任何不确定或模糊的目标表示怀疑，因为它们更有可能成为我们的绊脚石，而不是机遇。即使在王者荣耀这样的游戏里，要逆风翻盘也很困难，更何况在工作中呢。

当领导提出一个棘手的问题时，我们应立刻警惕，这可能不是一个好的机会，而是一个陷阱。我们不应该被领导画的饼所迷惑，而是要冷静客观地思考。哪些目标和结果是难以达到的，这些目标和结果就是领导给我们画的大饼！

领导给出任务后，我们就要努力完成。通常情况下，他们会给我们一大堆任务，需要我们确认各种事情。简而言之，他们只是有个想法，而调研报告和具体实施方案就需要我们去做。

如果领导是一位优秀而谦虚的人，通常在我们完成调研后，会根据调研结果来判断这个想法是否可行。如果不可行，他们会立即放弃，而我们也不会有什么损失。

但是，一旦领导有了一个想法，肯定是希望我们来完成的，即便我们在调研后认为不可行，大多数情况下，他们也不会接受我们的结论！因此，我们的调研工作必须极度认真，如果我们认为不可行，就要清楚地阐述不可行的理由，要非常充分。

这是我们第一次逃离的机会，我们必须重视这次机会，并抓住机会。

2、积极想办法退出

对于这种模糊不靠谱的事情，能避开就避开，不要犹豫。因为这种事情往往占用大量时间，但很难取得显著的成果。对于这种时间周期长、收益低、风险高的事情，最好保持距离。

你还需要忍受巨大的机会成本

在你长期投入这种事情的过程中，如果团队接到更好的项目和需求，那肯定不会考虑你。你只能羡慕别人的机会。

因此，如果可以撤退的话，最好离开这种费力不讨好的活远远的！

子曰：吾日三省吾身，这事能不能不干，这事能不能晚点干，这事能不能推给别人干。

如何摆脱这件事呢？

2.1 借助更高优事情插入，及时抽身

例如，突然出现了一件更为紧急的事情，这就是脱身的机会。与此同时，我们也可以为领导保留一些颜面，因为随着工作的进展，领导也会意识到这件事情的意义不大，很难取得实质成果。但是，如果我们一开始就表示不再继续做这件事，那么领导可能会觉得自己的判断出了问题，失去面子。所以，我们可以寻找一个时机，给领导下台阶。

或者，突然出现了一个需求，与我们目前的重构方案存在冲突。这是一个很好的借口。重构方案和未来产品规划产生了冲突，我们应优先满足产品规划和需求。重构方案需要后续再次评估，以找到更好的解决方案。

2.2 自己规划更重要的事情，并说服领导

当你对系统优化没有想法时，不要怪领导给你找事干。

如果领导有一个系统重构的计划和目标需要你执行，但是你不想干，或者你认为这件事不靠谱。那么你可以思考一个更可行、更有效、更能带来收益的重构方案，并与领导进行汇报。如果领导认为你的计划更加重要且更具可行性，那他可能会放弃自己的想法。

这就是主动转被动的策略。这时你的技术能力将接受考验，你能提出一个更优秀的系统重构方向吗？你能提出一个更佳的系统建设方向吗？

2.3 选择更好的时机做这件事

如果领导让你去做技术重构，而这件事的优先级不如产品需求高，上下游团队也不愿意配合你，而且领导给你的人力和时间资源也不够充裕，你应该怎么办呢？可以考虑与产品需求一起进行技术重构。也就是说，边开发需求，边进行技术重构。这样做有以下好处：可以借助于产品的力量，很自然地协调上下游团队与你一同进行重构。同时也能推动测试同事进行更全面的测试。在资源上遇到的问题，也可以让产品帮助解决。

所以，技术重构最好和产品需求结合起来进行。如果技术重构规模庞大，记得一定要分阶段进行，避免因技术重构导致产品需求延期哦。

2.4 坦诚自己能力不足，暂时无法完成这件事，以后再干行不行

可以考虑向领导坦然承认自己的能力还不足以立即执行这项任务，因此提出先缓一缓，先熟悉一下这个系统的建议。我可以多做一些需求，以此来熟悉系统，然后再进行重构。

我曾经接手一个系统，领导分配给我一个非常复杂的技术重构任务。当时我并没有足够聪明，没有拒绝，而是勉强去做，结果非常不理想，还导致了线上P0级别的事故发生！

新领导告诉我，"先想清楚如何实施，再去行动。盲目地勉强上阵只会带来糟糕的结果。当你对一个系统不熟悉的时候，绝对不能尝试对其进行重构。"

先熟悉系统至少三个月到半年。再谈重构系统！

2.5 拖字诀，拖到领导不想干这件事！

拖到领导不想干的时候，就万事大吉了。

注意这是最消极的策略，运气好，拖着拖着就不用干了。但如果运气不佳，拖延只会让任务在时间上更加紧迫，而且还会招致领导的不满。

使用拖延策略很可能得罪领导，给他们留下不良的印象。

因此，在使用此策略时应谨慎行事！

2.6 退出时毫不犹豫，不要惋惜沉默成本

如果有撤退的机会，一定不要犹豫，不要为自己付出的投入感到遗憾，不要勉强继续前进，也不必试图得到明确的结果。错误的决策只会带来错误的结果。一定要及时止损。

因为我曾经犯过类似的错误，本来有机会撤退，但是考虑到已经付出了很多，想要坚持下去。幸好有一位同事更加冷静，及时制止了我。事后我反思，庆幸及时撤退，否则后果真的不敢想象啊。

3、适当焦虑

每个人都喜欢做确定性的事情，面对不确定的事情每个人都会感到焦虑。为此可能你每天都很焦虑，甚至开始对工作和与领导见面感到厌恶。之所以这个事情让你感到不适，是因为它要求你跳出舒适区。

但是，请记住，适度的焦虑是正常的。告诉自己，这并没有什么大不了的。即使做得不好，顶多被领导责备一下而已。不值得让生活充满焦虑，最重要的是保持身心健康和快乐。

当你沉浸在焦虑中时，可能会对工作和领导感到厌烦。这样一来，你可能会对和领导沟通感到反感。这种情况是可怕的，因为你需要不断和领导沟通才能了解他真正的意图。如果失去了沟通，这个事情肯定不会有好的结果。

因此，一定要保持适度的焦虑。

3.1 沟通放在第一位

面对模糊的目标和结果，你需要反复和领导沟通，逐步确认他的意图。或者在沟通中，让领导他自己逐渐确定的自己的意图。在这方面有几个技巧~

3.2 直接去工位找他

如果在线上沟通，领导回复可能慢，可能沟通不通畅。单独约会议沟通，往往领导比较忙，没空参加。所以有问题可以直接去工位找他，随时找他沟通问题。提高效率

3.3 没听懂的话让领导说清楚

平常时候领导没说清楚，无所谓，影响不大。例如普通的产品需求，领导说的不清楚没关系，找产品问清楚就行。

面对目标不明确的项目，领导的意图就十分重要。因为你除了问领导，问其他人没用。领导就是需求的提出方，你不问领导你问谁。 在这种情况下，没听懂的事情必须要多问一嘴。把领导模糊的话问清楚。

不要怕啰嗦，也不要自己瞎揣摩领导的意图。每个人的想法都不同，瞎猜没用。

3.4 放低姿态

如果领导和你说这件事不用干了，你肯定拍手叫好。很多烦恼，领导一句话，就能帮你摆平！

放低姿态就是沟通时候，该叫苦叫苦，该求助就求助，别把自己当成超人，领导提啥要求都不打折扣的行为完全没必要。可以和领导叫叫苦，可以活跃气氛，让领导多给自己点资源，包括人和时间。

说白了，就是和 领导 “撒娇”。这方面女生比较有优势，男生可能拉不下脸。之前的公司，我真见识过，事情太多，干不完，希望领导给加人，但被领导拒绝。 然后她就哭了，最后还真管用！是个女同事。

男孩子想想其他办法撒娇吧。评论区留下你们的办法！

3.5 维护几个和领导的日常话题

平常如果有机会和领导闲聊天，一定不要社交恐惧啊！ 闲聊天很能提升双方的信任关系，可以多想想几个话题。例如车、孩子、周末干啥、去哪旅游了等等。

提升了信任关系，容易在工作中和领导更加融洽。说白了就是等你需要帮忙的时候，领导会多卖你人情！

4 积极想替代方案————当领导提的想法不合理时

积极寻求替代方案，不要被领导的思路局限！引导众人朝着正确的方向前进！

不同领导的水平和对技术问题的认知不尽相同，他们注重整体大局，而员工更注重细节。这种差异导致了宏观和微观层面之间存在信息不对称，再加上个人经验、路径依赖导致的个人偏见，使得领导的想法不一定正确，也不一定能够顺利实施。

就我个人的经历来说，领导要求我进行一次技术重构。由于我对这个项目还不够熟悉，所以我完全按照领导的方案去操作，没有怀疑过。事后回顾，发现这个方案过于繁重，其实只需要调整前端接口就能解决问题，但最终我们却对底层数据库存储、业务代码和接口交互方式进行了全面改变。

最终收益并不高，反而导致了一个严重的故障。既没有获得功劳，也没有得到应有的认可。

事后反思，我意识到我不应该盲目按照领导的方案去执行，而是应该怀着质疑和批判的态度去思考他的方案。多寻求几个备选方案，进行横向比较，找到成本最低、实施最简单的方案。

4.1 汇报材料高大上，实现方案短平快

私底下，可以对老板坦诚这件事，就是没什么搞头。但是对外文章要写得高大上！

技术方案要高大上，实现方案要短平快。

面对不确定的目标、面对不好完成的任务，要适当吹牛逼和画饼。汇报文档可以和实现方案有出入。

模糊的目标，往往难以执行和完成，技术方案越复杂，越容易出问题。本来就没什么收益，还引出一堆线上问题，只能当项目失败的背锅侠，得不偿失。

一定要想办法，把实现方案做的简单。这样有3个好处；

程序员一般情况下习惯于实话实说，如果说假话，一定是被人逼得。

不会写文档？# 写文档不用发愁，1000个互联网常用词汇送给你

不会写技术方案？# 不会画图? 17 张图教你写好技术方案！

5、申请专门的团队攻克难关！

例如重构系统涉及到上下游系统，一个人搞不定的！要向领导寻求帮助，让上下游同事一起干这件事。

让熟悉系统的人跟自己一起做，拉更多的人入伙！多个人一起承担重任！ 这种组织上的安排，只能由领导出面解决。

假如别的同事经常打扰你，总让你确认这件事，确认那件事，总让你帮忙梳理文档，你愿意配合吗？ 每个人都很忙，没人愿意长期给你干活。

让领导帮忙成立重构小组！然后你可以给每个人都分派任务，比自己独自硬扛，成功概率大很多。

虽然重构的目标不明确，但你可以尝试明确每个人的责任，设置短期的里程碑。例如前三天梳理整理资料，每天开早会， push大家干活。（这样很招人恨！没办法，领导卷的）

5.1 寻求合作的最大公约数

重大项目往往需要多个团队同时配合，即便你申请了专门的小组跟进这件事，但是别人可能出工不出力！

他们不配合的原因在于：不光没有收益，付出还很多。成本和收益不对等，人家不愿意很正常。保持平常心！不要带着脾气看待这件事！

略微想一下就明白，既然你觉得这件事风险高、收益低，难道其他人看不出来吗？

作为项目的负责人推动事情更加困难。当别人不配合时，除了把矛盾上升到上层领导外，还有哪些更好的办法呢？

总之，涉及多个团队合作时，除了依靠上层领导的强硬干预之外，还要想一些合作共赢的方案！

6、争取更多的资源支持

没有完不成的事情，只要资源充裕，任何事情都是有希望的。当你面临棘手的问题时，除了打起12分的精气神，还要多想想和领导申请资源啊！

最重要的包括人力资源、时间资源。如果空口白牙就要人，可能比较困难。

这需要你在调研阶段深入思考，预想到系统的挑战点，把任务细分，越细越好，然后拿着排期表找领导，要人、要时间。

如果人和时间都不给！可以多试几次，软磨硬泡也是好办法！

此外还有别的办法，例如 ”偷工减料"。你可以和领导沟通，方案中哪些内容不重要，是否可以砍掉。”既然你不给人，砍掉不重要的部分，减少工作量，总可以吧"

除此之外，还可以考虑分期做。信用卡可以分期付款，技术重构当然也可以分期优化！

7、能分期就分期

对于技术重构类工作，一定要想办法分期重构，不要一次性只求大而全！

分期的好处自不必说，在设计方案时一定要想如何分期完成。

如果对一个系统不熟悉，建议分期方案 先易后难！先做简单的，逐渐地你对系统会有更深入的理解！

如果对一个系统很熟悉，可以考虑先难后易。先把最困难的完成！后面会轻松很多！

但是我还是建议庞大的重构工作，先易后难！先做简单的，拖着拖着，也许就不需要重构了呢！

8、即便没有功劳但是要收获苦劳

当一件事干成很难的时候，要想办法把损失降到最低。一定要想着先保护自己！别逞能！

工作几年的朋友应该知道，不是所有的项目都能成功！甚至大部分项目在商业上是失败的！做不成一件事很正常！

如果一件事很难办成，功劳就不要想了。但是可以赚一份苦劳。

这要求你能把自己的困难说给领导，例如其他团队不配合！你可以一直和领导反馈，并寻求领导的帮助。

日常工作的内容也要有文档留存。工作以周报形式单独和领导汇报！要让领导知道你每周的进展，向领导传递一个事实：“每一周你都努力地在做事，并且也都及时汇报了，日后干不成，可别只怪我一人啊！”

接到一个烫手山芋，处理起来很难~ 斗智斗勇，所以能躲开还是躲开啊！

9、转变观念：放弃责任心，领导关注的内容重点完成

出于责任心的角度，我们可能认为领导提出的方案并不正确，甚至认为领导给自己派的工作完全没有意义。

你可能认为领导的Idea 不切合实际！

出于责任心，你有你的想法，你有你的原则！你认为系统这样重构更适合！但那又怎样，除非你有足够的理由说服领导，否则改变不了什么。

站在更高的位置能看的更远，一般领导都会争取团队利益最大化。虽然看起来不切实际，但是努力拼一拼，也许能给团队带来更大的利益。这可能是领导的想法！说白了，就是领导想让团队多去冲锋陷阵，多把一些不可能变成可能！

和领导保持节奏，领导更关注哪件事，就尽力把这件事做好！ 放弃自己所谓的“责任心”。

10、挑战、机遇、风险并存。

在互联网稳定期，各行各业都在内卷，公司内部更是在内卷！

在没有巨大增量的团队和公司里，靠内卷出成绩是很困难的事情。有时候真的很绝望，每一分钟都想躺平 。

像这种目标不明确、执行方案不明确、结果不明确、需要协调其他团队干活的难事越来越多！风险高、低收益的事情谁都不想干！

但是一旦能做成，对于个人也是极大地锻炼。所以大家不要一味地悲观，遇到这种棘手的事情，多和领导沟通，多想想更优的解决方案。也许能走出一条捷径，取得极大的成果~

0. 引言

es的java客户端不太友好的语法一直饱受诟病，书写一个查询语句可能需要书写一大串的代码，如果能像mybatis--plus一样，支持比较灵活方便的语句生成器那就好了。

于是为elasticsearch而生的ORM框架Easy-Es诞生了，使用及其方便快捷，今天我们就一起来学习easy-es，对比看看原生java-client方便之处在哪儿。

1. Easy-Es简介

Easy-Es是以elasticsearch官方提供的RestHighLevelClient为基础，而开发的一款针对es的ORM框架，类似于es版的mybatis-plus，可以让开发者无需掌握es复杂的DSL语句，只要会mysql语法即可使用es，快速实现es客户端语法

官方文档：http://www.easy-es.cn/

2. Easy-Es使用

1、引入依赖

<!-- 引入easy-es最新版本的依赖-->

        <dependency>

            <groupId>org.dromara.easy-es</groupId>

            <artifactId>easy-es-boot-starter</artifactId>

            <version>2.0.0-beta3</version>

        </dependency>



        <!-- 排除springboot中内置的es依赖,以防和easy-es中的依赖冲突-->

        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-web</artifactId>

            <exclusions>

                <exclusion>

                    <groupId>org.elasticsearch.client</groupId>

                    <artifactId>elasticsearch-rest-high-level-client</artifactId>

                </exclusion>

                <exclusion>

                    <groupId>org.elasticsearch</groupId>

                    <artifactId>elasticsearch</artifactId>

                </exclusion>

            </exclusions>

        </dependency>

        <dependency>

            <groupId>org.elasticsearch.client</groupId>

            <artifactId>elasticsearch-rest-high-level-client</artifactId>

            <version>7.14.0</version>

        </dependency>

        <dependency>

            <groupId>org.elasticsearch</groupId>

            <artifactId>elasticsearch</artifactId>

            <version>7.14.0</version>

        </dependency>

2、添加配置项，这里只配置了几个基本的配置项，更多配置可参考官网文档：easy-es 配置介绍

easy-es: 

  # es地址、账号密码

  address: 192.168.244.11:9200

  username: elastic

  password: elastic

3、在启动类中添加es mapper文件的扫描路径

@EsMapperScan("com.example.easyesdemo.mapper")

4、创建实体类，通过@IndexName注解申明索引名称及分片数， @IndexField注解申明字段名、数据类型、分词器等，更多介绍参考官方文档：essy-es 注解介绍

@IndexName(value = "user_easy_es")

@Data

public class UserEasyEs {



    @IndexId(type = IdType.CUSTOMIZE)

    private Long id;



    private String name;



    private Integer age;



    private Integer sex;



    @IndexField(fieldType = FieldType.TEXT, analyzer = Analyzer.IK_SMART, searchAnalyzer = Analyzer.IK_SMART)

    private String address;



    @IndexField(fieldType = FieldType.DATE, dateFormat = "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis")

    private Date createTime;



    private String createUser;



}

5、创建mapper类，继承BaseEsMapper类，注意这里的mapper一定要创建到第3步中设置的mapper扫描路径下com.example.easyesdemo.mapper

public interface UserEsMapper extends BaseEsMapper<UserEasyEs> {

}

6、创建controller，书写创建索引、新增、修改、查询的接口

@RestController

@RequestMapping("es")

@AllArgsConstructor

public class UserEsController {



    private final UserEsMapper userEsMapper;



    /**

     * 创建索引

     * @return

     */

    @GetMapping("create")

    public Boolean createIndex(){

        return userEsMapper.createIndex();

    }



    @GetMapping("save")

    public Integer save(Long id){

        UserEasyEs user = new UserEasyEs();

        user.setId(id);

        user.setName("用户"+id);

        user.setAddress("江苏省无锡市滨湖区");

        user.setAge(30);

        user.setSex(1);

        user.setCreateUser("admin");

        user.setCreateTime(new Date());

        Long count = userEsMapper.selectCount(EsWrappers.lambdaQuery(UserEasyEs.class).eq(UserEasyEs::getId, id));

        if(count > 0){

            return userEsMapper.updateById(user);

        }else{

            return userEsMapper.insert(user);

        }

    }



    @GetMapping("search")

    public List<UserEasyEs> search(String name, String address){

        List<UserEasyEs> userEasyEs = userEsMapper.selectList(

                EsWrappers.lambdaQuery(UserEasyEs.class)

                        .eq(UserEasyEs::getName, name)

                        .match(UserEasyEs::getAddress, address)

                );

        return userEasyEs;

    }



}

7、分别调用几个接口

• 创建索引
  
  kibana中查询索引，发现创建成功
  


• 新增接口
  这里新增了4笔
  
  数据新增成功
  


• 数据查询

如上便是针对easy-es的简单使用，这里的用法都与mp类似，上手相当简单，不用再写那些复杂的DSL语句了

3. 拓展介绍

• 条件构造器

上述演示，我们构造查询条件时，使用了EsWrappers来构造条件，用法与mp及其类型，大家根据提示就可以推导出方法如何书写，更详细的使用说明可以查看官方文档：easy-es 条件构造器介绍

• 索引托管

如果想要自动根据创建的es实体类来创建对应的索引，那么只需要调整索引的托管模式为非手动模式即可，因为这里我不需要自动同步数据，所以选择非平滑模式

easy-es:

  global-config:

    process_index_mode: not_smoothly

其中三种模式的区别为：
平滑模式：smoothly，索引的创建、数据更新迁移等都由easy-es自动完成
非平滑模式：not_smoothly，索引自动创建，但不会自动迁移数据
手动模式：manual，全部操作由用户手动完成，默认模式

• 数据同步

如果数据源是来自mysql, 那么建议使用canal来进行同步，canal的使用可在我主页搜索。
其次还有DataX, Logstash等同步工具，当然你也可以使用easy-es提供的CRUD接口，来手动同步数据

• 日志打印

通过开启日志，可以在控制台打印执行的DSL语句，更加方便我们在开发阶段进行问题排查

logging:

  level:

   tracer: trace # 开启trace级别日志,在开发时可以开启此配置,则控制台可以打印es全部请求信息及DSL语句,为了避免重复,开启此项配置后,可以将EE的print-dsl设置为false.

• 聚合查询
  easy-es实现的聚合查询，只要是针对gr0up by这类聚合，也就是es中的Terms aggregation，以及最大值、最小值、平均值、求和，而对于其他类型的聚合，还在不断更新中，但这里大家也需要了解，es的聚合和mysql的聚合完全是不一样的维度和复杂度，es支持非常多的聚合查询，所以其他类型的实现还需要借助RestHighLevelClient来实现

我们利用easy-es来实现下之前书写的聚合案例

@RestController

@AllArgsConstructor

@RequestMapping("order")

public class OrderEsController {



    private final OrderTestEsMapper orderEsMapper;



    @GetMapping("search")

    public String search(){

        SearchResponse search = orderEsMapper.search(EsWrappers.lambdaQuery(OrderTest.class).groupBy(OrderTest::getStatus));



        // 包装查询结果

        Aggregations aggregations = search.getAggregations();

        Terms terms = (Terms)aggregations.asList().get(0);

        List<? extends Terms.Bucket> buckets = terms.getBuckets();

        HashMap<String,Long> statusRes = new HashMap<>();

        buckets.forEach(bucket -> {

            statusRes.put(bucket.getKeyAsString(),bucket.getDocCount());

        });

        System.out.println("---聚合结果---");

        System.out.println(statusRes);

        return statusRes.toString();

    }

}

可以看到实际上的查询语句就一行，而其他的都是对返回结果的封装，因为es本身返回的数据是封装到嵌套的对象中的，所以我们需要对其进行包装

对比原始的查询语句，其易用性上的提升还是很明显的

4. 总结

至此对easy-es的介绍就结束了，可以看到如果是针对es实现CRUD上，easy-es表现出非常好的便捷性，而在复杂的聚合查询中，仍然还有进步空间，目前还需要借助RestHighLevelClient，但easy-es的出现，为未来提供更好用的ES ORM框架，提供了希望和方向

文中演示代码见：gitee.com/wuhanxue/wu…

背景 (书接上回)

• ui妹子的无理要求，我通通满足了。但是不出意外的话，意外就出来了。


• 此功能在上线之后，我们的业务在客户app内使用刷脸的时候会因为内存过高导致app将webview杀死。


• 然后我们leader爆了，让我排查问题。可是可是，我哪里会排查内存泄漏呀。


• 我：我不会。你自己不会上吗？你tm天天端个茶，抽个烟，翘个二郎腿，色眯眯的看着ui妹妹。


• 领导：污蔑，你纯粹就是污蔑。我tm现在就可以让你滚蛋，你信吗？


• 我：我怕你个鸟哦，我还不知道你啥水平，你tm能写出来个防抖节流，我就给你磕头。


• 领导：hi～ui妹妹，今天过的好吗，来，哥哥这里有茶喝。（此时ui妹妹路过）。你赶快给我干活，以后ui妹妹留给你。


• 艹！你早这么说不就好了。

开始学习

Chrome devTools查看内存情况

• 打开Chrome的无痕模式，这样做的目的是为了屏蔽掉Chrome插件对我们之后测试内存占用情况的影响


• 打开开发者工具，找到Performance这一栏，可以看到其内部带着一些功能按钮，例如：开始录制按钮；刷新页面按钮；清空记录按钮；记录并可视化js内存、节点、事件监听器按钮；触发垃圾回收机制按钮等

简单录制一下百度页面，看看我们能获得什么，如下动图所示：

从上图中我们可以看到，在页面从零到加载完成这个过程中JS Heap（js堆内存）、documents（文档）、Nodes（DOM节点）、Listeners（监听器）、GPU memory（GPU内存）的最低值、最高值以及随时间的走势曲线，这也是我们主要关注的点

看看开发者工具中的Memory一栏，其主要是用于记录页面堆内存的具体情况以及js堆内存随加载时间线动态的分配情况

堆快照就像照相机一样，能记录你当前页面的堆内存情况，每快照一次就会产生一条快照记录

如上图所示，刚开始执行了一次快照，记录了当时堆内存空间占用为33.7MB，然后我们点击了页面中某些按钮，又执行一次快照，记录了当时堆内存空间占用为32.5MB。并且点击对应的快照记录，能看到当时所有内存中的变量情况（结构、占总占用内存的百分比...）

在开始记录后，我们可以看到图中右上角有起伏的蓝色与灰色的柱形图，其中蓝色表示当前时间线下占用着的内存；灰色表示之前占用的内存空间已被清除释放

在得知有内存泄漏的情况存在时，我们可以改用Memory来更明确得确认问题和定位问题

首先可以用Allocation instrumentation on timeline来确认问题，如下图所示：

内存泄漏的场景

• 闭包使用不当引起内存泄漏


• 全局变量


• 分离的DOM节点


• 控制台的打印


• 遗忘的定时器

1. 闭包使用不当引起内存泄漏

使用Performance和Memory来查看一下闭包导致的内存泄漏问题

<button onclick="myClick()">执行fn1函数button>

<script>

    function fn1 () {

        let a = new Array(10000)  // 这里设置了一个很大的数组对象



        let b = 3



        function fn2() {

            let c = [1, 2, 3]

        }



        fn2()



        return a

    }



    let res = []  



    function myClick() {

        res.push(fn1())

    }

script>

在退出fn1函数执行上下文后，该上下文中的变量a本应被当作垃圾数据给回收掉，但因fn1函数最终将变量a返回并赋值给全局变量res，其产生了对变量a的引用，所以变量a被标记为活动变量并一直占用着相应的内存，假设变量res后续用不到，这就算是一种闭包使用不当的例子

设置了一个按钮，每次执行就会将fn1函数的返回值添加到全局数组变量res中，是为了能在performacne的曲线图中看出效果，如图所示：

• 在每次录制开始时手动触发一次垃圾回收机制，这是为了确认一个初始的堆内存基准线，便于后面的对比，然后我们点击了几次按钮，即往全局数组变量res中添加了几个比较大的数组对象，最后再触发一次垃圾回收，发现录制结果的JS Heap曲线刚开始成阶梯式上升的，最后的曲线的高度比基准线要高，说明可能是存在内存泄漏的问题


• 在得知有内存泄漏的情况存在时，我们可以改用Memory来更明确得确认问题和定位问题


• 首先可以用Allocation instrumentation on timeline来确认问题，如下图所示：

• 在我们每次点击按钮后，动态内存分配情况图上都会出现一个蓝色的柱形，并且在我们触发垃圾回收后，蓝色柱形都没变成灰色柱形，即之前分配的内存并未被清除


• 所以此时我们就可以更明确得确认内存泄漏的问题是存在的了，接下来就精准定位问题，可以利用Heap snapshot来定位问题，如图所示：

• 第一次先点击快照记录初始的内存情况，然后我们多次点击按钮后再次点击快照，记录此时的内存情况，发现从原来的1.1M内存空间变成了1.4M内存空间，然后我们选中第二条快照记录，可以看到右上角有个All objects的字段，其表示展示的是当前选中的快照记录所有对象的分配情况，而我们想要知道的是第二条快照与第一条快照的区别在哪，所以选择Object allocated between Snapshot1 and Snapshot2即展示第一条快照和第二条快照存在差异的内存对象分配情况，此时可以看到Array的百分比很高，初步可以判断是该变量存在问题，点击查看详情后就能查看到该变量对应的具体数据了

以上就是一个判断闭包带来内存泄漏问题并简单定位的方法了

2. 全局变量

全局的变量一般是不会被垃圾回收掉的当然这并不是说变量都不能存在全局，只是有时候会因为疏忽而导致某些变量流失到全局，例如未声明变量，却直接对某变量进行赋值，就会导致该变量在全局创建，如下所示：

function fn1() {

    // 此处变量name未被声明

    name = new Array(99999999)

}



fn1()

• 此时这种情况就会在全局自动创建一个变量name，并将一个很大的数组赋值给name，又因为是全局变量，所以该内存空间就一直不会被释放


• 解决办法的话，自己平时要多加注意，不要在变量未声明前赋值，或者也可以开启严格模式，这样就会在不知情犯错时，收到报错警告，例如

function fn1() {

    'use strict';

    name = new Array(99999999)

}



fn1()

3. 分离的DOM节点

假设你手动移除了某个dom节点，本应释放该dom节点所占用的内存，但却因为疏忽导致某处代码仍对该被移除节点有引用，最终导致该节点所占内存无法被释放，例如这种情况

<div id="root">

    <div class="child">我是子元素div>

    <button>移除button>

div>

<script>

  let btn = document.querySelector('button')

  let child = document.querySelector('.child')

  let root = document.querySelector('#root')

  

  btn.addEventListener('click', function() {

      root.removeChild(child)

  })

script>

该代码所做的操作就是点击按钮后移除.child的节点，虽然点击后，该节点确实从dom被移除了，但全局变量child仍对该节点有引用，所以导致该节点的内存一直无法被释放，可以尝试用Memory的快照功能来检测一下，如图所示

同样的先记录一下初始状态的快照，然后点击移除按钮后，再点击一次快照，此时内存大小我们看不出什么变化，因为移除的节点占用的内存实在太小了可以忽略不计，但我们可以点击第二条快照记录，在筛选框里输入detached，于是就会展示所有脱离了却又未被清除的节点对象

解决办法如下图所示：

<div id="root">

    <div class="child">我是子元素div>

    <button>移除button>

div>

<script>

    let btn = document.querySelector('button')



    btn.addEventListener('click', function() {  

        let child = document.querySelector('.child')

        let root = document.querySelector('#root')



        root.removeChild(child)

    })



script>

改动很简单，就是将对.child节点的引用移动到了click事件的回调函数中，那么当移除节点并退出回调函数的执行上文后就会自动清除对该节点的引用，那么自然就不会存在内存泄漏的情况了，我们来验证一下，如下图所示：

结果很明显，这样处理过后就不存在内存泄漏的情况了

4. 控制台的打印

<button>按钮button>

<script>

    document.querySelector('button').addEventListener('click', function() {

        let obj = new Array(1000000)



        console.log(obj);

    })

script>

我们在按钮的点击回调事件中创建了一个很大的数组对象并打印，用performance来验证一下

开始录制，先触发一次垃圾回收清除初始的内存，然后点击三次按钮，即执行了三次点击事件，最后再触发一次垃圾回收。查看录制结果发现JS Heap曲线成阶梯上升，并且最终保持的高度比初始基准线高很多，这说明每次执行点击事件创建的很大的数组对象obj都因为console.log被浏览器保存了下来并且无法被回收

接下来注释掉console.log，再来看一下结果：

<button>按钮button>

<script>

    document.querySelector('button').addEventListener('click', function() {

        let obj = new Array(1000000)



        // console.log(obj);

    })

script>

可以看到没有打印以后，每次创建的obj都立马被销毁了，并且最终触发垃圾回收机制后跟初始的基准线同样高，说明已经不存在内存泄漏的现象了

其实同理 console.log也可以用Memory来进一步验证

未注释 console.log

注释掉了console.log

最后简单总结一下：在开发环境下，可以使用控制台打印便于调试，但是在生产环境下，尽可能得不要在控制台打印数据。所以我们经常会在代码中看到类似如下的操作：

// 如果在开发环境下，打印变量obj

if(isDev) {

    console.log(obj)

}

这样就避免了生产环境下无用的变量打印占用一定的内存空间，同样的除了console.log之外，console.error、console.info、console.dir等等都不要在生产环境下使用

5. 遗忘的定时器

定时器也是平时很多人会忽略的一个问题，比如定义了定时器后就再也不去考虑清除定时器了，这样其实也会造成一定的内存泄漏。来看一个代码示例：

<button>开启定时器button>

<script>



    function fn1() {

        let largeObj = new Array(100000)



        setInterval(() => {

            let myObj = largeObj

        }, 1000)

    }



    document.querySelector('button').addEventListener('click', function() {

        fn1()

    })

script>

这段代码是在点击按钮后执行fn1函数，fn1函数内创建了一个很大的数组对象largeObj，同时创建了一个setInterval定时器，定时器的回调函数只是简单的引用了一下变量largeObj，我们来看看其整体的内存分配情况吧：

按道理来说点击按钮执行fn1函数后会退出该函数的执行上下文，紧跟着函数体内的局部变量应该被清除，但图中performance的录制结果显示似乎是存在内存泄漏问题的，即最终曲线高度比基准线高度要高，那么再用Memory来确认一次：

• 在我们点击按钮后，从动态内存分配的图上看到出现一个蓝色柱形，说明浏览器为变量largeObj分配了一段内存，但是之后这段内存并没有被释放掉，说明的确存在内存泄漏的问题，原因其实就是因为setInterval的回调函数内对变量largeObj有一个引用关系，而定时器一直未被清除，所以变量largeObj的内存也自然不会被释放


• 那么我们如何来解决这个问题呢，假设我们只需要让定时器执行三次就可以了，那么我们可以改动一下代码：

<button>开启定时器button>

<script>

    function fn1() {

        let largeObj = new Array(100000)

        let index = 0



        let timer = setInterval(() => {

            if(index === 3) clearInterval(timer);

            let myObj = largeObj

            index ++

        }, 1000)

    }



    document.querySelector('button').addEventListener('click', function() {

        fn1()

    })

script>