打印流程

小程序连接蓝牙打印大致可以分为九步:1.初始化蓝牙模块、2.开始搜索附近的蓝牙设备、3.获取搜索到的蓝牙列表、4.监听寻找到新设备的事件、5.连接蓝牙设备、6.关闭搜索蓝牙设备事件、7.获取蓝牙设备的所有服务、8.获取服务的所有特征值、9.向蓝牙设备写入数据

1.初始化蓝牙模块 uni.openBluetoothAdapter

注意:其他蓝牙相关 API 必须在 uni.openBluetoothAdapter 调用之后使用。

uni.openBluetoothAdapter({

  success(res) {

    console.log(res)

  }

})

2.开始搜索附近的蓝牙设备 uni.startBluetoothDevicesDiscovery

此操作比较耗费系统资源，请在搜索并连接到设备后调用 uni.stopBluetoothDevicesDiscovery 方法停止搜索。

uni.startBluetoothDevicesDiscovery({

  success(res) {

    console.log(res)

  }

})

3.获取搜索到的蓝牙列表 uni.getBluetoothDevices

获取在蓝牙模块生效期间所有已发现的蓝牙设备。包括已经和本机处于连接状态的设备(不是很准确,有时会获取不到)。

uni.getBluetoothDevices({

  success(res) {

    console.log(res)

  }

})

4.监听寻找到新设备的事件 uni.onBluetoothDeviceFound

监听寻找到新设备的事件,跟第三步一起使用,确保能获取附近所有蓝牙设备。

uni.onBluetoothDeviceFound(function (devices) {

  console.log(devices)

})

5.连接蓝牙设备 uni.createBLEConnection

若APP在之前已有搜索过某个蓝牙设备，并成功建立连接，可直接传入之前搜索获取的 deviceId 直接尝试连接该设备，避免用户每次都要连接才能打印，省略二三四步减少资源浪费。

uni.createBLEConnection({

  deviceId:获取到蓝牙的deviceId,

  success(res) {

    console.log(res)

  }

})

6.关闭搜索蓝牙设备事件 uni.stopBluetoothDevicesDiscovery

停止搜寻附近的蓝牙外围设备。若已经找到需要的蓝牙设备并不需要继续搜索时，建议调用该接口停止蓝牙搜索。

uni.stopBluetoothDevicesDiscovery({

  success(res) {

    console.log(res)

  }

})

7.获取蓝牙设备的所有服务 uni.getBLEDeviceServices

uni.getBLEDeviceServices({

  // 这里的 deviceId 需要已经通过 createBLEConnection 与对应设备建立链接

  deviceId,

  success(res) {

    console.log('device services:', res.services)

  }

})

8.获取服务的所有特征值 uni.getBLEDeviceCharacteristics

uni.getBLEDeviceCharacteristics({

  // 这里的 deviceId 需要已经通过 createBLEConnection 与对应设备建立链接

  deviceId,

  // 这里的 serviceId 需要在 getBLEDeviceServices 接口中获取

  serviceId,

  success(res) {

    console.log('device getBLEDeviceCharacteristics:', res.characteristics)

  }

})

三种不同特征值的id

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

					if (!notify) {

						notify = res.characteristics[i].properties.notify;

						if (notify) readId = res.characteristics[i].uuid;

					}

					if (!indicate) {

						indicate = res.characteristics[i].properties.indicate;

						if (indicate) readId = res.characteristics[i].uuid;

					}

					if (!write) {

						write = res.characteristics[i].properties.write;

						writeId = res.characteristics[i].uuid;

					}

					if ((notify || indicate) && write) {

						/* 获取蓝牙特征值uuid */

						success &&

							success({

								serviceId,

								writeId: writeId,

								readId: readId,

							});

						finished = true;

						break;

					}

9.向蓝牙设备写入数据 uni.writeBLECharacteristicValue

向低功耗蓝牙设备特征值中写入二进制数据。注意：必须设备的特征值支持 write 才可以成功调用。

并行调用多次会存在写失败的可能性。

APP不会对写入数据包大小做限制，但系统与蓝牙设备会限制蓝牙4.0单次传输的数据大小，超过最大字节数后会发生写入错误，建议每次写入不超过20字节。

若单次写入数据过长，iOS 上存在系统不会有任何回调的情况（包括错误回调）。

安卓平台上，在调用 notifyBLECharacteristicValueChange 成功后立即调用 writeBLECharacteristicValue 接口，在部分机型上会发生 10008 系统错误

// 向蓝牙设备发送一个0x00的16进制数据

const buffer = new ArrayBuffer(1)

const dataView = new DataView(buffer)

dataView.setUint8(0, 0)

uni.writeBLECharacteristicValue({

  // 这里的 deviceId 需要在 getBluetoothDevices 或 onBluetoothDeviceFound 接口中获取

  deviceId,

  // 这里的 serviceId 需要在 getBLEDeviceServices 接口中获取

  serviceId,

  // 这里的 characteristicId 需要在 getBLEDeviceCharacteristics 接口中获取

  characteristicId,

  // 这里的value是ArrayBuffer类型

  value: buffer,

  success(res) {

    console.log('writeBLECharacteristicValue success', res.errMsg)

  }

})

写在最后

DEMO地址:gitee.com/zhou_xuhui/… (plus可能会报错,demo中注释掉就好,不影响流程)

打印机CPCL编程参考手册（CPCL 语言）:http://www.docin.com/p-2160

【新智元导读】 LeCun昨天在一场辩论中再贬ChatGPT！形容这个AI模型的智力连狗都不如。

图灵三巨头之一的LeCun昨日又爆金句。

「论聪明程度，ChatGPT可能连条狗都不如。」

这句话来自本周四LeCun在Vivatech上和Jacques Attalie的一场辩论，可谓精彩纷呈。

CNBC甚至直接把这句话放到了标题里，而LeCun也在之后火速转推。

“ChatGPT和狗：比不了一点”

LeCun表示，当前的AI系统，哪怕是ChatGPT，根本就不具备人类的智能水平，甚至还没有狗聪明。

要知道，在AI爆炸发展的今天，无数人已经为ChatGPT的强大性能所折服。在这种情况下，LeCun的这句话可谓惊世骇俗。

不过，LeCun一贯的观点都是——不必太过紧张，如今的AI智能水平远远没到我们该担忧的地步。

而其他的科技巨头则基本和LeCun持截然相反的意见。

比如同为图灵三巨头的Hinton和Bengio，以及AI届人士由Sam Altman挑头签的公开信，马斯克的危机言论等等。

在这种大环境下，LeCun一直「不忘初心」，坚定认为现在真没啥可担心的。

LeCun表示，目前的生成式AI模型都是在LLM上训练的，而这种只接受语言训练的模型聪明不到哪去。

「这些模型的性能非常有限，他们对现实世界没有任何理解。因为他们纯粹是在大量文本上训练的。」

而又因为大部分人类所拥有的知识其实和语言无关，所以这部分内容AI是捕捉不到的。

LeCun打了个比方，AI现在可以通过律师考试，因为考试内容都停留在文字上。但AI绝对没可能安装一个洗碗机，而一个10岁的小孩儿10分钟就能学会怎么装。

这就是为什么LeCun强调，Meta正尝试用视频训练AI。视频可不仅仅是语言了，因此用视频来训练在实现上会更加艰巨。

LeCun又举了个例子，试图说明什么叫智能上的差别。

一个五个月大的婴儿看到一个漂浮的东西，并不会想太多。但是一个九个月大的婴儿再看到一个漂浮的物体就会感到非常惊讶。

因为在九个月大的婴儿的认知里，一个物体不该是漂浮着的。

LeCun表示，如今我们是不知道如何让AI实现这种认知能力的。在能做到这一点之前，AI根本就不可能拥有人类智能，连猫猫狗狗的都不可能。

Attali：我也要签公开信

在这场讨论中，法国经济和社会理论家Jaques Attali表示，AI的好坏取决于人们如何进行利用。

然而他却对未来持悲观态度。他和那些签公开信的AI大牛一样，认为人类会在未来三四十年内面临很多危险。

他指出，气候灾难和战争是他最为关注的问题，同时担心AI机器人会「阻挠」我们。

Attali认为，需要为AI技术的发展设置边界，但由谁来设定、设定怎么样的边界仍是未知的。

这和前一阵子签的两封公开信所主张的内容相同。

当然，公开信LeCun也是压根没搭理，发推高调表示哥们儿没签。

LeCun炮轰ChatGPT——没停过

而在此之前，LeCun针对ChatGPT不止讲过过一次类似的话。

就在今年的1月27日，Zoom的媒体和高管小型聚会上，LeCun对ChatGPT给出了一段令人惊讶的评价——

「就底层技术而言，ChatGPT并不是多么了不得的创新。虽然在公众眼中，它是革命性的，但是我们知道，它就是一个组合得很好的产品，仅此而已。」

「除了谷歌和Meta之外，还有六家初创公司，基本上都拥有非常相似的技术。」

此外，他还表示，ChatGPT用的Transformer架构是谷歌提出的，而它用的自监督方式，正是他自己提倡的，那时OpenAI还没诞生呢。

当时闹得更大，Sam Altman直接在推上给LeCun取关了。

1月28日，LeCun梅开二度，继续炮轰ChatGPT。

他表示，「大型语言模型并没有物理直觉，它们是基于文本训练的。如果它们能从庞大的联想记忆中检索到类似问题的答案，他们可能会答对物理直觉问题。但它们的回答，也可能是完全错误的。」

而LeCun对LLM的看法一以贯之，从未改变。从昨天的辩论就可以看出，他觉得语言训练出来的东西毫无智能可言。

今年2月4日，LeCun直白地表示，「在通往人类级别AI的道路上，大型语言模型就是一条歪路」。

「依靠自动回归和响应预测下一个单词的LLM是条歪路，因为它们既不能计划也不能推理。」

当然，LeCun是有充分的理由相信这一点的。

ChatGPT这种大语言模型是「自回归」。AI接受训练，从一个包含多达14000亿个单词的语料库中提取单词，预测给定句子序列中的最后一个单词，也就是下一个必须出现的单词。

Claude Shannon在上个世纪50年代开展的相关研究就是基于这一原则。

原则没变，变得是语料库的规模，以及模型本身的计算能力。

LeCun表示，「目前，我们无法靠这类模型生成长而连贯的文本，这些系统不是可控的。比如说，我们不能直接要求ChatGPT生成一段目标人群是13岁儿童的文本。

其次，ChatGPT生成的文本作为信息来源并不是100%可靠的。GPT的功能更像是一种辅助工具。就好比现有的驾驶辅助系统一样，开着自动驾驶功能，也得把着方向盘。

而且，我们今天所熟知的自回归语言模型的寿命都非常短，五年算是一个周期，五年以后，过去的模型就没有人再会用了。

而我们的研究重点，就应该集中在找到一种是这些模型可控的办法上。换句话说，我们要研究的AI，是能根据给定目标进行推理和计划的AI，并且得能保证其安全性和可靠性的标准是一致的。这种AI能感受到情绪。」

要知道，人类情绪的很大一部分和目标的实现与否有关，也就是和某种形式的预期有关。

而有了这样的可控模型，我们就能生成出长而连贯的文本。

LeCun的想法是，未来设计出能混合来自不同工具的数据的增强版模型，比如计算器或者搜索引擎。

像ChatGPT这样的模型只接受文本训练，因此ChatGPT对现实世界的认识并不完整。而想要在此基础上进一步发展，就需要学习一些和整个世界的感官知觉、世界结构有关的内容。

然而好玩儿的是，Meta自己的模型galactica.ai上线三天就被网友喷的查无此人了。

原因是胡话连篇。

笑。

参考资料：http://www.cnbc.com/2023/0

移动端开发与pc端适配的不同

pc端布局常用方案

所谓适配，就是指我们的项目开发出来用户在不同虚拟环境、不同硬件环境等等各种情况下有一个稳定、正常的展示（简单理解就是不会排版混乱）

先来回顾一下pc端的项目我们如何写页面做到适配的，大部分页面都是采用版心布局的形式。也就是说所有的内容都写在版心容器盒子里，这个容器盒子设置：margin: 0 auto; & min-width: <版心宽度> & width: <版心宽度>就可以保证：

• 
  

  当用户的屏幕（浏览器）宽度很大，或者缩放浏览器到很小比例时，此时浏览器的宽度大于版心盒子的width，版心容器会自动生成margin-left & margin-right，总会保证版心容器处于页面的正中心。

  
  

  这里可以提一嘴pc端浏览器缩放的原理：页面所有元素的css宽高都不会改变，只是css像素的在屏幕上展示的大小缩水了，具体点来说，原本700px * 700px的盒子在浏览器上用10cm * 10cm面积（的物理像素）渲染，但现在用原本<浏览器缩放比率> * 10cm * 10cm面积（的物理像素）渲染。

  
  


• 
  

  当用户的屏幕小于版心盒子的width，出现横向滚动条，版心盒子的左右margin为0，width内的内容可滑动滚动条完整查看。

  
  

可以参考大淘宝pc端官网就是版心布局的实践。

好了，那么问题来了，移动端为啥不能照搬pc端的这种适配方案呢？

我们有必要先梳理一下移动端对页面进行渲染展示的逻辑：

移动端页面渲染的逻辑

无<meta name="viewport">的情况

在html文档里没有<meta name="viewport">标签配置的情况下（通过对比即可理解<meta>标签的意义）：

plus：如下整个流程篇口语话主要是梳理核心思路，没有一字一板的细节考究

1. 我们项目中布局写的所有dom元素的css大小都正常（完全按照css大小的预期）在一个非常大的空间进行渲染，这个空间可能不是无限大，但是为了帮助理解，因为这个空间的大小一般不影响我们项目的正常布局，所以我们可以理解为无限大，这是第一步，即项目页面就像在pc端一样完全按照css写的大小以及布局进行渲染。

2. 因为我们的移动端设备没有电脑屏幕那么大，所以会把第一步在“很大空间”渲染的页面进行缩小，直至缩小到我们的大页面宽度正好与手机屏幕的宽度一样即可。所以第二步相当于为了让用户把页面看全，手机自动把页面缩小至屏幕内。

为了帮助大家理解，也验证我上面的说法，我写了如下的pc端的版心布局的页面：

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Document</title>

</head>

<style>

.container {

    width: 1200px;

    min-width: 1200px;

    margin: 0 auto;

    border: 2px solid red;

    background: yellow;

}

.container .content {

    height: 3000px;

}

</style>

<body>

    <div class="container">

        <div class="content">内容</div>

    </div>

</body>

</html>

我把上面的页面部署到osrc（一个国内的免费部署网站，类似于vercel）上了（不可用chrome浏览器的移动端去模拟移动端访问的场景，chrome浏览器只是模拟了屏幕大小，而并没有模拟移动端环境，也就是说根本不会处理<meta>标签，所以这里我们需要部署），大家可以自行用pc端和移动端访问体验（实践一下绝对秒懂我上面的文字），为了照顾没有双端设备的读者，我截一下图（直接喂饭到胃哈哈）

pc端访问：

移动端访问：

清晰了吧兄弟们，我们写死的1200px宽的container盒子因为手机本身没这么大，所以缩小之后塞进了手机屏幕中，仔细看手机中的文字，已经被缩小的看不清了。

配置<meta name="viewport">的情况

暂时只给我们的index.html中<meta name="viewport">添加一个content="width=device-width, initial-scale=1.0"

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

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

    <title>Document</title>

</head>

<style>

.container {

    width: 1200px;

    min-width: 1200px;

    margin: 0 auto;

    border: 2px solid red;

    background: yellow;

}

.container .content {

    height: 3000px;

}

</style>

<body>

    <div class="container">

        <div class="content">内容</div>

    </div>

</body>

</html>

重新部署后访问查看效果，有meta的页面，部署地址，<meta>标签是针对移动端的，所以pc端完全没影响，跟上面一样。现在我们访问移动端效果如下，我没有缩小图片，注意观察页面底部出现滚动条了（纵向滚动条有滚动所以文字没展示，不重要）：

解释一下content="width=device-width, initial-scale=1.0"的作用。

解读<meta> & dip & 布局视口（自认为最精华，全网少数不带偏新人的解释）

其实相当于我们在content字段中进行了两项配置，第一项是width=device-width，第一个width是指布局视口的宽度，引出概念，何为布局视口？还记得我们上面说的在没有<meta>时的那个非常大的布局空间嘛，就是它！我们让这个空间的宽度等于device-width，device-width就是指dip即设备独立像素，第二个概念，何为dip（device independent piexl设备独立像素）呢？听我的，完全不要被网上各种乱七八糟的解释弄迷糊了，什么dpr，什么物理像素，我只能说那些东西与我们开发者并没有直接关系，笔者读了几户所有能搜到的各种移动端入门文章，一言难尽... ，我来给出对于dip的理解，每一个型号的移动设备都具有的一个大小，这个大小是用设备独立像素dip来描述的，所以它仅仅是一个描述大小的单位，但是这个单位究竟是多大呢，换句话说dip有何特殊性呢？

在移动端不缩放的情况下，一个css像素等于一个设备独立像素dip

（chrome浏览器的移动端开发工具里显示的就是dip大小）也就是说，我们让布局视口的宽度等于设备的dip宽度，这里注意：布局视口由原来的”无限大“现在改为一个具体的数值，并不会影响页面的正常布局，页面还是会完整渲染， 只是最后不用缩小放进屏幕了，因为我们缩小的目的就是让布局视口完整的展现在屏幕中。因为屏幕不能展示完整整个页面的布局，所以底部出现滚动条。用户可以滚动访问页面全部内容。

其实这里initial-scale=1.0的作用就是让移动端浏览器不自行缩放，不然的话浏览器会把如上页面再缩小，然后放到手机屏幕里去。

关于<meta name="viewport">的最佳实践

简简单单如下：

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

为什么说这是最佳实践，论证它其实还缺少一个关键点，也就是移动端css单位的选取，概括来说，width=device-width配置与移动端css单位的选取两者相辅相成，共同构成了“最佳实践”。

先说一下css单位选取——以vw为例：vw是相对屏幕大小的一个长度单位，1vw等于移动设备屏幕宽度的1%。

如何理解“最佳实践”？

首先width=device-width保证了无论何种机型的移动设备，我们开发时写页面的布局视口始终等于屏幕宽度，但看这一点，确实没啥用。如果再来一个条件：页面中所有长度单位用vw来表达。细品！

如何细品？别忘了初心，我们的目标是在不同的移动设备上都能有统一的展示效果，开品：我们用不同dip宽度的设备打开网页，首先布局视口的大小会随着设备dip的不同而不同，也就是始终等于dip宽度：

布局视口宽度 === 设备dip宽度，

并且我们的所有元素大小单位都是vw，也就是说页面中所有元素大小都以屏幕宽度为参照物。最终的效果就是，一个dip宽度超级小的设备打开网页，与一个dip宽度非常大的设备打开网页，看到的页面内容是完全相似的，也就是每个元素在页面中所占的比例不同设备都一样（不同点就在于屏幕本身的大小不一样）！

一般<meta>标签的content中还会设置initial-scale=1.0, maximum-scale=1.0, user-scalable=no，即不让页面进行缩放，感觉这个看需求吧，不让缩小应该是必须的，因为可以想一想，用户缩小完全没有意义呐！（需要大家自己去理解，属于只可意会），至于让不让放大，应该是看情况吧，反正移动端淘宝官网是允许放大的。

移动端适配方案理解

主流的有vw方案、flexible + rem方案，总而言之，把元素的大小用rem来表示或者vw表示，本质都是以手机屏幕宽度为参考，vw比较直接，表达的意思就是1vw等于手机屏幕宽度的百分之一；rem比较间接，通过flexible.js先把得知屏幕宽度是多少px，然后设置<html>的font-size，进而所有元素的rem其实还是表达占屏幕宽度的百分之多少。

当然两种方案都有一些技术细节问题需要解决，比如1px问题、安全区域问题等等。这里就不多说了。

相信能一步一步走到这里的同志，对移动端适配绝对有了一个清晰的把握。

2023.6.19,3: 59。

前言

通常我们在App中会使用第三方的开源代码，按照许可协议，我们应该在App中公开使用的开源代码并且附上对应的开源协议。当然，实际上只有少部分注重合规性的大厂才会这么干，比如下图是支付宝的关于界面的第三方信息。当然，对于小企业，基本上都不会放使用的第三方开源代码的任何信息。

不过，作为一个有“追求”的码农，我们还是想对开源软件致敬一下的，毕竟，没有他们我都不知道怎么写代码。然而，我们的 App 里用了那么多第三方开源插件，总不能一个个找出来一一致敬吧？怎么办？其实，Flutter 早就为我们准备好了一个组件，那就是本篇要介绍的 AboutDialog。

AboutDialog 简介

AboutDialog 是一个对话框，它可以提供 App 的基本信息，如 Icon、版本、App 名称、版权信息等。

同时，AboutDialog还提供了一个查看授权信息（View Licenses）的按钮，点击就可以查看 App 里所有用到的第三方开源插件，并且会自动收集他们的 License 信息展示。所以，使用 AboutDialog 可以让我们轻松表达敬意。怎么使用呢？非常简单，我们点击一个按钮的时候，调用 showAboutDialog 就搞定了，比如下面的代码：

IconButton(

  onPressed: () {

    showAboutDialog(

      context: context,

      applicationName: '岛上码农',

      applicationVersion: '1.0.0',

      applicationIcon: Image.asset('images/logo.png'),

      applicationLegalese: '2023 岛上码农版权所有'

    );

  },

  icon: const Icon(

    Icons.info_outline,

    color: Colors.white,

  ),

),

参数其实一目了然，具体如下：

• context：当前的 context；


• applicationName：应用名称；


• applicationVersion：应用版本，如果要自动获取版本号也可以使用 package_info_plus 插件。


• applicationIcon：应用图标，可以是任意的 Widget，通常会是一个App 图标图片。


• applicationLegalese：其他信息，通常会放置应用的版权信息。

点击按钮，就可以看到相应的授权信息了，点击一项就可以查看具体的 License。我看了一下使用的开源插件非常多，要是自己处理还真的很麻烦。

可以说非常简单，当然，如果你直接运行还有两个小问题。

按钮本地化

AboutDialog 默认提供了两个按钮，一个是查看授权信息，一个是关闭，可是两个按钮 的标题默认是英文的（分别是VIEW LICENSES和 CLOSE）。

如果要改成本地话的，还需要做一个自定义配置。我们扒一下 AboutDialog 的源码，会发现两个按钮在DefaultMaterialLocalizations中定义，分别是viewLicensesButtonLabel和closeButtonLabel。这个时候我们自定义一个类集成DefaultMaterialLocalizations就可以了。

class MyMaterialLocalizationsDelegate

    extends LocalizationsDelegate<MaterialLocalizations> {

  const MyMaterialLocalizationsDelegate();



  @override

  bool isSupported(Locale locale) => true;



  @override

  Future<MaterialLocalizations> load(Locale locale) async {

    final myTranslations = MyMaterialLocalizations(); // 自定义的本地化资源类

    return Future.value(myTranslations);

  }



  @override

  bool shouldReload(

          covariant LocalizationsDelegate<MaterialLocalizations> old) =>

      false;

}



class MyMaterialLocalizations extends DefaultMaterialLocalizations {

  @override

  String get viewLicensesButtonLabel => '查看版权信息';



  @override

  String get closeButtonLabel => '关闭';



}

然后在 MaterialApp 里指定本地化localizationsDelegates参数使用自定义的委托类对象就能完成AboutDialog两个按钮文字的替换。

return MaterialApp(

  debugShowCheckedModeBanner: false,

  title: 'Flutter Demo',

  theme: ThemeData(

    primarySwatch: Colors.blue,

  ),

  home: const AboutDialogDemo(),

  localizationsDelegates: const [MyMaterialLocalizationsDelegate()],

);

添加自定义的授权信息

虽然 Flutter 会自动收集第三方插件，但是如果我们自己使用了其他第三方的插件的话，比如没有在 pub.yaml 里引入，而是直接使用了源码。那么还是需要手动添加一些授权信息的，这个时候我们需要自己手动添加了。添加的方式也不麻烦，Flutter 提供了一个LicenseRegistry的工具类，可以调用其 addLicense 方法来帮我们添加授权信息。具体使用如下：

LicenseRegistry.addLicense(() async* {

  yield const LicenseEntryWithLineBreaks(

    ['关于岛上码农'],

    '我是岛上码农，微信公众号同名。\f如有问题可以加本人微信交流，微信号：island-coder。',

  );

});

这个方法可以在main方法里调用。其中第一个参数是一个数组，是因为可以允许多个开源代码共用一份授权信息。同时，如果一份开源插件有多个授权信息，可以多次添加，只要名称一致，Flutter就会自动合并，并且会显示该插件的授权信息条数，点击查看时，会将多条授权信息使用分割线分开，代码如下所示：

void main() {

  runApp(const MyApp());

  LicenseRegistry.addLicense(() async* {

    yield const LicenseEntryWithLineBreaks(

      ['关于岛上码农'],

      '我是岛上码农，微信公众号同名。如有问题可以加本人微信交流，微信号：island-coder。',

    );

  });



  LicenseRegistry.addLicense(() async* {

    yield const LicenseEntryWithLineBreaks(

      ['关于岛上码农'],

      '使用时请注明来自岛上码农、。',

    );

  });

}

总结

本篇介绍了在 Flutter 中快速展示授权信息的方法，通过 AboutDialog 就可以轻松搞定，各位“抄代码”的码农们，赶紧用起来向大牛们致敬吧！

我是岛上码农，微信公众号同名。如有问题可以加本人微信交流，微信号：island-coder。

👍🏻：觉得有收获请点个赞鼓励一下！

🌟：收藏文章，方便回看哦！

💬：评论交流，互相进步！

作者：岛上码农
来源：juejin.cn/post/7246328828837871677

引言

最近老大在cr我代码时，我就静静坐在他旁边看他装逼。他一顿断点+抓包+各种骚操作给我看楞了，我没忍住就让他手把手教我，他就和我在一个小屋子里xxxx了几个小时，他手法太快了俺看一遍就忘了，于是乎就靠回忆和资料查找整理了哈高频的js调试技巧，希望能帮助到各位。

一：console.dir

在打印dom节点时，普通的console.log是纯文本格式，而dir的打印是以对象的方式。因此在输出dom节点时，务必使用dir打印

<div id="main">

    <div class="box1">

      <p>p1</p>

    </div>

  </div>



  let oD = document.querySelector('.box1')

  console.log(oD)//普通的log输出

  console.dir(oD)//dir输出方式

二：二次发起请求

在调试接口时，通常我们会刷新页面然后观察network的接口信息，如果项目加载时间过长，刷新页面查看接口的效率是十分低的。

1. 对接口请求右键


2. 选择Relpy xhr发送请求

三：接口请求参数修改

借助浏览器控制台可以不用修改代码就可以发送不同参数的新请求了。具体操作如下

1. 对接口请求右键


2. 选择copy。


3. 再选择copy as fetch。


4. 在console区域粘贴上面的请求信息，然后修改请求体参数。


5. 然后切换到networkl查看最新请求的结果

效果展示

四：css查看伪类hover,active样式

在控制台右侧选择:hov可以选择对应dom各种伪类状态下的css样式，十分的便捷

五：css样式跳转到对应文件查看

选择css样式，按住alt点击就可以跳到对应文件查看具体代码

六：控制台输出选择的dom

首先在页面选择指定的位置dom,然后在在控制台使用$0就表示当前选中的dom了

七：展开全部dom

有时候我们在页面查找一个dom时，它嵌套层级特别深。这巨他妈蛋疼一层层展开，这个时候我们就需要找到一键全部展开来帮助我们解决这个问题了。

右键选择expand就可以展开选择的dom了。

八：断点调试

断点调试是本节最后一个内容了，它也是最核心的内容了，玩的6的是真的6，老大说我搞懂断点调试和对应的堆栈上下文就可以毕业了。（毕业=辞退？还是。。。）下面我列举的仅仅是入门级别的断点调试，只是说明如何上手操作，里面许多东西还望大家多多探索。

1. 打断点方式

代码中：debugger

在需要断点的地方写入debugger，此时程序运行后代码就会卡在这里，等待主人的安排

let a = 10

debugger

a++

浏览器中：

1. 选择sources


2. 在指定代码行左侧单击

2. 断点间调试

第一种断点调试是十分常用的方式，代码会从当前断点直接运行到下一个断点处执行，中间经过代码都默认被执行且跳过。如下图红色按钮就是断点间调试。

例子演示

我们在上图中打了3个断点，逐个点击，首先从断点15行直接跳到断点17行，最后跳到19行。由于异步最后执行，所以最后又跳到断点15行结束。断点经过的地方鼠标移动到变量上可以查看其内部数据。

3. 逐步调试

逐步调试很明显就是字面意思，从当前断点位置开始一行一行的运行代码，稍微注意的是，遇到函数不进入函数的内部，而是直接执行完函数。

例子演示

4. 进入与进出函数调试

逐步调试遇到函数是不进入函数内部的，因此需要借助进入和进出调试方式控制函数的访问

例子演示

5. 逐步调试详细版

上面讲述了第一种逐步调试方式，其遇到函数是不进入函数内部的，而是直接执行函数。因此下面这种方式是逐步调试的详细版，它也是从断点位置逐步的调试运行，遇到函数也会进入函数的内部进行逐步执行。

九：React/Vue中尝试

有吊毛说react和vue咋调试？嗯，那个吊毛其实就是我，其实也很简单滴。

1. 在需要调试的代码位置插入debugger


2. 在浏览器控制台需要查看变量的地方插入断点


3. 使用各种调试连招一顿操作就行。

代码例子

例如下面的例子，页面最后显示的num是多少？最后是101，不了解批量setState的开始肯定蒙，我们调试看看

import React,{useEffect, useState} from "react";

const Home = () => {

  const [num,setNum] = useState(1)

  useEffect(()=>{

    debugger

    setNum(100)

    setTimeout(() => {

      setNum(num+100)

    }, 0);

  },[])

  return (

    <div>num:{num}</div>

  )

}

export default Home;

调试演示
根据调试发现，进入定时器的时候num还未更新，还是1。

最近阅读了不少实现翻页效果的文章，受益匪浅，在此写个学习笔记。

一、元素拆解

从侧面来观察这个翻页过程，能看到承载文字内容的主要有三个面板：一个静止在上半部分的面板，显示旧文字的上半部分；一个静止在下半部分的面板，显示新文字的下半部分；第三个是旋转面板，一面显示旧文字的下半部分，另一面显示新文字的上半部分。翻转的动画，我们考虑采用FLIP的思想：

1. 先实现【动画结束帧】的样式；


2. 再从【动画开始帧】播放。

二、实现结束帧样式

准备工作：用vue脚手架创建一个模板项目，并添加一个div容器：

<!-- App.vue -->

<template>

  <div id="app">

    <test-comp/>

  </div>

</template>



<!-- Test.vue -->

<template>

  <div class="card"></div>

</template>



<style lang="less" scoped>

.card {

  position: relative;

  border: solid 4px black;

  width: 400px;

  height: 400px;

  perspective: 1000px;

}

</style>

2.1 实现静止的上半面板

<template>

  <div class="card">

    <div class="half-card top-half">发</div>

    <!-- <div class="half-card bottom-half">财</div> -->

  </div>

</template>



<style lang="less" scoped>

/* ... */

.half-card {

  position: absolute;

  width: 100%;

  height: 50%;

  overflow: hidden;

  background-color: #2c292c;

  color: white;

  font-size: 320px;

}

.top-half {

  line-height: 400px;

}

</style>

我们知道line-height配合font-size可以控制文字在垂直方向的位置，大多数情况下，文字顶部与容器顶部的距离公式为(line-height - font-size) / 2。

记容器高度h，文字大小f，容器只显示文字上半部分的情况下，上述距离的值为h - f / 2，即(line-height - f) / 2 = h - f / 2，所以line-height为2h（400px）。

2.2 实现静止的下半面板

<template>

  <div class="card">

    <!-- <div class="half-card top-half">发</div> -->

    <div class="half-card bottom-half">财</div>

  </div>

</template>



<style lang="less" scoped>

/* ... */

.bottom-half {

  top: 50%;

  line-height: 0;

}

</style>

在容器只显示文字下半部分的情况下，完整的文字顶部距离容器顶部的距离是-f / 2，那么就有(line-height - f) / 2 = - f / 2，即line-height = 0;

2.3 实现旋转面板

2.3.1 旋转面板的正面————新文字的上半部分

<template>

  <div class="card">

    <!-- <div class="half-card top-half">发</div> -->

    <!-- <div class="half-card bottom-half">财</div> -->

    <div class="rotating-half">

      <div class="half-card front-side">财</div>

      <!-- <div class="half-card back-side">发</div> -->

    </div>

  </div>

</template>



<style lang="less" scoped>

/* ... */

.rotating-half {

  position: absolute;

  width: 100%;

  height: 50%;

  .half-card {

    height: 100%;

  }

}

.front-side {

  line-height: 400px;

}

</style>

2.3.2 旋转面板的背面————旧文字的下半部分

怎么让一个div背对我们？只要让它绕着自己的腰部横线翻转180度即可（翻跟斗）。

<template>

  <div class="card">

    <!-- <div class="half-card top-half">发</div> -->

    <!-- <div class="half-card bottom-half">财</div> -->

    <div class="rotating-half">

      <!-- <div class="half-card front-side">财</div> -->

      <div class="half-card back-side">发</div>

    </div>

  </div>

</template>



<style lang="less" scoped>

/* ... */

.back-side {

  line-height: 0;

  transform: rotateX(180deg); // !!!!!!!!!!!

}

</style>

现在，如果把正面也加上，会发现这样一个问题：两个面的位置是重叠的，在模板中后声明的背面元素（即使它是背对着我们）会覆盖正面元素。我们想让这两个面在背对我们的状态下都不显示，这就需要到如下的css属性：backface-visibility: hidden。

此外，现在一个旋转面板中带有两个“面”，我们想要这两个面随着父元素面板的3d旋转一起旋转，也就是保持相对静止，这就需要设置旋转面板【将子元素纳入自己的3d变换空间】：transform-style: preserve-3d。

加上css后，让旋转面板简单地旋转一下，看看效果（效果图有点慢）：

<style lang="less" scoped>

/* ... */

.rotating-half {

  /* ... */

  transform-style: preserve-3d;

  .half-card {

    /* ... */

    backface-visibility: hidden;

  }

  /* to delete */

  transition: transform 1s;

  &:hover { transform: rotateX(-180deg); }

}

/* ... */

</style>

至此，三个面板静态效果已经完成：

三、播放动画

在第二节已经得到了动画结束时的状态。接下来需要从动画开始的状态进行播放。

3.1 设置好旋转轴

在目标动画中，旋转面板应该是绕着底边进行旋转的。把【变换原点】设置为底边的中点，这样，经过这个点的X轴就和底边所在的直线重合，绕X轴旋转就等价于绕底边旋转：

<style lang="less" scoped>

/* ... */

.rotating-half {

  /* ... */

  transform-origin: center bottom;

}

/* ... */

</style>

3.2 找到动画开始帧，使用animate播放动画

动画开始时，旋转面板在主面板的下半区域。要从上半区域（无变换状态）到达下半区域，需要绕着底边逆时针旋转180度，因此开始帧所处于的变换状态就是rotateX(-180deg)，从而得到动画的关键帧：

【transform: rotateX(-180deg)】->【transform: none】。

我们给旋转面板加上ref，然后在组件挂载完毕时播放即可：

<script>

export default{

  mounted() {

    this.$refs.rotate?.animate?.(

      [

        { offset: 0, transform: 'rotateX(-180deg)' },

        // { offset: 1, transform: 'none' },

      ],

      {

        duration: 1000,

        easing: 'ease-in-out',

      },

    );

  },

};

</script>

四、应用

这样的UI组件可能会用于记录时间、比赛分数变化啥的，自然是不能把值写死。考虑如下的应用场景：

<!-- App.vue -->

<template>

  <div id="app" class="flex-row">

    <test-comp :value="scoreLGD"/>

    <h1>VS</h1>

    <test-comp :value="scoreLiquid"/>

  </div>

</template>



<script>

import TestComp from './Test';

export default {

  components: { TestComp },

  data() { return {

      scoreLGD : 15,

      scoreLiquid: 13,

    };

  },

  mounted() {

    setInterval(() => {

      this.scoreLGD = this.randomInt(99);

      this.scoreLiquid = this.randomInt(99);

    }, 5000);

  },

  /* ... */

};

在该场景下，翻页组件需要在更新时而不是挂载时执行动画（因为没有上一个值）。因此我们在组件内部维护一个记录上一个值的状态，然后把动画从挂载阶段移动到更新阶段：

<template>

  <div class="card">

    <!-- 旧文字上 -->

    <div

      v-if="staleValue !== undefined"

      class="half-card top-half">

      {{ staleValue }}

    </div>

    <!-- 新文字下 -->

    <div class="half-card bottom-half">{{ value }}</div>

    <!-- 旋转面板 -->

    <div ref="rotate" class="rotating-half">

      <!-- 新文字上 -->

      <div class="half-card front-side">{{ value }}</div>

      <!-- 旧文字下 -->

      <div

        v-if="staleValue !== undefined"

        class="half-card back-side">

        {{ staleValue }}

      </div>

    </div>

  </div>

</template>



<script>

export default {

  props: ['value'],

  data() { return { staleValue: undefined }; },

  watch: {

    value(_, old) { this.staleValue = old; },

  },

  updated() {

    this.$refs.rotate?.animate?.(

      [{ offset: 0, transform: 'rotateX(-180deg)' }],

      { duration: 1000, easing: 'ease-in-out' },

    );

  },

};

</script>

基本完成：

总结一下

实现翻页效果 = 实现两块静态面板 + 实现一块双面旋转面板 + 播放旋转动画。


这里用vue写了demo, react应该也差不多，将updated换成layoutEffect等等。


另外，动画也可以用类名加css实现，当元素不在视口可以不播放，一些样式可以改成props配置。总之应该有不少地方还可以迭代优化下。

参考文章如下，分析思路基本一致，代码实现上有差异：

【1】优雅的时钟翻页效果，让你的网页时钟与众不同！

【2】原生JS实现

看到这个知乎问题时，我的思绪纷飞，往事一幕幕闪现在脑海里，等平静下来，内心变得很笃定。

于是，我做了如下的回答：

非常有必要。

1997年，乔布斯刚刚回归苹果不久，在开发者大会上，一名程序员当众质疑乔布斯不懂技术。

乔布斯，你是一个聪明又有影响力的人。但是很遗憾也很明显，很多时候你根本不知道自己在做什么。我希望你能用清楚的语言解释一下 Java 编程语言以及其变种是如何阐述 OpenDoc（开源技文档）内置的一些想法。等你说完以后，你能不能跟我们说一说你自己过去七年都干了些什么？

面对这样犀利的提问，乔布斯平静的喝了一口水，低头沉思了几秒，开口这样回答道：

有时候你能取悦一部分的人，但是当你想要作出改变的时候，最难的是某些事情别人做的是对的。我相信 OpenDoc 肯定有一些功能，没有任何其他东西能做到。我其实也不太懂，我相信你肯定能做一些样品出来，可能是一个小型的 app 来展示它的功能，最难的部分是如何将那些功能塞进更大的愿景里面，例如让你每年一个产品能够卖百八十亿美元。

我经常发现，你得从用户体验出发，倒推用什么技术，你不能从技术出发，然后去想如何才能卖出去。在座的没有人比我犯过更多这样的错误，我也搞到伤痕累累，我知道这就是原因，当我们尝试去为苹果思考战略和愿景，都是从能为用户带来什么巨大利益出发，我们可以给用户带来什么，而不是先找一群工程师，大家坐下来，看看我们有什么吊炸天的技术，然后怎么把它卖出去。

我非常认同乔布斯的话。

程序员有的时候沉迷在自己的世界里，执拗的以为“代码就是全部” 。

但现实并非如此，编码的目的是创造产品或者提供服务，从而在这个商业社会实现更大的价值。

而程序员成长为业务领域专家，能够更加深刻的理解公司的产品或者服务，从而更有优势为公司做出贡献。当个人的贡献上升时，公司的认同和利益也会随之而来。

这个回答一天内得到不少赞同，也是我意想不到的，因为我并不觉得我回答得好，看来很多同学都认可这个观点。

熟悉我的朋友都知道 ，我对技术非常有激情，曾经也认为技术意味着一切。

只是后来，工作中遇到越来越多的挫折，很多好朋友也友善的提醒我，不要太执着于技术，我也越来越认识到自己认知的局限性。

我不断的去读书、听演讲、思考，依稀之间得到一个结论："一个 IT 公司的成功 ，技术固然是重要的一环，而公司的产品、用户人群、经营模式是另一个我很少关注且非常重要的维度"。

偶然间我看了乔布斯的一个视频，视频的两句话让我醍醐灌顶。

• 
  

  我相信你肯定能做一些样品出来，可能是一个小型的 app 来展示它的功能，最难的部分是如何将那些功能塞进更大的愿景里面

  
  


• 
  

  你得从用户体验出发，倒推用什么技术，你不能从技术出发，然后去想如何才能卖出去

  
  

懂业务是一种认知模式，人的能力是多层次的，技术和懂业务并非互斥的关系。

亲爱的程序员朋友，技术是我们的立身之本，但是业务同样重要 , 真诚的希望你做一个既懂技术又懂业务的工程师。

如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我输出更高质

腾小云导读

PC Web 端、手机 H5 端、小程序端、App 安卓端、App iOS 端......在多端时代，一个应用往往需要支持多端。若每个端都独立开发一套系统来支持，将消耗巨大的人力和经费！腾讯视频团队想到一个“偷懒”的方法——能不能只开发一套基础系统，通过兼容不同平台的特性，来快速编译出不同平台的应用呢？本篇特邀腾讯视频团队为你分享快速编译出支持多端的应用、一套代码行走天下的“偷懒”历程。欢迎阅读。

目录

1 背景

2 设计思路

3 具体实现

4 总结

01、 背景

腾讯视频搜索在多个端都存在：安卓 App 端搜索、iOS App 端搜索、H5 端搜索、小程序端搜索、PC Web 端、PC 客户端搜索。每个端，除了个别模块的样式有细微差异之外，其他都一样，如下面的图片所示。

按照以前的现状，安卓 App 端搜索一套代码、iOS App 端搜索一套代码、手机 H5 端一套代码、小程序端搜索一套代码、PC 客户端一套代码、PC Web 端一套代码......每套代码都是独立开发，独立维护，成本非常高。并且，后端的搜索接口以前也是分散在多个不同的协议中，有的平台是 jce 协议的接口，有的是 PB 协议的接口，也是五花八门。

随着业务增长的需求，我们已经没有足够的时间来维护各自一套独立的系统，我们打算进行升级改革！治理的办法就是：收敛！把后端不同平台的接口都归一到同一个接口中，通过平台号来区分；前端也将不同平台的代码，收敛归一成一套代码，通过条件编译来兼容适配不同平台的差异性，不同的平台，在蓝盾流水线中配置不同的参数来上线，从而达到多合一的效果。

总体来说，我们团队就实现一个“多端合一的万能模板”的想法达成一致。并且，我们希望使用 hippy-vue 技术栈。

理由有以下：

02、设计思路

系统的架构图如下所示：

通用模版为了简化开发、提高开发效率，在模版中集成了大量现有组件和工具包，具体可以分为以下三层：

• 第三方工具层

在通用工具库中，模版包装并提供了很多常用方法，比如 cookie 的设置和 cookie 的获取方法；DOM 的操作方法；Cache 的设置，Cache 的获取，Cache 的过期时间等。在第三方接入库中，模版已经接好了 Aegis 监控，Tab 实验的实验值获取，大同上报等；在打包编译库中，模版提供了通用的 Hippy App 打包安卓脚本和 IOS 脚本、H5 的打包脚本、小程序地打包脚本、一套代码，运行不同的打包命令，执行不同的编译打包脚本，就可以生成不同平台对应的发布包。编译打包在后续还会详细讲解。

• 数据管理层

在这层中，模版集成了跟数据处理相关的模块。

在 Store 层，由于该模块是基于 Vue2 实现的（Vue3 会在下一个版本中提供），模版已经集成好了 Vuex、State、Getters、Mutations、Actions 等，并且都有实例代码（该模版是基于 Vue2 实现的，Vue3 会在下一个版本中提供）；

在 Model 层，模版提供了一套将 PB 文件转化为 TS 类文件的方法，方便快速接入后端PB协议接口请求；同时，还包装了接口通用请求方法，以及全局的统一错误处理上报方法；在数据配置中，模版提供了全局的常量配置文件，应用的版本配置文件（版本的配置对 Hippy App 的应用非常实用），以及 UI 样式的配置（正常模式样式还是暗黑模式样式，宽屏，窄屏等）。

• UI 层

为了提高开发速度，提高开发效率，模版提供了示例页面代码。同时，根据脚手架来选择是否需要路由，来动态添加应用的路由；以及常用的基础组件库。这些组件库中的组件，是从众多 Hippy 应用中提取出来，实用又高效。

03、具体实现

本文将从 Hippy App 端实现，Hippy H5 端的实现和 Hippy 微信小程序端端实现来分别展开介绍。

下图是 Hippy App 端实现逻辑。

App 端的入口文件为 main-native.ts。在里面，声明了一个 App 实例，指定 phone 下的一些属性设置，比如状态栏、背景色等等。同时，需要用到的 native 组件，都需要在 main-native 中进行声明绑定，才可以在页面中使用。

例如：下图示例中注册声明了两个 native 组件，LottieView 和 VideoView，在页面中就可以直接使用这两个 native 组件。

Vue.registerElement('LottieView');

Vue.registerElement('VideoView', {

  component: {

    name: 'VideoView',

    processEventData(event: any, nativeEventName: string, nativeEventParams: any) {

      // To do something for the native component event

      return event;

    },

  },});

main-native 中还有一个重要的方法：app.$start() 方法。

该方法为 Hippy 引擎初始化完成后回调到 Hippy 前端的方法；Hippy 端跟 App 方法进行通信，通过 jsbridge 来进行，模版中已经封装好了具体方法；Hippy 请求后端接口，通过 fetch 协议，也有具体的协议方法封装；Hippy 在 App 内部的跳转，是通过伪协议跳转来实现的。

Hippy App 应用的部署分为以下三种情况：

• 本地调试

本地调试是通过 Hippy + Chrome Devtools 来完成，通过 WS 通道转发消息，具体流程如下图。

• 部署测试环境

模版中引入了环境变量参数，同时在代码模版中做了大量环境变量的兼容逻辑，比如测试环境用测试环境的接口，正式环境用正式环境的接口；测试环境用测试环境的 CDN，静态文件上传到测试环境，测试环境部署测试环境的离线包等；测试环境的调试我们是通过离线包的方式来实现的，有专门的测试环境流水线接入使用，只需要稍微做少许调整即可，有需要的可以私聊。

• 部署正式环境

正式环境流程会做这样几件事情：正式环境接口、正式环境的 CDN、正式环境的日志上、部署正式环境的离线包平台、图片的特殊处理。因为 App 端是采用离线包的形式，如果所有本地图片都打包到离线包中，会导致离线包包体积很大，会影响到 App 的整体体积大小和离线包的下载速度。模版中做了针对图片的特殊脚本处理：引入了图片编译大小变量：STATIC_SIZE_LIMIT。当大于该限制条件的图片都一律上传到 CDN，如果想保留的，则需要增加特殊声明：inline。

具体流程如下图所示：

Hippy H5 的实现流程如下图所示。

Hippy H5 的实现跟 App 的实现流程类似，但是差异如下：

这里重点讨论一下大同上报的实现。大同上报在 App 端的上报参数声明跟 H5 端的上报参数声明不一致，如何统一这些差异？模版中的解决方案是：封装自定义标签 Directive。

具体实现如下：在 Directive 标签中兼容 App 和 H5 的不一致。

/**

* @example

*

* <element v-report="elementReportInfo" />

* <element v-report="{ eid, ...extra }" />

* <page v-report="{ pgid, ...extra }" />

* <page v-report.page="assertPageReport" />

*/



Vue.directive('report', {

  bind(el) {

    el.addEventListener('layout', throttledForceReport);

  },

  unbind(el) {

    el.removeEventListener('layout', throttledForceReport);

  },

  inserted: setReport,

  update: setReport,

} as DirectiveOptions);

很多人可能会问，Hippy App 跟 Hippy H5 有很多不同的地方，如果写两套代码，会不会导致代码的体积变得很大？答案是一定的，为了解决以上问题，该万能模版提供了条件编译。引入环境变量：isNative。然后，根据该条件，进行条件编译，不同的平台，生成不同平台的代码，避免了生成大量冗余代码。

Hippy 微信小程序的实现流程如下图所示：

小程序的实现是基于 Taro Vue 框架。该框架跟 Hippy Vue 框架天然兼容，但是也有一些小程序的特殊地方：

为了一套代码能够同时支持 App，H5 和微信小程序，需要遵循一些约定的规范，否则在从 Hippy Vue 转化为 Taro Vue 的时候会遇到一些问题：

04、总结

目前该模版已经在腾讯视频的搜索场景落地，并且上线应用，但是，还是有一些需要共同打磨的地方：

Vue3 的支持：目前我们是基于 Hippy Vue2 来实现的。随着 Vue3 的广泛应用，后续我们需要升级到 Vue3。

组件丰富：通用组件的种类还不是特别丰富，只是基于我们腾讯视频搜索场景进行的封装，后续可以补充更多更丰富的组件。

迭代升级：通用组件目前还是通过源代码的方式存放在代码模版中，不利于后续组件的升级迭代。计划后续会把组件给迁移到我们的应用组件库平台 Athena，该平台我们会后续发专文介绍，大家敬请期待。

以上是本次分享全部内容，如果觉得文章还不错的话欢迎分享~

-End-

原创作者｜熊才刚

技术责编｜陈恕胜

你有什么开发提效小技巧？欢迎在腾讯云开发者公众号评论区中分享你的经验和看法。我们将选取1则最有意义的分享，送出腾讯云开发者-文化衫1件（见下图）。6月21日中午12点开奖。

就业之前

​ 应该大三、大二或者大四的你都会有这么一个焦虑：该怎么去选择，考公务员、考研、还是就业？

​ 我也曾经是这其中的一员，从大三上就开始陷入焦虑。

​ 首先是排除了考公务员，因为家里的姐姐就是毕业2年仍然在考公，算是陷入其中，我自己也觉得应该不会好到哪儿去。

​ 然后是考研，这是个纠结了很久的问题，甚至在2023年过年的时候，我仍然有想去考研的想法，但是多数是受到了旁边的人干扰。（当然能考到一个好的学校还是很好的），但是我自认是学渣，所以，最最多也就一个双非二本研究生，期间还得附上3-4年的时间，可能是读书太久了，所以最后选择了直接就业。

​ 高考完选了大数据专业，当初选择大数据以为是新兴专业，而且在贵州，快毕业了才发现，所谓的大数据只有大公司才有，小公司基本就前端+后端这样的模式，甚至都是全干工程师。我是从2022年前开始学习的前端，6月暑假找的实习。其实我很佩服自己那半年的时间，从js到vue和小程序，期间在小破站上学习的视频还是蛮多的。

第一段实习 — 贵阳

早9晚5.30，双休，2.5k

​ 2022年后，当时觉得自己身上有用不完的干劲，觉得毕业后非大厂莫属。当时学校一门课程就是做小程序+后台+后端，我和室友们做了一个关于项目管理的项目，期间也大概学会了git、接口对接、项目配合这些东西，后面项目也获得了学院的作品展示。现在看起来做的什么玩意儿啊，哈哈哈。在2月到4月那段时间就是学习+做项目，期间的收获很大。

​ 到了五月开始投简历，也是我最焦虑的一段时间，因为带来的反差真的很大，背了很多八股文，信心满满的却得不到一点回复。有几次线上面试也都凉了，其中有一次鹅厂的实习，被按在地上摩擦。运气比较好的是得到了一家线下的面试（我和室友都进了），后面在20多个人中也是我俩拿下了前端实习的2个名额，2.5k。然后开始了合租之旅...

​ 很清楚的记得租房的时候，被中介差点骗了300块，但是最后遇到一个很好的房东。去的第一天，根本睡不着，那个月也是疯狂爆痘。在公司的3个月其实学到了好些东西，因为之前没机会去接触这么大的项目，对于git和项目配合的理解更深了。而且在空余时间也有机会学习新的知识（ts、react等），合租的时候我的室友做饭我就洗碗（他做的饭真的好吃，就是口味重了点）就这样到10月，迎来了第一波疫情，很清楚的记得是在中秋节之前开始的，疫情的时候，每天想的是怎么买到菜，到快结束的时候，3个菜都是发的白萝卜，太残忍了。坚持到10月底疫情结束，由于疫情和公司接的政府的外包，贵阳的财政情况（懂的都懂，拖欠工资），所以我开始投简历，准备下一家，最后去了一家重庆的音乐公司（因为当时女朋友也是在重庆工作）。

第二段 — 重庆

995，3k

​ 11月初，说走就走，当时前一天得到offer，后两天我就去了重庆，实习3.5k。刚到公司，就2个人！！一个淘宝运营，一个财务，还有一个老板和总监出差去了。如果不是用的vue3+ts，估计我当时就会走。就这样就开始做起了（还有一个实习的后端）。好处是有一个技术顾问，给了整体的框架技术的搭建建议。最后选择用vue3+ts+quasar搭建的后台管理系统。运气不好的是，又一波疫情来了，在家里居家办公了近1个月。那是最阴暗的一个月了，每天在房间里都是一个人，没有人可以说话，心情好的时候写一写代码，不好的就打游戏。当时一个人也想了很多，也有了想去考研的想法。所以在疫情结束的时候，1月初，离职了，准备回家过年。

现在 - 贵阳

6.5k+300补贴+住宿
大小周,早8.30晚5.30

在这2023年过年2个月的时间里，自己想通了很多，其实自己没有那么特别，就接受了自己的平凡，当时抱着试试的态度也投了一些沿海的城市。最后得到了贵阳目前这家公司的面试。很搞笑的记得当时顺道去重庆，拖着行李箱去面试的。最后得到offer:6.5k+300补贴+住宿。

面试的时候挺简单的，没什么太难的点。入职后做的原生小程序开发，业务倒是挺麻烦，对于组件的封装和代码规范是我目前觉得最值得学习的，对于原生好处就是，可以了解更多底层一点的东西，不用组件。坏处就是：开发速度会有所降低，样式也可能没有组件的好看。

感受：工作氛围挺好，非外包的项目，也挺清闲，大概有1/2 +的时间没事做，挺适合养老。
还有就是：遇到不会的别一个人死磕，多问问。

坏处：自控不好的话容易摆烂，周末空闲时间比较少

关于感情

我们是从高中一直到现在，因为异地+她忘不了从前喜欢的，在入职后几天，我提的分手。

说实话挺难受的，但是也没有必要在继续了。但是在这段情感中也学到了很多，成长了很多，懂得了自爱。

分手之后，感觉回归到了自由，也舍得给自己花钱了（从前我是很拮据的那种）。

3月，买了人生中第一台相机:尼康D750,后来也用它拍了很多照片。其实也可以用手机拍，但是觉得相机的意义就是可以多出去走走，还有女生好像对这个很感兴趣（哈哈哈），学会很加分。

5月，认识新的朋友，去了大理、丽江。虽然像是去踩坑的，但是，也学到了一点人像拍照的技巧。感谢同行小姐姐宽宏大量（我拍的贼丑）还鼓励我。

顺便给你们避避坑：

1.景区租服饰拍照的：其实不怎么专业,精修的图还没她们自己批的好看。

2.旅游之前做好攻略！！！（我就是当天决定当天走的）

3.丽江的 茶马古道 x ,日照金山√，玉龙雪山需要预约

4.大理的洱海√，基本上玩的都是环洱海

附上几组图片：

最后

马上毕业了，很庆幸自己能找到这份工作。随着工作的清闲，感觉自己变得闲鱼了，还是得支棱起

前言

在某书上的写了好几年的文章，发现某书越来越烂了，全是广告，各种擦边标题党文章和小说等，已经不适合技术人员了。

想把某书上的文章全部下载下来整理一下，某书上是有一个下载所有文章功能的，用了以后发现下载功能现在有问题，无法下载个人账号里所有文章，不知道是不是下载功能根据日期什么判断了，还是bug了，试了好几次都这样，官方渠道只能放弃了。

手动一篇一篇粘贴的成本太高了，不仅有发布的文章，还有各种没有发布的笔记在里面，各种文章笔记加起来好几百篇呢，既然是工程师，就用工程师思维解决实际问题，能用脚本下载个人账号的下的所有文章吗？

思路梳理

由于是下载个人账号下的所有文章，包含发布的和未发布的，来看下个人账号的文章管理后台

根据操作以及分析浏览器控制台 网络 请求得知，文章管理后台逻辑是这样的，默认查询所有文集(文章分类列表)， 默认选中第一个文集，查询第一个文集下的所有文章，默认展示第一篇文章的内容，点击文集，获取当前文集下的所有文章，默认展示文集中的第一篇文章，点击文章获取当前文章数据，来分析一下相关的接口请求

获取所有文集

https://www.jianshu.com/author/notebooks 这个 Get 请求是获取所有 文集，用户信息是放在 cookie 里

来看下返回结果

[

    {

        "id": 51802858,

        "name": "思考，工具，痛点",

        "seq": -4

    },

    {

        "id": 51783763,

        "name": "安全",

        "seq": -3

    },

    {

        "id": 51634011,

        "name": "数据结构",

        "seq": -2

    },

    ...

]

接口返回内容很简单，一个 json 数据，分别是：id、文集名称、排序字段。

获取文集中的所有文章

https://www.jianshu.com/author/notebooks/51802858/notes 这个 Get 请求是根据 文集id 获取所有文章，51802858 为 "思考，工具，痛点" 文集的id, 返回数据如下

[

    {

        "id": 103888430, // 文章id

        "slug": "984db49de2c0",

        "shared": false,

        "notebook_id": 51802858, // 文集id

        "seq_in_nb": -4,

        "note_type": 2,

        "autosave_control": 0,

        "title": "2022-07-18", // 文章名称

        "content_updated_at": 1658111410,

        "last_compiled_at": 0,

        "paid": false,

        "in_book": false,

        "is_top": false,

        "reprintable": true,

        "schedule_publish_at": null

    },

    {

        "id": 98082442,

        "slug": "6595bc249952",

        "shared": false,

        "notebook_id": 51802858,

        "seq_in_nb": -3,

        "note_type": 2,

        "autosave_control": 3,

        "title": "架构图",

        "content_updated_at": 1644215292,

        "last_compiled_at": 0,

        "paid": false,

        "in_book": false,

        "is_top": false,

        "reprintable": true,

        "schedule_publish_at": null

    },

    ...

]

接口返回的 json 数据里包含 文章id 和 文集名称，这是接下来需要的字段，其他字段暂时忽略。

获取文章内容

https://www.jianshu.com/author/notes/98082442/content 这个 Get 请求是根据 文章id 获取文章 Markdown 格式内容, 98082442 为 《架构图》 文章的id, 接口返回为 Markdown 格式的字符串

{"content":"![微服务架构图 (3).jpg](https://upload-images.jianshu.io/upload_images/6264414-fa0a7893516725ff.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)\n"}

现在，我们了解清楚了文集，文章，以及文档内容的获取方式，接下来开始脚本实现。

代码实现

由于我是前端攻城狮，优先考虑使用 js 来实现下载，还有一个考虑因素是，接口请求里面的用户信息是通过读取 cookie 来实现的，js 脚本在浏览器的控制台执行发起请求时，会自动读取 cookie，很方便。

如果要下载个人账号下所有文章的话，根据梳理出来的思路编写代码就行

获取所有文集id

fetch("https://www.jianshu.com/author/notebooks")

  .then((res) => res.json())

  .then((data) => {

    // 输出所有文集

    console.log(data);

  })

使用fetch函数进行请求，得到返回结果，上面的代码直接在浏览器控制台执行即可，控制台输出效果如下

根据文集数据获取所有文章

上一步得到了所有文集，使用 forEach 循环所有文集，再根据 文集id 获取对应文集下的所有文章，依然使用 fetch 进行请求

...

let wenjiArr = [];

wenjiArr = data; // 文集json数据

let articleLength = 0;

wenjiArr.forEach((item, index) => {

  // 根据文集获取文章

  fetch(`https://www.jianshu.com/author/notebooks/${item.id}/notes`)

    .then((res2) => res2.json())

    .then((data2) => {

      console.log("输出文集下的所有文章：", data2);

    });

});

根据文章id获取文章内容，并下载 Markdown 文件

有了文章 id, 根据 id 获取内容，得到的内容是一个对象，对象中的 content 属性是文章的 Markdown 字符串，使用 Blob 对象和 a 标签，通过 click() 事件实现下载。

在这里的代码中使用 articleLength 变量记录了一下文章数量，使用循环中的文集名称和文章名称拼成 Markdown 文件名 item.name - 《item2.title》.md

...

console.log(item.name + " 文集中的文章数量: " + data2.length);

articleLength = articleLength + data2.length;

console.log("articleLength: ", articleLength);

data2.forEach(async (item2, i) => {

  // 根据文章id获取Markdown内容

  fetch(`https://www.jianshu.com/author/notes/${item2.id}/content`)

    .then((res3) => res3.json())

    .then((data3) => {

      console.log(data3);

      const blob = new Blob([data.content], {

        type: "text/markdown",

      });

      const link = document.createElement("a");

      link.href = window.URL.createObjectURL(blob);

      link.download = item.name + " - 《" + item2.title + `》.md`;

      link.click();

    });

});

代码基本完成，运行

在浏览器控制台中运行写好的代码，浏览器下方的下载提示嗖嗖的显示，由于没有做任何处理，当前脚本执行过程中报错了，文章下载了几十个以后就停止了，提示 429

HTTP 请求码 429 表示客户端发送了太多的请求，服务器无法处理。这种错误通常表示服务器被攻击或过载。

文章内容太多了，意料之中的情况，需要改进代码

思路改进分析

根据问题分析，脚本里的代码是循环套循环发请求的，这部分改造一下试试效果。

把每个循环里面发送 fetch 请求的外面是加个 setTimeout, 第一个循环里面的 setTimeout 延迟参数设置为 1000 * index ， index 为当前循环的索引，第一个请求0秒后执行，后面每一次都加1秒后执行，由于文集的数量不多，大约20个，这一步这样实现是没问题的。

重点是第二个循环，根据文集获取所有文章，每个文集里多的文章超过50篇，少的可能2，3篇，这里面的 setTimeout 延迟参数这样设置 2000 * (i + index)， i 为第二个循环的索引，这样保证在后面的请求中避免了某个时间段发送大量请求，导致丢包的问题。

再次执行代码，对比控制台输出的文章数量和下载目录中的文章(项目)数量，如果一致，说明文章都下载好了

改造后的完整代码地址

github.com/gywgithub/F…

思考

整体来看，文章下载脚本的逻辑并不复杂，接口参数也简单明确，两个 forEach 循环，三个 fetch 请求，把获取到的文章内容实用 a 标签下载下来就行了。关于大量请求发送导致 429 或者请求丢失的问题，脚本中使用了一种方案，当时还想到了另外两种方案：

请求同步执行

通过同步的方式先得到所有文集下的所有文章，再根据文章列表数组同步发请求下载，请求一个个发，文章一篇篇下载

Promise.all

使用 Promise.all() 分批发送请求，避免一次请求发送太多

也可能还有其他的解决方案，欢迎大家评论区讨论交流，一起学习共同进步 ^-^

作者：草帽lufei
来源：juejin.cn/post/7245184987531018300

最近帮公司招聘，主要负责一面，所以基本上问的基础多一点。但是我在问这样一道面试题的时候，很少有人答对。不少人觉得我问这道题多少有点过分了😭，当然了面试还是奔着相互沟通相互学习的目的，并不是说这道题不会就被刷掉，单纯的觉得这道题有意思。话不多说，我们直接上题

题目

var foo = function () {

    console.log("foo1")

}

foo()



var foo = function () {

    console.log("foo2")

}

foo()





function foo() {

    console.log("foo1")

}

foo()



function foo() {

    console.log("foo2")

}

foo()

这里我会要求面试者从上到下依次说出执行结果。普遍多的面试者给出的答案是：foo1、foo2、foo1、foo2。虽然在我看来这是一道简单的面试题，但是也不至于这么简单吧😱~~~

当然面试本来就是一个相互讨论的过程，那就和面试者沟通下这道题我的理解，万一我理解错了呢😂

解答

拆分函数表达式

首先我会让面试者先看前面两个函数

var foo = function () {

    console.log("foo1")

}

foo()



var foo = function () {

    console.log("foo2")

}

foo()

这时候大部分人基本上都可以答对了，是：foo1、foo2。再有很少数的人答不对那就只能”施主，出门右转“😌。接着根据我当时的心情可能会稍作追问（美女除外🙂）：

foo()

var foo = function () {

    console.log("foo1")

}

这时候又有一部分的人答不上来了。这毫无疑问是肯定会报错的啊

我们都知道用var定义的变量会变量提升，所以声明会被拿到函数或全局作用域的顶部，并且输出undefined。所以当执行foo()的时候，foo还是undefined，所以会报错。由于js从按照顺序从上往下执行，所以当执行foo = function(){}的时候，才对foo进行赋值为一个函数。我们重新看拆分之后的代码

var foo = function () {

    console.log("foo1")

}

foo()



var foo = function () {

    console.log("foo2")

}

foo()

foo首先会变量提升，然后进行赋值为function。所以当执行第一个foo的时候，此时foo就是我们赋值的这个函数。接着执行第二个foo的赋值操作，由于函数作用域的特性，后面定义的函数将覆盖前面定义的函数。
由于在调用函数之前就进行了函数的重新定义，所以在调用函数时，实际执行的是最后定义的那个函数。所以上面的代码会打印：foo1、foo2。

这种定义函数的方式，我们称为函数表达式。函数表达式是将函数作为一个值赋给一个变量或属性

函数表达式我们拆分完了，下面就看看函数声明吧。

拆分函数声明

function foo() {

    console.log("foo1")

}

foo()



function foo() {

    console.log("foo2")

}

foo()

大部分人其实都卡在了这里。函数声明会在任何代码执行之前先被读取并添加到执行上下文，也就是函数声明提升。说到这里其实大多数人就已经明白了。这里使用了函数声明定义了两个foo函数，由于函数声明提升，第二个foo会覆盖第一个foo,所以当调用第一个foo的时候，其实已经被第二个foo覆盖了，所以这两个打印的都是foo2。

当两段代码结合

当开始解析的时候，函数声明就已经提升了，第四个foo会覆盖第三个foo。然后js开始从上往下执行，第一个赋值操作之后执行foo()后，打印了”foo1“,第二个赋值之后执行foo()，打印了"foo2"。下面两个foo的执行其实是第二个赋值了的foo,因为函数声明开始从刚开始就被提升了，而下面的赋值会覆盖foo。

总结

我们整体分析代码的执行过程

1. 通过函数表达式定义变量foo并赋值为一个匿名函数，该函数在被调用时打印"foo1"。


2. 接着，通过函数表达式重新定义变量foo，赋值为另一个匿名函数，该函数在被调用时打印"foo2"。


3. 使用函数声明定义了两个名为foo的函数。函数声明会在作用域中进行提升。后面的会覆盖前面的，由于声明从一开始就提升了，而又执行了两个赋值操作，所以此时foo是第二个赋值的函数。


4. 然后调用foo()，输出"foo2"。


5. 再调用foo()，也输出"foo2"。

其实就一个点： 函数表达式相对于函数声明的一个重要区别是函数声明在代码解析阶段就会被提升（函数声明提升），而函数表达式则需要在赋值语句执行到达时才会创建函数对象

小伙伴们，以上是我的理解，欢迎在评论区留言，大家相互讨论相互学习。

之前的描述确实有点不妥，所以做了改动，望大家谅解，还

Vue 是一款流行的前端框架，支持过渡动画的实现是其中的一项重要特性。在 Vue 中，使用过渡动画可以为用户提供更加友好的用户体验。下面我将为大家介绍一下子如何在 Vue 中实现过渡动画。

1. 你知道什么是过渡动画吗

过渡动画是指在 DOM 元素从一个状态到另一个状态发生变化时，通过添加过渡效果使得这个变化看起来更加平滑自然的动画效果。在 Vue 中，过渡动画可以应用到以下几个场景中：

• 显示和隐藏元素


• 动态添加或删除元素


• 元素位置的变化

2. Vue 过渡动画的实现方法

2.1 CSS 过渡

Vue 提供了 transition 组件来支持过渡动画。我们可以在需要应用过渡动画的元素外层包裹一个 transition 组件，并通过设置 CSS 样式或绑定动态 class 来实现过渡动画的效果。

Vue 的过渡动画通过添加 CSS 类名来实现。我们可以通过为需要过渡的元素添加 v-if 或 v-show 指令来控制元素的显示和隐藏，然后使用 transition 组件进行动画效果的设置。

下面我写个示例给大家参考一下，我将给按钮添加过渡动画效果：

<template>

  <button @click="show=!show">Toggle</button>

  <transition name="fade">

    <div v-if="show">Hello, World!</div>

  </transition>

</template>

<script>

export default {

  data() {

    return {

      show: false

    };

  }

};

</script>

<style>

.fade-enter-active,

.fade-leave-active {

  transition: opacity .5s;

}

.fade-enter,

.fade-leave-to {

  opacity: 0;

}

</style>

在上面的代码思路中，我们在 transition 包裹的 div 元素上使用了 v-if 指令来控制元素的显示和隐藏。同时，我们给 transition 组件添加了一个 name 属性，并使用 CSS 样式来定义过渡动画的效果。其中，.fade-enter-active 和 .fade-leave-active 分别表示进入和离开时的过渡动画，而 .fade-enter 和 .fade-leave-to 则分别表示进入和离开时元素的样式。

2.2 JS 过渡

除了使用 CSS 过渡外，在 Vue 中也可以使用 JavaScript 过渡来实现动画效果。JS 过渡相比于 CSS 过渡的优势在于它可以更加灵活地控制过渡动画。

它与 CSS 过渡不同，Javascript 过渡可以更加灵活地控制过渡动画，可以实现更加丰富的效果。Vue 提供了事件钩子函数，使得我们可以自定义过渡动画的效果。

Vue 中提供了以下事件钩子函数：

• before-enter


• enter


• after-enter


• enter-cancelled


• before-leave


• leave


• after-leave


• leave-cancelled

我们可以使用 transition 组件的 mode 属性来设置过渡的模式，如果使用了 mode 属性，Vue 将会自动调用对应的钩子函数，我们可以通过这些钩子函数来自定义过渡效果。

下面是我写的一个基于 JS 过渡的演示Demo，我们将为按钮添加自定义的过渡动画：

<template>

  <button @click="show=!show">Toggle</button>

  <transition :css="false" @before-enter="beforeEnter" @enter="enter" @leave="leave">

    <div v-if="show">Hello, World!</div>

  </transition>

</template>

<script>

export default {

  data() {

    return {

      show: false

    };

  },

  methods: {

    beforeEnter(el) {

      el.style.opacity = 0;

      el.style.transformOrigin = 'left';

    },

    enter(el, done) {

      anime({

        targets: el,

        opacity: 1,

        translateX: [20, 0],

        easing: 'easeInOutQuad',

        duration: 500,

        complete: done

      });

    },

    leave(el, done) {

      anime({

        targets: el,

        opacity: 0,

        translateX: [-20, 0],

        easing: 'easeInOutQuad',

        duration: 500,

        complete: done

      });

    }

  }

};

</script>

在上面的前端页面中，我们通过设置 transition 组件的 css 属性为 false 来禁用 CSS 过渡，然后我们使用了 before-enter、enter 和 leave 等钩子函数来自定义过渡动画。在这个示例代码中，我们使用了第三方动画库 Anime.js 来实现元素进入和离开时的动画效果，同时在 anime 动画完成后，我们还需要手动调用 done 函数来告知 Vue 过渡动画已经完成。

3. 小结一下

通过我写的这篇文章的介绍，可以让大家多了解了 Vue 过渡动画的基本概念，并且掌握了如何在 Vue 中实现过渡动画。不论是使用 CSS 过渡还是 JavaScript 过渡，都可以帮助我们为用户提供更加友好的用户体验。我希望本文对您有所帮助，如果您有任何疑问或建议，欢迎在评论区留言。

for循环的可控性比forEach好，但是它的代价却鲜为人知，这篇文章就是简单的探讨下这背后的代价。 先定一个基调，我们从作用域的角度去分析,也会按需讲一些作用域的知识。

作用域是什么？

要解释这个问题，先从程序的角度来看，几乎所有编程语言上来就会介绍自己的变量类型，因为如果没有变量程序只能执行一些简单的任务。但是引入变量之后程序怎么才能准确的找到自己需要的变量。这就需要建立一套规则让程序能够准确的找到需要的变量，这样的规则被称为作用域。

块级作用域

块级作用域如同全局作用域和函数作用域一样，只不过块级作用域由花括号（{}）包裹的代码块创建的。在块级作用域内声明的变量只能在该作用域内访问，可以使用 let 或 const 关键字声明变量，可以在块级作用域内创建变量。
所以引擎在编译时是通过花括号（{}）包裹和声明关键字判断是否创建块级作用域，因此绝大多数的语句是没有作用域的，同时从语言设计的角度来说越少作用域的执行环境调度效率也就越高，执行时的性能也就越好。
基于这个原则，switch语句被设计为有且仅有一个作用域，无论它有多少个case语句，其实都是运行在一个块级作用域环境中的。
一些简单的、显而易见的块级作用域包括：

// 例1

try {

  // 作用域1

}

catch (e) { // 表达式e位于作用域2

  // 作用域2

}

finally {

  // 作用域3

}



// 例2

//（注：没有使用大括号）

with (x) /* 作用域1 */; // <- 这里存在一个块级作用域



// 例3, 块语句

{

  // 作用域1

除此之外，按上述理解，for语句也可以满足上述的条件。

for循环作用域

并不是所有的for循环都有自己的作用域，有且仅有

for ( <let/const> ...) ...

这个语法有自己的块级作用域。当然，这也包括相同设计的for await和for .. of/in ..。例如：

for await ( <let/const> x of ...) ...

for ( <let/const> x ... in ...)

for ( <let/const>  x ... of ...) ...

已经注意到了，这里并没有按照惯例那样列出“var”关键字。简单理解就是不满足创建的条件。Js引擎在编译时，会对标识符进行登记，而为了兼容，将标识符分为了两类varNames 和 lexicalNames。以前 var 声明、函数声明将会登记在varNames，为了兼容varNames只有全局作用域和函数作用域两种，所以编译时会就近登记在全局作用域和函数作用域中且变量有“提升”效果。Es6新增的声明关键词将登记在lexicalNames，编译时会就近创建块级作用或就近登记在函数作用域中。

varNames 和 lexicalNames属性只是一个用于记录标识符的列表，是通过词法作用域分析，在当前作用域中做登记的。它们记录了当前作用域中的变量和函数的名称，以及它们的作用域信息，帮助 JavaScript 引擎在代码执行时正确地解析标识符的作用域。

关于作用域还有一点要说明，JavaScript采用词法作用域，这意味着变量的作用域在代码编写时就确定了，而不是在运行时确定。这与动态作用域不同，动态作用域是根据函数的调用栈来确定变量的作用域。
举个例子：

function foo() {

  console.log( a ); // 2

}

function bar() {

  var a = 3;

  foo();

}

var a = 2;

bar();

词法作用域下log的结果是2，动态作用域下log的是3。

词法作用域是指 JavaScript 引擎在编译时如何确定变量的作用域。在 JavaScript 中，词法作用域是指变量的作用域是由代码的位置（词法）决定的，而不是由运行时的作用域链决定的。

变量的作用域和可见性是由词法作用域和作用域链来决定的，作用域链是基于词法作用域和函数作用域来确定的，这也证明了 JavaScript 采用的是词法作用域。

for循环隐藏作用域

首先，必须要拥有至少一个块级作用域。如之前讲到的，满足引擎创建的条件。但是这一个作用域貌似无法解释下面这段代码

for(let i=0;i<10;i++){

  let i=1;

  console.log(i) // 1

}

这段代码时可以正常运行的，而我们知道let语句的变量不能重复声明的,所以对for循环来说一个作用域是满足了这个场景的。
但是这段代码依然可以执行，那JS引擎是如何处理的呢？
只能说明循环体又创建了一个块级作用域，事实如你所见，JS引擎确实对for循环的每个循环体都创建了一个块级作用域。
举个栗子，以下代码中使用 let 声明变量 i：

for (let i = 0; i < 5; i++) {

  console.log(i);

}

在编译时，JavaScript 引擎会将循环体包裹在一个块级作用域中，类似于以下代码：

{

  let i;

  for (i = 0; i < 5; i++) {

    console.log(i);

  }

}

每次循环都会创建一个新的块级作用域，因此，在循环中声明的变量 i 只能在当前块级作用域中访问，不会污染外部作用域的变量。而通过作用域链每个循环体内都可以访问外层变量i。
而我们知道从语言设计的角度来说越少作用域的执行环境调度效率也就越高，执行时的性能也就越好，所以这也算是代价之一吧。
就算如此设计还是无法解释下面这段代码。

for (let i = 0; i < 5; i++) {

 setTimeout(()=>{console.log(i)})

}

如果按上述的理解，那最后log时访问的都是外层的变量i,最后的结果应该都是4,可事实却并非如此。当定时器被触发时，函数会通过它的闭包来回溯，并试图再次找到那个标识符i。然而，当定时器触发时，整个for迭代都已经结束了。这种情况下，访问i,获取到的也是上层作用域中的i,此刻i的值应该是最后一次赋。
之所能按我们预想的输出1，2，3，4，那是因为JavaScript 引擎在创建循环体作用域的时候，会在该作用域中声明一个新的变量 i，并将其初始化为当前的迭代次数,这个新的变量 i 会覆盖外层的变量 i。这个过程是由 JavaScript 引擎自动完成的，我们并不需要手动

据说，西西弗斯是一个非常聪明的国王，但他也非常自负和狂妄。他甚至敢欺骗神灵，并把死者带回人间。为此，他被宙斯（Zeus）惩罚，被迫每天推着一块巨石上山，但在接近山顶时，巨石总是会滚落下来，他不得不重新开始推石头，永远困在这个循环中…

很多开发工作也如此单调而乏味，比如今天要讲的中后台开发的场景。中后台业务基本上就是一些数据的增删改查、图表，技术含量不高，比较容易范式化。

前端如何破除这种 CRUD 的单调循环呢？

低代码

过去几年前端的低代码很火，这些低代码平台通常支持创建数据模型后，一键生成对应的增删改查页面：

💡 本文提及的低代码是狭义的低代码，你可以认为就是可视化搭建平台。

低代码在过去几年就是 「雷声大，雨点小」，跟现在的 AI 颇为相似。

不管是大厂还是小厂都在搞低代码，包括笔者也参与过几个低代码项目，但是小厂支撑不起来这样的资源投入，最后都胎死腹中。我相信很多读者也经历过这种情况。
大部分公司只是尾随市场营销噱头，盲目跟风，压根就没有做这种低代码平台资源准备和沉淀。

作为前端，能参与到低代码项目的开发是一件非常兴奋的事情，毕竟是少数前端能主导的项目，架构、组件设计、编辑器的实现可玩性很高，可以跟同行吹很久。

作为用户(开发者)呢？可能会排斥和质疑，不管怎么说，它并没有发挥市场所期望的价值。

最主要的原因是：它解决不了复杂的问题。

低代码直观、门槛低， 前期开发确实很爽，可视化数据建模、拖拉拽生成页面、流程编排，很快就可以把一些简单的业务开发出来。

然而软件编码本身占用研发流程的比例，据 ChatGPT 估算大约只有 20% ~ 30%。而且业务持续变化，代码也需要持续迭代。试想一下如何在这些低代码平台上进行重构和检索？

总的来说，有一些缺点：

• 
  

  复杂的业务逻辑用低代码可能会更加复杂。低代码应该是特定领域问题的简化和抽象，如果只是单纯将原有的编码工作转换为 GUI 的模式，并没有多大意义。

  
  

  例如流程编排，若要用它从零搭建一个复杂的流程，如果照搬技术语言去表达它，那有可能是个地狱：

  
  

  

  
  

  理想的流程编排的节点应该是抽象程度更高的、内聚的业务节点，来表达业务流程的流转。然而这些节点的设计和开发其实是一件非常有挑战性的事情。

  
  


• 
  

  软件工程是持续演进的，在可维护性方面，目前市面上的低代码平台并不能提供可靠的辅助和验证。因此企业很难将核心的稳态业务交给这些平台。

  
  


• 
  

  还有很多… 平台锁定，缺乏标准，性能问题、复用、扩展性、安全问题、黑盒，可迁移性，研发成本高，可预测性/可调试性差，高可用，版本管理，不能自动化…

  
  

当然，低代码有低代码的适用场景，比如解决特定领域问题(营销活动页面，海报，数据大屏，表单引擎、商城装修、主页)，POC 验证。即一些临时的/非核心的敏态业务。

💡 目前有些低代码平台也有「出码能力」，让二开有了一定的可行性。

💡 AI 增强后的低代码可能会更加强大。但笔者依旧保持观望的态度，毕竟准确地描述软件需求，本身就是就是软件研发的难题之一，不然我们也不需要 DDD中的各种方法论，开各种拉通会，或许也不需要需求分析师，产品…


非专业用户直接描述需求来产出软件，大多是不切实际的臆想

中间形态

有没有介于可视化低代码平台和专业代码之间的中间形态？既能保持像低代码平台易用性，同时维持代码的灵活性和可维护性。

我想那就是 DSL(domain-specific language) 吧? DSL 背后体现的是对特定领域问题的抽象，其形式和语法倒是次要的。

💡 DSL 的形式有很多，可以创建一门新的微语言(比如 SQL, GraphQL)；可以是一个 JSON 或者 YAML 形式；也可以基于一门现有的元语言(比如 Ruby、Groovy，Rust…)来创建，这些元语言，提供的元编程能力，可以简洁优雅地表达领域问题，同时能够复用元语言 本身的语言能力和基础设施。

严格上可视化低代码平台也是一种‘可视化’ 的 DSL，笔者认为它的局限性更多还是来源‘可视化’，相对的，它优点也大多来源’可视化‘。

这又牵扯到了持续了半个多世纪的： GUI vs CLI（程序化/文本化） 之争。这个在《UNIX 编程艺术》中有深入的探讨。命令行和命令语言比起可视化接口来说，更具表达力，尤其是针对复杂的任务。另外命令行接口具有高度脚本化的能力。缺点就是需要费劲地记忆，易用性差，透明度低。当问题规模变大、程序的行为日趋单一、过程化和重复时， CLI 也常能发挥作用。

如果按照友好度和问题域的复杂度/规模两个维度来划分，可以拉出以下曲线：

中间会出现一个交叉点，在这个交叉点之后，命令行的简要行和表达力变得要比避免记忆负担更有价值。

《反 Mac 接口》一书中也进行了总结：可视化接口在处理小数量物体简单行为的情况下，工作的很好，但是当行为或物体的数量增加是，直接操作很快就编程机械重复的苦差…

也就是说，DSL 的形式会约束 DSL 本身的表达能力。

正如前文说的，如果‘低代码’仅仅是将原本的编码工作转换为 GUI 形式，其实并没有多大意义，因为没有抽象。

反例：JSON GUI vs JSON

正例： VSCode 案例

充分利用 GUI 的优势，提供更好的目录组织、文本提示、数据录入的约束和校验。

我们可能会说 GUI 形式用户体验更好，门槛低更低，不用关心底层的细节。其实并不一定是 GUI 带来的，而是抽象后的结果。GUI 只不过是一种接口形式。

回到正题，为了摆脱管理后台 CRUD 的 「西西弗斯之石」： 我们可以创建一个 DSL，这个 DSL 抽象了管理端的各种场景，将繁琐的实现细节、重复的工作封装起来，暴露简洁而优雅的用户接口(User Interface)。

💡 小结。DSL 是可视化低代码与 pro code 之间的中间中间形态，权衡了易用性/灵活性和实现成本。DSL 的形式会直接影响它的表达能力，但比形式更重要的是 DSL 对特定问题域的抽象。

我们不必重新发明一门语言，而是复用元语言的能力和生态，这基本上是零成本。

抽象过程

典型的增删改查页面：

分析过程：

1. 后端增删改查主要由两大组件组成: 表单和表格。


2. 而表单和表格又由更原子的’字段’组成。字段的类型决定了存储类型、录入方式、和展示方式


3. 字段有两种形态：编辑态和预览态。表格列、详情页通常是预览态，而表单和表格筛选则使用编辑态。

借鉴低代码平台的组件库/节点库，我们可以将这些‘字段’ 提取出来， 作为表单和表格的‘原子’单位， 这里我们给它取个名字，就叫原件(Atomic)吧。

原件将取代组件库里面的表单组件，作为我们 CRUD 页面的最小组成单位。它有且只有职责：

• 数据类型和校验。原件代表的是一种数据类型，可以是基础类型，比如数字、字符串、布尔值、枚举；也可以是基础类型上加了一些约束和交互，比如邮件、手机号码、链接；甚至可能有业务属性，比如用户，商品，订单，二维码。


• 数据的预览。


• 数据的录入，严格约束为 value/onChange 协议。好处是方便进行状态管理，可能保证原件实现的统一性。

接着组合原件来实现表单和表格组件，满足 CRUD 场景：

理想状态下，我们仅需声明式地指定表格的列和原件类型，其余的技术细节应该隐藏起来。表格伪代码示例：

# 创建包含 名称、创建时间、状态三列的表格，其中可以搜索名称和创建时间

Table(

  columns(

    column(名称，name, queryable=true)

    column(创建时间, created, data-range, queryable=true)

    column(状态, status, select, options=[{label: 启用，value: 1, {label: 禁用， value: 0}}])

  )

)

表单伪代码示例：

# 创建包含 名称、状态、地址的表单

Form(

  item(名称，name, required=true)

  item(状态，status, select, options=[{label: 启用，value: 1, {label: 禁用， value: 0}}])

  item(地址, address, address)

)

如上所示，本质上，开发者就应该只关注业务数据本身，而应该忽略掉前端技术实现的噪音(比如状态管理、展示风格、分页、异常处理等等)。

表格和表单为了适应不同的需求，还会衍生出不同的展现形式：

原件 + 核心的表单/表格能力 + 场景/展示形式，一套「组合拳」下来，基本就可以满足常见的后台 CRUD 需求了。

约定大于配置

前端的在研发流程中相对下游，如果上游的产品定义，UI 设计，后端协议没有保持一致性，就会苦于应付各种混乱的差异，复用性将无从谈起。

为了最小化样板代码和沟通成本，实现开箱即用的效果。我们最好拉通上下游，将相关的规范确定下来，前端开发者应该扮演好串联的角色。

这些规范包含但不限于：

• 页面的布局


• UI 风格


• 提示语


• 验证规则


• 数据的存储格式


• 通用的接口(比如文件上传，导入导出)


• …

组件库可以内置这些约定，或者提供全局的配置方式。这些规范固化后，我们就享受开箱即用的快感了。

实现示例

基于上述思想，我们开发了一套组件库(基于 Vue 和 element-ui)，配合一套简洁的 DSL，来快速开发 CRUD 页面。

💡 这套组件库耦合了我们自己的约定。因此可能不适用于外部通用的场景。本文的意义更多是想启发读者，去构建适合自己的一套解决方案。

列表页定义：

import { defineFatTable } from '@wakeadmin/components'



/**

 * 表格项类型

 */

export interface Item {

  id: number

  name: string

  createDate: number

}



export const MyTable = defineFatTable<Item>(({ column }) => {

  // 可以在这里放置 Vue hooks

  return () => ({

    async request(params) {

      /* 数据获取，自动处理异常和加载状态 */

    },

    // 删除操作

    async remove(list, ids) {

      /*列删除*/

    },

    // 表格列

    columns: [

      // queryable 标记为查询字段

      column({ prop: 'name', label: '名称', queryable: true }),

      column({ prop: 'createDate', valueType: 'date-range', label: '创建时间', queryable: true }),

      column({

        type: 'actions',

        label: '操作',

        actions: [{ name: '编辑' }, { name: '删除', onClick: (table, row) => table.remove(row) }],

      }),

    ],

  })

})

语法类似于 Vue defineComponent，传入一个’setup’, 。这个 setup 中可以放置一些逻辑和状态或者 Vue hooks，就和 Vue defineComponent 定义一样灵活。

返回关于表格结构的”声明”。最优的情况下，开发者只需要定义表格结构和后端接口，其余的交由组件库处理。

当然复杂的定制场景也能满足，这里可以使用 JSX，监听事件，传递组件支持的任意 props 和 slots。

表单页示例:

import { defineFatForm } from '@wakeadmin/components'

import { ElMessageBox } from 'element-plus'



export default defineFatForm<{

  // 🔴 这里的泛型变量可以定义表单数据结构

  name: string

  nickName: string

}>(({ item, form, consumer, group }) => {

  // 🔴 这里可以放置 Vue Hooks



  // 返回表单定义

  return () => ({

    // FatForm props 定义

    initialValue: {

      name: 'ivan',

      nickName: '狗蛋',

    },



    submit: async (values) => {

      await ElMessageBox.confirm('确认保存')

      console.log('保存成功', values)

    },



    // 🔴 子节点

    children: [

      item({ prop: 'name', label: '账号名' }),

      item({

        prop: 'nickName',

        label: '昵称',

      }),

    ],

  })

})

💡 和 tailwind 配合食用更香。我们假设整体的页面是符合UI规范的，细微的调整使用 tw 会很方便

全局配置：

import { provideFatConfigurable } from '@wakeadmin/components'

import { Message } from 'element-ui'



export function injectFatConfigurations() {

  provideFatConfigurable({

    // ...

    // 统一处理 images 原件上传

    aImagesProps: {

      action: '/upload',

    },

    // 统一 date-range 原件属性

    aDateRangeProps: {

      rangeSeparator: '至',

      startPlaceholder: '开始日期',

      endPlaceholder: '结束日期',

      valueFormat: 'yyyy-MM-dd',

      shortcuts: [

        {

          text: '最近一周',

          onClick(picker: any) {

            picker.$emit('pick', getTime(7))

          },

        },

        {

          text: '最近一个月',

          onClick(picker: any) {

            picker.$emit('pick', getTime(30))

          },

        },

        {

          text: '最近三个月',

          onClick(picker: any) {

            picker.$emit('pick', getTime(90))

          },

        },

      ],

    },

  })

}

更多示例和深入讲解见这里。

更多实现

前端社区有很多类似的产品，比如：

• XRender。中后台「表单/表格/图表」开箱即用解决方案


• Antd ProComponents。ProComponents 是基于 Ant Design 而开发的模板组件，提供了更高级别的抽象支持，开箱即用。可以显著的提升制作 CRUD 页面的效率，更加专注于页面


• 百度 Amis 。 用 JSON 作为 DSL，来描述界面

读者不妨多参考参考。

总结

简单来说，我们就是从提供「毛坯房」升级到了「精装房」，精装房的设计基于我们对市场需求的充分调研和预判。目的是对于 80% 的用户场景，可以实现拎包入住，当然也允许用户在约束的范围内改装。

本文主要阐述的观点：

• 低代码平台的高效和易用大多来源于抽象，而不一定是 GUI，GUI ≠ 低代码。


• 摆脱「西西弗斯之石」 考验的是开发者的抽象能力，识别代码中固化/重复的逻辑。将模式提取出来，同时封装掉底层的实现细节。最终的目的是让开发者将注意力关注到业务本身，而不是技术实现细节。


• 用声明式、精简、高度抽象 DSL 描述业务 。DSL 的形式会约束他的表达能力，我们并不一定要创建一门新的语言，最简单的是复用元语言的生态和能力。


• 约定大于配置。设计风格、交互流程、数据存储等保持一致性，才能保证抽象收益的最大化。因此规范很重要。这需要我们和设计、产品、后端深入沟通，达成一致。


• 沉淀原件。低代码平台的效率取决于平台提供的组件能力、数量和粒度。比如前端的组件库，亦或者流程引擎的节点，都属于原件的范畴。


• 要求不要太高，没有万精油方案，我们期望能满足 80% 常见的场景，这已经是一个很好的成绩。至于那 20% 的个性需求，还是从毛坯房搞起吧。

扩展阅读

• 精读《低代码逻辑编排》


• UNIX 编
  
  作者：荒山
  来源：juejin.cn/post/7244800185024380984
  程艺术

如果你想在网页上展示一些代码，你可能会遇到一个问题：代码看起来很单调，没有任何颜色或格式，这样的代码不仅不美观，也不利于阅读和理解。

那么，有没有什么办法可以让代码变得更漂亮呢？答案是有的，而且很简单。

你只需要使用一个叫做 highlight.js 的第三方库，就可以轻松实现代码着色的效果。

highlight.js 是一个非常强大和流行的库，它可以自动识别和着色超过 190 种编程语言。

它支持多种主题和样式，让你可以根据自己的喜好选择合适的配色方案。

在本文中，子辰将向你介绍如何使用 highlight.js 来为你的代码着色，以及它的基本原理和优势。

让我们开始吧！

如何使用 highlight.js

使用 highlight.js 的方法有两种：一种是通过 npm 下载并安装到你的项目中，另一种是通过 CDN 引入到你的网页中。

这里我们以 CDN 的方式为例，如果你想使用 npm 的方式，可以参考官方文档。

首先，我们需要在网页中引入 highlight.js 的 JS 文件和 CSS 文件。

JS 文件是核心文件，负责识别和着色代码，CSS 文件是样式文件，负责定义代码的颜色和格式。

我们可以从 CDN 中选择一个合适的 JS 文件和 CSS 文件。

highlight.js 提供了多个 CDN 服务商，你可以根据自己的需求选择一个，这里我们以 jsDelivr 为例。

JS 文件的链接如下：

<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/highlight.min.js"></script>

CSS 文件的链接则需要根据你想要的主题来选择。

highlight.js 提供了很多主题，你可以在官网上预览每个主题的效果，并找到对应的 CSS 文件名，这里我们以 github-dark 为例。

CSS 文件的链接如下：

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/styles/github-dark.min.css">

将上面两个链接分别放到网页的 head 标签中，就完成了引入 highlight.js 的步骤。

接下来，我们需要在网页中写一些代码，并用 pre 标签和 code 标签包裹起来。

pre 标签用于保留代码的格式，code 标签用于标识代码内容。例如：

<pre>

  <code id="code-area">

  * {

    margin: 0;

    padding: 0;

    box-sizing: border-box;

  }

  body {

    display: flex;

    justify-content: center;

    align-items: center;

    gap: 20px;

    height: 100vh;

    width: 100vw;

  }

  </code>

</pre>

注意，我们给 code 标签添加了一个 id 属性，方便后面通过 JS 获取它。

最后，我们需要在网页中添加一些 JS 代码，来调用 highlight.js 的方法，实现代码着色的功能。

highlight.js 提供了两个主要的方法：highlightElement 和 highlight。

这两个方法都可以实现代码着色的效果，但是适用于不同的场景。

highlightElement

highlightElement 方法适用于当你的代码是直接写在网页中的情况。

这个方法接受一个元素作为参数，并将该元素内部的文本内容进行着色处理。例如：

// 获取 code 元素

const codeEle = document.getElementById("code-area");

// 调用 highlightElement 方法，传入 code 元素

hljs.highlightElement(codeEle);

如果一切顺利，你应该能看到类似下图的效果：

代码已经被着色了，并且你可以看到代码被替换成了一个个标签，标签被加上了样式。

在最后的原理里我们在详细的说一下。

highlight

highlight 方法适用于当你的代码是通过 Ajax 请求获取到的纯文本数据的情况。

这个方法接受一个字符串作为参数，并返回一个对象，包含着色后的文本内容和代码的语言。例如：

<script>

  const codeEle = document.getElementById('code-area')

  // 比如说现在 code 就是 Ajax 返回的数据，lang 就是代码语言，content 就是代码内容

  const code = {

    lang: 'css',

    content: `

    * {

      margin: 0;

      padding: 0;

    }`

  }

  // 我们接下来可以使用 hljs.highlight，将代码内容与代码语言传入进去

  const result = hljs.highlight(code.content, {

    language: code.lang

  })

  // 它会返回一个结果，我们打印到控制台看看

  console.log('result >>> ', result)

</script>

我们可以看到，打印出来的是一个对象，code 是它原始的代码，language 是它的语言，而 value 就是它着色后的代码。

那么现在要做的就是将 value 添加到 code 元素里边去。

<script>

  const code = {

    lang: 'css',

    content: `

    * {

      margin: 0;

      padding: 0;

    }`

  }

  const result = hljs.highlight(code.content, {

    language: code.lang

  })

  const codeEle = document.getElementById('code-area')

  codeEle.innerHTML = result.value

</script>

我们可以看到，代码确实被着色了，但是和之前的有所差别，我们看一下是什么原因。

打开控制后我们发现，用这种方式 code 元素就没有办法被自动加上类样式了，所以说我们就需要手动给 code 加上类样式才可以。

// 通过 className 为 code 手动添加类样式，并添加类的语言

codeEle.className = `hljs language-${code.lang}`

highlight.js 的语言支持

无论使用哪种方法，都需要注意指定代码所属的语言。

如果不指定语言，highlight.js 会尝试自动识别语言，并可能出现错误或不准确的结。

指定语言可以通过两种方式：

• 在 code 标签中添加 class 属性，并设置为 language-xxx 的形式，其中 xxx 是语言名称。


• 在调用 highlightElement 或 highlight 方法时，在第二个参数中传入一个对象，并设置 language 属性为语言名称。

上图是 highlight.js 支持的语言，可以看到有很多种，需要用其他语言的时候，language 设置成指定的语言名称就可以了。

原理

它的原理你可能已经猜到了，在 highlightElement 里我们简单说了一下，现在再看下图：

之所以可以实现着色，其实就是查找和替换的过程，将原来的纯文本替换为元素标签包裹文本，元素是可以加上样式的，而样式就是我们引入的 css 文件。

这就是它的基本原理了。

总结

其实有时候我们去设置 Mackdown 的自定义样式呢，在代码区域设置的时候也是这样设置的，当然类样式的名字呢，基本上都是标准的格式。

好了，这个库分享介绍给你了，库的原理也为你做了简单的科普，希望对你有所帮助。

如果你有什么问题或建议，请在评论区留言，如果你觉得这篇文章有用，请点赞收

前段时间社区上大肆讨论「前端已死」，各种唱衰前端的言论此起彼伏，真是闻者落泪，听者伤心。

最近又听说某大厂取消大前端部门，前端被拆分到各个业务组。很多前端高 P 或离职，或被裁，或转后端。

这是前端的落日？

今天就瞎聊聊，聊到哪算哪。

前端技术发展趋于稳定

过去前端最被开发者诟病的是发展太快了，三天不学前端就跟不上了。

在我个人的前端经历中，技术栈从 Jquery 到 Angular，再到 React，前端技术快速切换，同时配套的前端研发体系也在不断推倒重建。

仅仅 React，从 V14 到 V15，再到 V16，一路快速迭代，每一个版本都有质的飞跃。尤其是 V16.8 hooks 出来之后，各种生态工具又得重建。

但最近几年，前端技术发展似乎慢了下来，React 16.8 版本还是 19 年发布的，距离现在已经四年多时间了，在这四年多时间内，React 虽然发布了 V17、V18，但并没有什么质的提升。对于我而言，只要能用 Hooks，16/17/18 哪个版本无所谓。

前端生态趋于稳定，是好事还是坏事？

我以前很羡慕 JAVA 开发同学，学习一套技术体系可以用到老。现在似乎前端也可以这样了，我认为这是一件非常好的事情，是前端成熟的标志。

只有前端技术体系不再发展，前端工程师才能 100% 精力投入在产品建设上。不用总是分精力去学习新技术，新轮子，最大程度复用过去的学习成果和基础设施。

比如现在有个需求是计算 43✖️5 的结果，我们会使用现有的方法，计算出结果，而不是要去思考有没有更好的计算方法。

本质上是我们的计算方法已经非常成熟稳定了，我们只要专注需求本身。前端什么时候稳定到这个程度，就皆大欢喜了。

公司中前端部门的发展

再聊聊一个公司中，前端团队定位的问题。

1. 公司发展初期，产品建设高速期，前端的首要目标是建设产品，这时候前端通常在业务部门中，大家全力做产品。


2. 随着公司发展，产品越来越多，各个业务部门的前端交流少，使用的技术五花八门，重复造轮子。这时候公司通常会搞一个大前端部门，使其研制出来一套在公司内成熟的前端解决方案，统一各种基建，提高人均效能。


3. 当前端解决方案统一到一定程度之后，大前端部门的使命就结束了，这时候前端又会被拆分到业务部门中。

这里说说阿里大前端部门拆分，我认为原因有两个：

1. 阿里前端基建相对已经成熟，拆分之后对前端研发效能影响不大。


2. 公司不挣钱，不吃大锅饭了。以前是各个业务部门一起挣钱，一起养着大前端团队。现在公司不赚钱了，要改革，要求各个业务线自己挣钱自己花，所以前端开发也要回归到业务团队中。

最近并不只是「前端已死」了，我认为各个工种都在面临裁员潮，原罪是公司不赚钱了。在发展阶段啥问题都没有，一旦发展停滞，那什么都是问题，一个一个开刀。

对于个体来讲，如果想在这个公司发展，就要尽力帮助公司成长。另外就是居安思危，提升个人竞争力，只有跑的比别人快，才能在逆风中活下来，才能比别人更容易找到工作。

这里不得不吐槽下，很多人乐意躺平，你说要学习，要往前走一步，他会喷你卷，喷你带坏了风气，喷你是资本主义的走狗。大无语~

一个前端创业机会

之前在蚂蚁，前端基建非常完善，开发者真正的只用关心业务，不用去思考技术的东西。在公司内部基本上做到了只用关心 43✖️5 这个需求，不用考虑该用哪种计算方法。

从蚂蚁离开后，非常怀念蚂蚁的前端解决方案，但在社区上，并没有类似的收费或者免费方案。
据我所知，各个大公司，都会有自己的前端解决方案。但中小公司，基本上没有能力去自建一套类似解决方案。

阿里的后端解决方案，有商业化的产品「云效」。

蚂蚁的后端解决方案，有商业化的产品「SOFAStack」。

微软的后端解决方案，有商业化的产品「Azure DevOps」。

为什么后端有，前端没有呢？

我认为是后端技术栈稳定，基于这一套技术栈的生态也就稳定，发展多年下来势必会有成熟的解决方案。大公司产出商业化解决方案，给中小公司用。

前端技术栈过去发展快，生态不稳定，大公司内部的解决方案也是最近一两年才出来，所以前端目前还没有类似的解决方案。

所以我认为前端解决方案，是未来一个确定性的机会。

这个解决方案覆盖前端研发的整个生命流程，包括不限于：

• 产品：埋点、数据分析等等


• 开发：迭代协作、脚手架、组件库、逻辑库、联调、国际化、跨端等等


• 上线：灰度、回滚、CDN、监控告警、性能、SEO、SSR、SSG、离线包、安全等等

希望未来前端解决方案，像乘法解决方案一样，能成为行业统一规范，让开发者真正的只用关心业务，不用关心技术。

前端的未来

说几点自己的思考：

1. 前端技术趋于稳定，开始有商业化的前端解决方案出来。


2. 前端不会消失，但门槛会进一步降低，低端前端饱和。


3. 高级前端依旧紧缺，因为高级前端并不是只是看前端技能，而是综合考虑技术能力、业务能力、沟通能力、情商、职业素养、工作经验等等，这个过去现在未来都不会变。


4. 前端工程师可能会变成用户体验工程师，后端考虑存储并发等，前端考虑用户体验，为整体用户体验负责。


5. 前端会进一步蚕食桌面端开发、移动端开发的生存空间。


6. AI 可能会改变前端研发模式。

总结

也许前端技术栈稳定之后，才是真正的开始。

文中所有观点未经论证，纯属 YY，欢迎理性讨论。

作者：前端技术砖家
来源：juejin.cn/post/7245874747390083109

你好，我是泰罗凹凸曼，今天我们来一篇JS中的位运算科普，经常在源码中看到的位运算符，和用其定义的一系列状态到底有什么优势？

位运算符号的基本了解

首先，我们应该要简单了解位运算符，常用的位运算符大概有以下几种，我们可以在JS中使用 toString 将数字转换为二进制查看，也可以通过 0b 开头来手动创建一个二进制数字：

(3).toString(2) // 11

0b00000011 // 3 前面的几位0可以省略，可以简写为 0b11 

1. 与 &

按位对比两个二进制数，如果对应的位都为 1，则结果为 1，否则为 0

console.log((1 & 3) == 1) // true

对比图例如下所示：

2. 或 |

按位对比两个二进制数，如果对应的位有一个 1，则结果为 1，否则为 0

console.log((1 | 3) == 3) // true

对比图例如下所示：

3. 异或 ^

按位对比两个二进制数，如果对应的位有且只有一个 1，则结果为 1，否则为 0

console.log((1 ^ 3) == 2) // true

对比图例如下所示：

4. 非 ~

按位对操作的二进制数取反，即 1 变 0，0 变 1，任何数的非运算符计算结果都是 -(x + 1)

const a = -1 // ~a = -(-1 + 1) = 0

console.log(~a) // 0

const b = 5 // ~b = -(5 + 1) = -6

console.log(~b) // -6

一个数和它的取反数相加的结果总为 -1

5. 左移 <<

左移会将二进制值的有效位数全部左移指定位数，被移出的高位(最左边的数字)丢弃，但符号会保留，低位(最右边的数字)会自动补0

console.log(1 << 2) // 4

图例如下所示：

6. 右移 >>

和左移相反的操作，将二进制的操作数右移指定位数，高位补0，低位丢弃！

console.log(4 >> 2) // 1

参考资料均来自 MDN，除了这些常用的符号之外，文档还标注了所有的JS操作符号，感兴趣的同学可以看一看！

有什么用？

说了这么多符号，对于操作符的影响是加深了，但是有什么用呢？二进制数字难理解，位操作符也难理解，二进制和十进制的互转不写个代码都心算不了，相信各位同学肯定有如此费解，我们先来看一段 Vue 的源代码，其中定义了很多状态类的字段！

源码位置戳这里

以及 Vue 中对其的使用，源码位置戳这里

我们可以看到，Vue 定义了一系列状态列标识一个 Dom 是属于什么类型，并用 VNode 中的一个字段 shapeFlag 来完成存储和判断，对状态的存储只用到了一个字段一个数字，就可以进行多种状态的判断！

我们尝试着设计一种类似的判断结构出来如何？

我有N个权限

假设系统中的用户我们规定其有增删改查四个权限，我们可以设计一个枚举类来标识拥有的四个权限：

enum UserPerm {

  CREATE = 1 << 0,

  DELETE = 1 << 1,

  UPDATE = 1 << 2,

  SELECT = 1 << 3,

} 

我们设计的时候，完全不必在意上述的二进制的十进制值是什么，只需要清楚的是，上述枚举的 1 在二进制位的哪个位置，如 1 的 二进制为 00000001，将其左移 1(1 << 1), 就变成了 00000010, 依次类推，我们用一个二进制串中的每一位来标识一个权限，这样一个字符串中只要出现对应位置的 1， 则该用户就拥有对应位置的权限，如图：

有什么好处呢？

我们知道二进制是可以转换为十进制的，这样子我们就可以用一个数字来表示多个权限，如一个用户完整的拥有四个权限，那他的二进制为 0b1111, 那么其状态为数字 15

如果一个用户只有 CREATE 和 SELECT 的权限，那么二进制表达为 0b1001，十进制数字为 9

后端数据库中，前端用户信息中，接口返回都只有一列一个字段就可以表示，那么用户信息应该是下面的形式：

const userInfo = {

  name: '泰罗凹凸曼',

  phone: '15888888888',

  perm: 9, // 代表其只有 CREATE 和 SELECT 两种权限

}

权限的判断

如何判断这个用户是否具备某一个权限呢？那就需要请出我们的 与运算符(&)，参考 Vue 的做法：

console.log(userInfo.perm & UserPerm.CREATE) // 9 & (1 << 0) = 1



console.log(userInfo.perm & UserPerm.UPDATE) // 返回 0, 0代表不通过

如果 userInfo.perm 中包含 CREATE，就会返回 CREATE 的值，否则返回 0，在JS中，任何非0的数字都可以通过 if 判断，所以我们只需要一个判断就足够了！

if (userInfo.perm & UserPerm.CREATE) {

  console.log('有创建权限')

} else {

  console.log('没有创建权限')

}

什么原理？我们之前给过与运算符的图例，接下来我们看一下如上两句代码的图例所示：

我们看到，上下的符号位如果对不上的话，返回的结果都是 0，这样子我们就轻松实现了权限的判断

权限的增删

那么我们如何实现对一个用户的权限更新呢，比如给上面的用户新增一个 UPDATE 权限，这个时候我们就需要 或运算符(|)

比如：

userInfo.perm | UserPerm.UPDATE // 1001 | 0100 = 1101 = 13

这样子我们就对一个用户权限进行了增加，或的规则我们上面也给过图例，这里大家可以自己尝试理解一下，无非是两个二进制数 1001 和 0100 之间的或运算，只有其中一位为 1 则为 1，这两个数字计算的结果自然是 1101

那么如何实现权限删除呢？异或运算符(^)给你答案！有且只有一个 1，返回 1，否则为 0，删除对我们刚刚添加的 UPDATE 权限的方法：

userInfo.perm ^ UserPerm.UPDATE // 1101 ^ 0100 = 1001

非常简单是吧？看到这里，相信你已经完全理解位运算符在权限系统的妙用了，如果我这个时候需要添加一个新的权限，如分享权限，那么我只有用第五位的1来表示这个权限就可以啦

enum UserPerm {

  SHARE = 1 << 5

}



// 添加分享权限

userInfo.perm | UserPerm.SHARE

以前的方案

我们以前在做用户标识的时候，通常会定义一个数组来表示，然后执行数组判断来进行权限的判断

const userPerm = ['CREATE', 'UPDATE', 'DELETE', 'SELECT']



// 判断有无权限

if (userPerm.includes('CREATE')) {

  // ...

}



// 增加权限

user.perm.push('UPDATE')



// 删除权限

user.perm.splice(user.perm.indexOf('UPDATE'), 1)

相信大家也可以看出来，无论是从内存占用，效率，便捷程度来说位运算符的形式都是完胜，这也是会被各大项目使用的原因之一！快去你的项目中实践吧，记得写好注释哦！

结语

今天带大家认识了位运算符在权限系统的妙用，小伙伴们还有什么使用位运算符的巧妙思路，可以在评论中给出来哦！继续加油吧，快去实践少年！

祝大家越来越牛逼！

去探索，不知道的东西还多着呢，我是泰罗凹凸曼，M78星云最爱写代码的，我们下一篇再会！

最近有个朋友来问我晋升的事，其实他没什么产出，只不过因为做的那块业务还不错，赚了好几个小目标，然后顺理成章的被提名了。所以他慌的要死！

你猜他来问什么内容？他什么都想问，又什么都问不出来，因为我也没晋升过。不过这并不妨碍我写点什么，谁让我会编呢？

我要不要提名晋升

我要不要提名晋升？你要是能问出这问题，要不刚毕业，要不加班加迷糊了！

晋升意味着涨薪，涨薪意味着每个月能多吃几顿海底捞，多看几部电影，这世道和谁过不去都不能和钱过不去。

但晋升往往是领导说了才算，除非你是向园，还有个董事长爷爷。所以，怎么说服他就成了一道槛。

工作三要素：A-能力；B-岗位；C-环境（其他人和事），而晋升基本只和 AB 有关。如 果你在自己岗位上，已经承担了下一级该承担的责任。然后能力又达到了下一级所要求的水平，再不提名晋升就没天理了。

例如我是P6，但是我一直在做P7的事情，同时在抗P7的责任，并且表现不错。那么我对标P7不就是既定事实嘛，既然是事实谁又能阻止你提名？

另外还有 C，如果把晋升与环境挂钩，晋升的理由变成了诸如  “如果我在他的位置上，我能做得比他更好”、“为什么他是P9而我是P8”，以这些理由提名晋升，属实是自寻烦恼，说不定明年你就成为人才输送给社会了。

从这个角度上看，我那位朋友已经晋升失败了。不过你们也不要太关注这个，缘分这个东西不是说有就有。就像你能恰好看见我这篇帖子，然后顺手点赞、收藏、在看一样。

提名之后，如何准备答辩

晋升靠的是硬实力，以及10%的运气。 你想去吹牛也不是不行，就怕到时候下不来台。仅仅是 P6 升 P7 的答辩，上面坐着的都是P9级别的大佬和砖家。

PPT 以真实、简朴为主，凡是在 PPT 上花费超过10小时的，我觉得都有耍流氓的嫌疑。这些内容应该是这段时间你所积累的工作成果。平时没事拿个小笔记记一下，关键时刻它能像宋江一样救你的命。【推荐你用语雀，真的很好用】

有了 PPT，你得去讲出来吧。讲话作为一门艺术，对于我们理工科的同学还是有一定难度的，所以我建议你有空去参加下吐槽大会。没有条件？那就创造条件，公司里找几个段子手还不是轻而易举。相比之下，产品经理的优势比我们大多了。

如何把实力讲透？这里面是有一定技巧的，3分讲结果，7分讲过程。光讲结果不讲过程，30分钟的答辩，你5分钟就完成了，还是包含自我介绍的那种。

3分成效如何讲？——把我在当前岗位上，如何把手里的工作做上了一个新台阶 ， 这种感觉讲出来，就是，因为你的努力而带来了什么改变？

7分过程如何讲？——把事情的复杂度、岗位的挑战、面临的困难讲清楚，把你做事的匠心讲清楚，你把你的做事的方法、思路讲清楚。说白了，就是“我解了一个挺难的题，我是这样那样解的”；

关于答辩与专家评委

评委扮演的角色很简单，评审的过程，就是评委向答辩人学习的过程。每个人都存在未涉及的领域，你看 ChatGPT 用了上亿的数据训练，花了几十亿美金，现在连小学数学题都解不出来。

三个评委，花45分钟与答辩人进行深度交流，如果评委们都表示没有收获，学不到东西（无论是学到知识还是方法或者心态），那么答辩人晋升不通过，也不冤枉。

这个道理够简单吧，神雕侠侣里黄老邪为什么会和杨过拜把子，一方面是杨过的性格和黄老邪很像，另一方面是因为能从杨过那学到点东西。

回到现实，我们每个人都有直接的体会。如果有个大牛（至少他在当前的工作中是专业的）跟我们交流，我们一定有收获。如果对方十分平庸（或者在工作中能力一般），我们收获就比较少。

晋升通过，意味着什么

意味着加薪，年终奖多了点。

意味着岗位（B）对你的能力（A）要求更大了一些。

意味着你离 3.25 更近了一些，我知道的几个同事，每次晋升之后的第一个季度或半年度，都会拿一次3.25。

晋升不通过，意味着什么

恭喜你，终于松了口气！

结尾

如果这篇文章对您有所帮助，可以关注我的公众号。

我是车辙，掘金小册《SkyWalking》作者

概论

对于js的垃圾回收，很多人的理解还停留在引用计数和标记清除的阶段。

有人会说，学习这个，对业务代码开发没啥作用。但是我想说，了解了这些基础的东西之后，才能更好地组织代码，在写代码的时候，才能做到心中能有个框架，知道浏览器到底发生了什么。

我也不是科班出身，很多东西不清不楚的。但我感觉计算机行业有个很好的地方，就是学了的知识很快就能得到验证，就能在生产上应用。这种成就感是我当年干机械的时候所无法体验到的。

前几天就有个报障说有个项目越用越卡，但是排查不出问题，我最近正好在学习垃圾回收内存泄漏，就立马能分析出来是不是内存不足产生的影响，就很开心。

本文我会采用图解的方式，尽量照着js垃圾回收的演变历史讲解。

一，什么是垃圾回收

GC 即 Garbage Collection，也就是我们常说的垃圾回收。

我们知道，js是v8引擎编译执行的，而代码的执行就需要内存的参与，内存往往是有限的，为了更好地利用内存资源，就需要把没用的内存回收，以便重新使用。

比如V8引擎在执行代码的过程中遇到了一个函数，那么我们会创建一个函数执行上下文环境并添加到调用栈顶部，函数的作用域里面包含了函数中所有的变量信息，在执行过程中我们分配内存创建这些变量，当函数执行完毕后函数作用域会被销毁，那么这个作用域包含的变量也就失去了作用，而销毁它们回收内存的过程，就叫做垃圾回收。

如下代码：

var testObj1={

    a:1

}

testObj1={

    b:2

}

对应的内存情况如下：

其中堆中的{a:1}就变成了垃圾，需要被GC回收掉。

在C / C++中，需要开发者跟踪内存的使用和管理内存。而js等高级语言，代码在执行期间，是V8引擎在为我们执行垃圾回收。

那么既然已经有v8引擎自动给我们回收垃圾了，为啥我们还需要了解V8引擎的垃圾回收机制呢？这是因为依据这个机制，还有些内存无法回收，会造成内存泄漏。具体的表现就是随着项目运行时间的变成，系统越来越卡滞，需要手动刷新浏览器才能恢复。

了解V8的垃圾回收机制，才能让我们更好地书写代码，规避不必要的内存泄漏。

二，内存的生命周期

如上所说，内存应该存在这样三个生命周期：

1. 
   

   分配所需要的内存：在js代码执行的时候，基本数据类型存储在栈空间，而引用数据类型存储在堆空间。

   
   


2. 
   

   使用分配的空间：可能对对应的值做一些修改。

   
   


3. 
   

   不需要时将其释放回收。

   
   

   如下代码：

   
   

   function fn(){
   
       //创建对象，分配空间
   
       var testObj={
   
           a:1
   
       }
   
       //修改内容
   
       testObj.a=2
   
   }
   
   fn()//调用栈执行完毕，垃圾回收
   
   

   
   

   对应的内存示意图：

   
   

三，垃圾回收的策略

当函数执行完毕，js引擎是通过移动ESP（ESP：记录当前执行状态的指针）来销毁函数保存在栈当中的执行上下文的，栈顶的空间会被自动回收，不需要V8引擎的垃圾回收机制出面。

然而，堆内存的大小是不固定的，那堆内存中的数据是如何回收的呢？

这就引出了垃圾回收的策略。

通常用采用的垃圾回收有两种方法：引用计数(reference counting)和标记清除（mark and sweep）。

3.1，引用计数(reference counting)

如上文第二节中所说，testObj对象存放在堆空间，我们想要使用的时候，都是通过指针来访问，那么是不是只要没有额外的指针指向它，就可以判定为它不再被使用呢？

基于这个想法，人们想出了引用计数的算法。

它工作原理是跟踪每个对象被引用的次数，当对象的引用次数变为 0 时，则判定该对象为无用对象, 可以被垃圾回收机制进行回收。

    function fn(){

        //创建对象，分配空间

        var testObj1={

            a:1

        }//引用数：1

        var testObj2=testObj1//引用数：2

        var testObj3=testObj1//引用数：3

        var testObj4={

            b:testObj1

        }//引用数：4

        testObj1=null//引用数：3

        testObj2=null//引用数：2

        testObj3=null//引用数：1

        testObj4=null//引用数：1

    }

    fn()//调用栈执行完毕，垃圾回收

如上代码，引用次数变成0后，堆内存中的对应内存就会被GC。

如下图，当testObj1-4都变成null后，原来的testObj4引用数变成0，而{a:1}这时候的引用数还为1（有一个箭头指向它），而{b:1002}被回收后，它的引用数就变成0，故而最后也被垃圾回收。

引用计数的优点：

引用计数看起来很简单，v8引擎只需要关注计数器即可，一旦对象的引用数变成0，就立即回收。

但是很明显的，引用计数存在两个缺点：

1，每个对象都需要维护一个计数器去记录它的引用数量。

2，如果存在相互循环引用的对象，因为各自的引用数量无法变成0（除非手动改变），因而无法被垃圾回收。

对于第二点，如下代码：

function fn(){

    //创建对象，分配空间

    var testObj1={

        a:testObj2

    }

    var testObj2={

        b:testObj1

    }

}

fn()

当fn执行完毕后的内存情况如下，因为两个对象相互引用，导致引用数到不了0，就无法被GC：

因为引用计数的弊端，后续的浏览器开始寻找新的垃圾回收机制，从2012年起，所有现代浏览器都使用了标记清除垃圾回收算法。所有对JavaScript垃圾回收算法的改进都是基于标记清除算法的改进。

3.2，标记清除（mark and sweep）

标记清除是另一种常见的垃圾回收机制。

它工作原理是找出所有活动对象并标记它们，然后清除所有未被标记的对象。

其实现步骤如下：

1. 根节点：垃圾回收机制的起点是一组称为根的对象(有很多根对象)，根通常是引擎内部全局变量的引用，或者是一组预定义的变量名，例如浏览器环境中的 Window 对象和 Document 对象。


2. 遍历标记：从根开始遍历引用的对象，将其标记为活动对象。每个活动对象的所有引用也必须被遍历并标记为活动对象。


3. 清除：垃圾回收器会清除所有未标记的对象，并使空间可用于后续使用。

因为能从根节点开始被遍历到的（有被使用到的），就是有用的活动对象，而剩余不能被链接到的则是无用的垃圾，需要被清除。

对于前文引用计数中循环引用的例子，就因为从根对象触发，无法遍历到堆空间中的那两个循环引用的对象，就会把它判定为垃圾对象，从而回收。

如下代码：

var obj1={

    a:{

        b:{

            c:3

        }

    }

}

var obj2={

    d:1

}

obj2=null

如下图，从根节点无法遍历到obj2了，就会把d垃圾回收。

按照这个思路，标记清除算法有一个很大的缺点，就是在清除之后，剩余的对象内存位置是不变的，会导致空闲内存空间是不连续的，出现了 内存碎片（如下图），并且由于剩余空闲内存不是一整块，它是由不同大小内存组成的内存列表，这就牵扯出了内存分配的问题：当新对象需要空间存储时，需要遍历空间以找到能够容纳对象大小size的区域：

这样效率比较低，因而又有了标记整理（Mark-Compact）算法 ，它的标记阶段和标记清除算法没有什么不同，只是标记结束后，标记整理算法会先将活动对象向内存的一端移动，然后再回收未标记的垃圾内存：

四，V8引擎的分代回收

如上文所说，在每次垃圾回收时都要检查内存中所有的对象，这样的话对于一些占用空间大、存活时间长的对象，要是和占用空间小、存活时间短的对象一起检查，那不是平白浪费很多不必要的检查资源嘛。

因为前者需要时间长并且不需要频繁进行清理，后者恰好相反，那怎么优化呢？

类似于信誉分，信誉分高的，检查力度就应该小一些嘛。把信誉分抽象一下，其实说的就是分层级管理，于是就有了弱分代假设。

4.1，弱分代假设（The Weak Generational Hypothesis）

1. 多数对象的生命周期短


2. 生命周期长的对象，一般是常驻对象

V8的GC也是基于假设将对象分为两代： 新生代和老生代。

对不同的分代执行不同的算法可以更有效的执行垃圾回收。

V8 的垃圾回收策略主要基于分代式垃圾回收机制，将堆内存分为新生代和老生代两区域，采用不同的策略来管理垃圾回收。

他们的内存大小如下：

4.2，新生代的垃圾回收策略

新生代对象是通过一个名为 Scavenge 的算法进行垃圾回收。

在JavaScript中，任何对象的声明分配到的内存，将会先被放置在新生代中，而因为大部分对象在内存中存活的周期很短，所以需要一个效率非常高的算法。Scavenge算法是一个典型的牺牲空间换取时间的复制算法，在占用空间不大的场景上非常适用。

Scavenge 算法中将新生代内存一分为二，Semi space From和Semi space To，新生区通常只支持 1～8M 的容量。这块区域使用副垃圾回收器来回收垃圾。

工作方式也很简单：

1，等From空间满了以后，垃圾回收器就会把活跃对象打上标记。

2，把From空间已经被标记的活动对象复制到To空间。

3，将From空间的所有对象垃圾回收。

4，两个空间交换，To空间变成From空间，From变成To空间。以此往复。

而判断是否是活跃对象的方法，还是利用的上文说的从根节点遍历，满足可达性则是活跃对象。

具体流程如下图所示，假设有蓝色指针指向的是From空间，没有蓝色指针指向的是To空间：

从上图可以明显地看到，这种方式解决了上文垃圾回收后内存碎片不连续的问题，相当于是利用空间换时间。

现在新生代空间的垃圾回收策略已经了解，那新生代空间中的对象又如何进入老生代空间呢？

4.3，新生代空间对象晋升老生代空间的条件

1，复制某个对象进入to区域时，如果发现内存占用超过to区域的25%，则将其晋升老生代空间。（因为互换空间后要留足够大的区域给新创建对象）

2，经过两次from和to互换后，还存活的对象，下次复制进to区域前，直接晋升老生代空间。

4.4，老生代空间的垃圾回收策略

老生代空间最初的回收策略很简单，这在我们上文也讲过，就是标记整理算法。

1，先根据可达性，给所有的老生代空间中的活动对象打上标记。

2，将活动对象向内存的一端移动，然后再回收未标记的垃圾内存。

这样看起来已经很完美了，但是我们知道js是个单线程的语言，就目前而言，我们的垃圾回收还是全停顿标记：js是运行在主线程上的，一旦垃圾回收生效，js脚本就会暂停执行，等到垃圾回收完成，再继续执行。

这样很容易造成页面无响应的情况，尤其是在多对象、大对象、引用层级过深的情况下。

于是在这基础上，又有了增量标记的优化。

五，V8优化

5.1，增量标记

前文所说，我们给老生代空间中的所有对象打上活动对象的标记，是从一组根节点出发，根据可达性遍历而得。这就是全量地遍历，一次性完成，

但因为js是单线程，为了避免标记导致主线程卡滞。于是人们想出来和分片一样的思路：主线程每次遍历一部分，就去干其他活，然后再接着遍历。如下图：

增量标记就是将一次 GC 标记的过程，分成了很多小步，每执行完一小步就让应用逻辑执行一会儿，这样交替多次后完成一轮 GC 标记，这样就算页面卡滞，因为时间很短，使用者也感受不到，体验就好了很多。

但是这又引发了一个新的问题：每次遍历一部分节点就停下来，下次继续怎么识别到停顿点，然后继续遍历呢？

V8又引入了三色标记法。

5.2，三色标记法

首先要明确初心：三色标记法要解决的问题是遍历节点的暂停与恢复。

使用两个标志位编码三种颜色：白色（00），灰色（10）和黑色（11）。

白色：指的是未被标记的对象，可以回收

灰色：指自身被标记，成员变量（该对象的引用对象）未被标记，即遍历到它了，但是它的下线还没遍历。不可回收

黑色：自身和成员变量都被标记了，是活动对象。不可回收

1，从已知对象开始，即roots(全局对象和激活函数), 将所有非root对象标记置为白色

2，将root对象变黑,同时将root的直接引用对象abc标记为灰色

3，将abc标记为黑色，同时将它们的直接引用对象标记为灰色

4，直到没有可标记灰色的对象时，开始回收所有白色的对象

如上图所示，如果第一次增量标记只标记到（2），下次开始时，只要找到灰色节点，继续遍历标记即可。

而遍历标记完成的标志就是内存中不再有灰色的。于是这时候就可以把白色的垃圾回收掉。

那这样就解决了遍历节点的暂停与恢复问题，同时支持增量标记。

（ps:其实这里我有个疑惑，暂停后重新开始的时候，不也要遍历寻找灰色节点嘛，每次恢复都要遍历找灰色节点，不是也耗时嘛？）

5.3，写屏障

按照上文对标记的描述，其实有一个前提条件：在标记期间，代码运行不会变更对象的引用情况。

比如说我采用的是增量标记，前脚刚做好的标记，后脚就被js脚本修改了引用关系，那不是会导致标记结果不可信嘛？如下图：

就像上图一样，D已经被判定成垃圾了，但是下一个分片的js又引用了它，这时候如果删除，必然不对，所以V8 增量使用 写屏障 (Write-barrier) 机制，即一旦有黑色对象引用白色对象，该机制会强制将引用的白色对象改为灰色，从而保证下一次增量 GC 标记阶段可以正确标记，这个机制也被称作 强三色不变性

那在我们上图的例子中，将对象 B 的指向由对象 C 改为对象 D 后，白色对象 D 会被强制改为灰色。

这样一来，就不会将D判定为垃圾 ，并且图中新增的垃圾C在本轮垃圾回收中也不会回收，而是在下一轮回收了。

5.4，惰性清理

上文的增量标记和三色标记法以及写屏障只是对标记方式的优化。目的是采用分片的思想将标记的流程碎片化。

而清理阶段同样可以利用这个思想。

V8的懒性清理，也称为惰性清理（Lazy Sweeping），是一种垃圾回收机制，用于延迟清理未标记对象所占用的内存空间，以减少垃圾回收期间的停顿时间。

当增量标记结束后，假如当前的可用内存足以让我们快速的执行代码，其实我们是没必要立即清理内存的，于是可以将清理的过程延迟一下，让JavaScript逻辑代码先执行；也无需一次性清理完所有非活动对象内存，垃圾回收器可以按需逐一进行清理，直到所有的页都清理完毕。

六，垃圾回收总结

6.1，初始的垃圾回收策略：从引用计数到标记清除

对于js的垃圾回收，最开始的时候，是采用引用计数的算法，但是因为引用计数存在循环引用导致垃圾无法清除，于是又引入了标记清除算法，而标记清除算法存在碎片空间问题，于是又优化成标记整理算法。

随着技术的发展，v8引擎的垃圾回收机制也在不断完善。

6.2，弱分代假设，划分新老生代空间采用不同策略

第一次完善是采用弱分代假设，为了让内存占用大、存活时间长的对象减少遍历，采用分代模型，分成了新分代和老分代空间，垃圾回收采取不同的策略。

新生代空间以空间换时间，拆分成from和to空间互换位置，解决垃圾回收后内存不连续的问题。

将满足条件的对象晋升到老生代空间。而老生代空间采用标记整理算法。

6.3，从全停顿到引入分片思想

因为js是单线程，如果垃圾回收耗时过长，就会阻塞页面响应。

为了解决标记阶段的全停顿问题，引入了增量标记算法。但是非黑即白的标记算法在下一次重新开始标记时无法找到上次的中断点，所以使用三色标记法。此外，为了避免增量标记过程中js脚本变更引用关系，v8又增加了写屏障。

同样的，为了解决清理阶段的全停顿问题，引入了惰性清理。

七，本系列其他文章

最近在整理js基础，下面是已经完成的文章：

js从编译到执行过程 - 掘金 (juejin.cn)

从异步到promise - 掘金 (juejin.cn)

从promise到await - 掘金 (juejin.cn)

浅谈异步编程中错误的捕获 - 掘金 (juejin.cn)

作用域和作用域链 - 掘金 (juejin.cn)

原型链和原型对象 - 掘金 (juejin.cn)

this的指向原理浅谈 - 掘金 (juejin.cn)

js的函数传参之值传递 - 掘金 (juejin.cn)

js的事件循环机制 - 掘金 (juejin.cn)

从作用域链和内存角度重新理解闭包 - 掘金 (juejin.cn)

八，本文参考文章：

「硬核JS」你真的了解垃圾回收机制吗 - 掘金 (juejin.cn)

一文带你快速掌握V8的垃圾回收机制 - 掘金 (juejin.cn)

[深入浅出]JavaScript GC 垃圾回收机制 - 掘金 (juej

面试经历

（后来别人跟我说这种写法nacos里也常见）

记录一次面试经历

2023.06.01

美团海笔的，本来以为笔的情况也不咋好 看到牛客网上一堆ak说没面试机会的

结果也不知怎地到了一面

（略过自我介绍和项目介绍~）

面试官：会写单例吗，写个单例看看

我：

// 饿汉式

public class SingleObject {

   private static SingleObject instance = new SingleObject();

 

   //让构造函数为 private

   private SingleObject(){}



   public static SingleObject getInstance(){

      return instance;

   }

}

面试官：嗯 你这个单例在没有引用的时候就创建了对象？优化一下

我：应该是懒汉模式！

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        // 多了一个判断是否为null的过程

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

面试官：你这个线程不安全啊 再优化一下？

我：那就加个锁吧

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

    public static synchronized Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

面试官：这种写法 多线程来了的话会阻塞在一起 能否再优化？

我：。。。 不会了

面试官：回去看看双检锁单例

···

之后问了数据库事务

1. 读未提交（read uncommitted）


2. 读已提交（read committed）


3. 可重复读（repeatable read）


4. 序列化（serializable）以及默认是哪个（repeatable read） 、

数据库的范式了解吗 等等

不出意外：

还是非常可惜的 这次机会 再加油吧

单例模式整理

学习自菜鸟教程

1.饿汉式

懒加载 no
多线程安全 yes
缺点：没有实现懒加载，即还未调用就创建了对象

public class Singleton {  

    private static Singleton instance = new Singleton();  

    private Singleton (){}  

    public static Singleton getInstance() {  

    return instance;  

    }  

}

2.懒汉式（线程不安全）

懒加载 yes
多线程安全 no

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

3.懒汉式（线程安全）

懒加载 yes
多线程安全 yes
缺点：和面试官说的那样，多线程访问会阻塞

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

4.双检锁/双重校验锁（DCL，即 double-checked locking）

public class Singleton {  

    private volatile static Singleton singleton;  

    private Singleton (){}  

    public static Singleton getSingleton() {  

    if (singleton == null) {  

        synchronized (Singleton.class) {  

            if (singleton == null) {  

                singleton = new Singleton();  

            }  

        }  

    }  

    return singleton;  

    }  

}

这段代码是一个单例模式的实现，使用了双重检查锁定的方式来保证线程安全和性能。双重检查锁定是指在加锁前后都进行了一次判空的操作，以避免不必要的加锁操作。

而为了保证双重检查锁定的正确性，需要使用volatile关键字来修饰singleton变量，以禁止指令重排序优化。（JUC的知识串起来了！）如果没有volatile关键字修饰，可能会出现一个线程A执行了new Singleton()但是还没来得及赋值给singleton，而此时另一个线程B进入了第一个if判断，判断singleton不为null，于是直接返回了一个未初始化的实例，导致程序出错。

使用volatile关键字可以确保多线程环境下的可见性和有序性，即一个线程修改了singleton变量的值，其他线程能够立即看到最新值，并且编译器不会对其进行指令重排序优化。这样就能够保证双重检查锁定的正确性。

学到了 ！！！

后来别人提醒：

（牛逼。。）

5.登记式/静态内部类

public class Singleton {  

    private static class SingletonHolder {  

    private static final Singleton INSTANCE = new Singleton();  

    }  

    private Singleton (){}  

    public static final Singleton getInstance() {  

        return SingletonHolder.INSTANCE;  

    }  

}

这段代码是一个单例模式的实现，使用了静态内部类的方式来保证线程安全和性能。静态内部类是指在外部类中定义一个静态的内部类，该内部类可以访问外部类的所有静态成员和方法，但是外部类不能访问内部类的成员和方法。

在这个单例模式的实现中，SingletonHolder就是一个静态内部类，它里面定义了一个静态的、final的、类型为Singleton的变量INSTANCE。由于静态内部类只有在被调用时才会被加载，因此INSTANCE对象也只有在getInstance()方法被调用时才会被初始化，从而实现了懒加载的效果。

由于静态内部类的加载是线程安全的，因此不需要加锁就可以保证线程安全。同时，由于INSTANCE是静态final类型的，因此保证了它只会被实例化一次，并且在多线程环境下也能正确地被发布和共享。

这种方式相对于双重检查锁定来说更加简单和安全，因此在实际开发中也比较常用。

6. 枚举

public enum Singleton {  

    INSTANCE;  

    public void whateverMethod() {  

    }  

}

这段代码是使用枚举类型实现单例模式的一种方式。在Java中，枚举类型是天然的单例，因为枚举类型的每个枚举值都是唯一的，且在类加载时就已经被初始化。

在这个示例代码中，Singleton是一个枚举类型，其中只定义了一个枚举值INSTANCE。由于INSTANCE是一个枚举值，因此它在类加载时就已经被初始化，并且保证全局唯一。在使用时，可以通过Singleton.INSTANCE来获取该单例对象。

需要注意的是，虽然枚举类型天然的单例特性可以保证线程安全和反序列化安全，但是如果需要延迟初始化或者有其他特殊需求，仍然需要使用其他方式来实现单例模式。

7. 容器式单例

Java中可以使用容器来实现单例模式，比如使用Spring框架中的Bean容器。下面是一个使用Spring框架实现单例的示例代码：

1. 定义一个单例类，比如MySingleton：

public class MySingleton {

    private static MySingleton instance;

    private MySingleton() {}

    public static MySingleton getInstance() {

        if (instance == null) {

            instance = new MySingleton();

        }

        return instance;

    }

    public void doSomething() {

        // do something

    }

}

2. 在Spring的配置文件中定义该类的Bean：

<bean id="mySingleton" class="com.example.MySingleton" scope="singleton"/>

3. 在Java代码中获取该Bean：

ApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");

MySingleton mySingleton = (MySingleton) context.getBean("mySingleton");

mySingleton.doSomething();

在上面的代码中，我们在Spring的配置文件中定义了一个名为mySingleton的Bean，它的类是com.example.MySingleton，作用域为singleton（即单例）。然后在Java代码中，我们通过ApplicationContext获取该Bean，并调用它的doSomething()方法。

使用Spring框架可以方便地管理单例对象，同时也可以很容易地实现依赖注入和控制反转等功能。

总结完成 继续加油！！！

前言

最近，在逛一些技术群时，看到有人在吐槽，这个video媒体标签设置autoplay属性怎么不生效。不生效就算了，为什么我在dom渲染完成时去获取video元素（假设获取到的元素为el），然后执行el.paly()也不生效，why？？？？

那为什么我通过控制台去执行这两行代码的时候，它又生效了！！！！？？？

带着满脸疑惑，我们来了解一下浏览器的自动播放策略。

1、浏览器的自动播放策略

以谷歌浏览器为例：

在某些特定的情况下，浏览器是允许自动播放的：

1. 
   

   静音状态下始终允许自动播放

   
   


2. 
   

   有声音自动播放时：

   
   
   
   
   • 用户进行了页面点击等与界面发生交互行为后。
   
   
   • 达到媒体参与指数, 也就是用户之前在本站播放过有声音的视频。
   
   
   • 用户将页面添加到移动设备的主屏幕上或者在PC上安装了PWA。
   
   
   
   


3. 
   

   主站可以将自动播放权限委托给它们的 iframe，以允许自动播放声音。

   
   

2、静音播放。

在静音状态下，浏览器是允许自动播放的，代码如下：

<video controls class="videoItem" width="100%" autoplay muted loop="loop" src="./tets.mp4"></video>

属性说明：

muted: 是否静音播放，默认为false。

autoplay：是否自动播放，默认为false。

control：控制器是否显示，默认为false（可不写）。

loop：是否循环播放，默认为false（可不写）。

唉，好像可以自动播放了，于是我拿去应付产品，产品给我泼了一盆冷水，说能让它播放起来有声音吗？
。
于是，又开始了我们的与非静音状态自动播放功能的探索。

3、非静音自动播放

我们在上面有了解到非静音自动播放有四种情况：

1. 用户进行了页面点击等与界面发生交互行为后。


2. 达到媒体参与指数MEI.


3. 用户将页面添加到移动设备的主屏幕上或者在PC上安装了PWA。


4. 主站可以将自动播放权限委托给它们的 iframe。

3.1 用户进行了页面交互行为

这个就可以理解成用户触碰了页面之后，我们就可以进行有声音的自动播放了。看代码

HTML部分：

<video controls class="videoItem" width="100%"  loop="loop" src="./tets.mp4"></video>

JS部分：

const vdo = document.querySelector('video')

// 播放函数

async function playAudio() {

    const res = await vdo.play()

}

// 监听用户点击

document.addEventListener('click',playAudio)

// 监听媒体播放

vdo.addEventListener('play', function () { //播放开始执行的函数

    console.log("开始播放");

    // 移除点击监听事件

    document.removeEventListener("click",playAudio)

})

这里我们就有很大的发挥空间了，比如说视频不完全在可见区，或者用户看视频前给他弹个框？

3.2 达到媒体参与指数MEI

MEI是浏览器根据我们对一些网站的浏览行为打分，越高，就表示我们喜欢观看这个网站的视频，可以通过about://media-engagement来查询，不可更改。
注意：该策略只对PC端浏览器有效。

3.3 用户将页面添加到移动设备的主屏幕上或者在PC上安装了PWA。

用户将页面添加到移动设备的主屏幕上或者在PC上安装了PWA，这个我们基本可以不用去考虑了，在国内是比较少见的，感兴趣的可以去百度。

3.4 主站可以将自动播放权限委托给它们的 iframe。

这个就是通过iframe来控制媒体的自动播放。代码如下：

    <!-- 允许自动播放 -->

    <iframe src="跨源地址" allow="autoplay">



    <!-- 允许自动播放和设置全屏 -->

    <iframe src="跨源地址" allow="autoplay; fullscreen">

需要注意的是，我们可能需要做一些本地代理，不然可能会出现跨域问题。

4 补充

上面还有一点是没有提到的，就是同源下点击页面跳转后可实现自动播放。

比如：我在http://www.bilibili.com页面点击一个视频跳转到了一个新页面，就可以实现自动播放（注意：不能打开新窗口，否则非

前言

来自一个普通人的思考和分享，由于水平有限，认知有限，活动受限，观点可能也有个人偏见，不喜勿喷哈

欢迎JYM一起交流探讨人生、生人、上天，入地、活着、归去、等所有 法律允许， 社区允许 的开放性话题

自我介绍

一个普通人，坐标帝都，小厂前端攻城狮，每天奋斗在一线，时不时加班1-3个小时，工作地在西北 4 环，家住东 6 环，由于每天 10 环极限通勤, 下班到家就是一副有气无力的死狗样，妥妥的一个社畜。

第二天早上又是元气满满的一天，精力充沛的出门去打拼，都是为了活着……

基于周围的一些社会现状，分享一些自己的思考

1. 
   

   追剧看视频的人，好多人使用的 1.25倍速，1.5倍速；漫无目的不停的刷着各种短视频，不停的快速的往下翻着；在手机上不停的翻看着微博，朋友圈，群记录等。

   
   

   
   

   仿佛什么都看了，又仿佛什么都没看 😟

   
   

   
   


2. 
   

   经常手机上明明没有任何消息，总是打开翻两下，再息屏。

   
   

   
   

   似乎不想错过一些联系，又仿佛没有人联系。手机让我们通信更方便了，仿佛也让我们更孤独了 😕

   
   

   
   


3. 
   

   多少人每天睡醒的第一件事就是打开手机，从起床开始，看手机朋友圈，看热搜，看头条，看推送，看信息，看邮件，吃饭看手机，走路看手机，去上班路上看手机，站着看，躺着看，坐着看，拉便便也看。 最终得到了什么？得到了焦虑、暴躁、前倾的颈椎、渐厚的镜片，还有熬夜留下的黑眼圈......

   
   


4. 
   

   我们常常抽时间刷微博、看热搜和刷短视频，但却难以每天保持锻炼身体、系统学习和读几页书，以及坚持做一些微小的事情去发现自己的兴趣爱好。

   
   

   
   

   智能手机的发展，让我们变的浮躁，静不下来，似乎也停不下来 🧐

   
   

   这是一个互联网高度发达的时代，一个被算法支配的时代，一个缺少自我主动支配时间的时代，智能手机的发展给我们的生活带来了翻天覆地的变化，方便了出行、支付、交流等等，在带来极大便利的同时，我们也付出了代价，好多时候我感觉自己就是一副没有灵魂的躯壳。

   
   

   
   

   

   
   


5. 
   

   有些社区文章和公众号文章的标题，短短几个字，让人莫名产生焦虑感。

   
   
   
   
   • 
     

     最新大厂热乎面经，已拿offer

     
     
   
   
   • 
     

     前某大厂某高级别大牛带你xxxx

     
     
   
   
   • 
     

     大厂是怎么xxx

     
     
   
   
   • 
     

     都202x年了，你还不会xxx

     
     
   
   
   
   

   
   

   曾几何时，看到这种标题，我抱着学习提升跟上时代的想法，点击进去，发现好多是广告，卖课的，要么就是一些同质化的内容，无语翻倍...

   
   

   这是最好的时代，也是最坏的时代，好多人靠贩卖焦虑就能赚大钱，新闻自媒体靠一个标题就能吸引流量

   
   

   不知道什么时候想通了，承认自己是个普通人，工作只是我们活着的一种手段，每天过的开不开心，家庭幸不幸福和在哪上班收入多少有啥关系？

   
   

   该吃吃，该喝喝，有事儿别往心里搁，哟！今天天气真不错，开心 😁

   
   

   
   


6. 
   

   在疫情时代，看着工作机会减少了，生意不好做了，时代在变化，疫情时代干掉了一些工作，但是疫情核酸检测员，核酸检查站多了，保安也多了，疫情相关产业链上的工作岗位增多了。

   
   


7. 
   

   ChatGPT、AIGC 爆火的这段时间，好多文章以及社区之类的，大家都在讨论 AI，这时候各种 AI 峰会，线下交流会哪哪都爆满，AI 相关的培训也热的不行，仿佛搭不上 AI 这趟车，我们就会被马上淘汰一样。

   
   

   
   

   任何一个时代的变革，淘汰一些工作的同时，催生了大量新的岗位，跟上时代，时刻 "刷新" 自己，我已经想好了，什么时候 AI 能完全替代我这个前端工程师了，那时候我也不敲代码了，解脱！

   
   

   AI 快来解放我吧 😜

   
   

   
   

总的来看，我的焦虑感是由环境因素和心理因素共同作用的结果

既然知道了焦虑感产生的原因，也就相对好解决了，毕竟只是尽量减少自己的焦虑感

我尝试做了这些有趣而正向的东西，发现效果还不错

1. 例如有时会用碎片时间记个单词，dogsbody n.打工人;杂役 累的像狗，身体被掏空的就是打工人了, 是不是一下子就记住了呢？

2. 每周抽时间运动，目前是每周末早上去跑步，一般5-8公里。偶尔也在公司的健身区举举铁。个人比较喜欢跑步，跑到一定公里数的时候，心脏加快跳动，血液流动更畅通，还有夏天室外奔跑汗流浃背的感觉。感觉整个人都更轻松了，心情也会变好。我愿意坚持运动，享受运动过程中的愉悦感和得到放松的身体。

来看看我今年的跑步数据：

3. 无意间发现了一款乐器 -- 非洲手鼓，当时被这个手鼓颜值给吸引了，然后就果断入手一只。目前可以跟着《桥边姑娘》的节奏拍下来， 暖阳下 我迎芬芳 是谁家的姑娘，我走在了那座小桥上 你抚琴奏忧伤…… ，是不是有画面了，我跟着节奏去敲手鼓的时候，使我沉浸在这个音乐中，这首音乐有了参与感，对音乐有了更近一步的了解。

4. 
   

   在家的时候，如果没什么事情，我会把手机“藏”起来，让自己不那么容易看到手机，有空就看会书或者望着窗外发呆，刚看完村上春树的《当我谈跑步时我谈些什么》，看书的过程会感到很平静

   
   


5. 
   

   地铁路上由于通勤时间太久，有时候会闭目养神，尽量让自己少看手机，想一下今天有什么工作没完成，或者计划做点什么事情，让大脑活跃一下。我还把手机上总是发广告的那种公众号，总贩卖焦虑的那些自媒体取关了，不管他(她)是什么行业大佬，还是什么专业XXX，尝试远离他(她)们，发现世界慢慢变的更清净了