我们都知道JavaScript有== (强制相等)和===(严格相等)运算符进行比较。但你可能不知道它们两个究竟有什么不同，并且更重要的是，在 js 引擎中使用它们的时候发生了什么?

前面我们提到 == 是强制比较。强制意味着 VM 试图将进行比较的双方强制为相同的类型，然后查看它们是否相等。以下我们列举了一些自动被强制相等的例子:

"1" == 1 // true

1 == "1" // true

true == 1 // true

1 == true // true

[1] == 1 // true

1 == [1] // true

你要知道，强制是对称的，如果a == b为真，那么b == a也为真。另一方面，只有当两个操作数完全相同时===才为真(除了Number.NaN)。因此，上面的例子都真实的情况下都是假真 （即，在 === 的情况下是 false 的）。

为什么强制相等有这样的问题，这要归咎与强制相等的规则。

强制相等的规则

实际的规则很复杂(这也是不使用==的原因)。但是为了显示规则有多么复杂，我通过使用===实现了==，带大家看看强制相等的规则到底多复杂：

function doubleEqual(a, b) {

  if (typeof a === typeof b) return a === b;

  if (wantsCoercion(a) && isCoercable(b)) {

    b = b.valueOf();

  } else if (wantsCoercion(b) && isCoercable(a)) {

    const temp = a.valueOf();

    a = b;

    b = temp;

  }

  if (a === b) return true;

  switch (typeof a) {

    case "string":

      if (b === true) return a === "1" || a === 1;

      if (b === false) return a === "0" || a === 0 || a == "";

      if (a === "" && b === 0) return true;

      return a === String(b);

    case "boolean":

      if (a === true) return b === 1 || String(b) === "1";

      else return b === false || String(b) === "0" || String(b) === "";

    case "number":

      if (a === 0 && b === false) return true;

      if (a === 1 && b === true) return true;

      return a === Number(String(b));

    case "undefined":

      return b === undefined || b === null;

    case "object":

      if (a === null) return b === null || b === undefined;

    default:

      return false;

  }

}



function wantsCoercion(value) {

  const type = typeof value;

  return type === "string" || type === "number" || type === "boolean";

}



function isCoercable(value) {

  return value !== null && typeof value == "object";

}

这是不是太复杂了，我甚至不确定这是正确的! 也许有你知道更简单的算法。

但有趣的是，你会发现在上面的算法中，如果其中一个操作数是对象，VM 将调用. valueof()来允许对象将自身强制转换为基本类型。

强制转换的成本

上面的实现很复杂。那么==比=== 要多浪费多少性能呢? 看看下面这张图，我用基准测试做了一个对比：

其中，图表中越高表示越快(即，每秒操作次数越多)。

首先我们来讨论数字数组。当 VM 注意到数组是纯整数时，它将它们存储在一个称为PACKED_SMI_ELEMENTS的特殊数组中。在这种情况下，VM 知道将 == 处理为 === 是安全的，性能是相同的。这解释了为什么在数字的情况下，== 和 === 之间没有区别。但是，一旦数组中包含了数字以外的内容，== 的情况就变得很糟糕了。

对于字符串，== 比 === 的性能下降了 50%，看起来挺糟的是吧。

字符串在VM中是特殊的，但一旦我们涉及到对象，我们就慢了 4 倍。看看 mix 这栏，现在速度减慢了 4 倍!

但还有更糟的。对象可以定义 valueOf，这样在转换的时候可以将自己强制转换为原语。虽然在对象上定位属性可以通过内联缓存，内联缓存让属性读取变得快速，但在超大容量读取的情况下可能会经历 60 倍的减速，这可能会使情况更糟。如图中最坏情况(objectsMega)场景所示，==比=== 慢15 倍!

有其他使用 == 的理由吗

现在，=== 非常快! 因此，即使是使用 === 的15倍减速，在大多数应用程序中也不会有太大区别。尽管如此，我还是很难想出为什么要使用 == 而不是 === 的任何理由。强制规则很复杂，而且它存在一个性能瓶颈，所以在使用 == 之前请三思。

踏春，亦或是暂存的生日礼物，哈哈哈，管他呢，啥也不想，跟着老公就行了。

2023-4-7

去了趟苏州，从不明白老公为什么要选择这个城市旅游，到我舍不得离开。

风景很美，风景如画也不过如此吧。美的地方有很多，但是又美又有历史的地方，文化底蕴深厚，让人感觉到有韵味的美。

早上走在平江路上，很安静，初次看到小桥流水人家，很江南，确实没见过，慢慢我开始斜坐在桥上，吹着小风，从眼前美景慢慢关闭眼睛，闻着湿润的空气，放空自己。风是柔柔的，空气没有腥味，周五的早上，很安静。脚下是一千多年的桥，仿佛再闭一会儿睁开，就会穿梭在明朝。

走了一两公里，没觉得累，就是有点怕走到街道的尽头，就是喧哗刺眼的高楼。不用思考，就是跟着老公走，街道很干净，让人心情很好。

到了拙政园，好吧，今天真的是周五嘛。上次这么多人，还是去北京看漫展的时候，排了两条街。我们在门口租了一个讲解器，这个地方很适合自己带着耳机，听着讲解，看看古树，过着小桥，慢慢欣赏。跟着人群走了一圈，我们还了讲解器，慢慢的又走了一圈，回顾着这个石头的来源，这棵古树的年份，仔细的看了看最高的那几棵大树，园林的设计。这趟，很值。

出去后我们找了一家饭店，吃了个饭，去了酒店。睡了两个小时，晚上被老公拉起来，说是有好玩的。马上就来了兴致，收拾收拾出了门。

酒店就在山塘街边上，走了一会就进入了人流中，早上的安静的街道，现在人山人海。老公拉着我穿过人群，左拐右拐，一会过桥一会下桥，穿过一条清吧街，来到了一个叫玉涵堂的园子。老板把我们领到中间的位置，有小圆桌，椅子，小长椅，对面是戏台，旁边有个小亭子，亭子旁边是棵开的正好的桃花树，亭子上空有个小星星。慢慢就是萧声，琵琶声，二胡声，昆曲，小调，歌声。西厢记，牡丹亭，游园惊梦，玉簪记等等一曲曲婉转悠扬，动人心弦，最后一首声声慢结束了。

出门就是热闹的山塘街，是有点热闹，走路都是人挤人的跟着走，说实话，有点害怕踩踏事件。但是上到桥上，又觉得挤点也值得。桥下是一条条慢慢划着的船，两边是挂着灯笼的小房子，两边的水边是灯笼和房屋的倒影，没想到这种画，现实中也可以看到。

2023-4-8

第二天，有点起不来，但是一想到古镇，就有了动力。老公定的大巴车，车上看见了一些老年人，是的，他们来旅游，现在的他们有时间，大把的时间，有点羡慕。司机师傅拿着二维码，慢慢教他们怎么买回来的票，说是可以直接8折买古镇的票，一切就是告知，没有极力推销，让人比较舒服。再加上昨天走了一天的街道，街道不管人多少，干干净净，对这里的好感又上升了一些。

古镇的人。。。有点多。一波一波的旅游团。到古镇门口这一路，我眼里只有三个字——“万三蹄”。哈哈哈，没办法，一条街都是卖这个的，颜色很诱人。等会出来我要尝尝，再带点给家人尝尝。等到了五年没见的友人，朋友就是不用太联系，见到的时候一切依旧。这是老公的初中同学，从昆山打车来见我们的，五年没见了，一点不生疏。进去逛了一会，我们去坐了船。大哥很会聊，跟我们唱了几首歌谣，介绍了两边的树，道边停着的结婚用的花桥。听着小调，看着两边浮动的柳树，拍照的人，也是一番惬意。古镇有很多宅子，为首的当然是沈府，沈万三的家，在饭厅的“八大碗‘得知了，”万三蹄“的来历，朱元璋在沈万三家吃饭的时候，朱元璋问沈万三，这是什么菜，沈万三老婆说”猪蹄啊“。古代老百姓都要避讳皇帝的姓氏，沈万三赶紧说，这是”万三蹄“，后来的人就把这道菜叫做”万三蹄“。据说这道菜的制作，是先泡水，然后煮2分熟，蒸两个小时，再用冰糖炖，所以这个是偏甜口的。出去后，我们找了一家店，尝了下，挺鲜的，不腻，因为不喜甜口菜，所以没有多吃，但是是好吃的，还有不起眼的外婆菜，酸甜味的，下粥应该是不错的。

2023-4-9

第三天，每天2万多步的脚程，实在是有点歇不过来了，我们决定今天摆烂游了。慢悠悠退了房打车去了寒山寺。据导游说，寒山寺三个字不是一个人写的，四大才子之一，祝枝山写了前两个字。因为方丈看中了祝枝山的字，想让他提寺名，但是祝枝山是个财迷，要3000两，方丈凑了2200两，祝枝山写了前两个字，然后退回去了200两。后来方丈去世了，不了了之。直到陶濬宣写了第三个字，但是他有个要求，要在后面落款，所以现在的寒山寺外面的寺字是有陶濬宣的名字的。他就是写“光绪通宝”的人。寺庙外面都有一堵墙，写着寺名，据说是不建议拍照的，此乃萧墙，寺庙的萧墙是挡污秽东西的。休息之余，去大运河看货船，没装货的船，显得高大，空旷，装完货后，吃水很深，船旁边挂了一些轮胎，不知道是不是拿来当游泳圈的，哈哈哈，反正两个男生倒是很感兴趣，还跑过去近距离看了一会儿~

朋友找了一家店，松鼠桂鱼好看，也好吃。吃完饭就是别离。无论是别离友人，还是别离这风景如画的城市，别离无人打扰的短暂时光，都是那么的不舍。但是别离，也是为了下一次的相聚。这一路很美好。

起因

很多人都知道，setTimeout是有最小延迟时间的，根据MDN 文档 setTimeout：实际延时比设定值更久的原因：最小延迟时间中所说：

在浏览器中，setTimeout()/setInterval() 的每调用一次定时器的最小间隔是 4ms，这通常是由于函数嵌套导致（嵌套层级达到一定深度）。

在HTML Standard规范中也有提到更具体的：

Timers can be nested; after five such nested timers, however, the interval is forced to be at least four milliseconds.

简单来说，5 层以上的定时器嵌套会导致至少 4ms 的延迟。

用如下代码做个测试：

let a = performance.now();

setTimeout(() => {

  let b = performance.now();

  console.log(b - a);

  setTimeout(() => {

    let c = performance.now();

    console.log(c - b);

    setTimeout(() => {

      let d = performance.now();

      console.log(d - c);

      setTimeout(() => {

        let e = performance.now();

        console.log(e - d);

        setTimeout(() => {

          let f = performance.now();

          console.log(f - e);

          setTimeout(() => {

            let g = performance.now();

            console.log(g - f);

          }, 0);

        }, 0);

      }, 0);

    }, 0);

  }, 0);

}, 0);

在浏览器中的打印结果大概是这样的，和规范一致，第五次执行的时候延迟来到了 4ms 以上。

探索

假设就需要一个「立刻执行」的定时器呢？有什么办法绕过这个 4ms 的延迟吗，在 MDN 文档的角落里有一些线索：

如果想在浏览器中实现 0ms 延时的定时器，可以参考这里所说的window.postMessage()。

这篇文章里的作者给出了这样一段代码，用postMessage来实现真正 0 延迟的定时器：

(function () {

  var timeouts = [];

  var messageName = 'zero-timeout-message';



  // 保持 setTimeout 的形态，只接受单个函数的参数，延迟始终为 0。

  function setZeroTimeout(fn) {

    timeouts.push(fn);

    window.postMessage(messageName, '*');

  }



  function handleMessage(event) {

    if (event.source == window && event.data == messageName) {

      event.stopPropagation();

      if (timeouts.length > 0) {

        var fn = timeouts.shift();

        fn();

      }

    }

  }



  window.addEventListener('message', handleMessage, true);



  // 把 API 添加到 window 对象上

  window.setZeroTimeout = setZeroTimeout;

})();

由于postMessage的回调函数的执行时机和setTimeout类似，都属于宏任务，所以可以简单利用postMessage和addEventListener('message')的消息通知组合，来实现模拟定时器的功能。

这样，执行时机类似，但是延迟更小的定时器就完成了。

再利用上面的嵌套定时器的例子来跑一下测试：

全部在 0.1 ~ 0.3 毫秒级别，而且不会随着嵌套层数的增多而增加延迟。

测试

从理论上来说，由于postMessage的实现没有被浏览器引擎限制速度，一定是比 setTimeout 要快的。

设计一个实验方法，就是分别用postMessage版定时器和传统定时器做一个递归执行计数函数的操作，看看同样计数到 100 分别需要花多少时间。

实验代码：

function runtest() {

  var output = document.getElementById('output');

  var outputText = document.createTextNode('');

  output.appendChild(outputText);

  function printOutput(line) {

    outputText.data += line + '\n';

  }



  var i = 0;

  var startTime = Date.now();

  // 通过递归 setZeroTimeout 达到 100 计数

  // 达到 100 后切换成 setTimeout 来实验

  function test1() {

    if (++i == 100) {

      var endTime = Date.now();

      printOutput(

        '100 iterations of setZeroTimeout took ' +

        (endTime - startTime) +

        ' milliseconds.'

      );

      i = 0;

      startTime = Date.now();

      setTimeout(test2, 0);

    } else {

      setZeroTimeout(test1);

    }

  }



  setZeroTimeout(test1);



  // 通过递归 setTimeout 达到 100 计数

  function test2() {

    if (++i == 100) {

      var endTime = Date.now();

      printOutput(

        '100 iterations of setTimeout(0) took ' +

        (endTime - startTime) +

        ' milliseconds.'

      );

    } else {

      setTimeout(test2, 0);

    }

  }

}

实验代码很简单，先通过setZeroTimeout也就是postMessage版本来递归计数到 100，然后切换成 setTimeout计数到 100。

直接放结论，这个差距不固定，在 mac 上用无痕模式排除插件等因素的干扰后，以计数到 100 为例，大概有 80 ~ 100 倍的时间差距。在硬件更好的台式机上，甚至能到 200 倍以上。

Performance 面板

只是看冷冰冰的数字还不够过瘾，打开 Performance 面板，看看更直观的可视化界面中，postMessage版的定时器和setTimeout版的定时器是如何分布的。

这张分布图非常直观的体现出了上面所说的所有现象，左边的postMessage版本的定时器分布非常密集，大概在 5ms 以内就执行完了所有的计数任务。

而右边的setTimeout版本相比较下分布的就很稀疏了，而且通过上方的时间轴可以看出，前四次的执行间隔大概在 1ms 左右，到了第五次就拉开到 4ms 以上。

作用

也许有同学会问，有什么场景需要无延迟的定时器？其实在 React 的源码中，做时间切片的部分就用到了。

const channel = new MessageChannel();

const port = channel.port2;



// 每次 port.postMessage() 调用就会添加一个宏任务

// 该宏任务为调用 scheduler.scheduleTask 方法

channel.port1.onmessage = scheduler.scheduleTask;



const scheduler = {

  scheduleTask() {

    // 挑选一个任务并执行

    const task = pickTask();

    const continuousTask = task();



    // 如果当前任务未完成，则在下个宏任务继续执行

    if (continuousTask) {

      port.postMessage(null);

    }

  },

};

React 把任务切分成很多片段，这样就可以通过把任务交给postMessage的回调函数，来让浏览器主线程拿回控制权，进行一些更优先的渲染任务（比如用户输入）。

为什么不用执行时机更靠前的微任务呢？关键的原因在于微任务会在渲染之前执行，这样就算浏览器有紧急的渲染任务，也得等微任务执行完才能渲染。

总结

可以了解如下几个知识点：

1. setTimeout的 4ms 延迟历史原因，具体表现。


2. 如何通过postMessage实现一个真正 0 延迟的定时器。


3. postMessage定时器在 React 时间切片中的运用。


4. 为什么时间切片需要用宏任务，而不是微任务。

GitHub

Gitee

ComponentBus 这个项目已经内部使用了一段时间, 经过几次迭代.

他非常小巧, 且功能强大, 并且配有 IDEA 插件作为辅助.

ComponentBus 利用 ASM、KSP, 使组件间的通信变得简单且高效.

第一步组件间通信

新建一个 Module, 我们给他添加一个接口

@Component(componentName = "Test")

object ComponentTest {



    @Action(actionName = "init")

    fun init(debug: Boolean) {

        ...

    }

	

	@Action(actionName = "getId")

    fun getId(): String {

        return "id-001"

    }



	@Action(actionName = "openUserPage", interceptorName = ["LoginInterceptor"])

	fun openUserPage() {

        val newIntent = Intent(MyApplication.application, UserActivity::class.java)

        newIntent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP

        MyApplication.application.startActivity(newIntent)

    }

}

我们可以看到, 任何方法、参数、返回值都可作为通信 Action, 只要给他加上 Action 注解.

并且我们可以给他添加拦截器, 当条件不满足时进行拦截, 并做其他操作.

由于 module 间没有依赖, 返回值应该是所有 module 都可以引用到的类型.

组件间调用, 参数默认值目前不支持使用.

第二部调用其他组件API

新建一个 Module, 我们调用另一个 Module 的 API

ComponentBus.with("Test", "init")

	.params("debug", true)

	.callSync<Unit>()



val result = ComponentBus.with("Test", "getId")

	.callSync<String>()

if (result.isSuccess) {

	val id = result.data!!

}

就是这么简单, 不需要接口下沉.

这里有个问题, 那就是 componentName、actionName 都是字符串, 使用上不方便, 需要查看名称、复制.

为了解决这个问题, 我专门开发了一款 IDEA 插件, 辅助使用.

IDEA 插件

插件搜索 componentBus

拦截器

全局拦截器

/**  

 * 全局日志拦截器  

 */  

object LogGlobalInterceptor : GlobalInterceptor() {  

    override suspend fun <T> intercept(chain: Chain) = chain.proceed<T>().apply {  

        UtilsLog.log("Component: ${chain.request.componentName}${Utils.separatorLine}Action: ${chain.request.action}${Utils.separatorLine}Result: ($code) $msg $data", "Component")  

    }  

    override fun <T> interceptSync(chain: Chain) = chain.proceedSync<T>().apply {  

        UtilsLog.log("Component: ${chain.request.componentName}${Utils.separatorLine}Action: ${chain.request.action}${Utils.separatorLine}Result: ($code) $msg $data", "Component")  

    }  

}

普通拦截器

/**  

 * 判断是否是登录的拦截器  

 * 未登录会进入登录页面  

 */  

object LoginInterceptor : IInterceptor {  

    override suspend fun <T> intercept(chain: Chain): Result<T> {  

        return if (UsercenterComponent.isLoginLiveData.value == true) {  

            chain.proceed()  

        } else {  

            showLogin()  

            Result.resultError(-3, "拦截, 进入登录页")  

        }  

    }  

  

    override fun <T> interceptSync(chain: Chain): Result<T> {  

        return if (UsercenterComponent.isLoginLiveData.value == true) {  

            chain.proceedSync()  

        } else {  

            showLogin()  

            Result.resultError(-3, "拦截, 进入登录页")  

        }  

    }  

}

END

更多详情在 GitHub

欢迎感兴趣的朋友提供反馈和建议。

前言

事情是这样的，前段时间同事接到一个需求，需要将项目系统的签章正文脱密下载。不经意间听到同事嘀咕找不到头绪，网上的相关资料也很少，于是帮忙研究研究。

实现的思路：

首先，我们必须要明白一个PDF中存在哪些东西？PDF可以存储各种类型的内容，包括文本、图片、图形、表格、注释、标记和多媒体元素。那么印章在我们的PDF中其实就是存储的一个图片，然后这个图片附加的有印章信息，可用于文件的有效性验证，说白了其实就是一种【特殊的图片】，那么我们需要做的就是如何找到这个图片并如何将这个图片变成黑色最后插入到pdf的原始位置。下面我们就分析一下其处理的过程。

准备工作

我们使用apache 提供的 pdfbox用来处理和操作。

<dependency>

  <groupId>org.apache.pdfbox</groupId>

  <artifactId>pdfbox</artifactId>

  <version>2.0.24</version>

</dependency>

过程分析

查找印章定义

印章定义通常存储在 PDF 的资源文件中，例如字体、图像等。因此，我们需要找到印章定义所对应的 PDAnnotation（签名列表）。不同厂商对 签名信息 的标识可能不同，因此我们需要查找 PDF 文件中的 PDAnnotation。在这一步中，我们需要使用一些调试技巧和定向猜测，通过debug的模式我们去找或者猜测一下厂商的印章签名是什么，比如金格的就是：GoldGrid:AddSeal 。这个签名就带了金格的厂商名。

• 首先是加载文档：PDDocument document = PDDocument.load(new File("test.pdf"));

• 其次是遍历文档，查找每一个页中是否含有印章签名信息

List<PDAnnotation> annotations = page.getAnnotations();

for (PDAnnotation annotation : annotations) {

    if (KG_SIGN.equals(annotation.getSubtype()) || NTKO_SIGN.equals(annotation.getSubtype())) {

        // todo 

    }

}

上诉步骤我们就完成了查询信息的全过程，接下来我们需要获取印章图片信息。

获取印章流

一旦我们找到了印章定义所对应的 PDAnnotation，我们就可以获取到印章图片信息中相关的附加信息，比如印章的位置信息，字体，文字等等信息。

PDRectangle rectangle = annotation.getRectangle();

float width = rectangle.getWidth();

float height = rectangle.getHeight();

上诉代码我们获取了印章图片的大小信息，用于后续我们填充印章时的文件信息。PDRectangle 对象定义了矩形区域的左下角坐标、宽度和高度等属性。

PDAppearanceDictionary appearanceDictionary = annotation.getAppearance();

PDAppearanceEntry normalAppearance = appearanceDictionary.getNormalAppearance();

PDAppearanceStream appearanceStream = normalAppearance.getAppearanceStream();

PDResources resources = appearanceStream.getResources();

PDImageXObject xObject = (PDImageXObject)resources.getXObject(xObjectName);

那么上面代码就是我们获取到的原始图片对象信息。通过对PDImageXObject进行操作以完成我们的目的。

PDResources 资源对象包含了注释所需的所有资源，例如字体、图像等。可以使用资源对象进行进一步的操作，例如替换资源、添加新资源等。

在PDF文件中，图像通常被保存为一个XObject对象，该对象包含了图像的信息，例如像素数据、颜色空间、压缩方式等。对于一个PDF文档中的图像对象，通常需要从资源（Resources）对象中获取。

处理原始图片

一旦我们找到了印章图片对象，我们需要将其变成黑色。印章通常是红色的，因此我们可以遍历图像的像素，并将红色像素点变成黑色像素点。在这一步中，我们需要使用一些图像处理技术，例如使用 Java 的 BufferedImage 类来访问和修改图像的像素。

public static void replaceRed2Black(BufferedImage image) {

        int width = image.getWidth();

        int height = image.getHeight();

        // 获取图片的像素信息

        int[] pixels = image.getRGB(0, 0, width, height, null, 0, width);

        // 循环遍历每一个像素点

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

            // 获取当前像素点的颜色

            Color color = new Color(pixels[i]);

            // 如果当前像素点的颜色为白色 rgb(255, 255, 255)，颜色不变

            if (color.getRed() == 255 && color.getGreen() == 255 && color.getBlue() == 255) {

                pixels[i] &= 0x00FFFFFF;

            }else{

                // 其他颜色设置为黑色 ：rgb(0, 0, 0)

                pixels[i] &= 0xFF000000;

            }

        }

        image.setRGB(0, 0, width, height, pixels, 0, width);

    }

代码逻辑：首先获取图片的宽高信息，然后获取图片的像素信息，循环每一个像素，然后判断像素的颜色是什么色，如果不是白色那么就将颜色替换为黑色。

tips：这里其实有个小插曲，当时做的时候判断条件是如果为红色则将其变换为黑色，但是这里有个问题就是在红色边缘的时候，其颜色的rgb数字是一个区间，这样去替换的话，图片里面就会存在模糊和替换不全。所以后来灵光一现，改成现在这样。

插入处理后的图片

最后，我们需要将新的印章图像插入到 PDF 文件中原始印章的位置上,代码如下：

PDAppearanceStream newAppearanceStream = new PDAppearanceStream(appearanceStream.getCOSObject());

PDAppearanceContentStream newContentStream = new PDAppearanceContentStream(newAppearanceStream);

newContentStream.addRect(0, 0, width, height);

File file = new File("image.png");

PDImageXObject image = PDImageXObject.createFromFileByContent(file, document);

// 在内容流中绘制图片

newContentStream.drawImage(image, 0, 0, width, height);

// 关闭外观流对象和内容流对象

newContentStream.close();

这段代码是在Java语言中使用PDFBox库操作PDF文件时，创建一个新的外观流（Appearance Stream）对象，并在该流中绘制一张图片。

首先，通过调用PDAppearanceStream类的构造方法，创建一个新的外观流对象，并将其初始化为与原有外观流对象相同的COS对象。这里使用appearanceStream.getCOSObject()方法获取原有外观流对象的COS对象。然后，创建一个新的内容流（AppearanceContent Stream）对象，将其与新的外观流对象关联起来。

接下来，使用addRect()方法向内容流中添加一个矩形，其左下角坐标为(0,0)，宽度为width，高度为height。该操作用于确定图片在外观流中的位置和大小。

然后，通过PDImageXObject类中的createFromFileByContent()方法创建一个PDImageXObject对象，该对象表示从文件中读取的图片。这里使用一个File对象和PDF文档对象document作为参数创建PDImageXObject对象。

接下来，使用drawImage()方法将读取的图片绘制到内容流中。该方法以PDImageXObject对象、x坐标、y坐标、宽度、高度作为参数，用于将指定的图片绘制到内容流中的指定位置。

最后，通过调用close()方法关闭内容流对象，从而生成一个完整的外观流对象。

到此我们就完成了印章的脱密下载的全过程，这个任务的难点在于怎么查找不同厂商对印章的签名定义以及对pdf的理解和工具API的理解。

前言

某一天，产品经理找到我，他希望我们能够给用户更好的体验，提供长列表的滚动记忆功能。就是说当鼠标滚轮滚动到长列表的某个位置时，单击一个具体的列表项，就切换路由到了这个列表项的详情页；当导航返回到长列表时，还能回到之前滚动到的位置去。

思路

我低头思考了一阵儿，想到了history引入的scrollRestoration属性，也许可以一试。于是我回答，可以实现，一天工作量吧😂。产品经理听到后，满意地走了，但是我后知后觉，我为数不多的经验告诉我，这事儿可能隐隐有风险😨。但是没办法，no zuo no die。

scrollRestoration

Chrome46之后，history引入了scrollRestoration属性。该属性提供两个值，auto（默认值），以及manual。当设置为auto时，浏览器会原生地记录下window中某个元素的滚动位置。此后不管是刷新页面，还是使用pushState等方法改变页面路由，始终可以让元素恢复到之前的屏幕范围中。但是很遗憾，他只能记录下在window中滚动的元素，而我的需求是某个容器中滚动。

完犊子😡，实现不了。

其实想想也是，浏览器怎么可能知道开发者想要保存哪个DOM节点的滚动位置呢？这事只有开发者自己知道，换句话说，得自己实现。于是乎，想到了一个大致思路是：

发生滚动时将元素容器当时的位置保存起来，等到长列表再次渲染时，再对其重新赋值scrollTop和scrollLeft

真正的开发思路

其实不难想到，滚动恢复应该属于长列表场景中的通用能力，既然如此，那...，夸下的海口是一天，所以没招，只能根据上述的简单思路实现了一个，很low，位置信息保存在localStorage中，算是交了差。但作为一个有追求的程序员，这事必须完美解决，既然通用那么公共组件提上日程😎。在肝了几天之后，出炉的完美解决方案：

在路由进行切换、元素即将消失于屏幕前，记录下元素的滚动位置，当元素重新渲染或出现于屏幕时，再进行恢复。得益于React-Router的设计思路，类似于Router组件，设计滚动管理组件ScrollManager，用于管理整个应用的滚动状态。同理，类似于Route，设计对应的滚动恢复执行者ScrollElement，用以执行具体的恢复逻辑。

滚动管理者-ScrollManager

滚动管理者作为整个应用的管理员，应该具有一个管理者对象，用来设置原始滚动位置，恢复和保存原始的节点等。然后通过Context，将该对象分发给具体的滚动恢复执行者。其设计如下：

export interface ScrollManager {

    /**

     * 保存当前的真实DOM节点

     * @param key 缓存的索引

     * @param node

     * @returns

     */

    registerOrUpdateNode: (key: string, node: HTMLElement) => void;

    /**

     * 设置当前的真实DOM节点的元素位置

     * @param key 缓存的索引

     * @param node

     * @returns

     */

    setLocation: (key: string, node: HTMLElement | null) => void;

    /**

     * 设置标志，表明location改变时，是可以保存滚动位置的

     * @param key 缓存的索引

     * @param matched

     * @returns

     */

    setMatch: (key: string, matched: boolean) => void;

    /**

     * 恢复位置

     * @param key 缓存的索引

     * @returns

     */

    restoreLocation: (key: string) => void;

    /**

     * 清空节点的缓存

     * @param key

     * @returns

     */

    unRegisterNode: (key: string) => void;

}

• 上述Manager虽然提供了各项能力，但是缺少了缓存对象，也就是保存这些位置信息的地方。使用React.useRef，其设计如下：

//缓存位置的具体内容

const locationCache = React.useRef<{

    [key: string]: { x: number; y: number };

}>({});

//原生节点的缓存

const nodeCache = React.useRef<{

    [key: string]: HTMLElement | null;

}>({});

//标志位的缓存

const matchCache = React.useRef<{

    [key: string]: boolean;

}>({});

//清空节点方法的缓存

const cancelRestoreFnCache = React.useRef<{

    [key: string]: () => void;

}>({});

• 有了缓存对象，我们就可以实现manager，使用key作为缓存的索引，关于key会在ScrollElement中进行说明。

const manager: ScrollManager = {

    registerOrUpdateNode(key, node) {

        nodeCache.current[key] = node;

    },

    unRegisterNode(key) {

        nodeCache.current[key] = null;

        //及时清除

        cancelRestoreFnCache.current[key] && cancelRestoreFnCache.current[key]();

    },

    setMatch(key, matched) {

        matchCache.current[key] = matched;

        if (!matched) {

            //及时清除

            cancelRestoreFnCache.current[key] && cancelRestoreFnCache.current[key]();

        }

    },

    setLocation(key, node) {

        if (!node) return;

        locationCache.current[key] = { x: node?.scrollLeft, y: node?.scrollTop };

    },

    restoreLocation(key) {

        if (!locationCache.current[key]) return;

        const { x, y } = locationCache.current[key];

        nodeCache.current[key]!.scrollLeft = x;

        nodeCache.current[key]!.scrollTop = y;

    },

};

• 之后，便可以通过Context将manager对象向下传递

<ScrollManagerContext.Provider value={manager}>

    {props.children}

</ScrollManagerContext.Provider>

• 除了上述功能外，manager还有一个重要功能：获知元素在导航切换前的位置。在React-Router中一切路由状态的切换都由history.listen来发起，由于history.listen可以监听多个函数。所以可以在路由状态切换前，插入一段监听函数，来获得节点相关信息。

location改变 ---> 获得节点位置信息 ---> 路由update

• 在实现中，使用了一个状态shouldChild，来确保监听函数一定在触发顺序上先于Router中的监听函数。实现如下：

const [shouldChild, setShouldChild] = React.useState(false);



//利用useLayoutEffect的同步，模拟componentDidMount，为了确保shouldChild在Router渲染前设置

React.useLayoutEffect(() => {

        //利用history提供的listen监听能力

        const unlisten = props.history.listen(() => {

            const cacheNodes = Object.entries(nodeCache.current);

            cacheNodes.forEach((entry) => {

                const [key, node] = entry;

                //如果matchCache为true，表明从当前路由渲染的页面离开，所以离开之前，保存scroll

                if (matchCache.current[key]) {

                    manager.setLocation(key, node);

                }

            });

        });



        //确保该监听先入栈，也就是监听完上述回调函数后才实例化Router

        setShouldChild(true);

        //销毁时清空缓存信息

        return () => {

            locationCache.current = {};

            nodeCache.current = {};

            matchCache.current = {};

            cancelRestoreFnCache.current = {};

            Object.values(cancelRestoreFnCache.current).forEach((cancel) => cancel());

            unlisten();

        };

}, []);



//改造context传递

<ScrollManagerContext.Provider value={manager}>

    {shouldChild && props.children}

</ScrollManagerContext.Provider>

• 真正使用时，管理者组件要放在Router组件外侧，来控制Router实例化：

<ScrollRestoreManager history={history}>

    <Router history={history}>

        ...

    </Router>

</ScrollRestoreManager>

滚动恢复执行者-ScrollElement

ScrollElement的主要职责其实是控制真实的HTMLElement元素，决定缓存的key，包括决定何时触发恢复，何时保存原始HTMLElement的引用，设置是否需要保存的位置等等。ScrollElement的props设计如下：

export interface ScrollRestoreElementProps {

    /**

     * 必须缓存的key，用来标志缓存的具体元素，位置信息以及状态等，全局唯一

     */

    scrollKey: string;

    /**

     * 为true时触发滚动恢复

     */

    when?: boolean;

    /**

     * 外部传入ref

     * @returns

     */

    getRef?: () => HTMLElement;

    children?: React.ReactElement;

}

• ScrollElement本质上可以看作为一个代理，会拿到子元素的Ref，接管其控制权。也可以自行实现getRef传入组件中。首先要实现的就是滚动发生时，记录位置能力：

useEffect(() => {

    const handler = function (event: Event) {‘

        //nodeRef就是子元素的Ref

        if (nodeRef.current === event.target) {

            //获取scroll事件触发target，并更新位置

            manager.setLocation(props.scrollKey, nodeRef.current);

        }

    };



    //使用addEventListener的第三个参数，实现在window上监听scroll事件

    window.addEventListener('scroll', handler, true);

    return () => window.removeEventListener('scroll', handler, true);

}, [props.scrollKey]);

• 接下来处理路由匹配以及DOM变更时处理的能力。注意，这块使用了对useLayoutEffect和useEffect执行时机的理解处理：

//使用useLayoutEffect主要目的是为了同步处理DOM，防止发生闪动

useLayoutEffect(() => {

    if (props.getRef) {

        //处理getRef获取ref

        //useLayoutEffect会比useEffect先执行，所以nodeRef一定绑定的是最新的DOM

        nodeRef.current = props.getRef();

    }



    if (currentMatch) {

        //设置标志，表明当location改变时，可以保存滚动位置

        manager.setMatch(props.scrollKey, true);

        //更新ref，代理的DOM可能会发生变化（比如key发生了变化，remount元素）

        nodeRef.current && manager.registerOrUpdateNode(props.scrollKey, nodeRef.current);

        //恢复原先滑动过的位置，可通过外部props通知是否需要进行恢复

        (props.when === undefined || props.when) && manager.restoreLocation(props.scrollKey);

    } else {

        //未命中标志设置，不要保存滚动位置

        manager.setMatch(props.scrollKey, false);

    }



    //每次update注销，并重新注册最新的nodeRef，解决key发生变化的情况

    return () => manager.unRegisterNode(props.scrollKey);

});

• 上述代码，表示在初次加载或者每次更新时，会根据当前的Route匹配结果与否来处理。如果匹配，则表示ScrollElement组件应是渲染的，此时在effect中执行更新Ref的操作，为了解决key发生变化时DOM发生变化的情况，所以需要每次更新都处理。


• 同时设置标识位，相当于告诉manager，node节点此刻已经渲染成功了，可以在离开页面时保存位置信息；如果路由不匹配，那么则不应该渲染，manager此刻也不用保存这个元素的位置信息。主要是为了解决存在路由缓存的场景。


• 也可以通过when来控制恢复，主要是用来解决异步请求数据的场景。


• 最后判断ScrollElement的子元素是否是合格的

//如果有getRef，直接返回children

if (props.getRef) {

    return props.children as JSX.Element;

}



const onlyOneChild = React.Children.only(props.children);

//代理第一个child，判断必须是原生的tag

if (onlyOneChild && onlyOneChild.type && typeof onlyOneChild.type === 'string') {

    //利用cloneElement，绑定nodeRef

    return React.cloneElement(onlyOneChild, { ref: nodeRef });

} else {

    console.warn('-----滚动恢复失败，ScrollElement的children必须为单个html标签');

}



return props.children as JSX.Element;

多次尝试机制

在某些低版本的浏览器中，可能存在一次恢复并不如预期的情况。所以实现多次尝试能力，其原理就是用一个定时器多次执行callback，同时设定时间上限，并返回一个取消函数给外部，如果最终结果理想则取消尝试，否则再次尝试直到时间上限内达到理想位置。更改恢复函数：

restoreLocation(key) {

    if (!locationCache.current[key]) return;

    const { x, y } = locationCache.current[key];

    //多次尝试机制

    let shouldNextTick = true;

    cancelRestoreFnCache.current[key] = tryMutilTimes(

        () => {

            if (shouldNextTick && nodeCache.current[key]) {

                nodeCache.current[key]!.scrollLeft = x;

                nodeCache.current[key]!.scrollTop = y;

                //如果恢复成功，就取消

                if (nodeCache.current[key]!.scrollLeft === x && nodeCache.current[key]!.scrollTop === y) {

                    shouldNextTick = false;

                    cancelRestoreFnCache.current[key]();

                }

            }

        },

        props.restoreInterval || 50,

        props.tryRestoreTimeout || 500

    );

},

至此，滚动恢复的组件全部完成。具体源代码可以到github查看，欢迎star。 github.com/confuciusth…

效果

总结

一个滚动恢复功能，如果想要健壮，完善地实现。其实需要掌握Router，Route相关的原理、history监听路由变化原理、React Effect的相关执行时机以及一个好的设计思路。而这些都需要我们平时不断的研究，不断的追求完美。虽然这并不能“加钱”，但这种能力以及追求是我们成为技术大牛的路途中，最宝贵的财富。当然，能够加钱最好了😍。

创作不易，欢迎点赞！

1.问题描述：

这个bug是我在做一个二次元项目（vue+vite+mysql）的时候，最开始都没有问题，但是后来有一天我的这个项目打开控制台后出现了资源无法加载的问题，包括图片，组件等，但是我只要不打开控制台就没有问题，所以当时我觉得这个问题非常的逆天，

bug如图

2.解决思路：

先说正确答案：浏览器抽风，把我默认的网络限制改成了离线，而我之前一直是无限制，因此导致了我一打开控制台就断网，最主要的惑因就是不止我常用的edg浏览器这样了，捏吗连谷歌浏览器都跟着抽风，导致我误判了

0. 
   

   首先我遇到这种问题想的肯定先是我的代码有没有问题，因为这个bug是突然出现的。所以我检查了我的代码问题，例如图片我把原来的静态的src：“巴拉巴拉.jpg”换成了import动态引入的方法

   
   

    import src1 from "../assets/movie/miaonei/miaonei.aac";
   
    ​
   
    export default {
   
      name: "profile",
   
      components: { userTop },
   
      data() {
   
        return {
   
          src1,
   
        };
   
      },
   
      }
   
   

   
   

   但是问题依然没有得到解决。

   
   

   2.接下来我考虑到了浏览器本身的问题，但是因为我浏览器网络那里是默认，我的默认一直是无限制，接下来我就用谷歌打开了项目结果也是一样的，所以我就排除了是控制台网络的原因

   
   

   3.接下来就考虑是我nodel_modles或者vue，npm版本有问题，所以就开始检测各种的版本，但是也没有发现问题

   
   

   4.最后我就先放弃的一段时间，毕竟不用控制台也只是开发效率降低，不是不能写，后来我突然想到这种样子不就是断网吗，所以我认定了就是控制台打开导致的断网，所以一定是network那里的默认不是我之前的东西了，虽然我根本没有改过，但只有这一种可能了

   
   

   5.问题解决。

   
   

   3.解决后效果

   
   

   

   
   

   

   
   

   结语：

   
   

   
   

   山重水复疑无路，柳暗花明又一村。

   
   

   做项目遇到bug是很正常的事，对于在读生来说，遇到bug反而是一件是好事，我可以通过自己思考，结合所学的东西来解决问题，这样可以提升我们的能力，巩固我们的境界。

   
   

   就上面这个bug而言，在我成功解决这个问题之前，我都是不知道原来浏览器自己能修改我默认的东西。

   
   

   
   

背景

为什么同样是男人，但有的男人'🧔‍♂️'.length === 5，有的男人'🧔‍♂'.length === 4呢？

这二者都是JS中的字符串，要理解本质原因，你需要明白JS中字符串的本质，你需要理解 String Unicode UTF8 UTF16 的关系。本文，深入二进制，带你理解它！

从 ASCII 说起

各位对这张 ASCII 表一定不陌生：

因为计算机只能存储0和1，如果要让计算机存储字符串，还是需要把字符串转成二进制来存。ASCII就是一直延续至今的一种映射关系：把8位二进制（首位为0）映射到了128个字符上。

从多语言到Unicode

但是世界上不止有英语和数字，还有各种各样的语言，计算机也应该能正确的存储、展示它们。

这时候，ASCII的128个字符，就需要被扩充。有诸多扩充方案，但思路都是一致的：把一个语言符号映射到一个编号上。有多少个语言符号，就有多少个编号。

至今，Unicode 已经成为全球标准。

The Unicode Consortium is the standards body for the internationalization of software and services. Deployed on more than 20 billion devices around the world, Unicode also provides the solution for internationalization and the architecture to support localization.

Unicode 联盟是软件和服务国际化的标准机构。 Unicode 部署在全球超过 200 亿台设备上，还提供国际化解决方案和支持本地化的架构。

Unicode是在ASCII的128个字符上扩展出来的。

例如，英文「z」的Unicode码是7A（即十进制的122，跟ASCII一致）。

Unicode中80（即128号）字符是€，这是ASCII的128个字符（0-127）的后一个字符。

汉字「啊」的Unicode码是554A。

Emoji「🤔」的Unicode码是1F914。

从Unicode到Emoji

随着时代发展，人们可以用手机发短信聊天了，常常需要发送表情，于是有人发明了Emoji。Emoji其实也是一种语言符号，所以Unicode也收录了进来。

Unicode一共有多少

现在，Unicode已经越来越多了，它的编码共计111万个！（有实际含义的编码并没这么多）

目前的Unicode字符分为17组编排，每组称为平面（Plane），而每平面拥有65536（即2^4^4=2^16）个代码点。目前只用了少数平面。

以前只有ASCII的时候，共128个字符，我们统一用8个二进制位（因为log(2)128=7，取整得8），就一定能存储一个字符。

现在，Unicode有16*65536=1048576个字符，难道必须用log(2)1048576=20 向上取整24位（3个字节）来表示一个字符了吗？

那样的话，字母z就是00000000 00000000 01111010了，而之前用ASCII的时候，我们用01111010就可以表示字母z。也就是说，同样一份纯英文文件，换成Unicode后，扩大了3倍！1GB变3GB。而且大部分位都是0。这太糟糕了！

因此，Unicode只是语言符号和一些自然数的映射，不能直接用它做存储。

UTF8如何解决「文本大小变3倍问题」

答案就是：「可变长编码」，之前我在文章《太卷了！开发象棋，为了减少40%存储空间，我学了下Huffman Coding》提到过。

使用「可变长编码」，每个字符不一定都要用统一的长度来表示，针对常见的字符，我们用8个二进制位，不常见的字符，我们用16个二进制位，更不常见的字符，我们用24个二进制位。

这样，能够减少大部分场景的文件体积。这也是哈夫曼编码的思想。

要设计一套高效的「可变长编码」，你必须满足一个条件：它是「前缀码」。即通过前缀，我就能知道这个字符要占用多少字节。

而UTF8，就是一种「可变长编码」。

UTF8的本质

1. UTF8可以把2^21=2097152个数字，映射到1-4个字节（这个范围能够覆盖所有Unicode）。


2. UTF8完全兼容ASCII。也就是说，在UTF8出现之前的所有电脑上存储的老的ASCII文件，天然可以被UTF8解码。

具体映射方法：

• 0-127，用0xxxxxxx表示（共7个x）


• 128-2^11-1，用110xxxxx 10xxxxxx表示（共11个x）


• 2^11-2^16-1，用1110xxxx 10xxxxxx 10xxxxxx表示（共16个x）


• 2^16-2^21-1，用11110xxx 10xxxxxx 10xxxxxx 10xxxxxx表示（共21个x）

不得不承认，UTF8确实有冗余，还有压缩空间。但考虑到存储不值钱，而且考虑到解析效率，它已经是最优解了。

UTF16的本质

回到本文开头的问题，为什么'🧔‍♂️'.length === 5，但'🧔‍♂'.length === 4呢？

你需要知道在JS中，字符串使用了UTF16编码（其实本来是UCS-2，UTF16是UCS-2的扩展）。

为什么JS的字符串不用UTF8？

因为JS诞生（1995）时，UTF8还没出现（1996）。

UTF16不如UTF8优秀，因为它用16个二进制位或32个二进制位映射一个Unicode。这就导致：

1. 它涉及到大端、小端这种字节序问题。


2. 它不兼容ASCII，很多老的ASCII文件都不能用了。

UTF16的具体映射方法：

细心的你有没有发现个Bug？UTF16不是前缀码？ 遇到110110xx xxxxxxxx 110111xx xxxxxxxx，怎么判断它是1个大的Unicode字符、还是2个连续的小的Unicode字符呢？

答案：其实，在U+0000 - U+FFFF范围内，110110xx xxxxxxxx和110111xx xxxxxxxx都不是可见字符。也就是说，在UTF16中，遇到110110一定是4字节UTF16的前2字节的前缀，遇到110111一定是4字节UTF16的后2字节的前缀，其它情况，一定是2字节UTF16。这样，通过损失了部分可表述字符，UTF16也成为了「前缀码」。

JS中的字符串

在JS中，'🧔‍♂️'.length算的就是这个字符的UTF16占用了多少个字节再除以2。

我开发了个工具，用于解析字符串，把它的UTF8二进制和UTF16二进制都展示了出来。

工具地址：tool.hullqin.cn/string-pars…

我把2个男人，都放进去，检查一下他们的Unicode码：

发现区别了吗？

长度为4的，是1F9D4 200D 2642；长度为5的，是1F9D4 200D 2642 FE0F。

都是一个Emoji，但是它对应了多个Unicode。这是因为200D这个零宽连字符，一些复杂的emoji，就是通过200D，把不同的简单的emoji组合起来，展示的。当然不是任意都能组合，需要你字体中定义了那个组合才可以。

标题中的Emoji，叫man: beard，是胡子和男人的组合。

末尾的FE0F是变体选择符，当一个字符一定是emoji而非text时，它其实是可有可无的。

于是，就有的'🧔‍♂️'长，有的'🧔‍♂'短了。

当我躺在核磁共振机器里，就像科幻电影中的冷冻仓，我希望自己被封印在里面，睡个几百年。

我并没有写年终总结的习惯，以前也从来没写过。

一来是因为我总是觉得农历新年才是一年的开始，另外就是觉得给自己定新年目标也是一定完不成的~

今年有点例外，我想写点东西，总结下 2022 年，让它赶紧过去。Never see you 2022~

1. 死亡

十二月的某个周日晚上，我正在快乐的玩手机玩电脑，慢慢的发现胳膊没有力气，拿不动手机了，手指也几乎打不出来字了。大约 10 分钟之后，全身已经没有力气了，从椅子上站起来都吃力。

然后就喊我爸爸开车带我去医院急诊，住院了一星期。

当时的感受就像一只充满气的气球，被戳了一个大口子，气在飞快的跑，气球越来越软，但气球没有任何办法。

过去 30 年，我的身体一直很健康，完全没有任何征兆。不夸张的说，我当时觉得自己要完蛋了，甚至和我老婆交代了一些事情。

这件事情对我的影响非常大，我希望 2022 年赶快过去，走好不送。

经历过这件事情之后，想和大家分享一些我的想法。

1.1 及时享乐

上帝给了我们几十年的健康时光，我们碌碌无为。
上帝给了我们一周的痛苦，我们开始后悔没有好好享受生活。

这件事情给我最大的一个感受就是，珍惜健康的时间，玩好享受好。

我列了一份人生想做的事情清单，也会让家里人每人列一份。如果能把清单处理完，那以后出现最坏的事情，也不会后悔了。

1.2 透明

夫妻之间要完全透明，这样在意外到来的时候，没有后顾之忧。

第一，我会经常和老婆交流我对生死的看法，我对死亡这种事情看的很淡，死了说不定比活着舒服。

第二，我每个月会统计自己的资产状况，并记录在某软件上，我老婆可以很清楚的知道我有多少钱、分别放在哪里。同时我的各种账号密码，都对我老婆透明公开。

当时我给老婆说了一句话：“如果出现最坏的结果，我的钱在哪里你都知道。另外就是这种事情我看的很淡”。

1.3 莫生气

电视剧《天道》（小说《遥远的救世主》改编）中有这样一个情节：

男主丁元英在路边小摊吃饭，已经付过了一元饭钱，但吃完后摊主说没给钱。丁元英呆了一下，又付了一块钱。

当时看到这里，我大受震撼，不要和不值当的人生气。

之前在杭州租房子，物业女打电话说卫生间渗水到隔壁去了，让我打电话给隔壁房东处理。

我的意思是让隔壁房东加我微信，看看怎么处理。

物业女没有理我，第二天打电话指责我为什么没有联系隔壁房东，并且再次强调让我联系隔壁房东。

按我以前的性格，我 100% 不会主动联系隔壁房东，并且会继续和物业女吵几次架。

后来我想了想，我为什么要和物业女生气呢？这样搞下去未来几天的心情都会很糟糕的，于是我直接联系了隔壁房东，再也不用和物业女打交道了。

有个小伙伴说不敢写文章，因为每次发出去都会被喷。我自己以前也会膈应，但现在没啥特殊的感觉了，很多喷子评论我看都不看。

去年和好几个朋友分享过上面的故事，这件事情过后，感触更深，不要和不值当的人生气，当成空气忽略掉就可以了。

1.4 健康第一

以前每次下定决心锻炼，能坚持 2 天就算不错了。

经历过这个事情之后，锻炼已经不用下决心了。

我热爱运动~

2. 工作

工作上，今年是主动求变的一年，也终于想清楚了未来几年的发展方向。

年初，团队大调整，由于我们组的业务夕阳红，所以整个组被拆掉了，我被调动去做一块新业务，但个人兴趣不是很大。

在这个契机下，我好好思考了自己想做什么，确定了「区块链」行业大方向。

于是转岗到了蚂蚁链团队，花了好长时间学习行业知识，也算入了门。

半年以后，因为找到了「区块链」行业更前线的机会，并且是梦寐以求的「远程办公」，所以从蚂蚁离职，加入了新的公司。

目前入职两个月，整体感受超出预期，希望未来几年可以火力全开。

工作 7 年以来，今年是最特殊的一年，也是变化最大的一年，希望没有选错路。生命不息，折腾不止~

3. 生活

生活上今年最大的变化就是离开了杭州，回到了老家。

在老家农村办公了两个多月，发现并没有想象中的那么美好，有几点原因吧：

1. 村里冬天光秃秃的，没啥好玩的


2. 冷，没啥地方去


3. 没有外卖，没有好吃的，每天只能在家吃饭


4. 技术上交流机会比较少，有点憋得慌

明年还是得去大城市折腾折腾~~~~~~

其它的就是带父母去了一次海边。疫情结束，希望明年可以带家里人去更多的地方旅游。

4. 折腾

工作之余，一直在尝试折腾各种事情。

4.1 自媒体

前几年开始搞公众号，我只是想转发一些别人的文章，吸引一些关注，然后接点广告挣钱。没想到后来慢慢发展成了原创公众号，又累又不赚钱~~

今年听了朋友的建议，试试短视频。本来只想做每期十几秒，回答一个问题那种超短抖音视频，轻松不累。没想到阴差阳错 B 站渠道给火了，一个月涨粉接近一万个。承蒙 B 站粉丝厚爱，为了不丢脸，只能硬着头皮做了几期长视频，效果也都还可以。就是视频做起来太累了，慢慢的就鸽子了~~~

今年整体的创作输出上，技术内容更少了，思考感悟类内容更多了。也符合自己去年的想法，希望沉淀更多的方法论出来，授人以鱼不如授人以渔。

在自媒体上，我没给自己太大压力，想写了就写一篇，不想写就不写了，经常几个月不更新。距离上一次更文过了快两个月了，o(╥﹏╥)o

明年希望能多一些输出，不只是文字的，视频也希望多出几期。同时仍然不会在自媒体上给自己太多压力，开心就好~

4.2 创业

今年为了学习 web3，利用闲暇时间主动找了一些项目参与。和阿里同事深度玩了一个 web3 项目，投入了一个多月空余时间，虽然最后没有结果，但让自己真正的入门了 web3，也认识了一些牛逼的人，很充实很刺激~

这个项目 GG 之后，又和蚂蚁的几个小伙伴折腾另外的项目玩，虽然 99% 可能不会有结果，但过程真的很有趣。

也希望在新的一年，自己可以保持热情，让空余时间发挥更大的价值，折腾就对了~

4.3 看书

今年看了大约 15 本书，各种方向的都有，已经养成了看书的习惯，非常不错~
以前觉得看书，看完也记不住，太累。现在的心态就是记不住就记不住，看的时候爽就行~~

今年再接再厉，空余时间多看书~

4.4 理财

理财上，典型的韭菜一枚。
今年基金和股票应该在 -30% 以上，你们挣的钱都是我亏的~
目前投资属于放养状态，完全不管了，亏吧~
新的一年会多看一些投资类的书籍，让自己的亏的明白一些。

5. 总结

2022 年就这样吧，给 2023 年定一些方向：

1. 工作上，保持热情，持续折腾，高标准要求自己


2. 生活上，愿望清单开始清理，多带家里人出去玩玩


3. 锻炼身体


4. 自媒体继续努力


5. 学习英语


6. 空闲时间多折腾折腾各种项目


7. 认识更多朋友

关于作者

砖家，brickspert

前蚂蚁集团前端技术专家

开源库 ahooks 作者，10k+ star ⭐️

开源库 antd mobile 前负责人，10k+ star ⭐️

你可以在以下渠道找到我：

公众号：前端技术砖家

B 站：前端技术砖家

知乎：砖家

掘金：前端技术砖家

Github：brickspert

工作中大家会接触到形形色色的 url，有些完美遵循格式，有些却像刺客一样，冷不丁的给你一刀。

先介绍下我的惨痛经历，给大家避避坑，最后告诉大家一个 url 刺客的妙用。

刺客介绍

1. iOS WKWebview 刺客

此类刺客手段单一，只会影响 iOS WKWebview

• 空格

运营人员由于在通讯工具中复制粘贴，导致前面多了一个空格，没有仔细检查，直接录入了后台管理系统。

• 中文

运营人员为了方便自身统计，直接在url中加入中文，录入了后台管理系统。

现象均为打开一个空白页，常见的处理手段如下：

• 将参数里的中文URIEncode


• 去掉首尾空格

const safeUrl = (url: string) => {

    const index = url.indexOf('?');



    if (index === -1) return url.trim();



    // 这行可以用任意解析参数方法替代，仅代表要拿到参数，不考虑兼容性的简单写法

    const params = new URLSearchParams(url.substring(index));

    const paramStr = Object.keys(params)

        .map((key: string) => {

            return `${key}=${encodeURIComponent(params[key])}`;

        })

        .join('&');

        

    const formatUrl = url.substring(0, index + 1) + paramStr;



    return formatUrl.trim();

};

可以看到虽然这里提出了一个 safeUrl 方法，但如果业务中大量使用 window.location.href , window.location.replace, 之类的方法进行跳转，替换起来会比较繁琐.

再比如在 Hybrid App 的场景中，虽然都是跳转，打开新的 webview ，还是在本页面跳转会是不同的实现，所以在业务内提取一个公共的跳转方法更有利于健壮性和拓展性。

值得注意的是，如果链接上的中文可能是用于统计的，在上报打点时，应该将其值（前端/服务端处理均可）进行 URIDecode，否则运营人员会在后台看到一串串莫名其妙的 %XX ，会非常崩溃（别问我怎么知道的，可能只是伤害过太多运营）

2. 格式刺客

格式刺客指的是，不管何种原因，不知何种场景，就是不小心配错了，打错了，漏打了等。

比如：https://www.baidu.com 就被打成了 htps://www.baidu.com、www.baidu.com 等。

// 检查URL格式是否正确

function isValidUrl(url: string): boolean {

  const urlPattern = new RegExp(

    "^(https?:\/\/)?" + // 协议

    "(([a-zA-Z0-9-]+\.)+[a-zA-Z]{2,})" + // 域名

    "(:[0-9]{1,5})?" + // 端口号

    "(\/.*)?$", // 路径

    "i"

  );

  return urlPattern.test(url);

}

以上是一个很基础的判断，但是实际的应用场景中，有可能会需要填写相对路径，或者自定义的 scheme ，比如 wx:// ，所以检验的宽松度可以自行把握。

在校验到 url 配置可能存在问题时，可以上报到 sentry 或者其他异常监控平台，这样就可以比用户上报客服更早的发现潜在问题，避免长时间的运营事故。

3. 异形刺客

这种刺客在视觉上让人无法察觉，只有在跳转后才会让人疑惑不已。他也是最近被产品同学发现的，以下是当时的现场截图：

一段平平无奇的文本，跟着一段链接，视觉上无任何异常。

经过对跳转后的地址进行分析，发现了前面居然有一个这样的字符%E2%80%8B，好奇的在控制台中进行了尝试。

一个好家伙，这是什么，两个单引号吗？并不是，对比了很常用的 '%2B' ，单引号是自带的，那么我到底看到了什么，魔鬼嘛～

在进行了一番检索后知道了这种字符被称为零宽空格，他还有以下兄弟：

• \u202b-\u202f


• \ufeff


• \u202a-\u202e

具体含义可以看看参考资料，这一类字符完全看不见，但是却对程序的运行产生了恶劣的影响。

可以使用这个语句去掉

str.replace(/[\u200b-\u200f\uFEFF\u202a-\u202e]/g, "");

刺客的妙用

头一天还被刺客气的瑟瑟发抖。第二天居然发现刺客的妙用。

场景：

• 
  

  产品要求在微信环境隐藏标题

  
  

我方前端工程师：

• 大手一挥，发功完毕，准备收工

document.title = '';

测试：

• 
  

  来看看，页面A标题隐藏不了

  
  

我方前端工程师：

啊？怎么回事，本地调试还是好的，发上去就不行了，为什么页面A不可以，另外一个页面B只是参数变了变就行。

架构师出手：

页面A包含了开放标签，导致设置空Title失效，空，猛然想起了刺客，快用起来！

function setTitle(title: string) {

    if (title) {                

        document.title = title;            

    } else {                

        document.title = decodeURIComponent('%E2%80%8B');

    }

}

果然有效，成功解决了一个疑难杂症，猜测是微信里有不允许设置标题为空的机制，会在某些标签存在的时候被触发。（以上场景在 Android 微信 Webview 中可复现）

小结

以上只是工作中碰到 url 异常的部分场景和处理方案，如果小伙伴们也有类似的经历，可以在评论区中分享，帮助大家避坑，感谢朋友们的阅读，笔芯～

参考资料：

零宽字符 - 掘金LvLin

什么零宽度字符，以及零宽度字符在JavaScript中的应用 - 掘金whosmeya

前言

在Linux中，我们经常使用kill或者kill -9来杀死特定的进程，但是有些时候，这些方法可能无法终止某些进程。本文将详细解释为什么会出现这种情况，以及如何处理这种问题。

无法被杀死的进程：

首先，我们来理解一下为什么有些进程无法被杀死。通常，这是因为这些进程处于以下两种状态之一：

僵尸进程（Zombie Process）：

当一个进程已经完成了它的运行，但是其父进程还没有读取到它的结束状态，那么这个进程就会成为僵尸进程。僵尸进程实际上已经结束了，所以你无法使用kill命令来杀掉它。

内核态进程：

如果一个进程正在执行某些内核级别的操作（即进程处在内核态），那么这个进程可能无法接收到kill命令发送的信号。

查找和处理僵尸进程：

如果你怀疑有僵尸进程存在，你可以使用以下命令来查找所有的僵尸进程：

ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'

这个命令实际上是由两个命令通过管道(|)连接起来的。管道在Linux中的作用是将前一个命令的输出作为后一个命令的输入。命令的两部分是 ps -A -ostat,ppid,pid,cmd 和 grep -e '^[Zz]'。

• ps -A -ostat,ppid,pid,cmd：这是ps命令，用来显示系统中的进程信息。
  
  
  
  • -A：这个选项告诉ps命令显示系统中的所有进程。
  
  
  • -o：这个选项允许你定义你想查看的输出格式。在这里，你定义的输出格式是stat,ppid,pid,cmd。这会让ps命令输出每个进程的状态（stat）、父进程ID（ppid）、进程ID（pid）以及进程运行的命令（cmd）。
  
  
  
  


• grep -e '^[Zz]'：这是grep命令，用来在输入中查找匹配特定模式的文本行。
  
  
  
  • -e：这个选项告诉grep命令接下来的参数是一个正则表达式。
  
  
  • '^[Zz]'：这是你要查找的正则表达式。^符号表示行的开始，[Zz]表示匹配字符“Z”或者“z”。因此，这个正则表达式会匹配所有以“Z”或者“z”开头的行。在ps命令的输出中，状态为“Z”或者“z”的进程是僵尸进程。
  
  
  
  

因为僵尸进程已经结束了，所以你无法直接杀掉它。但是，你可以试图杀掉这些僵尸进程的父进程。杀掉父进程之后，僵尸进程就会被init进程（进程ID为1）接管，然后被清理掉。

你可以使用以下命令来杀掉父进程：

kill -HUP [父进程的PID]

请注意，在杀掉父进程之前，你需要确定这样做不会影响到系统的其他部分。另外，这个方法并不保证能够清理掉所有的僵尸进程。

查找和处理内核态进程：

如果一个进程处在内核态，那么这个进程可能无法接收到kill命令发送的信号。在这种情况下，你需要首先找到这个进程的父进程，然后试图杀掉父进程。你可以使用以下命令来查找进程的父进程：

cat /proc/[PID]/status | grep PPid

这个命令会输出进程的父进程的ID，由两个独立的命令组成，通过管道（|）连接起来。我会分别解释这两个命令，然后再解释整个命令：

• cat /proc/[PID]/status ：
  
  
  
  • 这是一个cat命令，用于显示文件的内容。在这个命令中，它用于显示一个特殊的文件/proc/[PID]/status。
  
  
  • /proc是一个特殊的目录，它是Linux内核和用户空间进行交互的一种方式。在/proc目录中，每个正在运行的进程都有一个与其PID对应的子目录。每个子目录中都包含了关于这个进程的各种信息。
  
  
  • /proc/[PID]/status文件包含了关于指定PID的进程的各种状态信息，包括进程状态、内存使用情况、父进程ID等等；
  
  
  
  


• grep PPid ：


• 这是一个grep命令，用于在输入中查找匹配特定模式的文本行。在这个命令中，它用于查找包含PPid的行。在/proc/[PID]/status文件中，PPid一行包含了这个进程的父进程的PID；
  然后，你可以使用以下命令来杀掉父进程：

kill -9 [父进程的PID]

同样，你需要在杀掉父进程之前确定这样做不会影响到系统的其他部分。另外，这个方法并不保证能够杀掉所有的内核态进程。

结论：

在Linux系统中，处理无法被杀死的进程可以是一项挑战，尤其是当你无法确定进程状态或者无法影响父进程的时候。以上的方法并不保证能够解决所有问题。如果你尝试了所有的方法，但问题仍然存在，或者你不确定如何进行，那么你可能需要联系系统管理员，或者寻求专业的技术支持。

总的来说，处理无法被杀死的进程需要对Linux的进程管理有深入的理解，以及足够的耐心和谨慎。希望这篇文章能够帮助你更好地理解这个问题，以及如何解决这个问题。

1. 背景

一般业务也很少接触摄像头，有也是现成的工具库扫个二维码。难得用一次，记录下踩坑。

2.调用摄像头的方法

2.1. input

<!-- 调用相机 -->

<input type="file" accept="image/*" capture="camera">

<!-- 调用摄像机 -->

<input type="file" accept="video/*" capture="camcorder">

<!-- 调用录音机 -->

<input type="file" accept="audio/*" capture="microphone">

这个就不用多说了，缺点就是没办法自定义界面，它是调用的系统原生相机界面。

2.2. mediaDevices

由于我需要自定义界面，就像下面这样：

所以我选择了这个方案，这个api使用起来其实很简单：

<!-- 创建一个video标签用来播放摄像头的视屏流 -->

<video id="video" autoplay="autoplay" muted width="200px" height="200px"></video>

<button onclick="getMedia()">开启摄像头</button>

async getMedia() {

    // 获取设备媒体的设置，通常就video和audio

    const constraints = {  

    // video配置，具体配置可以看看mdn

        video: {  

            height: 200,  

            wdith: 200,  

        },  

    // 关闭音频

        audio: false  

    };  

    this.video = document.getElementById("video");  

    // 使用getUserMedia获取媒体流

    // 媒体流赋值给srcObject

    this.video.srcObject = await window.navigator.mediaDevices.getUserMedia(constraints);

    // 直接播放就行了

    this.video.play();  

}

可以看到这个效果。

这个api的配置可以参考MDN

// 截图拍照

takePhoto() {  

    const video = document.getElementById("video");  

    // 借助canvas绘制视频的一帧

    const canvas = document.getElementById("canvas");  

    const ctx = canvas.getContext('2d');  

    ctx.drawImage(this.video, 0, 0, 300, 300);  

},

// 停止

stopMedia() {  

    // 获取媒体流

    const stream = this.video.srcObject;  

    const tracks = stream.getTracks();  

    // 停止所有轨道

    tracks.forEach(function (track) {  

        track.stop();

    })  

    this.video.srcObject = null;  

}

3.坑

如果你复制我的代码，在localhost上肯定能运行，但是你想在手机上试试的时候就会发现很多问题。

3.1. 需要https

由于浏览器的安全设置，除了localhost和https连接，你都没办法获取到navigator.mediaDevices，打印出来是undefined。如果要在手机上测试，你要么用内网穿透代理一个https，要么部署在https域名的服务器上测试。

3.2. 设置前后摄像头

默认是使用user设备，也就是前摄像头，想要使用后摄像头也是有配置的，

async getMedia() {

    // ...

    let constraints = {  

        video: {  

            height: 200,  

            wdith: 200,  

            // environment设备就是后置

            facingMode: { exact: "environment" },  

        },  

        audio: false  

    };

    // ...

}

3.3. 设置显示区域大小

我的需求是铺满整个设备，所以我想当然的直接把video样式宽高设置成容器大小：

#video {

    width: 100%;

    height: 100%;

}

async getMedia() {

    // ....

    // 将宽高设置成容器大小

    const pageSize = document.querySelector('.page').getBoundingClientRect()  

    let constraints = {  

    video: {  

            height: pageSize.height,  

            width: pageSize.width,  

            facingMode: { exact: "environment" },

        },  

        audio: false  

    };

    //....

}

发现这个视频横着而且没有铺满屏幕。

通过输出video的信息可以看到，设备返回的视频流宽高是反的：

所以配置换一下就行了：

    let constraints = {  

        video: {  

            height: pageSize.width,  

            width: pageSize.height,  

        },  

    };

上面是我打开百度百科，写着对全栈工程师的解释：是指掌握多种技能，可以胜任前端和后端，能用多种技能独立完成产品的人。

对于这个答案我是保持观望的态度。如果说能同时开发前端和后端，还能独立完成产品，它就是全栈工程师的话，那计算机专业的大学生做完毕业设计之后就都是全栈了。

对于百科的这个定义，我感觉确实有点宽泛了，于是我就重新编辑了这个百度百科：

小伙伴们可能不知道百度百科是可以随意编辑的，我整整花了一分钟的时间，精心编辑了一个百度百科的概念：全栈工程师是指在web项目开发中，独立掌握web前端、安卓开发、ios开发、后端技术（Java，PHP，Node，关系型数据库，分布式开发等技术）的综合性、高素质软件工程师。 目前为止这个词条的审批还没有通过。

再回到全栈工程师这个称呼上，我第一次听到这个词是在2015年，那时候前后端分离的开发模式刚刚开始被普及。因为2015年之前的web开发项目，前端几乎都是用模板套jQuery来做的。像ember、backbone、angularjs这些框架，小公司几乎用不起来。

但是在2015年这个节点，web项目井喷式地增长，像react这样新兴的轻量级框架，开始走进了中小公司。前后端分离的开发模式也越来越多的被大家使用起来了，在这个技术背景之下，全栈工程师这个词被提的就越来越多，而被称为全栈工程师的人主要分成以下三类。

第一类：

在公司的技术部门独挡一面，被同事称为问题终结者或者是bug收割机，这样的全栈工程师其实也是所有对技术追求的程序员而奋斗的目标，我确实很佩服这样的全栈。

第二类：

主要分布在中小公司，名头是【全栈工程师】，其实是【全干工程师】。小公司为了节约人力成本，前后端就找一个人干，甚至可能一个公司就一个程序员把所有的活都干了。

各种的压榨劳动力，然后还给了一个好的名头（全栈工程师），没事再画画饼，说公司上市之后，你就是技术总监，然后享受各种股份，期权，你就财富自由了。现实情况就是你累倒了，老板财富自由了。

但是在2015年前后那个时候大家还是很吃这一套的，所以很多人愿意天天加班，最后大多数人也是什么也没得到。现在大家看招聘网站上，小公司招聘的全栈工程师基本都是这个套路：

就是说想用更少的钱去招人干更多的活，这工作基本上干起来就是一地鸡毛。

第三类：

相比上面的【全干工程师】，这一类才坑，培训机构。借着【全栈工程师】的这个名号忽悠大学生。比如一个机构，它以前是教java的，后面就加了点前端的课程，又或者以前是教前端的，然后加了点Node课程，就说我们是全栈工程师培训机构。

许多学生们纷纷交钱报班，等毕业了才知道自己学的这个【全栈工程师】只能去小作坊企业，996公司，或者是去一些非软件，非互联网干一些辅助工作。

总结：

真正正规的软件公司或者互联网公司都是专人专岗的，就算它招了全栈工程师，也是高新的技术专家，怎么可能招一个培训班刚毕业，包装2年工作经验的职场新人呢。所以大部分情况下，我确实不太喜欢全栈工程师这个岗位（称呼），因为这个词总是能和【忽悠大学生】，【压榨劳动力】这些联系到一起。

程序猿的35岁危机

程序猿的35岁危机已经不是个新鲜话题了，不管行内还是行外多少都听过了解过。行外的一听：咦～😒，程序猿狗都不干！、行内的一听笑一笑也就过去了，大部分都是当成个笑点，并未真正思考过（当然也可能是逃避）。

程序员毕竟是有点脑力活的职业，到了35岁基本上就无法在一线开发上熬了，不像拧螺丝，我感觉我60岁拧的应该也不慢哈哈哈。所以如果能预测到35岁升不到管理岗或者未转行，那就要开始思考如果被裁之后能干什么了。

• 卖煎饼（有贷在身的就别想了，卖不完根本卖不完


• 短视频等副业（有点搞头，趁早


• 独立AI应用工程师（有精力才行）


• ......

我预想这个问题的时候，发现我竟然什么都不会，舒适圈待久了，也没有动力去学新的东西，我意识到这样下去肯定不行，得找点后路。

屌丝现状

我：从小到大都是那种处在中间层的人物，没有做过领头羊，也没有拖过别人的腿。成绩属于中层；身高处于中层（180🤪）；家庭属于中层。当然肉夹馍我只吃中间那层。

正是因为都是夹心饼干，让我一直处于舒适圈，既拿不出寒门学子的冲劲，家底也不支持我躺的安静，导致我高不成低不就的状况，没错，就是这款冰红茶，屌丝款极具性价比。

虽然有点技术追求，也看过写过不少源码，算法题也做了不少，但是就是缺少一鞭子让我跳出那个圈子，刚校招时，信誓旦旦的觉得自己技术牛逼，肯定能进大厂，但是现实总会给你迎头一棒，于是就进了一家中厂，刚开始的时候内心还是满船清梦，心态良好，路漫漫其修远兮，吾将上下而求索。

到了后面，才发现满腔热血早已被各种业务琐事冷却，许多精力都用来应对客户以及各种内部无厘头，加上加班，回到茅屋根本无力再精进功力，慢慢地，曾经想在大厂大显身手的念头也羞于提起，毕业两年未到就想着养老躺平，各种摸鱼技术倒是进步了不少，哈哈哈，这让我想起老父亲常常训我的话：

$你学习要有打游戏这份劲，早就上清华啦🤡$

回想起来，已经许久未跟家里通过一通电话了，筹划许久带父母国庆去旅行也没有实现，只寄了几个老母亲下不了口的双流老妈麻辣兔头，估计也是得等我回去消灭了。

我呢，属于是人小穷志不穷，志虽然不穷，但是也不多，有点杞人忧天，喜欢想很远很远的可能存在的隐患，差不多是时态里面的一般过去现在将来时（最近在从头梳理英语哈哈）。想的东西特别多，行动的屈指可数。

• 35岁危机之前一直在想


• 健身


• 博客写作


• 骑行，吉他 还算过得去


• ......

以俺目前的情况来看，如果不努力一把进大厂搞点青春血汗钱，大概率是浑浑噩噩，凄凄惨惨戚戚的在中小厂熬到35岁，然后一大把年纪，卷不过小鲜肉，熬不过鸡汤，然后下岗。当然这对于有点咸鱼觉悟的我来说是万万不可能让它发生的，摸鱼我也要可持续性摸鱼！

咱就是说现今这种社会夹心饼的情况，不知道有多少Javaer跟我一样，每天上班💼就是打几行代码，摸摸鱼，像你们一样看看掘金。每天就在掘金找找别人生活失意的文章来抚慰内心的荒芜不安，看到别人过的不咋样，自己也就烂的心安理得了；看到别人凭自己的努力进大厂进外企又心痒痒，打开leetcode，肯触c肯触v，搞定，今天又骗过了自己。

我相信应该有不少人就像我这样，别否认，说的就是你

$\color{green}{内心虽有鸿鹄之志，怎耐无破而后立之决心$
}

都怪自己没有穷的叮当响，激发不出意志潜力哈哈哈哈

话说回来，虽然知道这样不好，自欺欺人，结果不会帮着你一起行骗，但是就是少了份冲劲，没有一个小镇做题家该有的决心觉悟，内心又渴望自己能够提升进步，却一而再的给自己留退路找借口。

痛定思痛

为了自己的前途着想（持续摸鱼😀），彻夜冥想，找了三条可以应对危机又不那么累的路。

退路一：考公

考公现在很卷，2022年212.3万人通过了资格审查，实际录用人数只有3.12万，报录比高达68：1，虽然但是，只要我们心态放好，别去选那些几千个人招一个的，趁早考，多考几次，希望还是很大的，最重要的是坚持以及学习方法，再不行还可以考事业编。

退路二：外企

程序员去外企主要是英语能力要跟的上，虽然也可能有危机，但是概率小很多，况且英语能力摆在那，就算去干其他的也不至于入不敷出（关键在于把英语学好，过程重要‼️，最终能不能去外企放倒是其次）

退路三：放弃自我，精神小伙

其实为什么现在很多网红都是学历比较低，因为学历低的人接受教育比较少，没那么多包袱，许多想做的事情不会有心理负担，而高学历的人，很多都不愿意抛头露面，认为那是丢脸的事情。另外高学历的人道德感比较强，不愿意做一些违心的话题，特别是不愿意炒作。

加上如今畸形的社会审美，低俗的短视频反而更能获得注目，优秀的产出只有少数人驻足。

如果我们能放好心态，告诉自己赚钱不寒碜，跟网红们卷起来，高等的教育能让我们经受住网络看客的审察，这也许是优势🖖

总结

像我这样处在中间高不成低不就的程序员，心态放好就是一种幸福，每天打打代码偶尔旅旅游，陪陪父母，不会大富大贵也不会食不果腹，摆烂会不安，努力又泡汤，我想这应该就是属于我的道。

最后：如果你已经为自己选好了退路，就全力以赴，不要每天想起来就学一点，造成退路已经妥了的假象。我希望你可以两手抓，而不是说你在备考公务员，你觉得你有退路了，目前的工作就不重视，态度散漫，到时还没开始考试你就失业了。

这是我在掘金的第一篇文章，主要是记录下自己的所思所想，当然如果这篇文章能引起读者们的一些思考，那也是掘掘子啊👍🏽，哈哈哈哈。

但使龙城飞将在，不教胡马度阴山