距我被裁已经过去 34 天了，我还没有去找工作，接下来的一个月大概率也不会找工作，而是打算和老公去西藏旅游一趟，我对一周或者两周后的西藏之旅满是期待。至于老东家，我对他没有怨言，在那儿工作期间很愉快，被裁的时候他爽快的给了 N+1 的赔偿，离职的过程中没有发生不愉快的事情。我写这篇文章不是为了缅怀过去或者反思过去，而是记录我的一天，余下的内容没有华丽的词藻，也没有令人深思的道理，只是流水账。

今天我 7 点 20 就醒了，醒来的前一刻还在做梦，我梦到自己睡不着觉，可想而知那不是一个美梦。醒来的那一瞬间，我甚至没有分辨出是现实还是梦境，头昏昏沉沉的赖了一会儿床，在赖床期间我老公起床了，他洗漱结束的时候，我用手机放了一首歌，他走到床边对我巴拉巴拉说了些话，说的都是些大道理，大概是选择呀未来呀思考呀这一套，如果让我将他的话背下来，可真是在难为我。其实他一大早就讲大道理，我特别不想听，但我觉得他的话有些道理，于是赶紧起了床，洗漱完去跑步。

今天温度不高，早上很适合跑步，估摸着跑了 15 分钟，没有记录跑了多少公里，我打算明天记录一下跑步的公里数。跑完步给手机充了一会儿就出门吃早餐，需要坐两站地铁才能到那家包子铺，我住的地方距地铁站大概 1.5 公里，这段路可以坐小区的摆渡车，但我选择了走路。

那家包子铺叫什么名儿？不记得了，更准确的说，我从来没想过要记住它的名字。我买了两个豇豆包，一个卤鸡蛋还有一杯豆浆。为什么要买这些食物呢？不是没有缘由。昨天我只买了两个豇豆包和一杯豆浆，没有吃饱，于是今天加了一个卤鸡蛋。今天买的这些食物，还是没让我吃饱，明天我要再加一个豇豆包。

为什么要买豇豆包呢？因为我喜欢吃酸豇豆，但是这包子里包的不是酸豇豆，而是新鲜的豇豆，所以第一次吃它的时候它与我的预期不符合，尝了之后又发现新鲜的豇豆也好吃，现在我每次都买豇豆包。今天我看见豇豆包里包的不是豇豆，而是四季豆，四季豆也挺好吃。

这家包子店里能喝的食物除了有豆浆还有稀饭，它的稀饭不是很稀，我担心豇豆包就着稀饭吃不好下咽，于是买了豆浆。

吃了早餐我就回家了，到家的第一件事是联系物业师傅来疏通地漏，还让他们处理电动晾衣架不能升降的问题。关于电动晾衣架，我今天学到了一个新知识，有些人可能会认为那是小常识，不值一提，但我还是要写下来——电池放在遥控器里久了会腐蚀铜板，这将导致遥控器通不了电，遥控器就指挥不了晾衣架，我家的晾衣机不能升降就是这个原因的。

今天我写了两篇技术文章去参加掘金推出的金石计划征文活动，这可以瓜分奖金，这是我第 5 次参加金石计划，每一次都瓜分到了最高奖金，这次我瓜分不到最高奖金了，因为写不出 6 篇原创技术文章。

等物业师傅处理好地漏和晾衣架，发布了文章，我就出发去健身房游泳，健身房离我家有 4.8 公里左右，出发前我在想是开车还是走路，最终选了走路。

今后要做什么？在路上我不由得思考。

今年是我工作的第 6 年，6 年来我断断续续的有考研的想法。为什么想考研呢？在路上我想出了一个原因 —— 源自虚荣心。走着走着想上厕所，路过一家花店，进店问老板附近是否有厕所，他说马路对面有，到了马路对面又向烟酒铺的老板询问厕所的具体位置，如愿的上了厕所，一身轻松。

上完厕所路过一家包子铺，肚子饿了，于是进店买了 2 个包子，1 个鸡蛋还有 1 碗粥，其实我想喝带丝汤，但是卖完了，所以没喝成。

吃完午餐继续往健身房走。哦，我想起在包子铺吃午餐的时候看到了一个皮肤特别好的女生。走呀走呀，终于到了健身房，到那儿之后我没有立即去游泳池，而是去休闲区按摩，在按摩椅上躺着的时候，开始思考我是否想继续当程序员，如果当程序员，想做那方面的业务呢？

我喜欢写作。2021 年期间我写了一部小说，超过 10 万个字，2022 年写我的第一本技术书，上个月才交稿，出版社编辑说稿子问题不大，昨天我根据编辑老师的反馈做了修改，并补充了前言，现在稿件已进入 3 审。我还有一个微信公众号，每个月至少发一篇技术文章。

如果继续当程序员，我想做内容创作类的产品。

按摩完就去游泳，游泳池里只有两个人，除了我还有一个小男孩，他挺可爱的。游完 3 圈我离开游泳池去了桑拿室，那儿只有我一个人，当时我突然想到我还想当程序员，不禁眼睛里有了点泪花。

我很爱哭，被裁后我一个人在家哭了好几次。哭，不是因为被裁，因为以前没被裁的时候，我一个人在家也有哭的时候。桑拿室温度很高，泪花流出来就蒸发了。蒸完桑拿洗完澡打算回家，可是外面在下雨，于是又到按摩椅上躺了一会儿，寻思着等雨停了再回家。第二次按完摩，雨没有停的迹象，我决定淋着雨到外面去打车，16 点到的家，在家吃了一包薯片，看了一会莫言的小说《生死疲劳》，17 点的时候到床上睡觉，18 点的时候才醒，然后到小区门口买了做晚餐的蔬菜，今天晚上煮了面。

这篇文章写了 2 个小时。最后我想说今天还有一件想做的事情没有做成——开车到兴隆湖吹风。

我自己耶

从业10年了，经常在娱文中看到这种的文章，我怀疑是精准推送！！

1. 30岁以上的程序员该何去何从？ - 知乎
   


2. 30岁: 程序员心中永远的痛?
   


3. 过了30岁，程序员该怎么办？ - 阿里云开发者社区
   


4. 30岁转行程序员晚了吗？分享30岁转行的经历 - SegmentFault
   


5. 30岁后“大龄程序员"应该何去何从？ - 脉脉
   


6. 程序员：伤不起的三十岁 - 菜鸟教程
   


7. 程序员迷茫：30岁以上的“大龄程码农”出路在哪？java码 ... - 掘金
   


8. 30岁老程序员迷茫| Laravel - LearnKu
   

关于职场的焦虑无处不在，而这些文章也加重了我们的焦虑。就我个人而言，我也仔细想过这个问题，其实从本质上来说，只是个“竞争力”的问题。

如果你觉得自己没有竞争力了，那么你就会焦虑，而你又将焦虑的原因归结于一个你没办法改变的问题，那就是“年龄”。于是一个逻辑自洽的描述出来了：

我30岁了，没啥竞争力，未来何去何从？

出路耶

我从事这个行业，其实是个人挺喜欢编程的，觉得编程是一件挺舒心的事情，所以没有考虑过换行。周围其实有一些同事，离开了这个行当，有一些赚了更多的钱，也有一些日子过的更不舒心，这里不予置评。

我简单的叙述一些可能的出路，这些出路没什么对错的区别，只是在我们人生抉择中，希望你能看到更多的选项。

技术深造

如果你在技术上有优势，这是一条可以走通的路子，未来的方向大致是“架构师”、“技术顾问”等等。这需要你有一些大型项目的经验，所以一些在大型公司就业的程序员，天然的拥有更多的机会。

通常技术深造主要是两部分：

1. 技术视野，你需要一定的知识广度，对常用技术有深刻的理解，对部分不常用技术也要熟悉。


2. 技术能力，有的时候，亲自动手能力、解决问题能力会很重要。

项目管理

很多程序员转行做了项目管理，其实在我们的日常工作中，项目管理一直伴随着我们，时长日久，我们对项目管理会变的更熟悉一些。这也造成了一些错觉，让我们觉得项目管理没那么难，“我去我也行”。

但是，项目管理从来不是一项普通的工作，相对于程序员，项目管理人员面临的环境会更加复杂。

1. 面对客户。有时候，会遇见一些喜欢刁难我们的客户的。


2. 面对团队。团队也可能不和谐。


3. 计划乱了、工期排期、风险控制、质量管理、干系人管理等等专业知识。

自由职业

依赖于自己过硬的技术，可以承接一些外包的项目，成为一名自由的外包人员。

1. 你的人际关系会很重要。周围有一些能打单的朋友，会让你工作的很舒服。


2. 把事情做好，赢得信赖。


3. 来自第三方平台的外包项目还是比较坑的，尽量做熟人生意。

跑单

当然，你在行业内可能会认识不少的朋友，他们的手里可能有些业务需要外包人员进行开发，那么拿下这些合同，找到自己朋友里面有时间做私活的人，然后我完成它。

1. 你的人际关系更为重要。通常，这会给你带来财富。


2. 做好自己的品牌，赢得认可，那么就有赢得钞票的机会。

插件独立开发者

一个人开发一个应用，然后上架，成功率是很低的。所以依托于平台，做一些平台内的插件，然后依托于平台推广，那么成功的几率会大一些。

1. 你的技术能力很重要，毕竟没有专门的测试人员进行测试。


2. 你选择的平台很重要，比如跨境电商、钉钉、微信、谷歌浏览器等等。


3. 更加重要的是，你要对这个方向感兴趣。

独立开发者

如果你财富自由了，又喜欢编程，可以成为一名伟大的独立开发者，你脑海中的任何想法，都可以通过双手变为现实。

1. 因为热爱，所以你会有更多的可能。


2. 能力足够，可以参与开源的基金会，参与一些开源项目。


3. 如果财富没自由，那也不影响我们在闲暇时间里追逐我们的梦想。

团购

IT行业是一个挺特殊的团体，他们的某些消费习惯趋于雷同，针对这些消费习惯和爱好，做一些团购，相信会赚到不少钱。

1. 还是人际关系。


2. 你喜欢做这些事情，从免费到收费循序渐进。


3. 记住，双赢才能长久，IT行的聪明人是比较多的。

大公司养老团

找个大的，稳定的公司养老，但是也要留好退路，居安思危。

其他

比如炒股、搞理财的、做导游的、创业的……

每个人都会有自己的选择，有的人做好了准备，有的人还懵懵懂懂，2023年的行情如何还未可知，希望能长风破浪吧

在⾯试过程中，应聘者可能想要从对公司环境的观察以及对⾯试官的提问当中获取公司相关的信息，以此来判断这家公司靠不靠谱，⾃⼰值不值得去。但这种信息可能会带有⼀定的⽚⾯性，毕竟 应聘者没有在公司实际体验过⼯作的内容，很难通过⼀两次⾯试就能看出公司的实际情况。这些细节⼀般只能给予应聘者⼀点有效信息，虽然并不是绝对的准确，综合这些信息判断这家公司是否靠谱。

1 观⾯试流程

靠谱公司都有完善⾯试流程。公司发展到⼀定规模，不会随便找⾯试者过来沟通⼀下就决定要不要这个⾯试者。HR会主动跟应聘者 确定⾯试时间，通过招聘软件或正式邮件跟应聘者确定⾯试时间和⾯试准备内容，在⾯试当天主动跟进应聘者的到场情况，联系好⾯试官随时准备⾯试。如果你发现公司的⾯试流程⼗分混乱，HR 会突然更改⾯试时间，约好⾯试时间后⼜说⾯试官不在、让你第⼆天再过来，或者⾯试时连个会议 室都没有，说明公司招聘的HR⼀点都不专业。可能公司在招聘⼈才的能⼒和经验⼗分有限，或者公 司连⼀套完善的⾯试流程和制度都没有，这样的公司⼀般都是初创企业或⽐较⼩的公司。

2 察工作氛围

在⾯试当天，你可以提前到达公司，仔细稍微观察⼀下办公室⾥的⼯作氛围，看公司的氛围是否严 肃压抑，或者招聘信息 上写着不强制加班，实际个个⼯作压⼒都很⼤，每天被迫加班。如果⼤家 ⼯作的时候都是特别紧绷、各忙各的东⻄，员⼯或领导的神⾊表情都不是特别好，那这家公司有可 能是存在⼀定的内卷现象。加班可能特别严重。

如果不确定⾃⼰观察到的⼯作氛围是否就是真实情况，要如何去印证呢？

⼀般来说，⾯试官都会在⾯试环节询问⾯试者是否愿意接受加班。如果⾯试官主动问起你是否愿意 接受加班，你可以在回答中顺⼿推⾈反问⾯试官：

“⾸先我能理解公司在项⽬紧急的情况下是需要加班的，这个时候我肯定会⽀持公司的⼯作，以公司 的利益为先。（表示理解）我不是⼀个盲⽬加班的⼈，这样会让我的⽣活和⼯作⽐例失衡，反⽽会 影响⾃⼰的⼯作状态。（表明态度）如果是我⾃⼰⼯作效率低造成的加班，我肯定会先努⼒提升个 ⼈能⼒，改进⼯作⽅法，在规定的时间内完成⼯作任务。（提出解决⽅法）最后我想了解⼀下，贵 公司的加班频率是怎么样的，是否有对应的加班费呢？这是很多就业者都会关⼼的问题，希望你能 理解。（借机反问）”

如果⾯试官没有问起加班的问题，你就可以拿刚才在进⼊公司时观察到情况做⽂章，试探⼀下⾯试 官。例如：

（看到氛围差）刚才我进来到时候看到贵公司的同事⼯作都⼗分紧凑，⼯作时都是眉头紧锁、不说 ⼀句话，请问贵公司是对员⼯的⼯作效率有要求么？还是公司普遍存在⾼压或加班⽂化呢？ （看到同事们⼯作时有说有笑）刚才进⼊公司的时候，我观察到贵公司的氛围⼗分轻松活跃，我⼗ 分喜欢贵公司的这种氛围，请问你们能做到这种氛围的原因是什么？是因为公司倡导⾼效率办公， 对员⼯是否加班没有硬性要求么？ 当然，如果你时间⽐较充裕，或者⾯试的时间是在下午的时间，完全可以在公司附近停留⼀段时 间，等下班时间看看员⼯们是否有准时下班。如果下班时间过了半⼩时都没有员⼯⾛出来，那你对 这家公司的加班⽂化和⼯作压⼒就会有⼀定了解了。

3 ⾯试最后利用提问

套取信息。值不值得去⼀家公司，可以在⾯试的过程中询问公司发展的情况和业务发展阶段，以此判断你⼊职 后需要承担的⻆⾊和负责的⼯作内容。例如可以问⾯试官这些问题：

• 
  

  公司/部⻔发展到⼀个什么样的阶段了?

  
  


• 
  

  ⽬前部⻔的业务是否有成熟的体系？

  
  


• 
  

  这个岗位需要重点解决哪些问题?负责的业务有哪些？

  
  


• 
  

  现在的部⻔/团队由哪些部分组成？具体是怎么分⼯的？

  
  


• 
  

  岗位的转正/绩效考核是怎样的？有什么要求？

  
  

如果对⽅不能清晰介绍现在的业务或团队情况，或者跟你说现在的业务还处于起步阶段，需要你来 进⾏协助，那你就要警醒，这个岗位往往是需要你作为负责⼈或开荒⽜的⻆⾊，甚⾄要你帮公司重 新搭建业务体系，过程可能会⽐较⾟苦。如果薪酬也⽆法给到⽐较⾼的⽔平，说明这家公司可能也 是初创阶段，很多东⻄都不⼀定有保障，你就要慎重考虑这家公司值不值得去了。

4 爱压价？

在⾯试之前，HR⼀般会让⾯试者先填⼀张信息表，表格⾥往往有⼀个“期望薪资 ”这⼀栏。除⾮你 能⼒特别突出，否则公司⼀般会根据你期望薪资范围的下限来作为底薪的依据。假如你开出的底薪 条件并不算⾼，但公司还要继续压你的底薪下限，要么就是领导或⽼板格局太⼩，只想招⼀些廉价 劳动⼒ ，不是真的想吸引⼈才；要么是预算有限，你的要求不算⾼，但别⼈就是开不出这样的薪 酬条件。遇到那种跟你讨价还价的公司，就要学会擦亮双眼，这种公司⼊职后福利待遇多半不会太好。

5 查信息平台

• 某眼查


• 某查查


• 某脉

6 总结

无论何时，求人不如求己，多谋求更多职业出路，才能无惧天下。

前言

本篇主要讲述了如何禁止阻止控制台调试以及使用了MutationObserver构造方法禁止修改DOM样式。

正文

话说在三国时期，大都督周瑜为了向世人宣布自己盛世容颜的妻子小乔，并专门创建了一个网站来展示自己的妻子

这么好看的看的小乔，谁看谁不糊，更何况曹老板。这天，曹操在浏览网页的时候，无意间发现了周瑜的这个网站，看着美若天仙的小乔，曹操的眼泪止不住的从嘴角流了下来。赶紧将网站上的照片保存了下来。

这个消息最后传到了周瑜的耳朵里，他只是想展示小乔，可不是为了让别人下载的。于是在自己的网站上做了一些预防措施。

为了防止他人直接在网站上直接下载图片，周瑜将右键的默认事件给关闭了，并且为了防止有人打开控制台，并对图片保存，采取了以下方法：

禁用右键和F12键

//给整个document添加右击事件，并阻止默认行为

document.addEventListener("contextmenu", function (e) {

    e.preventDefault();

    return false;

  });

  

  //给整个页面禁用f12按键  keyCode即将被禁用 不再推荐使用  但仍可以使用

    document.addEventListener("keydown", function (e) {

    //当点了f3\f6\f10之后，即使禁用了f12键依旧可以打开控制台，所以一并禁用

      if (

        [115, 118, 121, 123].includes(e.keyCode) ||

        ["F3", "F6", "F10", "F12"].includes(e.key) ||

        ["F3", "F6", "F10", "F12"].includes(e.code) ||

        //ctrl+f 效果和f3效果一样 点开搜索之后依旧可以点击f12 打开控制台 所以一并禁用

        //缺点是此网站不再能够  **全局搜索**

        (e.ctrlKey && (e.key == "f" || e.code == "KeyF" || e.keyCode == 70))||

        //禁用专门用于打开控制台的组合键

        (e.ctrlKey && e.shiftKey && (e.key == "i" || e.code == "KeyI" || e.keyCode == 73))

      ) {

        e.preventDefault();

        return false;

      }

    });

当曹操再次想保存小乔照片的时候，发现使用网页的另存了已经没用了。这能难倒曹老板吗，破解方法，在浏览器的右上角进行操作就可打开控制台，这个地方是浏览器自带的，没办法禁用

这番操作之后，曹操可以选择元素保存那个图片了。周瑜的得知了自己的禁用措施被破解后，赶忙连夜加班打补丁，于是又加了一些操作，禁止打开控制台后进行操作

禁用控制台

如何判定控制台被打开了，可以使用窗口大小来判定

function resize() {

      var threshold = 100;

      //窗口的外部减窗口内超过100就判定窗口被打开了

      var widthThreshold = window.outerWidth - window.innerWidth > threshold;

      var heightThreshold = window.outerHeight - window.innerHeight > threshold;

      if (widthThreshold || heightThreshold) {

        console.log("控制台打开了");

      }

    }

  window.addEventListener("resize", resize);

但是也容易被破解，只要让控制台变成弹窗窗口就可以了

也可以使用定时器进行无限debugger，因为只有在控制台打开的时候debugger才会生效。关闭控制台的时候，并不会影响功能。当前网页内存占用比较大的时候，定时器的占用并不明显。在当前网页占用比较小的时候，一直开着定时器才会有较为明显的提升

  setInterval(() => {

      (function () {})["constructor"]("debugger")();

    }, 500);

破解方法一样有，在debugger的位置右键禁用调试就可以了。这样控制台就可以正常操作了

既然有方法破解，就还要做一层措施，既然是要保存图片，那就把img转成canvas，这样即使打开控制台也没办法进行对图片的保存

//获取dom

 const img = document.querySelector(".img");

 const canvas = document.querySelector("#canvas");

 //img转成canvas

  canvas.width = img.width;

  canvas.height = img.height;

  ctx = canvas.getContext("2d");

  ctx.drawImage(img, 0, 0, img.width, img.height);

  document.body.removeChild(img);

经过一夜的努力，该加的措施都加上了。周瑜心想这下就没办法保存我的小乔了吧。

来到曹操这边，再次打开周瑜的小破站，还想故技重施时，发现已经有了各种显示，最后也没难倒曹操，那些阻碍也都被破解了。但是到保存图片的时候傻眼了，竟然已经不是图片格式了，那就没办法下载了呀。但是小乔真的很养神，曹操心有不甘，于是使用了最后一招，既然没办法下载那就截图，虽然有损画质，但是依旧能看。

得知如此情况的大都督周瑜不淡定了，从未见过如此厚颜无耻之人，竟然使用截图。

话说魔高一尺，道高一丈，周瑜再次熬夜加班进行对网站的优化。于是使用了全屏水印+MutationObserver监听水印dom的方法。即使截图也让他看着不舒服。

MutationObserver

MutationObserver是一个构造函数，接口提供了监视对 DOM 树所做更改的能力。它被设计为旧的 Mutation Events 功能的替代品，该功能是 DOM3 Events 规范的一部分。

它接收一个回调函数，每当监听的dom发生改变时，就会调用这个函数，函数传入一个参数，数组包对象的格式，里面记录着dom的变化以及dom的信息。

返回的实例是一个新的、包含监听 DOM 变化回调函数的 MutationObserver 对象。有三个方法observe，disconnect，takeRecords

• observe接收两个参数，第一个为要监听的dom元素，第二个则是一些配置对象，当调用 observe() 时，childList、attributes 和 characterData 中，必须有一个参数为 true。否则会抛出 TypeError 异常。配置对象如下：
  
  
  
  • subtree：当为 true 时，将会监听以 target 为根节点的整个子树。包括子树中所有节点的属性，而不仅仅是针对 target。默认值为 false。
  
  
  • childList:当为 true 时，监听 target 节点中发生的节点的新增与删除（同时，如果 subtree 为 true，会针对整个子树生效）。默认值为 false。
  
  
  • attributes:当为 true 时观察所有监听的节点属性值的变化。默认值为 true，当声明了 attributeFilter 或 attributeOldValue，默认值则为 false。
  
  
  • attributeFilter:一个用于声明哪些属性名会被监听的数组。如果不声明该属性，所有属性的变化都将触发通知。
  
  
  • attributeOldValue:当为 true 时，记录上一次被监听的节点的属性变化；可查阅监听属性值了解关于观察属性变化和属性值记录的详情。默认值为 false。
  
  
  • characterDate:当为 true 时，监听声明的 target 节点上所有字符的变化。默认值为 true，如果声明了 characterDataOldValue，默认值则为 false。
  
  
  • characterDateOldValue:当为 true 时，记录前一个被监听的节点中发生的文本变化。默认值为 false
  
  
  
  


• disconnect方法用来停止观察（当被观察dom节点被删除后，会自动停止对该dom的观察），不接受任何参数


• takeRecords：方法返回已检测到但尚未由观察者的回调函数处理的所有匹配 DOM 更改的列表，使变更队列保持为空。此方法最常见的使用场景是在断开观察者之前立即获取所有未处理的更改记录，以便在停止观察者时可以处理任何未处理的更改。

该构造函数监听的dom即使在控制台中被更改属性或值，也会被监听到。

使用MutationObserver对水印dom进行监听，并限制更改。

<style>

//定义水印的样式

    #watermark {

        width: 100vw;

        height: 100vh;

        position: absolute;

        left: 0;

        top: 0;

        font-size: 34px;

        color: #32323238;

        font-weight: 700;

        display: flex;

        flex-wrap: wrap;

        justify-content: space-evenly;

        align-content: space-evenly;

        z-index: 9999999;

      }

      #watermark span {

        transform: rotate(45deg);

      }

</style>



 <script>

 //获取水印dom

    const watermark = document.querySelector("#watermark");

    //克隆水印dom ，用作后备,永远不要改变

    const _watermark = watermark.cloneNode(true);

    //获取水印dom的父节点

    const d = watermark.parentNode;

    //获取水印dom的后一个节点

    let referenceNode;

    [...d.children].forEach((item, index) => {

      if (item == watermark) referenceNode = d.children[index + 1];

    });

    //定义MutationObserver实例observe方法的配置对象

    const prop = {

      childList: true,//针对整个子树

      attributes: true,//属性变化

      characterData: true,//监听节点上字符变化

      subtree: true,//监听以target为根节点的整个dom树

    };

    //定义MutationObserver

    const observer = new MutationObserver(function (mutations) {

    //在这里每次坚挺的dom发生改变时 都会运行，传入的参数为数组对象格式

      mutations.forEach((item) => {

      //这里可以只针对监听dom的样式来判断

        if (item.attributeName === "style") {

        //获取父节点的所有子节点，因为时伪数组，使用扩展运算符转以下

          [...d.children].forEach((v) => {

          //判断一下，是父节点里的那个节点被改变了，并且删除那个被改变的节点（也就是删除水印节点）

            if (item.target.id && v == document.querySelector(`#${item.target.id}`)) {

              v.remove();

            }

          });

          //原水印节点被删除了，这里使用克隆的水印节点，再次克隆

          const __watermark = _watermark.cloneNode(true);

          //这里的this指向是MutationObserver的实例对象，所以同样可以使用observe监听dom

          //监听第二次克隆的dom

          this.observe(__watermark, prop);

          //因为水印dom被删除了，再将克隆的水印dom添加到原来的位置 就是referenceNode节点的前面

          d.insertBefore(__watermark, referenceNode);

        }

      });

    });

    在初始化的时候监听初始化的水印dom

    observer.observe(watermark, prop);

  </script>

这样，每当对水印dom进行更改样式的时候，就会删除该节点，并重新添加一个初始的水印dom，即使突破重重困难打开开控制台，用户也是无法对dom 进行操作。

隔天曹操再次打开网页，发现网页上的水印，心里不足为惧，心想区区水印能难倒自己？操作到最后却发现，不论如何对水印dom进行操作，都无法改变样式。虽说只是为了保存图片，但是截图有着这样水印，任谁也不舒服呀。曹操大怒，刚吃了两口的饭啪的一下就盖在了桌子上......

然而曹操不知道的是，在控制台中，获取dom节点右键是可以只下载获取的那个节点的......

结尾

文章主要是以鬼畜恶搞的方式讲述了，如何禁止用户打开控制台（还有重写toSring，consloe.log等一些方法，但我并没有没有实现，所以这里并没有写上），并且如何使用MutationObserver构造函数来监听页面中的dom元素。其实大多情况下并没有这方面的项目需求，完全可以当扩展知识看了。

写的不好的地方可以提出意见，虚心请教！

成都，带不走的，只有你.....

XXXX说，一千个人就有一千个成都

有人说成都是天府之国，有人说成都是西南柬埔寨。

我的成都，有爱有梦，谢谢你。

还记得5年前，2017年7月份，我从一个不知名的二本财经学校里的不知名专业毕业，凛冽的西北风最终没能把我留在兰州，大三一次偶然的寒假工，让我才意识到原来冬季并不都是白雪茫茫，原来冬季也可以绿意盎然，于是那年校招，我忽略了所有的北方校招，只参加了所有来自南方的企业。

在经历了当时看起来几次的高光时刻后，我最终通过校招加入了广东一家大型集团公司。

7月的兰州，需要穿件毛衣才可以让自己看起来非常从容，那时人生第一次坐飞机，原谅来自农村的孩子真的见识短浅，穿过白云的世界真的从来没有见识过，飞机上的2小时一刻也没有睡着，光顾着去拍下那高空中的世界。

下了飞机后，一股热气流扑面而来，让我一度怀疑广东人天天在蒸桑拿，走在路上没10分钟，我已经汗流浃背，非常羡慕走在我旁边的一个靓妹，小短袖，小短裤，甚是凉快。

加入公司后，公司为每个新人分配了导师，导师带我们做常规开发任务，同时为我们能在这复杂的社会上立足而答疑解惑。

由于是传统企业，技术相对而言非常老旧，经常需要维护Jquery项目，唯独一个在当时看起来眼前一亮的项目是内部HR使用的考勤平台，在我们几个90后一再的说服下，领导同意使用React开发，但是我们必须保证进度.....

广东传统企业大部分都配备有员工餐厅，员工宿舍，因此毕业的那两年从来没有经历颠沛流离的生活，每天下班后会和当时校招进去的几个同期生先去糖水店吃一下，周末流窜于广州的大街小巷，上下九步行街.....，生活看起来无忧无虑。

直到2019年下半年，11月份的广州依然是那么炎热，桑拿生活还是一样在继续，周一正常打卡上班，上班没多久，领导给我发消息，“来下办公室呢”，进去后，领导还是和往常一样，在自己狭小略显简陋的办公室里沏了一壶茶，接下来的谈话让我一生难忘，因为这看似关心，实则裁员的谈话最终导致了我抑郁症的发作，久久没有平复.....

领导直言，公司在某个大的战略方向上已经折腾了3年，老板和投资人不愿意继续下去，开发人员只会留下部分，他可以替我申请，更换部门，去市场部就职....，一想起同期的一个市场部门同事说市场部会喝酒是一项工作技能，而我，生理本能排斥那样的生活.....

那天的广州，阳光非常热烈，但维护没有一丝丝光线照进我的工位，走出领导办公室的我，瘫坐在自己工位上，身体发软，毫无力气，喘气困难......

很多思绪开始在我脑海里出现，如果我当时选择了北方的校招，如果我曾经选择了跳槽，如果......随之而来的情绪将我击倒，没人给我说过我该怎样面对这样突如其来的变化.....

之后的日子，总感觉广州的天没有了曾经那般蓝天白云的美丽，只觉得它刺眼且讨厌，每天总感觉身体加倍的疲惫，每一天都在思考的是到底做错了什么会导致现在的模样，当然也没有了当初那般谈笑风生的快乐.....，与同期生朋友的谈话聊天也变的心不在焉，乏味无趣，像那迷失的候鸟一般，找不到任何的归宿。

就这样持续了一个月，我还是鼓起勇气去了医院，果然是重度抑郁，医生建议回家修养，可我那从来走出过一亩三分地的父母又如何才能理解抑郁症的由来呢？

就这样我每天如同僵尸一样摇摇晃晃，来回走动.....

硬撑到年底，我向领导提了离职，也该离开我喜欢的南方城市了.....

回到北方，熟悉的父母，熟悉的冬日白雪，妹妹也在过年时嫁为人妻。

之后的事情，想必大家都清楚，2019年年底，我们在新闻里看着新冠肺炎的消息，那么遥远，却没想到短短一个月，那么迅速就来到了我们身边。

我沉浸在父母和家乡的冬日里，实则是在逃避人生的下一段旅程，每当夜幕降临，我一遍又一遍打开Boss，脉脉，听闻着他人的故事，也探寻着自己的故事。

过年之后，到了4月，我知道，我得再次出发，就像当时刚毕业时那种对未来的美好期待一般。

最终我选择了离家不远，但又迎合了我的南方情结的成都。

在1个月内我找到了能够安身立命的前端开发工作，我开着我的小船，再次起航了......

我深深迷恋着夏日成都街头小巷的冰粉，也和很多成都朋友一样，一周必须吃一顿火锅来证明自己是个新成都人，饭桌上的折耳根永远是外地人百思不得其解的食物，川西的四季永远那么耀眼动人，令人向往。

2023年的5月，我也在这个巴适的城市和一位姑娘牵手走入了婚姻殿堂，我们都深爱着彼此，也深爱着我们几乎每周都要前往的川西。

如今的自己，也褪去了曾经的那份稚嫩，迷茫，渐渐在这片地方扎根，生长。

如今的工作也是朝九晚六，三天居家，二两办公室，wlb的日子才真正让人觉得人生值得走一遭。

平日里刷刷freecodecamp和油管上的技术视频，练习练习算法防止脑瓜壳生锈，和香港技术官探讨探讨技术，好让项目不至于那么难以维护，偶尔也用工作用的全栈技术（MERN）帮老婆写一两个小网站，谁让四川的男人都是耙耳朵呢。

在移动应用开发中，Android卡顿是一个常见但令人讨厌的问题，它可能导致用户体验下降，甚至失去用户。本文将深入探讨Android卡顿的原因，以及如何通过代码优化和性能监测来提高应用的性能。

卡顿现象

卡顿是指应用在运行时出现的明显延迟和不流畅的感觉。这可能包括滑动不流畅、界面响应缓慢等问题。要解决卡顿问题，首先需要了解可能导致卡顿的原因。

卡顿原因

主线程阻塞

主线程负责处理用户界面操作，如果在主线程上执行耗时任务，会导致界面冻结。

public void doSomeWork() {

    // 这里执行耗时操作

    // ...

    // 下面的代码会导致卡顿

    updateUI();

}

内存泄漏

内存泄漏可能会导致内存消耗过多，最终导致应用变得缓慢。

public class MyActivity extends AppCompatActivity {

    private static List<SomeObject> myList = new ArrayList<>();



    @Override

    protected void onCreate(Bundle savedInstanceState) {

        // 向myList添加数据，但没有清除

        myList.add(new SomeObject());

    }

}

过多的布局层次

复杂的布局层次会增加UI绘制的负担，导致卡顿。

<RelativeLayout>

    <LinearLayout>

        <ImageView />

        <TextView />

        <!-- 更多视图 -->

    </LinearLayout>

</RelativeLayout>

大量内存分配

频繁的内存分配与回收，会导致性能下降，发生卡顿。

// 创建大量对象

List<Object> objects = new ArrayList<>();

for (int i = 0; i < 10000; i++) {

    objects.add(new Object());

}

优化策略

使用异步任务

避免在主线程上执行耗时操作，使用异步任务或线程池来处理它们。
协程提供了一种更清晰和顺序化的方式来执行异步任务，并且能够很容易地切换线程

// 创建一个协程作用域

val job = CoroutineScope(Dispatchers.IO).launch {

    // 在后台线程执行后台任务

    val result = performBackgroundTask()

    

    // 切换到主线程更新UI

    withContext(Dispatchers.Main) {

        updateUI(result)

    }

}



// 取消协程

fun cancelJob() {

    job.cancel()

}



suspend fun performBackgroundTask(): String {

    // 执行后台任务

    return "Background task result"

}



fun updateUI(result: String) {

    // 更新UI

}

在此示例中，我们首先创建一个协程作用域，并在后台线程（Dispatchers.IO）中启动一个协程（launch）。协程执行后台任务（performBackgroundTask），然后使用withContext函数切换到主线程（Dispatchers.Main）来更新UI。

内存管理

确保在不再需要的对象上及时释放引用，以避免内存泄漏。

public class MyActivity extends AppCompatActivity {

    private List<SomeObject> myList = new ArrayList<>();



    @Override

    protected void onCreate(Bundle savedInstanceState) {

        myList.add(new SomeObject());

    }



    @Override

    protected void onDestroy() {

        super.onDestroy();

        myList.clear(); // 清除引用

    }

}

精简布局

减少不必要的布局嵌套，使用ConstraintLayout等优化性能的布局管理器。

<ConstraintLayout>

    <ImageView />

    <TextView />

    <!-- 更少的视图层次 -->

</ConstraintLayout>

使用对象池

避免频繁的内存分配和回收。尽量重用对象，而不是频繁创建新对象。
使用对象池来缓存和重用对象，特别是对于复杂的数据结构。

// 使用对象池来重用对象

ObjectPool objectPool = new ObjectPool();

for (int i = 0; i < 10000; i++) {

    Object obj = objectPool.acquireObject();

    // 使用对象

    objectPool.releaseObject(obj);

}

卡顿监测

Android提供了性能分析工具，如Android Profiler和Systrace，用于帮助您找到性能瓶颈并进行优化。

为了更深入地了解应用性能，您还可以监测主线程处理时间。通过解析Android系统内部的消息处理日志，您可以获取每条消息的实际处理时间，提供了高度准确的性能信息。

for (;;) {

    Message msg = queue.next(); 



    final Printer logging = me.mLogging;

    if (logging != null) {

        logging.println(">>>>> Dispatching to " + msg.target + " " +

                msg.callback + ": " + msg.what);

    }



    msg.target.dispatchMessage(msg);



    if (logging != null) {

        logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);

    }

}

当消息被取出并准备处理时，通过 logging.println(...) 记录了">>>>> Dispatching to" 日志，标志了消息的处理开始。同样，在消息处理完成后，记录了"<<<<< Finished to" 日志，标志了消息的处理结束。这些日志用于追踪消息的处理时间点。

这段代码对 Android 卡顿相关内容的分析非常重要。通过记录消息的处理起点和终点时间，开发者可以分析主线程消息处理的性能瓶颈。如果发现消息的处理时间过长，就可能导致卡顿，因为主线程被长时间占用，无法响应用户交互。

Looper.getMainLooper().setMessageLogging(new LogPrinter(new String("MyApp"), Log.DEBUG) {

    @Override

    public void println(String msg) {

        if (msg.startsWith(">>>>> Dispatching to ")) {

            // 记录消息开始处理时间

            startTime = System.currentTimeMillis();

        } else if (msg.startsWith("<<<<< Finished to ")) {

            // 记录消息结束处理时间

            long endTime = System.currentTimeMillis();

            // 解析消息信息

            String messageInfo = msg.substring("<<<<< Finished to ".length());

            String[] parts = messageInfo.split(" ");

            String handlerInfo = parts[0];

            String messageInfo = parts[1];

            // 计算消息处理时间

            long executionTime = endTime - startTime;

            // 记录消息处理时间

            Log.d("DispatchTime", "Handler: " + handlerInfo + ", Message: " + messageInfo + ", Execution Time: " + executionTime + "ms");

        }

    }

});

这种方法适用于需要深入分析主线程性能的情况，但需要权衡性能开销和代码复杂性。

结语

Android卡顿问题可能是用户体验的重要破坏因素。通过了解卡顿的原因，采取相应的优化策略，利用性能分析工具和消息处理日志监测，您可以提高应用的性能，使用户体验更加流畅。卡顿问题的解决需要不断的监测、测试和优化，通过不断发现与解决卡顿问题，才能让应用更加流畅。

推荐

android_startup: 提供一种在应用启动时能够更加简单、高效的方式来初始化组件，优化启动速度。不仅支持Jetpack App Startup的全部功能，还提供额外的同步与异步等待、线程控制与多进程支持等功能。

AwesomeGithub: 基于Github的客户端，纯练习项目，支持组件化开发，支持账户密码与认证登陆。使用Kotlin语言进行开发，项目架构是基于JetPack&DataBinding的MVVM；项目中使用了Arouter、Retrofit、Coroutine、Glide、Dagger与Hilt等流行开源技术。

flutter_github: 基于Flutter的跨平台版本Github客户端，与AwesomeGithub相对应。

android-api-analysis: 结合详细的Demo来全面解析Android相关的知识点, 帮助读者能够更快的掌握与理解所阐述的要点。

daily_algorithm: 每日一算法，由浅入深，欢迎加入一起共勉。

1、在任意目录之间快速移动

你发现自己要在两个或更多目录之间频繁移动，一会切换到这里，一会切换到那里，来回跳转。这些目录之间隔得还挺远，反复输入冗长的路径让人疲惫不堪。

使用内建命令 pushd 和 popd 来管理目录栈，轻松地在目录之间切换。下面是一个简单的示例：

$ cd /tmp/tank

$ pwd

/tmp/tank



$ pushd /var/log/cups

/var/log/cups /tmp/tank



$ pwd

/var/log/cups



$ ls

access_log error_log page_log



$ popd

/tmp/tank



$ ls

empty full



$ pushd /var/log/cups

/var/log/cups /tmp/tank



$ pushd

/tmp/tank /var/log/cups



$ pushd

/var/log/cups /tmp/tank



$ pushd

/tmp/tank /var/log/cups



$ dirs

/tmp/tank /var/log/cups

栈是一种后进先出的结构，这两个命令也正是这么做的。如果对一个新目录使用 pushd，那么它会将前一个目录压入栈中。当使用 popd时，它会弹出栈顶保存的当前位置，切换到新的栈顶目录。使用这些命令更改位置时，会从左到右输出目录栈中的值，对应于栈中自顶向下的顺序。

如果使用 pushd 时没有指定目录，那么它会交换栈顶的两个目录的位置，这样就可以重复使用 pushd 命令来实现两者之间的切换。cd命令也能够达到相同效果。

如果不记得目录栈中都有哪些目录，可以使用内建命令 dirs 按照从左到右的顺序显示。加上 -v 选项后，显示形式更形象。

$ dirs -v

 0  /opt/yongheng

 1  /opt/yongheng/Shell

$

数字可用来调整栈内目录的位置。pushd +1 会将编号为 1 的目录置为栈顶（并切换到该目录）并将其他目录下压。

$  pushd +1

/opt/yongheng/Shell /opt/yongheng



$  dirs -v 

0  /opt/yongheng/Shell

1  /opt/yongheng 

要想看到类似于栈的目录列表，但又不希望出现编号，可以使用 -p选项。

# dirs -p                                                                                              /opt/yongheng/Shell                                                                                    /opt/yongheng     

2、重复上一个命令

你刚刚输入了一个又长又麻烦的命令，其中包含了冗长的路径名和一堆复杂的参数。现在需要重新执行该命令。难道还得再输入一次？

这个问题有两种解决方法。第一种方法只需要在提示符下输入两个惊叹号，然后 bash 就会显示并重复执行上一个命令。例如：

$  cd /opt/                                                                                            $ !!                                                                                                   cd /opt/  

另一种（更现代的）方法是使用箭头键。按上箭头键会回滚到执行过的上一个命令。如果找到了需要的命令，按下 Enter 键就可以（再次）执行该命令。

3、参数重用

重用上一个命令很简单，使用 !! 就行了，但你需要的未必总是整个命令。如何只重用最后一个参数呢？

用 !$ 指明上一个命令中的最后一个参数。!:1 表示第一个参数，!:2 表示第二个参数，以此类推。

多个命令使用相同的文件名为参数是司空见惯的事情。最常见的场景之一就是程序员编辑源代码文件，然后编译、再编辑，再编译……有了 !$，事情就方便多了。如下：

$ vi /some/long/path/name/you/only/type/once

...

$ gcc !$

gcc /some/long/path/name/you/only/type/once

...

$ vi !$

vi /some/long/path/name/you/only/type/once

...

$ gcc !$

gcc /some/long/path/name/you/only/type/once

...

$

明白其中的意思了吗？这不仅省去了大量的键盘输入，还避免了错误。如果编译时输错文件名，那编译的可就不是刚刚编辑好的源代码文件了。有了 !$，就可以始终得到刚刚用过的文件名。要是想重用的参数位于命令行内部，可以使用带编号的 !: 命令来获取。

4、安全第一，命令测试

一不小心就会输错字符。 （不信你瞧！）即便是简单的 bash 命令，由此带来的后果也非常严重：你会移动错或删错文件。如果再加上模式匹配，结果更让人心跳，因为模式中的输入错误会导致南辕北辙的结果。小心谨慎的用户会怎么做？

可以使用命令历史特性和键盘便捷方式来重复参数，无须从头输入，因此能够减少输入错误。如果要用到棘手的模式来匹配文件，先用echo 测试一下模式能否正常匹配，然后再用 !$ 进行实际操作。例如：

$ ls

ab1.txt ac1.txt jb1.txt wc3.txt



$ echo *1.txt

ab1.txt ac1.txt jb1.txt



$ echo [aj]?1.txt

ab1.txt ac1.txt jb1.txt



$ echo ?b1.txt

ab1.txt jb1.txt



$ rm !$

rm ?b1.txt

$

echo 是检查模式匹配结果的一种方法。一旦确信结果符合预期，就可以将模式用于实际命令。这里我们要删除有特定名称的文件，没人愿意在这种事上犯错。

一、什么是压缩炸弹，会有什么危害

1.1 什么是压缩炸弹

压缩炸弹(ZIP)：一个压缩包只有几十KB，但是解压缩后有几十GB，甚至可以去到几百TB，直接撑爆硬盘，或者是在解压过程中CPU飙到100%造成服务器宕机。虽然系统功能没有自动解压，但是假如开发人员在不细心观察的情况下进行一键解压(不看压缩包里面的文件大小)，可导致压缩炸弹爆炸。又或者压缩炸弹藏在比较深的目录下，不经意的解压缩，也可导致压缩炸弹爆炸。

以下是安全测试几种经典的压缩炸弹

graph LR

A(安全测试的经典压缩炸弹)

B(zip文件42KB)

C(zip文件10MB)

D(zip文件46MB)

E(解压后5.5G)

F(解压后281TB)

G(解压后4.5PB)



A ---> B --解压--> E

A ---> C --解压--> F

A ---> D --解压--> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style F fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style G fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

压缩炸弹（也称为压缩文件炸弹、炸弹文件）是一种特殊的文件，它在解压缩时会迅速膨胀成极其庞大的文件，可能导致系统资源耗尽、崩溃或磁盘空间耗尽。

压缩炸弹的原理是利用文件压缩算法中的重复模式和递归压缩的特性。它通常是一个非常小的压缩文件，但在解压缩时会生成大量的重复数据，导致文件大小迅速增长。这种文件的设计意图是迫使系统进行大量的解压缩操作，以消耗系统资源或填满磁盘空间。

压缩炸弹可能对系统造成严重的影响，包括系统崩溃、资源耗尽、拒绝服务攻击等。因此，它被视为一种恶意的计算机攻击工具，常常被用于恶意目的或作为安全测试中的一种工具。

1.2 压缩炸弹会有什么危害

graph LR

A(压缩炸弹的危害)

B(资源耗尽)

C(磁盘空间耗尽)

D(系统崩溃)

E(拒绝服务攻击)

F(数据丢失)



A ---> B

A ---> C

A ---> D

A ---> E

A ---> F



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

压缩炸弹可能对计算机系统造成以下具体的破坏：

1. 
   

   资源耗尽：压缩炸弹在解压缩时会生成大量的重复数据，导致系统的CPU、内存和磁盘资源被迅速占用。这可能导致系统反应迟缓、无法响应用户的请求，甚至系统崩溃。

   
   


2. 
   

   磁盘空间耗尽：由于压缩炸弹的膨胀特性，它可能在解压缩过程中填满磁盘空间。这会导致系统无法写入新的数据，造成磁盘空间耗尽，影响系统的正常运行。

   
   


3. 
   

   系统崩溃：当一个压缩炸弹被解压缩时，系统可能由于资源耗尽或磁盘空间耗尽而崩溃。这可能导致系统重启或需要进行紧急修复，造成数据丢失或系统不可用的情况。

   
   


4. 
   

   拒绝服务攻击：大规模的解压缩操作可能消耗大量系统资源，导致系统无法正常提供服务。这被恶意攻击者利用，用于进行拒绝服务攻击，使目标系统无法响应合法用户的请求。

   
   


5. 
   

   数据丢失：在某些情况下，压缩炸弹可能会导致系统文件或数据的损坏或丢失。这可能发生在磁盘空间被耗尽时，写入操作无法成功完成的情况下。

   
   

重要提示：压缩炸弹可能对计算机系统造成不可逆的损害，请不要尝试创建、传播或使用压缩炸弹，以保护计算机和网络的安全。

二、怎么检测和处理压缩炸弹，Java怎么防止压缩炸弹

2.1 个人有没有方法可以检测压缩炸弹？

有一些方法可以识别和处理潜在的压缩炸弹，以防止对系统造成破坏。以下是一些常见的方法：

graph LR

A(个人检测压缩炸弹)

B(安全软件和防病毒工具)

C(文件大小限制)

D(文件类型过滤)



A ---> B --> E(推荐)

A ---> C --> F(太大的放个心眼)

A ---> D --> G(注意不认识的文件类型)



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style F fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style G fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

1. 
   

   安全软件和防病毒工具（推荐）：使用最新的安全软件和防病毒工具可以帮助检测和阻止已知的压缩炸弹。这些工具通常具备压缩文件扫描功能，可以检查文件是否包含恶意的压缩炸弹。

   
   


2. 
   

   文件大小限制：设置对文件大小的限制可以帮助防止解压缩过程中出现过大的文件。通过限制解压缩操作的最大文件大小，可以减少对系统资源和磁盘空间的过度消耗。

   
   


3. 
   

   文件类型过滤：识别和过滤已知的压缩炸弹文件类型可以帮助阻止这些文件的传输和存储。通过检查文件扩展名或文件头信息，可以识别潜在的压缩炸弹，并阻止其传输或处理。

   
   

2.2 Java怎么防止压缩炸弹

在java中实际防止压缩炸弹的方法挺多的，可以采取以下措施来防止压缩炸弹：

graph LR

A(Java防止压缩炸弹)

B(解压缩算法的限制)

C(设置解压缩操作的资源限制)

D(使用安全的解压缩库)

E(文件类型验证和过滤)

F(异步解压缩操作)

G(安全策略和权限控制)



A ---> B

A ---> C

A ---> D

A ---> E

A ---> F

A ---> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

1. 
   

   解压缩算法的限制：限制解压缩算法的递归层数和重复模式的检测可以帮助防止解压缩过程无限膨胀。通过限制递归的深度和检测重复模式，可以及时中断解压缩操作并避免过度消耗资源。

   
   


2. 
   

   设置解压缩操作的资源限制：使用Java的java.util.zip或java.util.jar等类进行解压缩时，可以设置解压缩操作的资源限制，例如限制解压缩的最大文件大小、最大递归深度等。通过限制资源的使用，可以减少对系统资源的过度消耗。

   
   


3. 
   

   使用安全的解压缩库：确保使用的解压缩库是经过安全验证的，以避免存在已知的压缩炸弹漏洞。使用官方或经过广泛验证的库可以减少受到压缩炸弹攻击的风险。

   
   


4. 
   

   文件类型验证和过滤：在解压缩之前，可以对文件进行类型验证和过滤，排除潜在的压缩炸弹文件。通过验证文件的类型、扩展名和文件头信息，可以识别并排除不安全的压缩文件。

   
   


5. 
   

   异步解压缩操作：将解压缩操作放在异步线程中进行，以防止阻塞主线程和耗尽系统资源。这样可以保持应用程序的响应性，并减少对系统的影响。

   
   


6. 
   

   安全策略和权限控制：实施严格的安全策略和权限控制，限制用户对系统资源和文件的访问和操作。确保只有受信任的用户或应用程序能够进行解压缩操作，以减少恶意使用压缩炸弹的可能性。

   
   

2.2.1 使用解压算法的限制来实现防止压缩炸弹

在前面我们说了Java防止压缩炸弹的一些策略，下面我将代码实现通过解压缩算法的限制来实现防止压缩炸弹。

先来看看我们实现的思路：

graph TD

    A(开始) --> B[创建 ZipFile 对象]

    B --> C[打开要解压缩的 ZIP 文件]

    C --> D[初始化 zipFileSize 变量为 0]

    D --> E{是否有更多的条目}

    E -- 是 --> F[获取 ZIP 文件的下一个条目]

    F --> G[获取当前条目的未压缩大小]

    G --> H[将解压大小累加到 zipFileSize 变量]

    H --> I{zipFileSize 是否超过指定的大小}

    I -- 是 --> J[调用 deleteDir方法删除已解压的文件夹]

    J --> K[抛出 IllegalArgumentException 异常]

    K --> L(结束)

    I -- 否 --> M(保存解压文件) --> E

    E -- 否 --> L

 

style A fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style H fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style I fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style J fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style K fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style L fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style M fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

实现流程说明如下：

1. 
   

   首先，通过给定的 file 参数创建一个 ZipFile 对象，用于打开要解压缩的 ZIP 文件。

   
   


2. 
   

   zipFileSize 变量用于计算解压缩后的文件总大小。

   
   


3. 
   

   使用 zipFile.entries() 方法获取 ZIP 文件中的所有条目，并通过 while 循环逐个处理每个条目。

   
   


4. 
   

   对于每个条目，使用 entry.getSize() 获取条目的未压缩大小，并将其累加到 zipFileSize 变量中。

   
   


5. 
   

   如果 zipFileSize 超过了给定的 size 参数，说明解压后的文件大小超过了限制，此时会调用 deleteDir() 方法删除已解压的文件夹，并抛出 IllegalArgumentException 异常，以防止压缩炸弹攻击。

   
   


6. 
   

   创建一个 File 对象 unzipped，表示解压后的文件或目录在输出文件夹中的路径。

   
   


7. 
   

   如果当前条目是一个目录，且 unzipped 不存在，则创建该目录。

   
   


8. 
   

   如果当前条目不是一个目录，确保 unzipped 的父文件夹存在。

   
   


9. 
   

   创建一个 FileOutputStream 对象 fos，用于将解压后的数据写入到 unzipped 文件中。

   
   


10. 
    

    通过 zipFile.getInputStream(entry) 获取当前条目的输入流。

    
    


11. 
    

    创建一个缓冲区 buffer，并使用循环从输入流中读取数据，并将其写入到 fos 中，直到读取完整个条目的数据。

    
    


12. 
    

    最后，在 finally 块中关闭 fos 和 zipFile 对象，确保资源的释放。

    
    

实现代码工具类：

import java.io.File;

import java.io.FileOutputStream;

import java.io.InputStream;

import java.util.Enumeration;

import java.util.zip.ZipEntry;

import java.util.zip.ZipFile;



/**

 * 文件炸弹工具类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2023/10

 */

public class FileBombUtil {



    /**

     * 限制文件大小 1M（限制单位：B）[1M=1024KB 1KB=1024B]

     */

    public static final Long FILE_LIMIT_SIZE = 1024 * 1024 * 1L;



    /**

     * 文件超限提示

     */

    public static final String FILE_LIMIT_SIZE_MSG = "The file size exceeds the limit";



    /**

     * 解压文件（带限制解压文件大小策略）

     *

     * @param file         压缩文件

     * @param outputfolder 解压后的文件目录

     * @param size         限制解压之后的文件大小（单位：B），示例 3M：1024 * 1024 * 3L （FileBombUtil.FILE_LIMIT_SIZE * 3）

     * @throws Exception IllegalArgumentException 超限抛出的异常

     *                   注意：业务层必须抓取IllegalArgumentException异常，如果msg等于FILE_LIMIT_SIZE_MSG

     *                   要考虑后面的逻辑，比如告警

     */

    public static void unzip(File file, File outputfolder, Long size) throws Exception {

        ZipFile zipFile = new ZipFile(file);

        FileOutputStream fos = null;

        try {

            Enumeration<? extends ZipEntry> zipEntries = zipFile.entries();

            long zipFileSize = 0L;

            ZipEntry entry;

            while (zipEntries.hasMoreElements()) {

                // 获取 ZIP 文件的下一个条目

                entry = zipEntries.nextElement();

                // 将解缩大小累加到 zipFileSize 变量

                zipFileSize += entry.getSize();

                // 判断解压文件累计大小是否超过指定的大小

                if (zipFileSize > size) {

                    deleteDir(outputfolder);

                    throw new IllegalArgumentException(FILE_LIMIT_SIZE_MSG);

                }

                File unzipped = new File(outputfolder, entry.getName());

                if (entry.isDirectory() && !unzipped.exists()) {

                    unzipped.mkdirs();

                    continue;

                } else if (!unzipped.getParentFile().exists()) {

                    unzipped.getParentFile().mkdirs();

                }



                fos = new FileOutputStream(unzipped);

                InputStream in = zipFile.getInputStream(entry);



                byte[] buffer = new byte[4096];

                int count;

                while ((count = in.read(buffer, 0, buffer.length)) != -1) {

                    fos.write(buffer, 0, count);

                }

            }

        } finally {

            if (null != fos) {

                fos.close();

            }

            if (null != zipFile) {

                zipFile.close();

            }

        }



    }



    /**

     * 递归删除目录文件

     *

     * @param dir 目录

     */

    private static boolean deleteDir(File dir) {

        if (dir.isDirectory()) {

            String[] children = dir.list();

            //递归删除目录中的子目录下

            for (int i = 0; i < children.length; i++) {

                boolean success = deleteDir(new File(dir, children[i]));

                if (!success) {

                    return false;

                }

            }

        }

        // 目录此时为空，可以删除

        return dir.delete();

    }



}

测试类：

import java.io.File;



/**

 * 文件炸弹测试类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2023/10

 */

public class Test {



    public static void main(String[] args) {

        File bomb = new File("D:\temp\3\zbsm.zip");

        File tempFile = new File("D:\temp\3\4");

        try {

            FileBombUtil.unzip(bomb, tempFile, FileBombUtil.FILE_LIMIT_SIZE * 60);

        } catch (IllegalArgumentException e) {

            if (FileBombUtil.FILE_LIMIT_SIZE_MSG.equalsIgnoreCase(e.getMessage())) {

                FileBombUtil.deleteDir(tempFile);

                System.out.println("原始文件太大");

            } else {

                System.out.println("错误的压缩文件格式");

            }

        } catch (Exception e) {

            e.printStackTrace();

        }

    }



}

三、总结

文件炸弹是一种恶意的计算机程序或文件，旨在利用压缩算法和递归结构来创建一个巨大且无限增长的文件或文件集
合。它的目的是消耗目标系统的资源，如磁盘空间、内存和处理能力，导致系统崩溃或无法正常运行。文件炸弹可能是有意制造的攻击工具，用于拒绝服务（DoS）攻击或滥用资源的目的。

文件炸弹带来的危害极大，作为开发人员，我们必须深刻认识到文件炸弹的危害性，并始终保持高度警惕，以防止这种潜在漏洞给恐怖分子以可乘之机。

总而言之，我们作为开发人员，要深刻认识到文件炸弹的危害性，严防死守，不给恐怖分子任何可乘之机。通过使用安全工具、限制文件大小、及时更新软件、定期备份数据以及加强安全意识，我们可以有效地防止文件炸弹和其他恶意活动对系统造成损害。

在中国，网络安全和计算机犯罪问题受到相关法律法规的管理和监管。以下是一些中国关于网络安全和计算机犯罪方面的法律文献，其中也涉及到文件炸弹的相关规定：

1. 
   

   《中华人民共和国刑法》- 该法律规定了各种计算机犯罪行为的法律责任，包括非法控制计算机信息系统、破坏计算机信息系统功能、非法获取计算机信息系统数据等行为，这些行为可能涉及到使用文件炸弹进行攻击。

   
   


2. 
   

   《中华人民共和国网络安全法》- 该法律是中国的基本法律，旨在保障网络安全和维护国家网络空间主权。它规定了网络安全的基本要求和责任，包括禁止制作、传播软件病毒、恶意程序和文件炸弹等危害网络安全的行为。

   
   


3. 
   

   《中华人民共和国计算机信息系统安全保护条例》- 这是一项行政法规，详细规定了计算机信息系统安全的保护措施和管理要求。其中包含了对恶意程序、计算机病毒和文件炸弹等威胁的防范要求。

   
   

面试官：小伙子，了解HashMap吗?

学弟：哎呦，你干嘛～ 真的问这个呀....

面试官：呦，练习时长两年半？待会答不上来，你可就遭老罪喽！

那行吧，那开始吧...唱跳rap篮球🏀......

一、HashMap的底层结构

说一下你理解的HashMap底层？

hashMap是由数值和链表组合而成的数据结构，存储为key Value形式。

在java7中叫entry，数据形式为数组+链表。java8中叫Node，数据形式为数组+链表+红黑树（当链表长度大于8时转为红黑树）。

每一个节点都会保存自身的hash、key、value、以及next属性指向下一个节点。

二、为什么使用数组+链表数据结构

你刚提到了使用数组+链表，可以讲讲为什么使用这个结构吗？

HashMap内部使用数组来存储键值对，这个数组就是 HashMap 的主体。

在数组中存储的每个位置上，可能会有多个键值对，这些键值对通过链表的形式链接在一起。

使用数组+链表的数据结构是为了解决散列表中的键冲突问题。在散列表中，每个键都会被映射到一个桶中，但是不同的键可能会被映射到同一个桶中，这种情况被称为键冲突。

为了解决键冲突问题，HashMap 采用了链表的形式将所有映射到同一个桶中的键值对链接在一起，这样就可以通过遍历链表来查找指定键的值。当链表长度过长时，查找效率就会下降，因此在链表长度超过一定阈值（8）后，HashMap会将链表转换为红黑树，以提高查找效率。

同时，数组的优势在于支持通过下标快速访问元素，因此HashMap可以将每个桶的位置映射到数组的一个元素上，通过下标访问该元素即可访问到对应的链表或红黑树。

我们都知道：数组的查询效率很高，添加和删除的效率低。链表的查询效率很低，添加和删除的效率高。

因此：使用数组加链表形式，不仅可以解决散列表中的键冲突问题，且数组的查询效率高、链表的添加和删除效率高。结合在一起，增删查效率都很高。

嗯，确实不错。不愧是练习时长两年半的程序员.....

三、数组+链表+红黑树

你刚说数组+链表+红黑树，什么情况下会转化红黑树？什么情况下转数组呢？

链表中元素过多，会影响查找效率，当其个数达到8的时候转换为红黑树。红黑树是平衡二叉树，在查找性能方面比链表要高。

当红黑树的节点数小于等于6时，红黑树转换为链表，是为了减少内存开销。

需要注意的是：将链表转换为红黑树、红黑树转换为链表的操作会影响HashMap的性能，因此需要尽可能避免这种情况的发生。同时，当HashMap中的元素数量较小时，不会出现链表转换为红黑树的情况，因此使用HashMap时，可以考虑在元素数量较少的情况下使用HashMap，以提高性能。

四、头插法和尾插法

说一下什么是头插法，什么是尾插法？

哇，这不是为难我胖虎吗？啥是头插法？啥是尾插法？

4.1、头插法

顾名思义，头插法就是新增元素时，放在最前面嘛。

举个栗子🌰，楼主画了一个简单的框框。用来表示原有存储顺序依次为1、2、3的数组。

假设现在加入了一个4，如果使用头插法，就会变为4123。

4.2、尾插法

同样道理，尾插法就是新增元素时，放在最后面。

还是原有存储顺序依次为1、2、3的数组。

假设现在加入了一个4，如果使用尾插法，就会变为1234。

头插法为什么要调整为尾插法呢？

为什么头插法要调整为尾插法？这是个好问题！！！

java7中使用头插法，新来的值会取代原有的值，原有的值就顺推到链表中。在这种情况下，引用关系可能会乱掉，严重会造成死循环。java8使用尾插法，把元素放到最后，就不会出现这种情况。

五、HashMap如何运算存储索引

向一个hashMap中存入数据时，如何知道数据放在哪个位置呢？

当向一个hashMap中存入数据时，会先根据key的哈希值决定放在数组中哪个索引位置。

Hash公式：index = HashCode（Key） & （Length - 1）

如果数组中该索引位置是空的，直接将元素放入，如果该索引位置已经存在元素了，就根据equals方法判断下已有的元素是否和我们新放入的元素是同一个，如果返回true是同一个，则覆盖掉。不是同一元素则在原有元素下面使用链表进行存储。

每个元素都有一个next属性指向下一个节点（数组+链表）

    /**

     * Basic hash bin node, used for most entries.  (See below for

     * TreeNode subclass, and in LinkedHashMap for its Entry subclass.)

     */

    static class Node<K,V> implements Map.Entry<K,V> {

        final int hash;

        final K key;

        V value;

        Node<K,V> next;

        .........

    }

六、HashMap初始化、扩容

嗯，你知道HashMap默认初始化大小是多少吗？还有它的扩容？

HashMap默认初始化容量大小是16，最大容量为2的30次方，负载因子是0.75。

扩容时，会把原有数组中的值取出再次hash到新的数组中（长度扩大以后，Hash的规则也随之改变），因此性能消耗也相对较大。

当HashMap中的元素数量超过负载因子（默认为 0.75）乘以数组长度时，就会触发扩容操作，将数组长度增加一倍，并重新计算每个元素在新数组中的位置。

七、hash碰撞是什么

你听说过hash碰撞吗？

hash碰撞就是不同的Key，经过同一散列算法之后得到的hashCode值相同。

hashCode不同，key一定不同。hashCode相同，key却不一定相同。

当两个key的hashCode()返回值不同时，它们对应哈希表索引也一定不同。不同的key对象，即使它们包含相同的属性、值或状态，它们的hashCode()返回值也是不相同的。

当两个key的hashCode()返回值相同时，它们可能对应同一个哈希表索引，但它们并不一定相等。在哈希表中，不同的key可能会产生相同的哈希值（哈希碰撞）。

因此，当 key的hashCode相同时，还需要比较key的相等性。需要调用key的equals() 方法来判断它们是否相等。只有当hashCode相等，且equals方法返回true时。才可以认为这两个key相等。

八、如何解决hash碰撞

解决hash碰撞的方法有哪些呢？

在哈希表中，哈希碰撞可能会导致性能下降或者安全问题。

常见的解决方法有：

1、开放地址法：在发生哈希碰撞时，通过一定的算法在哈希表中寻找一个空闲的位置，并将元素插入该位置。

2、链式哈希表：在每个哈希表的元素位置上，存储一个链表，哈希碰撞时，将元素插入到相应的链表中。

3、再哈希法：如果一个哈希函数产生的哈希值发生了碰撞，就再次使用另一个哈希函数计算哈希值。

4、负载因子调整：通过调整哈希表的容量、负载因子等参数，可以减少哈希碰撞的发生。

九、HashMap为什么线程不安全

HashMap线程安全吗？为什么？

HashMap是非线程安全的。在多线程环境下，如果多个线程同时修改HashMap中的数据，就可能会导致数据的不一致性。

说白了就是没加锁。

当多个线程同时调用HashMap的put()方法，一旦他们计算出的hash值相同，就会发生冲突，导致数据被覆盖。

所以，对于多线程并发访问的情况，建议使用线程安全的Map实现。

例如ConcurrentHashMap，或者使用Collections.synchronizedMap()方法将HashMap包装成一个线程安全的Map。

十、HashMap、HashTable、ConcurrentHashMap的区别

最后一个问题：说一下HashMap、HashTable、ConcurrentHashMap的区别？

麻了! 真的麻了....救救孩子吧....

HashMap、HashTable、ConcurrentHashMap都是Java中常用的哈希表实现。

区别主要在以下几个方面：

1、线程安全性：HashTable是线程安全的，HashMap是非线程安全的，ConcurrentHashMap通过分段锁的方式保证了线程安全。

2、是否可为空：HashTable不允许value为空，ConcurrentHashMap不允许null值作为key或value，而HashMap则允许null作为key或value。

3、迭代器：HashTable的迭代器是通过Enumeration实现的，而HashMap和ConcurrentHashMap使用的是Iterator实现的。

4、扩容：HashTable在扩容时，将容量扩大一倍加一，而HashMap和ConcurrentHashMap的扩容机制是将容量扩大一倍。

5、初始容量：HashTable的初始容量为11，而HashMap和ConcurrentHashMap的初始容量为16。

6、性能：HashMap通常比HashTable性能更好，因为它没加锁。所以弊端就是线程不安全。但后者加了锁，是线程安全的，缺点就是消耗性能。ConcurrentHashMap在多线程并发访问时，比HashTable和HashMap性能更好，因为它使用了分段锁来保证线程安全。

所以，不建议使用HashTable。至于选择HashMap还是ConcurrentHashMap取决于并发访问量的大小，若并发访问量不高，则选用HashMap。若并发访问量较大，则选用ConcurrentHashMap。

ok，那今天先到这里吧。练习时长两年半的程序员.....唱跳rap篮球🏀....差点就遭老罪喽～

还有，别忘记给那个练习时长两年半的三婶儿也点个赞哈～她唱跳rap篮球也还行......

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

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

1. 结果和目标极其模糊。


2. 需要协调其他团队干活但是对方很不配合。


3. 领导也不知道怎么干

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

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

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

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个好处；

1. 
   

   降低实现难度，减少上线风险。

   
   


2. 
   

   缩短开发周期，尽快摆脱这个项目。

   
   


3. 
   

   把更多的时间放在汇报材料上。代码没人看！！！

   
   

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

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

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

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

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

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

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

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

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

5.1 寻求合作的最大公约数

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

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

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

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

1. 
   

   平时多和相关同学打好关系。平时奶茶咖啡多送点，吃别人嘴短，到时候求人时候很管事的。

   
   


2. 
   

   调动对方的积极性！例如重构系统需要人家配合，但是这件事对他们又没有收益。可以和他们一起头脑风暴，想一下对方系统可以做哪些重构。当双方一拍即合，各取所需时，才能合作融洽。双赢的合作，才能顺利。

   
   


3. 
   

   多作妥协。上下游系统的交互边界很难划分，如果交互存在争议，可以适当让步，换取对方的积极合作。完成胜于完美！

   
   

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

6、争取更多的资源支持

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

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

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

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

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

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

7、能分期就分期

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

1. 
   

   越复杂的技术方案越容易出问题！

   
   


2. 
   

   越长的开发周期越容易出问题！

   
   


3. 
   

   越想一次性完成，越容易忙中出错！

   
   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前言

抓包工具是一种在计算机网络中进行调试和分析的强大工具，它能够拦截、查看和分析在网络中传输的数据包内容。通过捕获这些数据包，我们可以深入挖掘其中包含的大量有用信息。抓包工具不仅提供了直观和可视化的界面，而且具有强大的过滤和分析功能，使用户能够轻松地掌握网络数据流量的细节。

在计算机通信中，数据包是由发送端（如浏览器或应用程序）构建的，并通过互联网传输到接收端（如服务器或另一台计算机）。通常情况下，这些数据包由发送和接收的应用程序自行处理，用户往往无法直接观察这些数据包的内容。然而，抓包工具可以截取这些数据包，并将其内容以明文或加密的形式展示给用户。如果数据包是以明文形式发送的，或者我们可以推断出其加密方法，那么我们就可以对这些数据包进行深入的分析和解密。这样，我们便可以了解这些数据包的内容、用途和意义。

通过使用抓包工具，开发人员和系统管理员可以调试和分析网络应用程序和通信协议，以便更好地了解它们的性能、安全性和可靠性。此外，普通用户也可以利用抓包工具来了解他们正在使用的应用程序和网络服务的内部工作原理，并保障他们的网络安全和隐私。总之，抓包工具是计算机网络中不可或缺的一部分，它为我们提供了深入洞察和分析网络数据流量的能力。

抓包工具更多的分析网络流量以及数据包内容、检测网络问题、获取数据传输的详细信息、功能调试等。市面上常见的抓包工具有很多，比如说我们网页上常用到的浏览器开发者工具、移动端常用的vConsole以及市面上大家都在用的Charles和whistle，今天就简单给大家分享一下whistle的基本使用。

1. 简介

whistle主要是基于node来实现的一个跨平台web调试代理工具，whistle采用的是类似配置系统hosts的方式，一切操作都可以通过配置实现，支持域名、路径、正则表达式、通配符、通配路径等多种匹配方式，且可以通过Node模块扩展功能：

2. 安装启动

wproxy.org/whistle/ins…

1. 环境

首先要使用whistle的话，必须要具备node环境(下载地址)，下载成功后可以通过命令行来查看是否已安装

node -v // 查询当前node版本信息

2.安装whistle

后面也会提到桌面端应用LightProxy，也是基于Electron和whistle的桌面端代理软件。

npm install -g whistle // Windows

sudo npm install -g whistle // Mac(非root权限)

安装成功可以使用命令whistle help 或者w2 help查看whistle的相关帮助信息

3.启动whistle

最新版本的whistle支持三种等价的命令whistle、w2、wproxy

w2 start // 启动whistle

w2 restart // 重启whistle

w2 stop // 停止whistle

w2 run // 调试模式启动whistle

4.配置代理

这里就以Mac配置举例，可以在设置->Wi-Fi->详细信息->代理中选择网页代理(HTTP)填入对应的ip以及端口号;

移动端这里同样以IOS为例，在Wi-Fi->HTTP代理中打开配置代理为手动，同时填入对应ip以及端口号.

我们也可以通过chrome浏览器插件SwitchyOmega来进行网页代理

1. 点击新建情景模式


2. 选择选项代理服务器


3. 配置代理协议、代理ip、代理端口


4. 点击应用选项保存并切换到代理模式

5.证书安装

最后我们只需要安装根证书即可。我们打开whistle生成的浏览器生成页，点开HTTPS选项，点击二维码下载证书，这里同样以MAC和IOS为例。

1.Mac我们打开钥匙串访问，这里要注意，当我们添加完成后依旧属于不被信任状态，我们需要双击证书，在信任的里面找到使用此证书时选中始终信任，配置证书完成后我们选中Capture TUNNEL CONNECTS即可代理成功，捕捉传输内容。

2.IOS同样我们通过扫码打开证书，允许描述配置文件下载，在设置已下载描述文件中安装描述文件，安装完成后我们打开通用->关于本机->证书信任设置中选择对下载的whistle证书启用完全信任即可。

如果是windows系统出现证书无法下载的情况，进入系统设置 - 网络 - Windows防火墙 - 高级设置，设置入站规则Node.js开头的都允许连接，保存确定下载；

手机端偶尔可能会遇到无法找到证书的情况，可以连接同一个局域网，访问电脑ip代理对应ip地址，扫码HTTPS进行证书下载

3.使用

whistle官网这里详细介绍了whistle相关的命令行参数，这里我们就不过多赘述。我们只介绍几个常用的功能。

1.HTTPS请求抓取:

所有配置完成后，我们打开whistle页面，浏览器或手机发起HTTPS请求后即可看到.

那么问题来了，这么多请求同时包含了预检等众多请求，我们怎么快速找到我们需要看到的接口呢？
我们可以在下方的Type filter text来进行简单的搜索功能，默认是按照url来进行搜索的,我们也可以按照固定的分类规则来进行快速查询

1. 默认搜索url


2. h: {word}搜索头部


3. c: {word}搜索内容


4. p: {word}搜索请求协议


5. o: {word}搜索ip


6. m: {word}搜索方法


7. s: {word}搜索状态码

如果我们依旧觉得不够清晰该怎么办呢，我们就可以用到whistle的Rules功能，Rules支持我们通过扩展系统host配置来进行所有操作。

// whistle将通过pattern匹配来完成对应uri的操作

pattern operatorURI

pattern的匹配规则支持域名、路径、正则、精准匹配和通配符匹配

api.juejin.cn style://color=@fff&fontStyle=italic&bgColor=red

这样我们就可以更清晰的来找到我们想捕捉的内容。

2.请求响应修改

我们可以通过固定的Rules配置来对请求或者返回来进行修改测试

{pattern} method://get 请求方式修改为get

{pattern} statusCode://500 请求状态码返回500

{pattern} log:// 日志打印

{pattern} resCors:// 跨域

以上提到的是我们部分的简单修改，如果我们需要修改请求的请求体以及相应内容，我们就需要用到whistle提供的Values板块来进行配置

{pattern} reqHeaders://filepath 修改请求头 //filepath: Values里面的key或者本地文件

// reqHeaders example

{pattern} reqHeaders://{testReqHeadersJSON}

// resBody example

{pattern} resBody://{testResBodyJSON}

Values模版中配置testReqHeadersJSON和testResBodyJSON

这样就可以添加或者修改请求头内容，修改或添加响应内容同理。

3.移动端调试

whistle不仅提供强大的web调试功能，对于移动端的调试也是十分友好的。

由于移动端需要适配众多不同的浏览器和设备，包括各种尺寸的屏幕、各种操作系统和不同的设备载体，因此相对于PC端的页面调试，移动端的调试难度更加复杂。在出现问题时，排查的过程也涉及更多因素，需要我们及时发现并修复问题。对于一个合格的开发人员来说，强大的开发能力是基础，同时还需要拥有快速解决问题的能力和精准定位问题的技能，这样才能够在面对不同的问题时应对自如、犹游刃有余。

像我们在测试环境常用到的vConsole一般是不会在生产环境以一般方式展现给用户的，但是whistle提供注入js的方法能够让我们通过js代码以及vConsole等工具来进行页面调试以及问题的快速排查。

1.接口调试

这里我们就简单的以掘金首页为例

1. 我们在Values中配置好vConsole以及对应生成实例代码；


2. 在Rules中通过jsPrepend进行js注入
   这样我们就可以成功生成vConsole来进行调试了

vConsole.min.js的源码我们可以去github上自行下载，或者也可以通过插件来解决。

// 集成 vConsole、eruda、mdebug 等调试H5页面工具的插件

sudo npm install -g whistle.inspect

{pattern} whistle.inspect://vConsole

{pattern} whistle.inspect://eruda

{pattern} whistle.inspect://mdebug

2. 元素样式调试

whistle同时内置了Weinre和Chii来帮助我们进行调试

{pattern} weinre://{yourName}

配置Rules后我们在Whistle下拉选项下选中对应name，重新打开页面后即可进行elment调试

{pattern} 同样配置Rules后我们在Whistle选项下的Plugins选中对应Chii，点击打开后选择inspect来进行element调试

{pattern} whistle.chii://

4.LightProxy

下载地址

LightProxy是基于whistle使用electron开发的一个桌面端代理软件，从操作以及证书代理配置上更加简单灵活，更好的满足开发者的需求，基本使用规则同whistle一致；同时也帮我们继承了常用的像inspect、vase等插件，更加方便快捷。

5.总结

Whistle作为常用的的网络调试工具之一，它不仅具备常规的抓包功能，还在跨域代理等方面展现了多样化的应用。通过巧妙的配置和强大的功能，我们可以进行深度定制和扩展，以满足各种复杂的调试需求。

这个工具的应用场景非常广泛，从简单的HTTP/HTTPS请求拦截，到复杂的爬虫和自动化测试，都可以借助Whistle实现。同时，它还支持JavaScript、TypeScript等多种编程语言，以及各种浏览器和Node.js环境。

使用Whistle进行调试非常简单，只需要简单地设置和配置，就可以轻松地实现对网络请求的拦截和修改。无论是排查问题、测试接口还是调试前端代码，Whistle都能够帮助我们快速定位问题并解决问题。它的易用性和灵活性也使得它成为了前端开发人员的得力助手。

通过使用Whistle，我们可以更好地了解网络请求的细节，掌握API接口的调用和数据传输的规律。这有助于我们优化代码、提高程序的稳定性和性能。因此，无论是初学者还是经验丰富的开发者，都应该尝试使用Whistle来提升自己的调试技能和开发效率。

参考

1.whistle官网: wproxy.org/whistle/

序言

我是一名全栈工程师，98年，正宗的湖南妹子，17年开始出来工作，一转眼已经工作6年了，回想起从工作至今，忙忙碌碌，没有停歇，也无法静下心来好好思考.

如今终于有时间，停下脚步，回想起过往，记忆也越来越模糊，也害怕自己最后不再记得当时的一路艰辛，想留点记录哪天等到不再做这行了闲下心来翻翻吧。

一路走来，相比同龄人还在校园读书时，由于家境窘迫，不得不早点踏入社会，尝遍酸甜苦辣。尽管一路上经历了漫长的痛苦、艰辛、泪水，但也获得了成长、温暖和最终的归宿。如果有时光回溯，可以重来一次，我还是会做出当初一样的选择，虽有遗憾，但不后悔。

文章大概脉络主要就是讲述了我是怎么踏入互联网这个行业，经历了互联网的飞速发展时期直至巅峰，又到目前经济衰条，一路磕磕绊绊，以及最后的人生规划吧。

以下描述也都是本人的真实经历，没有经历过的或许会唏嘘，因此大家就权当个乐子或者生活调剂看吧！

接上文~我当程序媛那些年(三)

相遇

从H城市到S城市距离不远，高铁大概1个小时，我们相约在人广见面，虽然见面之前已经见过照片了，但没见过真人，怕有点脸盲一时半会儿认不出哈哈~

ps:等待的过程是有点期待和忐忑不安的，如果大家也有过这种经历，相信差不多都是这样的心情大差不差😂

经过十多分钟的等待，我们终于快要见面，因为是五一的原因，所以那天人广人很多，正准备上电梯扶手时，我恍然间好像感觉到有人拍了一下我的肩膀，回头侧身一看。没有看到熟悉的身影。

正当我以为是我的错觉，刚好到电梯口的时候，一个身影窜到我面前(那画面脑补一下有点搞笑😂)，定睛注意一看，才发现眼前站了一个熟悉的人。背着书包，带着眼镜，斯斯文文，是典型的互联网宅男形象没跑了哈哈~(当然这里不是取笑之意，只是觉得这个形容词生动有趣😆)

因为是放假，所以我们前期就沟通好了去哪里玩。可能是因为初次见面，双方都有些拘谨，路上去聊到玩的地方话题才开始多了起来。

因为我本身就是性格外向，比较活泼的人。不熟悉我的人对我的第一印象可能是有点安静(实际正好相反哈哈~)，熟悉了就是话匣子，虽然偶尔性格上会透露出女汉子的气质哈哈~

也许是有比较长的一段时间没有和身边熟悉的人聊过天,所以聊到有趣的话题时，嗯~我话会比较多，属于压根不用担心会冷场的那种🤣。

我们首先去了迪斯尼，晚上的迪斯尼烟花很美。那天虽然是尽兴而归，如果是约会或者和朋友一起的真的不建议节假日去玩哈哈~，人真的超多，排队排了一天只玩了差不多两三个项目额。。。。所以之后我们出去玩都再也不去人潮拥挤的地方(没出去玩过被坑一次就长记性了😂)。

后面两天为了缓解一下疲惫，没有去往那种要排很长的队伍景点了，陆续去参观了一下S市的动物园，以及H市的西湖等。

生病危机

继五一过后，开始回归日常的上班族生活，那次见面之后，加上假期几天的相处，之前也有过联系(虽然没见面)，但是从谈吐、学识以及工作方面，我们都觉得互相很合拍，共同话题很多，所以我们后面不久就确认了关系，不过由于Z先生是在H市，所以我们前期算是属于异地恋。

上了一周班后，某天下班感觉腹部有点疼痛，一看伤口有些红肿，感觉就是被虫子咬了，至于是什么虫子，就不得而知了。于是我回家买了红霉素软膏涂了一下，感觉稍稍有些缓解。

我以为过几天就会好，当时也没多想，甚至没想着去医院看看，结果这一忽视，差点让我丢了小命`(>﹏<)′

过了几天，伤口越来越恶化，渐渐开始有脓水出现。我感觉情况有点不对，打算周末去医院看看。由于当时Z先生工作是在杭州，我们确认关系后约的都是周末见面，因此我当时就去了H市的医院。

令我没想到的是，这次H市的医院之旅，差点要了我的小命。起初找的也算是H市的三甲医院了，当时虽然就确认了是蜱虫叮咬，但是给的药物却并没有完全治好我的伤口，我不知道是不是我体质原因还是药物就没啥效果额，虽然最后花了一千多(⊙﹏⊙)。。。。

后面两天病情突然一下子就恶化的很快，腹部周围开始也全是脓，伤口开始剧烈疼痛，不能碰触的那种。

但是医生说脓水必须挤掉，我只记得当时算是痛彻心扉了，怎么形容呢，就似乎有人拿了把刀在你的腐肉上刮，还不打麻醉药的那种，挤脓的时候痛的都感觉有点意识模糊了。

当时Z先生看到治疗没效果，果断放弃继续治疗，请假带我直奔S市的专业皮肤科医院。当时伤口已经恶化到没有办法再继续上班，坐往前往S市的高铁一直到医院时，一边走伤口一边在流脓血，可想而知有多严重了。

后面到了S市的医院，医生简单的看了一下，我也把之前开的药给医生检查了一下，最终医生开了一套中药，直接热敷在伤口上，从看病－＞开药－＞敷药，整个时间大概持续了两三个小时。

在这里真的得感叹一句中药材的神奇，敷完药大概一个小时，伤口脓血已经止住，伤口疼痛也几乎缓解，红肿情况开始好转，感觉就好像在死亡的边缘跑了一趟突然能喘上气来的那种，算是毫不夸张了。

待我好些了之后，医生才开始跟我详细的说明了一下，他说我伤口之所以会恶化的这么严重，是因为蜱虫的尸体和毒素都留在了伤口里面，不清理出来只会越来越严重。

我问医生，我没有去蚊虫比较多的地方，为什么会无故染上这种虫子，医生问我是不是有去过公园或者草地呆过，像公园或者草地有的人会带猫猫狗狗啥的，动物身上最容易有沾染这种虫子，一旦沾到人体，后果不堪设想。

听到这里，我心里忽然一惊，想想放假的时候有在西湖边的草坪上坐过休息一会儿，那就有可能是那时沾染上的了。关键是这种虫子咬了还毫无感觉的那种，想想要多恐怖有多恐怖了😭。

随后医生还说，我这伤口算是恶化到最后严重的时期了，再晚来一周，小命估计都不保了。。。。。。

ps: 说到这里jym就得注意了，如果是女生或者有女朋友的男士们，千万千万去公园不要做草地，反正尽量多注意一下吧！！！！

经过这次，真是一朝被蛇咬，十年怕井绳，从此对虫子类心生恐惧，尤其是蜱虫、隐翅虫。

至于隐翅虫为什么也很恐怖，额外说个小故事吧，算是亲眼见证的。

之前读初中的时候，由于是在农村，夏天晚上教室亮的时候会有很多隐翅虫飞进来，有的飞在灯泡上，有的飞在书桌上，当时班上一位女同学晚自习的时候，摁了一下隐翅虫，估计是没有洗手，然后摸了一下脸，然后就是没过两天，人就请假了，一周多才回来，整个脸脱了一层皮(一点都不带夸张，事实就是这样额)。。。。。

ps:也给各位jym提个醒，被虫子咬了如果不知道是什么虫子咬的，最好及时去医院看，千万不要拖！！！不然像我一样倒霉就得不偿失了😖，最后贴一下蜱虫和隐翅虫的照片，给大家提个醒。

文章以待后续。。。。如果觉得文章写的不错，那就给个赞或者关注一下吧，你的支持将是我写文最大的动力！

近期文章预览

我当程序媛那些年(一)

我当程序媛那些年(二)

我当程序媛那些年(三)

我当程序媛那些年(四)

在 Spring Boot 出现之前，我们要运行一个 Java Web 应用，首先需要有一个 Web 容器（例如 Tomcat 或 Jetty），然后将我们的 Web 应用打包后放到容器的相应目录下，最后再启动容器。

在 IDE 中也需要对 Web 容器进行一些配置，才能够运行或者 Debug。而使用 Spring Boot 我们只需要像运行普通 JavaSE 程序一样，run 一下 main() 方法就可以启动一个 Web 应用了。这是怎么做到的呢？今天我们就一探究竟，分析一下 Spring Boot 的启动流程。

概览

回看我们写的第一个 Spring Boot 示例，我们发现，只需要下面几行代码我们就可以跑起一个 Web 服务器：

@SpringBootApplication

public class HelloApplication {

	public static void main(String[] args) {

		SpringApplication.run(HelloApplication.class, args);

	}

}

去掉类的声明和方法定义这些样板代码，核心代码就只有一个 @SpringBootApplication 注解和 SpringApplication.run(HelloApplication.class, args) 了。而我们知道注解相当于是一种配置，那么这个 run() 方法必然就是 Spring Boot 的启动入口了。

接下来，我们沿着 run() 方法来顺藤摸瓜。进入 SpringApplication 类，来看看 run() 方法的具体实现：

public class SpringApplication {

	......

	public ConfigurableApplicationContext run(String... args) {

		// 1 应用启动计时开始

		StopWatch stopWatch = new StopWatch();

		stopWatch.start();

		

		// 2 声明上下文

		DefaultBootstrapContext bootstrapContext = createBootstrapContext();

		ConfigurableApplicationContext context = null;

		

		// 3 设置 java.awt.headless 属性

		configureHeadlessProperty();

		

		// 4 启动监听器

		SpringApplicationRunListeners listeners = getRunListeners(args);

		listeners.starting(bootstrapContext, this.mainApplicationClass);

		try {

			// 5 初始化默认应用参数

			ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);

			

			// 6 准备应用环境

			ConfigurableEnvironment environment = prepareEnvironment(listeners, bootstrapContext, applicationArguments);

			configureIgnoreBeanInfo(environment);

			

			// 7 打印 Banner（Spring Boot 的 LOGO）

			Banner printedBanner = printBanner(environment);

			

			// 8 创建上下文实例

			context = createApplicationContext();

			context.setApplicationStartup(this.applicationStartup);

			

			// 9 构建上下文

			prepareContext(bootstrapContext, context, environment, listeners, applicationArguments, printedBanner);

			

			// 10 刷新上下文

			refreshContext(context);

			

			// 11 刷新上下文后处理

			afterRefresh(context, applicationArguments);

			

			// 12 应用启动计时结束

			stopWatch.stop();

			if (this.logStartupInfo) {

				// 13 打印启动时间日志

				new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);

			}

			

			// 14 发布上下文启动完成事件

			listeners.started(context);

			

			// 15 调用 runners

			callRunners(context, applicationArguments);

		}

		catch (Throwable ex) {

			// 16 应用启动发生异常后的处理

			handleRunFailure(context, ex, listeners);

			throw new IllegalStateException(ex);

		}



		try {

			// 17 发布上下文就绪事件

			listeners.running(context);

		}

		catch (Throwable ex) {

			handleRunFailure(context, ex, null);

			throw new IllegalStateException(ex);

		}

		return context;

	}

	......

}

Spring Boot 启动时做的所有操作都这这个方法里面，当然在调用上面这个 run() 方法之前，还创建了一个 SpringApplication 的实例对象。因为上面这个 run() 方法并不是一个静态方法，所以需要一个对象实例才能被调用。

可以看到，方法的返回值类型为 ConfigurableApplicationContext，这是一个接口，我们真正得到的是 AnnotationConfigServletWebServerApplicationContext 的实例。通过类名我们可以知道，这是一个基于注解的 Servlet Web 应用上下文（我们知道上下文（context）是 Spring 中的核心概念）。

上面对于 run() 方法中的每一个步骤都做了简单的注释，接下来我们选择几个比较有代表性的来详细分析。

应用启动计时

在 Spring Boot 应用启动完成时，我们经常会看到类似下面内容的一条日志：

Started AopApplication in 2.732 seconds (JVM running for 3.734)

应用启动后，会将本次启动所花费的时间打印出来，让我们对于启动的速度有一个大致的了解，也方便我们对其进行优化。记录启动时间的工作是 run() 方法做的第一件事，在编号 1 的位置由 stopWatch.start() 开启时间统计，具体代码如下：

public void start(String taskName) throws IllegalStateException {

    if (this.currentTaskName != null) {

        throw new IllegalStateException("Can't start StopWatch: it's already running");

    }

    // 记录启动时间

    this.currentTaskName = taskName;

    this.startTimeNanos = System.nanoTime();

}

然后到了 run() 方法的基本任务完成的时候，由 stopWatch.stop()（编号 12 的位置）对启动时间做了一个计算，源码也很简单：

public void stop() throws IllegalStateException {

    if (this.currentTaskName == null) {

        throw new IllegalStateException("Can't stop StopWatch: it's not running");

    }

    // 计算启动时间

    long lastTime = System.nanoTime() - this.startTimeNanos;

    this.totalTimeNanos += lastTime;

    ......

}

最后，在 run() 中的编号 13 的位置将启动时间打印出来：

if (this.logStartupInfo) {

    // 打印启动时间

   new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);

}

打印 Banner

Spring Boot 每次启动是还会打印一个自己的 LOGO，如图：

这种做法很常见，像 Redis、Docker 等都会在启动的时候将自己的 LOGO 打印出来。Spring Boot 默认情况下会打印那个标志性的“树叶”和 “Spring” 的字样，下面带着当前的版本。

在 run() 中编号 7 的位置调用打印 Banner 的逻辑，最终由 SpringBootBanner 类的 printBanner() 完成。这个图案定义在一个常量数组中，代码如下：

class SpringBootBanner implements Banner {



    private static final String[] BANNER = {

            "", 

            "  .   ____          _            __ _ _",

            " /\\\\ / ___'_ __ _ _(_)_ __  __ _ \\ \\ \\ \\", 

            "( ( )\\___ | '_ | '_| | '_ \\/ _` | \\ \\ \\ \\",

            " \\\\/  ___)| |_)| | | | | || (_| |  ) ) ) )", 

            "  '  |____| .__|_| |_|_| |_\\__, | / / / /",

            " =========|_|==============|___/=/_/_/_/" 

    };

    ......

        

	public void printBanner(Environment environment, Class sourceClass, PrintStream printStream) {

		for (String line : BANNER) {

			printStream.println(line);

		}

		......

	}



}

手工格式化了一下 BANNER 的字符串，轮廓已经清晰可见了。真正打印的逻辑就是 printBanner() 方法里面的那个 for 循环。

记录启动时间和打印 Banner 代码都非常的简单，而且都有很明显的视觉反馈，可以清晰的看到结果。拿出来咱们做个热身，配合断点去 Debug 会有更加直观的感受，尤其是打印 Banner 的时候，可以看到整个内容被一行一行打印出来，让我想起了早些年用那些配置极低的电脑（还是 CRT 显示器）运行着 Win98，经常会看到屏幕内容一行一行加载显示。

创建上下文实例

下面我们来到 run() 方法中编号 8 的位置，这里调用了一个 createApplicationContext() 方法，该方法最终会调用 ApplicationContextFactory 接口的代码：

ApplicationContextFactory DEFAULT = (webApplicationType) -> {

    try {

        switch (webApplicationType) {

            case SERVLET:

                return new AnnotationConfigServletWebServerApplicationContext();

            case REACTIVE:

                return new AnnotationConfigReactiveWebServerApplicationContext();

            default:

                return new AnnotationConfigApplicationContext();

        }

    }

    catch (Exception ex) {

        throw new IllegalStateException("Unable create a default ApplicationContext instance, "

                                        + "you may need a custom ApplicationContextFactory", ex);

    }

};