最近在教授前端小白学员编写一些简单的网页。在这个过程中发现了小白们比较容易遇到的一些问题或者坏习惯，在这里对它们进行一一解释。

文件名命名

有些学员的文件命名是这样的：

除了网页的内容外，所有的东西都应该用英文，而不是拼音。

原因有如下几点：

1. 编程不是一个人的活动，是群体活动。我们使用的编程语言、框架和库，几乎全部都是英文。使用中文，你的协作者会难以理解你的代码。而且中英混搭会让代码阅读困难。


2. 使用拼音和使用汉字基本上没有什么区别，甚至还不如汉字直观。


3. 拼音很难加音标，而且即使能加音标，也很难表达真正的意思，因为同音词太多，它存在多义性，比如 heshui，你不知道它到底是在表达喝水还是河水。


4. 使用拼音会让你显得非常不专业。


5. 坚持使用英文编程，有利于提高英语水平。

如果英语不好，刚开始可能会难以忍受，但是一旦熬过去开始这段时间，坚持下来，将会是长期的回报。

如果你英语实在是非常差劲，可以借助一些翻译软件。比如世界上最好的翻译网站：translate.google.com/，虽然是 Google 的域名，但是大陆并没有墙。

不止是文件名，变量、函数等事物都应该使用英文命名。

使用英语，越早越好。

文件类型命名

有些同学的文件命名是这样的：

文件命名的问题上面已经解释了，这里主要来看文件后缀名的问题。

应该使用小写 .htm/.html 结尾。

原因有如下几点：

1. 不同的操作系统处理大小写是不一样的。Windows/Mac 系统大小写不敏感，Linux 系统大小写敏感。统一命名方式会具有更好的移植性。

比如我们有如下目录结构：

├── cat.html

├── dog.html

下面的代码在 Mac/Windows 系统上正常。

<a href="./Dog.html">跳转到狗的页面</a>

但是在 Linux 系统上会出现 404。

我们开发时通常是在 Mac/Windows 系统，这时问题很难暴露，但是部署时通常是在 Linux 系统，就容易导致开发时正常，部署时异常的不一致性。

2. 易读性，事实证明小写的单词更易于阅读。


3. 便捷性，文件名和后缀名都保持小写，不需要额外按下 Shift 键了。


4. htm 和 html 的区别是，在老的 DOS 系统上，文件后缀名最多只支持 3 位。所以很多语言都会把文件后缀名限制成 3 位以内。现在的操作系统已经没有这个问题了，所以 htm 和 html 的作用是完全一致的。如果你追求简洁一点，那么使用 htm 时完全没问题的。

代码格式化

有些同学的代码是这样的：

VSCode 提供了 prettier 插件，我们可以使用它对代码格式化。

代码格式化有以下优点：

1. 代码格式化后更易于阅读和修改。比如它会自动帮你添加空格、对齐、换行等。


2. 不需要去刻意学习代码样式了，代码格式化工具会帮你做好，并且在这个过程中你会潜移默化的学会怎么样调整代码样式。


3. 使用统一的代码格式化，可以帮助大家在协作时保持一致，不会有比必要的争议。


4. 新人加入项目时也可以更容易地融入到项目，不会看到风格迥异的代码。


5. 在代码合并的时候也可以减少冲突的发生。

建议一定要开启代码格式化。

补充说明

这部分和文章内容无关，是针对评论区进行补充。

掘金没有评论置顶功能，我没办法逐一回复评论区。所以只能在文末进行统一解释。

很多人在评论区说本文水，或者在拿拼音的事情抬杠。本来我不想解释，但是负面评论的人确实不少。

我说两点。

第一，文章标题开头四字明确表明目标群体是前端小白，小白是什么概念能明白吗？一定是「xxx源码解读」才是干货硬货？

第二，关于中文好还是英文好，我不想继续争论。我从业多年，看过无数项目源码，从后端 Java JDBC、Spring、JVM、Go 到前端 React、Redux、Webpack、Babel，无一例外全是英文。或者你随便找个初具规模的互联网中大厂或者外企的程序员，看看他们公司是不是有不让用拼音和汉字的规范。

程序员群体普遍的毛病就是固执己见。永远只是站在自己的视角去观察世界，看到的永远都是自己想看到的。然后去贸然指责，这样真的会显得自己很没有修养，而且很无知。

哪怕做不到感同身受，也应该给予应有的尊重，哪怕难以理解，也不要随意贬低。这是做人的基本修养。

掘金是技术分享平台，不是贴吧/知乎。我写文章的本心只是分享内容，没有收各位一分钱。

文章内容对你有价值的话，非常感谢你的点赞支持。

文章内容对你无用的话，退出去就好了。

言尽于此。

能看懂就看，再看不懂就直接屏蔽我吧，谢谢配合。

最后希望掘金能推出文章评论置顶功能，或者文章禁止评论功能。这对创作者来说绝对是刚需。

Spring Boot 3.1.0-M1 已经发布一段时间了，不知道各位小伙伴是否关注了。随着Spring 6.0以及SpringBoot 3.0的发布，整个开发界也逐步进入到jdk17的时代。大有当年从jdk6 到jdk8升级过程，痛苦并快乐着。

为了不被时代抛弃，开发者应追逐新的技术发展，拥抱变化，不要固步自封。

0x01 纵观发展

• 
  

  Pre-alpha（Dev）指在软件项目进行正式测试之前执行的所有活动

  
  


• 
  

  LTS（Long-Term Support）版本指的是长期支持版本

  
  


• 
  

  Alpha 软件发布生命周期的alpha阶段是软件测试的第一阶段

  
  


• 
  

  Beta阶段是紧随alpha阶段之后的软件开发阶段，以希腊字母第二个字母命名

  
  


• 
  

  Release candidate 发行候选版（RC），也被称为“银色版本”，是具备成为稳定产品的潜力的 beta 版本，除非出现重大错误，否则准备好发布

  
  


• 
  

  Stable release 稳定版又称为生产版本，是通过所有验证和测试阶段的最后一个发行候选版（RC）

  
  


• 
  

  Release 一旦发布，软件通常被称为“稳定版”

  
  

下面我们来看下JDK9~JDK17的发展：

需要注意的是，LTS 版本的支持时间可能会受到 Oracle 官方政策变化的影响，因此表格中的支持时间仅供参考。

0x02 详细解读

JDK9 新特性

JDK 9 是 Java 平台的一个重大版本，于2017年9月发布。它引入了多项新特性，其中最重要的是模块化系统。以下是 JDK 9 新增内容的详细解释：

1. 模块化系统（Jigsaw）：

Jigsaw 是 JDK 9 引入的一个模块化系统，它将 JDK 拆分为约 90 个模块。这些模块相互独立，可以更好地管理依赖关系和可见性，从而提高了代码的可维护性和可重用性。模块化系统还提供了一些新的工具和命令，如 jmod 命令和 jlink 命令，用于构建和组装模块化应用程序。

2. JShell：

JShell 是一个交互式的 Java 命令行工具，可以在命令行中执行 Java 代码片段。它可以非常方便地进行代码测试和调试，并且可以快速地查看和修改代码。JShell 还提供了一些有用的功能，如自动补全、实时反馈和历史记录等。

3. 接口的私有方法：

JDK 9 允许在接口中定义 private 和 private static 方法。这些方法可以被接口中的其他方法调用，但不能被实现该接口的类使用。这样可以避免在接口中重复编写相同的代码，提高了代码的重用性和可读性。

4. 改进的 try-with-resources：

在 JDK 9 中，可以在 try-with-resources 语句块中使用 final 或 effectively final 的变量。这样可以避免在 finally 语句块中手动关闭资源，提高了代码的可读性和可维护性。

5. 集合工厂方法：

JDK 9 提供了一系列工厂方法，用于创建 List、Set 和 Map 等集合对象。这些方法可以使代码更加简洁和易读，而且还可以为集合对象指定初始容量和类型参数。

6. 改进的 Stream API：

JDK 9 引入了一些新的 Stream API 方法，如 takeWhile、dropWhile 和 ofNullable 等。takeWhile 和 dropWhile 方法可以根据指定的条件从流中选择元素，而 ofNullable 方法可以创建一个包含一个非空元素或空元素的 Stream 对象。

除了以上几个新特性，JDK 9 还引入了一些其他的改进和优化，如改进的 Stack-Walking API、改进的 CompletableFuture API、Java 应用程序启动时优化（Application Class-Data Sharing）等等。这些新特性和改进都为 Java 应用程序的开发和运行提供了更好的支持。

JDK10 新特性

JDK10是JDK的一个短期支持版本，于2018年3月发布。它的主要特性如下：

1. 
   

   局部变量类型推断：Java 10中引入了一种新的语法——var关键字，可以用于推断局部变量的类型，使代码更加简洁。例如，可以这样定义一个字符串类型的局部变量：var str = "hello"。

   
   


2. 
   

   G1 垃圾回收器并行全阶段：JDK10中对G1垃圾回收器进行了改进，使其可以在并行全阶段进行垃圾回收，从而提高了GC效率。

   
   


3. 
   

   应用级别的 Java 类数据共享：Java 10中引入了一项新的特性，即应用级别的 Java 类数据共享（AppCDS），可以在多个JVM进程之间共享Java类元数据，从而加速JVM的启动时间。

   
   


4. 
   

   线程局部握手协议：Java 10中引入了线程局部握手协议（Thread-Local Handshakes），可以在不影响整个JVM性能的情况下，暂停所有线程执行特定的操作。

   
   


5. 
   

   其他改进：Java 10还包含一些其他的改进，例如对Unicode 10.0的支持，对时间API的改进，以及对容器API的改进等等。

   
   

总的来说，JDK10主要关注于提高Java应用程序的性能和可维护性，通过引入一些新的特性和改进对JDK进行优化。

JDK11 新特性

JDK11是JDK的一个长期支持版本，于2018年9月发布。它的主要特性如下：

1. 
   

   HTTP 客户端 API：Java 11中引入了一个全新的HTTP客户端API，可以用于发送HTTP请求和接收HTTP响应，而不需要依赖第三方库。

   
   


2. 
   

   ZGC 垃圾回收器：Java 11中引入了ZGC垃圾回收器（Z Garbage Collector），它是一种可伸缩且低延迟的垃圾回收器，可以在数百GB的堆上运行，且最大停顿时间不超过10ms。

   
   


3. 
   

   移除Java EE和CORBA模块：Java 11中移除了Java EE和CORBA模块，这些模块在Java 9中已被标记为“过时”，并在Java 11中被完全移除。

   
   


4. 
   

   Epsilon垃圾回收器：Java 11中引入了一种新的垃圾回收器，称为Epsilon垃圾回收器，它是一种无操作的垃圾回收器，可以在不进行垃圾回收的情况下运行应用程序，适用于测试和基准测试等场景。

   
   


5. 
   

   其他改进：Java 11还包含一些其他的改进，例如对Lambda参数的本地变量类型推断，对字符串API的改进，以及对嵌套的访问控制的改进等等。

   
   

总的来说，JDK11主要关注于提高Java应用程序的性能和安全性，通过引入一些新的特性和改进对JDK进行优化。其中，HTTP客户端API和ZGC垃圾回收器是最值得关注的特性之一。

JDK12 新特性

JDK12是JDK的一个短期支持版本，于2019年3月发布。它的主要特性如下：

1. 
   

   Switch 表达式：Java 12中引入了一种新的Switch表达式，可以使用Lambda表达式风格来简化代码。此外，Switch表达式也支持返回值，从而可以更方便地进行流程控制。

   
   


2. 
   

   Microbenchmark Suite：Java 12中引入了一个Microbenchmark Suite，可以用于进行微基准测试，从而更好地评估Java程序的性能。

   
   


3. 
   

   JVM Constants API：Java 12中引入了JVM Constants API，可以用于在运行时获取常量池中的常量，从而更好地支持动态语言和元编程。

   
   


4. 
   

   Shenandoah 垃圾回收器：Java 12中引入了Shenandoah垃圾回收器，它是一种低暂停时间的垃圾回收器，可以在非常大的堆上运行，且最大暂停时间不超过几毫秒。

   
   


5. 
   

   其他改进：Java 12还包含一些其他的改进，例如对Unicode 11.0的支持，对预览功能的改进，以及对集合API的改进等等。

   
   

总的来说，JDK12主要关注于提高Java应用程序的性能和可维护性，通过引入一些新的特性和改进对JDK进行优化。其中，Switch表达式和Shenandoah垃圾回收器是最值得关注的特性之一。

JDK13 新特性

JDK13是JDK的一个短期支持版本，于2019年9月发布。它的主要特性如下：

1. 
   

   Text Blocks：Java 13中引入了一种新的语法，称为Text Blocks，可以用于在代码中编写多行字符串，从而简化代码编写的复杂度。

   
   


2. 
   

   Switch 表达式增强：Java 13中对Switch表达式进行了增强，支持多个表达式和Lambda表达式。

   
   


3. 
   

   ZGC 并行处理引用操作：Java 13中对ZGC垃圾回收器进行了改进，支持并行处理引用操作，从而提高了GC效率。

   
   


4. 
   

   Reimplement the Legacy Socket API：Java 13中重新实现了Legacy Socket API，从而提高了网络编程的性能和可维护性。

   
   


5. 
   

   其他改进：Java 13还包含一些其他的改进，例如对预览功能的改进，对嵌套访问控制的改进，以及对集合API的改进等等。

   
   

总的来说，JDK13主要关注于提高Java应用程序的性能和可维护性，通过引入一些新的特性和改进对JDK进行优化。其中，Text Blocks和Switch表达式增强是最值得关注的特性之一。

JDK14 新特性

JDK14是JDK的一个短期支持版本，于2020年3月发布。它的主要特性如下：

1. 
   

   Records：Java 14中引入了一种新的语法，称为Records，可以用于定义不可变的数据类，从而简化代码编写的复杂度。

   
   


2. 
   

   Switch 表达式增强：Java 14中对Switch表达式进行了增强，支持使用关键字 yield 返回值，从而可以更方便地进行流程控制。

   
   


3. 
   

   Text Blocks增强：Java 14中对Text Blocks进行了增强，支持在Text Blocks中嵌入表达式，从而可以更方便地生成动态字符串。

   
   


4. 
   

   Pattern Matching for instanceof：Java 14中引入了一种新的语法，称为Pattern Matching for instanceof，可以用于在判断对象类型时，同时对对象进行转换和赋值。

   
   


5. 
   

   其他改进：Java 14还包含一些其他的改进，例如对垃圾回收器和JVM的改进，对预览功能的改进，以及对JFR的改进等等。

   
   

总的来说，JDK14主要关注于提高Java应用程序的可维护性和易用性，通过引入一些新的特性和改进对JDK进行优化。其中，Records和Pattern Matching for instanceof是最值得关注的特性之一。

JDK15 新特性

JDK15是JDK的一个短期支持版本，于2020年9月发布。它的主要特性如下：

1. 
   

   Sealed Classes：Java 15中引入了一种新的语法，称为Sealed Classes，可以用于限制某个类的子类的数量，从而提高代码的可维护性。

   
   


2. 
   

   Text Blocks增强：Java 15中对Text Blocks进行了增强，支持在Text Blocks中使用反斜杠和$符号来表示特殊字符，从而可以更方便地生成动态字符串。

   
   


3. 
   

   Hidden Classes：Java 15中引入了一种新的类，称为Hidden Classes，可以在运行时动态创建和卸载类，从而提高代码的灵活性和安全性。

   
   


4. 
   

   ZGC并发垃圾回收器增强：Java 15中对ZGC垃圾回收器进行了增强，支持在启动时指定内存大小，从而提高了GC效率。

   
   


5. 
   

   其他改进：Java 15还包含一些其他的改进，例如对预览功能的改进，对JVM和垃圾回收器的改进，以及对集合API和I/O API的改进等等。

   
   

总的来说，JDK15主要关注于提高Java应用程序的可维护性和性能，通过引入一些新的特性和改进对JDK进行优化。其中，Sealed Classes和Hidden Classes是最值得关注的特性之一。

JDK16 新特性

JDK16是JDK的一个短期支持版本，于2021年3月发布。它的主要特性如下：

1. 
   

   Records增强：Java 16中对Records进行了增强，支持在Records中定义静态方法和构造方法，从而可以更方便地进行对象的创建和操作。

   
   


2. 
   

   Pattern Matching for instanceof增强：Java 16中对Pattern Matching for instanceof进行了增强，支持在判断对象类型时，同时对对象进行转换和赋值，并支持对switch语句进行模式匹配。

   
   


3. 
   

   Vector API：Java 16中引入了一种新的API，称为Vector API，可以用于进行SIMD（Single Instruction Multiple Data）向量计算，从而提高计算效率。

   
   


4. 
   

   JEP 388：Java 16中引入了一个新的JEP（JDK Enhancement Proposal），称为JEP 388，可以用于提高Java应用程序的性能和可维护性。

   
   


5. 
   

   其他改进：Java 16还包含一些其他的改进，例如对垃圾回收器、JVM和JFR的改进，对预览功能的改进，以及对集合API和I/O API的改进等等。

   
   

总的来说，JDK16主要关注于提高Java应用程序的性能和可维护性，通过引入一些新的特性和改进对JDK进行优化。其中，Records增强和Pattern Matching for instanceof增强是最值得关注的特性之一。

JDK17 新特性

JDK17是JDK的一个长期支持版本，于2021年9月发布。它的主要特性如下：

1. 
   

   Sealed Classes增强：Java 17中对Sealed Classes进行了增强，支持在Sealed Classes中定义接口和枚举类型，从而提高代码的灵活性。

   
   


2. 
   

   Pattern Matching for switch增强：Java 17中对Pattern Matching for switch进行了增强，支持在switch语句中使用嵌套模式和or运算符，从而提高代码的可读性和灵活性。

   
   


3. 
   

   Foreign Function and Memory API：Java 17中引入了一种新的API，称为Foreign Function and Memory API，可以用于在Java中调用C和C++的函数和库，从而提高代码的可扩展性和互操作性。

   
   


4. 
   

   JEP 391：Java 17中引入了一个新的JEP（JDK Enhancement Proposal），称为JEP 391，可以用于提高Java应用程序的性能和可维护性。

   
   


5. 
   

   其他改进：Java 17还包含一些其他的改进，例如对垃圾回收器、JVM和JFR的改进，对预览功能的改进，以及对集合API和I/O API的改进等等。

   
   

总的来说，JDK17主要关注于提高Java应用程序的灵活性、可扩展性和性能，通过引入一些新的特性和改进对JDK进行优化。其中，Sealed Classes增强和Foreign Function and Memory API是最值得关注的特性之一。

总结

• 
  

  JDK9：引入了模块化系统、JShell、私有接口方法、多版本兼容性等新特性

  
  


• 
  

  JDK10：引入了局部变量类型推断、垃圾回收器接口、并行全垃圾回收器等新特性

  
  


• 
  

  JDK11：引入了ZGC垃圾回收器、HTTP客户端API、VarHandles API等新特性

  
  


• 
  

  JDK12：引入了Switch表达式、新的字符串方法、HTTP/2客户端API等新特性

  
  


• 
  

  JDK13：引入了Text Blocks、Switch表达式增强、改进的ZGC性能等新特性

  
  


• 
  

  JDK14：引入了Records、Switch表达式增强、Pattern Matching for instanceof等新特性

  
  


• 
  

  JDK15：引入了Sealed Classes、Text Blocks增强、Hidden Classes等新特性

  
  


• 
  

  JDK16：引入了Records增强、Pattern Matching for instanceof增强、Vector API等新特性

  
  


• 
  

  JDK17：引入了Sealed Classes增强、Pattern Matching for switch增强、Foreign Function and Memory API等新特性

  
  

总的来说，JDK9到JDK17的更新涵盖了Java应用程序开发的各个方面，包括模块化、垃圾回收、性能优化、API增强等等，为Java开发者提供了更多的选择和工具，以提高代码的质量和效率

小记

Java作为一门长盛不衰的编程语言，未来的发展仍然有许多潜力和机会。

• 
  

  云计算和大数据：随着云计算和大数据的发展，Java在这些领域的应用也越来越广泛。Java已经成为了许多云计算平台和大数据处理框架的首选语言之一。

  
  


• 
  

  移动端和IoT：Java也逐渐开始在移动端和物联网领域崭露头角。Java的跨平台特性和安全性，使得它成为了许多移动应用和物联网设备的首选开发语言。

  
  


• 
  

  前沿技术的应用：Java社区一直在积极探索和应用前沿技术，例如人工智能、机器学习、区块链等。Java在这些领域的应用和发展也将会是未来的趋势。

  
  


• 
  

  开源社区的发展：Java开源社区的发展也将会对Java的未来产生重要影响。Java社区的开源项目和社区贡献者数量不断增加，将会为Java的发展提供更多的动力和资源。

  
  


• 
  

  新的Java版本：Oracle已经宣布将在未来两年内发布两个新的Java版本，其中一个是短期支持版本，另一个是长期支持版本。这将会为Java开发者提供更多的新特性和改进，以满足不断变化的需求。

  
  

总的来说，Java作为一门优秀的编程语言，具有广泛的应用和发展前景。随着技术的不断创新和社区的不断发展，Java的未来将会更加光明。

更多内容:

🤭当我是if-else侠的时候

😶怕出错

给我一个功能，我总是要写很多if-else,虽然能跑，但是维护起来确实很难受，每次都要在一个方法里面增加逻辑，生怕搞错，要是涉及到支付功能，分分钟炸锅

😑难调试

我总是不知道之前写的逻辑在哪里，一个方法几百行逻辑，而且是不同功能点冗余在一起！这可能让我牺牲大量时间在这查找调试中

🤨交接容易挨打

当你交接给新同事的时候，这个要做好新同事的白眼和嘲讽，这代码简直是坨翔！这代码简直是个易碎的玻璃，一碰就碎！这代码简直是个世界十大奇迹！

🤔脱下if-else侠的皮衣

先学习下开发的设计原则

单一职责原则(SRP)

就一个类而言，应该仅有一个引起他变化的原因

开放封闭原则(ASD)

类、模块、函数等等应该是可以扩展的，但是不可以修改的

里氏替换原则(LSP)

所有引用基类的地方必须透明地使用其子类的对象

依赖倒置原则(DIP)

高层模块不应该依赖底层模块

迪米特原则(LOD)

一个软件实体应当尽可能的少与其他实体发生相互作用

接口隔离原则(ISP)

一个类对另一个类的依赖应该建立在最小的接口上

在学习下设计模式

大致可以分三大类：创建型，结构型，行为型

创建型：工厂模式 ，单例模式，原型模式

结构型：装饰器模式，适配器模式，代理模式

行为型：策略模式，状态模式，观察者模式

为了尽快脱掉这个if-else的皮衣，我们就先学习一种比较容易接受的设计模型：策略模式

策略模式

举个例子

• 当购物类型为“苹果”时，满 100 - 20，不满 100 打 9 折


• 当购物类型为“香蕉”时，满 100 - 30，不满 100 打 8 折


• 当购物类型为“葡萄”时，满 200 - 50，不叠加


• 当购物类型为“梨”时，直接打 5 折
  
  然后你根据传入的类型和金额，写一个通用逻辑出来,
  当我是if-else侠的时候，我估计会这样写：

funcion getPrice(type,money)

  //处理苹果

   if(type == 'apple'){

     if(money >= 100){

       return money - 20

     }

     return money * 0.9

   }

  //处理香蕉

    if(type == 'banana'){

     if(money >= 100){

       return money - 30

     }

     return money * 0.8

   }

  //处理葡萄

    if(type == 'grape'){

     if(money >= 200){

       return money - 50

     }

     return money

   }

  //处理梨

    if(type == 'pear'){

       return money * 0.5

   }

}

然后我们开始来分析问题：\

1. 违反了单一职责原则(SRP)
   
   一个方法里面处理了四个逻辑，要是里面的哪个代码块出事了，调试起来也麻烦


2. 违反了开放封闭原则(ASD)
   
   假如我们要增加多一种水果的逻辑，就又要在这个方法中修改，然后你修改完这个方法，就跟测试说，我在这个方法增加了多一个种水果，可能要重新回归这个方法，那你看测试增加了多少工作量

改造考虑：消灭if-else, 支持扩展但是不影响原本功能！

const fruitsPrice = {

  apple(money){

   if(money >= 100){

       return money - 20

     }

     return money * 0.9

  },

  banana(money){

      if(money >= 100){

       return money - 30

     }

     return money * 0.8

  },

  grape(money){

   if(money >= 200){

       return money - 50

     }

     return money

  },

  pear(money){

   return money * 0.5

  }

}

首先定义一个fruitPrice对象,里面都是各种水果价格的映射关系

然后我们调用的时候可以这样

function getPrice(type,money){

  return fruitsPrice[type](money)

}

当我们要扩展新水果的时候

fruitsPrice.orange = function(money){

   return money*0.4

}

综上所述：
用策略模式重构这个原本的逻辑，方便扩展，调试，清晰简明，当然这只是一个模式重构的情况，可能还有更优的情况，靠大家摸索

结尾

遵守设计规则，脱掉if-else的皮衣，善用设计模式，加油，骚年们！

了解需求

实际生活中，由于好奇朋友撤回的微信图片信息，但直接去要又怎会是我的性格呢。由此萌生出做一个微信防撤回程序（已向朋友说明）。

当前网络上其实存在一些微信防撤回程序，不过担心不正规软件存在漏洞，泄漏个人信息，这里也就不考虑此种方法。

解决方案

思路

由于当前微信不支持微信网页版登陆，因此使用itchat的方法不再适用。

后来了解到电脑端微信图片会先存储在本地，撤回后图片再从本地删除，因此只要在撤回前将微信本地图片转移到新文件夹即可。

在此使用Python的watchdog包来监视文件系统事件，例如文件被创建、修改、删除、移动，我们只需监听创建文件事件即可。

安装watchdog包:    pip install watchdog

我的python环境为python3.9版本

实现

1.首先进行文件创建事件监听，在监听事件发生后的事件处理对象为复制微信图片到新文件夹。具体代码如下。

需要注意的是微信在2022.05前，图片存储在images目录下；在2022.05后，图片存储在MsgAttach目录下，并按微信对象分别进行存储。

# 第一步：加载路径，并实时读取JPG信息

import os

import shutil

import time

from watchdog.observers import Observer

from watchdog.events import FileSystemEventHandler



def mycopyfile(srcfile,dst_dir):

    if not os.path.isfile(srcfile):

        print ("%s not exist!"%(srcfile))

    else:

        fpath,fname=os.path.split(srcfile)             # 分离文件名和路径

        if fname.endswith('.jpg') or fname.endswith('.png') or fname.endswith('.dat'):

            dst_path = os.path.join(dst_dir, fname)

            shutil.copy(srcfile, dst_path)          # 复制文件



class MyEventHandler(FileSystemEventHandler):

    # 文件移动

    # def on_moved(self, event):

    #     print("文件移动触发")

    #     print(event)





    def on_created(self, event):

        # print("文件创建触发")

        print(event)

        mycopyfile(event.src_path, dst_dir)





    # def on_deleted(self, event):

    #     print("文件删除触发")

    #     print(event)

    #

    # def on_modified(self, event):

    #     print("文件编辑触发")

    #     print(event)



if __name__ == '__main__':



    dst_dir = r"E:\03微信防撤回\weixin"  #TODO：修改为自己的保存文件目录

    if not os.path.exists(dst_dir):

        os.makedirs(dst_dir)  



    observer = Observer()  # 创建观察者对象

    file_handler = MyEventHandler()  # 创建事件处理对象

    listen_dir = r"C:\Users\hc\Documents\WeChat"  #TODO：修改为自己的监听目录

    observer.schedule(file_handler, listen_dir, True)  # 向观察者对象绑定事件和目录

    observer.start() # 启动

    try:

        while True:

            time.sleep(1)

    except KeyboardInterrupt:

        observer.stop()

    observer.join()

2.由于微信保存文件以.dat格式保存，因此需要对微信文件格式进行解码，具体解码代码如下。

# weixin_Image.dat 破解

# JPG 16进制 FF D8 FF

# PNG 16进制 89 50 4e 47

# GIF 16进制 47 49 46 38

# 微信.bat 16进制 a1 86----->jpg  ab 8c----jpg     dd 04 --->png

# 自动计算异或 值

import os



into_path = r'E:\03微信防撤回\weixin'  # 微信image文件路径

out_path = r'E:\03微信防撤回\image'



def main(into_path, out_path):



    dat_list = Dat_files(into_path)  # 把路径文件夹下的dat文件以列表呈现

    lens = len(dat_list)

    if lens == 0:

        print('没有dat文件')

        exit()



    num = 0

    for dat_file in dat_list:  # 逐步读取文件

        num += 1

        temp_path = into_path + '/' + dat_file  # 拼接路径：微信图片路径+图片名

        dat_file_name = dat_file[:-4]  # 截取字符串 去掉.dat

        imageDecode(temp_path, dat_file_name, out_path)  # 转码函数

        value = int((num / lens) * 100)             # 显示进度

        print('正在处理--->{}%'.format(value))





def Dat_files(file_dir):

    """

    :param file_dir: 寻找文件夹下的dat文件

    :return: 返回文件夹下dat文件的列表

    """

    dat = []

    for files in os.listdir(file_dir):

        if os.path.splitext(files)[1] == '.dat':

            dat.append(files)

    return dat



def imageDecode(temp_path, dat_file_name, out_path):

    dat_read = open(temp_path, "rb")  # 读取.bat 文件

    xo, j = Format(temp_path)  # 判断图片格式 并计算返回异或值 函数



    if j == 1:

        mat = '.png'

    elif j == 2:

        mat = '.gif'

    else:

        mat = '.jpg'



    out = out_path + '/' + dat_file_name + mat  # 图片输出路径

    png_write = open(out, "wb")  # 图片写入

    dat_read.seek(0)  # 重置文件指针位置



    for now in dat_read:  # 循环字节

        for nowByte in now:

            newByte = nowByte ^ xo  # 转码计算

            png_write.write(bytes([newByte]))  # 转码后重新写入





def Format(f):

    """

    计算异或值

    各图片头部信息

    png：89 50 4e 47

    gif： 47 49 46 38

    jpeg：ff d8 ff

    """

    dat_r = open(f, "rb")



    try:

        a = [(0x89, 0x50, 0x4e), (0x47, 0x49, 0x46), (0xff, 0xd8, 0xff)]

        for now in dat_r:

            j = 0

            for xor in a:

                j = j + 1  # 记录是第几个格式 1：png 2：gif 3：jpeg

                i = 0

                res = []

                now2 = now[:3]      # 取前三组判断

                for nowByte in now2:

                    res.append(nowByte ^ xor[i])

                    i += 1

                if res[0] == res[1] == res[2]:

                    return res[0], j

    except:

        pass

    finally:

        dat_r.close()





# 运行

if __name__ == '__main__':

    main(into_path, out_path)

复制代码
作者：空气猫
来源：juejin.cn/post/7221376169370583101
>

本篇所讲的路由控制方案是由前端实现的，根据具体的业务做的设计，可能不具备一般性，仅供参考！

项目背景及路由初步设计

目前在做的一个项目，目标是为了解决互联网行业里面关于资金清分业务的一些痛点。虽然目前只成功对接并上线了一个第三方企业，随着产品功能的不断完善，相信后续还会有更多的第三方企业对接，以及更多的业务场景。

这就需要提前对系统的菜单权限进行规划，由于后期开发的不确定性以及人力资源有限，路由权限控制没有采用跟后端强耦合的方式实现，由前端自行配置并处理。

一开始由于意向企业业务上的强相关性，并没有规划太多的模块（主业务全都写在了src/views/main目录下），也没有对用户行为进行规划分类，路由控制方面也是根据平台标识手动配置的路由表。

const xxx = [

  '/main/nopage',

  '/main/checkFace',

  // ...

]

缺点

最近又做了一个B端的项目，发现上面的实现方法并不是很好，原因有以下几点：

1. 
   

   对接平台多的话，就会出现一堆路由配置，不优雅、不美观

   
   


2. 
   

   业务上的不一致性带来扩展的不灵活

   
   


3. 
   

   暂时没有想起来 : )

   
   

经过一番考量，我决定这样做（其实也是常见的方法）

改进方案

首先业务实现上需要我新建一个文件目录（src/views/xxx，不能再往main目录下放了），在里面写路由组件。

期间我想过以对接的平台标识创建路由组件目录，进行业务上的隔离，没有做出实际尝试就被我舍弃了，原因是：以平台标识作为业务的根目录，跟原先的做法本质上是一致的，只是改进，相当于是补丁，而我要做的是寻找另一种解决办法。

根据Linux系统一切皆文件的思想，类似的，我还是采用了老套的办法，给每一个路由菜单赋予一个访问权限的配置。

这样做，后面维护起来也简单（有了平台标识和用户行为的划分）

{

    path: "/test",

    name: "Test",

    meta: {

      belong: ["xxx", "xxx"] // 所属平台信息，操作行为信息...

    },

    component: () => import("@/views/test")

  },

后端同事配合规划用户平台和行为，在用户访问的时候，后端返回用户信息的同时，返回平台标识和行为标识。

同样的，在全局路由钩子里验证访问权限。

router.beforeEach((to, from, next) => {

  try {

    const { belong = [] } = to.meta

    const authInfo = ["platform", "action"]

    if (accessTokenStr) {

      // 已登录, 做点什么

      // belong <--> authInfo

      // arrayInclude(belong, authInfo)

    } else {

      next()

    }

  } catch (err) {

    console.log(err);

  }

})

/**

 * 判断数组元素的包含关系，不要求顺序一致

 * 数组中不存在重复元素

 * 用于验证路由权限

 * arrA包含arrB，返回true, 否则返回false

*/

export const arrayInclude = (arrA, arrB) => {

  let flag = true

  for (let i = 0; i < arrB.length; i++) {

    if (!arrA.includes(arrB[i])) {

      flag = false

      break

    }

  }

  return flag

}

👉👉以上方案写于2021-11-06

维护总结

2023-04-03

近期业务扩展，发现上面的菜单权限控制有点不合理

这种配置不直观，有点混乱！！！

还是采用json的方式分配路由， 比如：

const menus = {

  [platformId]: [

    "/a"，

    "/b"

  ],

  [platformId]: [

    "/a"，

    "/b"

  ],

}

这样可以更加直观的显示出来某个业务包含哪些菜单，而不是像之前那样把菜单的权限配置在路由上！

总结： 路由设计要中电考虑可读性、易维护性

我是 甜点cc，个人网站(国外站点): blog.i-xiao.space/

公众号

学习Node.js已有很长的时间了，但一直学的懵懵懂懂，不得要领，现决定跟网上的大佬从头开始理一下其中的底层逻辑，为早日成为全栈工程师打下基础。

Node.js 是什么？

Node.js 是一个基于 V8 引擎 的 JS 运行时，它由 Ryan Dahl 在 2009 年创建。

这里有两个关键词，一是 JS 引擎，二是 JS 的运行时。

那什么叫 JS 引擎呢？

JS 引擎就是把一些 JS 的代码进行解析执行，最后得到一个结果。

比如，上图的左边是用 JS 的语法定义一个变量 a 等于 1，b 等于 1，然后把 a 加 b 的值赋值给新的变量 c，接着把这个字符串传入 JS 引擎里，JS 引擎就会进行解析执行，执行完之后就可以得到对应的结果。

那么 JS 运行时又是什么呢？它和 JS 本身有什么区别 ？

要搞清楚上面的问题，可以看下面这张图：

从下往上看：

1. 
   

   最下面一层是脚本语言规范ECMAScript，也就是常说的ES5、ES6语法。

   
   


2. 
   

   往上一层就是对于该规范的实现了，如JavaScript、JScript等都属于对 ECMAScript语言规范的实现。

   
   


3. 
   

   再往上一层就是执行引擎，JavaScript 常见的引擎有 V8、QuickJS等，用来解释执行代码。

   
   


4. 
   

   最上面就是运行时环境了，比如基于 V8 封装的运行时环境有 Chromium、Node.js、Deno 等等。

   
   

可以看到，JavaScript 在第二层，Node.js 则在第四层，两个根本不是一个东西。

所以，Node.js 并不是语言，而是一个 JavaScript 运行时环境，它的语言是 JavaScript。这就跟 PHP、Python、Ruby 这类不一样，它们既代表语言，也可代表执行它们的运行时环境（或解释器）。

JS 作为一门语言，有独立的语法规范，提供一些内置对象和 API（如数组、对象、函数等）。但和其他语言（C、C++等）不一样的是，JS 不提供网络、文件、进程等功能，这些额外的功能是由运行时环境实现和提供的，比如浏览器或 Node.js。

所以，JS 运行时可以理解为 JS 本身 + 一些拓展的能力所组成的一个运行环境，如下面这张图：

可以看到，这些运行时都不同程度地拓展了 JS 本身的功能。JS 运行时封装底层复杂的逻辑，对上层暴露 JS API，开发者只需要了解 JS 的语法，就可以使用这些 JS 运行时做很多 JS 本身无法做到的事情。

Node.js 的组成

搞清楚了什么是Node.js后，再来看看 Node.js 的组成。

Node.js 主要是由 V8、Libuv 和一些第三方库组成的。

V8引擎

V8 是一个 JS 引擎，它不仅实现了 JS 解析和执行，还支持自定义拓展。

这有什么用处呢？

比如说，在下面这张图中我们直接使用了 A 函数，但 JS 本身并没有提供 A 这个函数。这个时候，我们给 V8 引擎提供的 API 里注入一个全局变量 A ，就可以直接在 JS 中使用这个 A 函数了。正是因为 V8 支持这个自定义的拓展，才有了 Node.js 等 JS 运行时。

Libuv

Libuv 是一个跨平台的异步 IO 库，它主要是封装各个操作系统的一些 API，提供网络还有文件进程这些功能。

我们知道在 JS 里面是没有网络文件这些功能的，前端是由浏览器提供，而 Node.js 里则是由 Libuv 提供。

1. 
   

   左侧部分是 JS 本身的功能，也就是 V8 实现的功能。

   
   


2. 
   

   中间部分是一些C++ 胶水代码。

   
   


3. 
   

   右侧部分是 Libuv 的代码。

   
   

V8 和 Libuv 通过第二部分的胶水代码粘合在一起，最后就形成了整一个 Node.js。

因此，在 Node.js 里面不仅可以使用 JS 本身给我们提供的一些变量，如数组、函数，还能使用 JS 本身没有提供的 TCP、文件操作和定时器功能。

这些扩展出来的能力都是扩展到V8上，然后提供给开发者使用，不过，Node.js 并不是通过全局变量的方式实现扩展的，它是通过模块加载来实现的。

第三方库工具库

有了 V8 引擎和拓展 JS 能力的 Libuv，理论上就可以写一个 JS 运行时了，但是随着 JS 运行时功能的不断增加，Libuv 已经不能满足需求，比如实现加密解密、压缩解压缩。

这时候就需要使用一些经过业界验证的第三方库，比如异步 DNS 解析 c-ares 库、HTTP 解析器 llhttp、HTTP2 解析器 nghttp2、解压压缩库 zlib、加密解密库 openssl 等等。

Node.js 代码组成

了解了 Node.js 的核心组成后，再来简单看一下 Node.js 代码的组成。

Node.js 代码主要是分为三个部分，分别是 C、C++ 和 JavaScript。

JS层

JS 代码就是我们平时使用的那些 JS 模块，像 http 和 fs 这些模块。

Node.js 之所以流行，有很大一部分原因在于选择了 JS 语言。

Node.js 内核通过 C、C++ 实现了核心的功能，然后通过 JS API 暴露给用户使用，这样用户只需要了解 JS 语法就可以进行开发。相比其他的语言，这个门槛降低了很多。

C++层

C++代码主要分为三个部分:

1. 
   

   第一部分主要是封装 Libuv 和第三方库的 C++ 代码，比如 net 和 fs 这些模块都会对应一个 C++ 模块，它主要是对底层 Libuv 的一些封装。

   
   


2. 
   

   第二部分是不依赖 Libuv 和第三方库的 C++ 代码，比方像 Buffer 模块的实现，主要依赖于 V8。

   
   


3. 
   

   第三部分 C++ 代码是 V8 本身的代码。

   
   

C++ 代码中最重要的是了解如何通过 V8 API 把 C、C++ 的能力暴露给 JS 层使用，正如前面讲到的通过拓展一个全局变量 A，然后就可以在 JS层使用 A。

C 语言层

C 语言代码主要是包括 Libuv 和第三方库的代码，它们大多数是纯 C 语言实现的代码。

Libuv 等库提供了一系列 C API，然后在 Node.js 的 C++ 层对其进行封装使用，最终暴露 JS API 给 JS 层使用。

总结

文章第一部分介绍了Node.js的本质，它实际上是一个JS运行时，提供了网络、文件、进程等功能，类似于浏览器，提供了JS的运行环境。

第二部分介绍了Node.js的组成，它由V8引擎、Libuv及第三方库构成，Node.js核心功能大都是Libuv提供的，它封装底层各个操作系统的一些 API，因此，Node.js是跨平台的。

第三部分从代码的角度描述了Node.js的组成，包括JavaScript、C++、C三部分，中间的C++部分通过对C部分的封装提供给JavaScript部分使用。

• 原文: medium.com/proandroidd…


• 译者：程序员 DHL


• 本文已收录于仓库 Technical-Article-Translation

这篇文章，主要分享在 Android 14 以上新增的权限 READ_MEDIA_VISUAL_USER_SELECTED，该权限允许用户仅授予对选定媒体的访问权限（Photos / Videos)），而不是访问整个媒体库。

新的权限弹窗

当你的 App 运行在 Andrid 14 以上的设备时，如果请求访问照片，会出现以下对话框，你将看到新的选项。

受影响的行为

当我们在项目中声明新的权限 READ_MEDIA_VISUAL_USER_SELECTED ，并且用户选择 Select photos and videos(Select photos or Select videos) ：

• 
  

  READ_MEDIA_IMAGES 和 READ_MEDIA_VIDEO 权限都会被拒绝

  
  


• 
  

  READ_MEDIA_VISUAL_USER_SELECTED 权限被授予时，将会被允许临时访问用户的照片和视频

  
  


• 
  

  如果我们需要访问其他照片和视频，我们需要同时申请 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限

  
  

如何在项目中使用新的权限

• 在 AndroidManifest.xml 文件中添加下面的权限

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />



// new permisison

<uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" />

• 使用 ActivityResultContract 请求新的权限

val permissionLauncher =

    rememberLauncherForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { mapResults ->

        mapResults.forEach {

            Log.d(TAG, "Permission: ${it.key} Status: ${it.value}")

        }

        // check if any of the requested permissions is granted or not

        if (mapResults.values.any { it }) {

            // query the content resolver

            queryContentResolver(context) { listOfImages ->

                imageDataModelList = listOfImages

            }

        }

    }

为什么要使用 RequestMultiplePermissions，因为我们需要同时请求 READ_MEDIA_IMAGES , READ_MEDIA_VIDEO 权限

• 启动权限申请流程

OutlinedButton(onClick = {

    permissionLauncher.launch(arrayOf(READ_MEDIA_IMAGES, READ_MEDIA_VISUAL_USER_SELECTED))

}) {

    Text("Allow to read all or select images")

}

关于 Android 12 、 Android 13 、Android 14 功能和权限的变更，点击下方链接前往查看：

• 
  

  快速适配 Android 14

  
  


• 
  

  Android 13这些权限废弃，你的应用受影响了吗？

  
  


• 
  

  Android 12 已来，你的 App 崩溃了吗？

  
  

最后我们看一下运行效果

全文到这里就结束了，感谢你的阅读，坚持原创不易，欢迎在看、点赞、分享给身边的小伙伴，我会持续分享原创干货！！！

我开了一个云同步编译工具（SyncKit），主要用于本地写代码，同步到远程设备，在远程设备上进行编译，最后将编译的结果同步到本地，代码已经上传到 Github，欢迎前往仓库 hi-dhl/SyncKit 查看。

• 仓库 SyncKit：https://github.com/hi-dhl/SyncKit


• 下载地址：https://github.com/hi-dhl/SyncKit/releases

Hi 大家好，我是 DHL，就职于美团、快手、小米。公众号：ByteCode ，分享有用、有趣的硬核原创内容，Kotlin、Jetpack、性能优化、系统源码、算法及数据结构、动画、大厂面经，真诚推荐你关注我。

• 公众号：ByteCode


• 哔哩哔哩： space.bilibili.com/498153238


• 掘金： juejin.im/user/259450…


• 博客： hi-dhl.com


• Github： github.com/hi-dhl

最新文章

• 国外大厂面试题， 7 个 Android Lifecycle 重要的知识点


• Android 13这些权限废弃，你的应用受影响了吗？


• Android 12 已来，你的 App 崩溃了吗？


• Android 利器，我开发了云同步编译工具


• Twitter 上有趣的代码


• 谁动了我的内存，揭秘 OOM 崩溃下降 90% 的秘密


• 反射技巧让你的性能提升 N 倍


• 90%人不懂的泛型局限性，泛型擦除，星投影


• 揭秘反射真的很耗时吗，射 10 万次耗时多久


• Google 宣布废弃 LiveData.observe 方法


• 影响性能的 Kotlin 代码（一）


• 揭秘 Kotlin 中的 == 和 ===

开源新项目

• 
  

  云同步编译工具（SyncKit），本地写代码，远程编译，欢迎前去查看 SyncKit

  
  


• 
  

  KtKit 小巧而实用，用 Kotlin 语言编写的工具库，欢迎前去查看 KtKit

  
  


• 
  

  最全、最新的 AndroidX Jetpack 相关组件的实战项目以及相关组件原理分析文章，正在逐渐增加 Jetpack 新成员，仓库持续更新，欢迎前去查看 AndroidX-Jetpack-Practice

  
  


• 
  

  LeetCode / 剑指 offer，包含多种解题思路、时间复杂度、空间复杂度分析，在线阅读

  
  

简介：本文介绍了使用 localStorage 判断设置值是否过期的方法。通过设置过期时间，我们可以使用 setItemWithExpiration 函数将数据存储到 localStorage 中，并使用 getItemWithExpiration 函数获取数据并检查是否过期。localStorage 提供简单的 API 方法来存储、检索和删除数据，并具有持久性和域隔离的特点。通过本文的方法，你可以方便地管理数据，并灵活设置过期时间，实现更多的数据存储和管理功能。

目标：在网站中实现定期弹窗功能，以提示用户。

选择实现方式：为了实现持久化存储和检测功能，我们选择使用localStorage作为首选方案。

解决方案：

1. 存储设置值：使用localStorage将设置值存储在浏览器中，以便在用户访问网站时保持数据的持久性。


2. 设置过期时间：根据需求，为设置值设定一个过期时间，表示多长时间后需要再次弹窗提示用户。


3. 检测过期状态：每次用户访问网站时，检测存储的设置值是否已过期。若过期，则触发弹窗功能，提醒用户。


4. 更新设置值：在弹窗提示后，可以根据用户的操作进行相应的更新操作，例如延长过期时间或更新设置内容。

优势：

1. 持久化存储：使用localStorage可以将设置值保存在浏览器中，即使用户关闭了浏览器或重新启动设备，设置值仍然有效。


2. 简单易用：localStorage提供了简单的API，方便存储和读取数据，实现起来相对简单。


3. 跨浏览器支持：localStorage是HTML5的标准特性，几乎所有现代浏览器都支持它，因此具有良好的跨浏览器兼容性。

注意事项：

1. 需要根据业务需求合理设置过期时间，避免频繁弹窗对用户体验造成困扰。


2. 在使用localStorage时，要考虑浏览器的隐私设置，以确保能够正常存储和读取数据。

说一下locaStorage

localStorage 是 Web 浏览器提供的一种存储数据的机制，它允许在浏览器中存储和检索键值对数据。

以下是关于 localStorage 的一些重要特点和使用方法：

1. 
   

   持久性：与会话存储（session storage）相比，localStorage 是一种持久性的存储机制。存储在 localStorage 中的数据在用户关闭浏览器后仍然保留，下次打开网页时仍然可用。

   
   


2. 
   

   容量限制：每个域名下的 localStorage 存储空间通常为 5MB。这个限制是针对整个域名的，不是针对单个页面或单个 localStorage 对象的。

   
   


3. 
   

   键值对数据存储：localStorage 使用键值对的方式存储数据。每个键和对应的值都是字符串类型。如果要存储其他数据类型（如对象或数组），需要进行序列化和反序列化操作。

   
   


4. 
   

   API 方法：

   
   

   属性	方法
   localStorage.setItem(key, value)	将键值对存储到 localStorage 中。如果键已存在，则更新对应的值。
   localStorage.getItem(key)	根据键获取存储在 localStorage 中的值
   localStorage.removeItem(key)	根据键从 localStorage 中删除对应的键值对
   localStorage.clear()	清除所有存储在 localStorage 中的键值对。
   localStorage.key(index)	根据索引获取对应位置的键名。

   
   


5. 
   

   域限制：localStorage 存储的数据与特定的域名相关。不同的域名之间的 localStorage 是相互隔离的，一个网站无法访问另一个网站的 localStorage 数据。

   
   


6. 
   

   安全性：localStorage 中的数据存储在用户的本地浏览器中，因此可以被用户修改或删除。敏感数据应该避免存储在 localStorage 中，并使用其他更安全的机制来处理。

   
   

以下是一个示例，展示如何使用 localStorage 存储和检索数据：

// 存储数据到 localStorage

localStorage.setItem('name', 'localStorage');

localStorage.setItem('size', '5mb');



// 从 localStorage 中获取数据

const name = localStorage.getItem('name');

const age = localStorage.getItem('size');



console.log(name); // 输出: localStorage

console.log(size); // 输出: 5mb



// 从 localStorage 中删除数据

localStorage.removeItem('size');



// 清除所有的 localStorage 数据

localStorage.clear();

总结来说，localStorage 是一种用于在 Web 浏览器中持久存储键值对数据的机制。它提供简单的 API 方法来存储、检索和删除数据，并具有一定的容量限制和域隔离。

判断本地存储时间的实现

存储时间与值

使用以下代码将值与过期时间存储到localStorage中：

const expiration = 24 * 60 * 60 * 1000 * 7; // 设置过期时间为七天

// const expiration = 2 * 60 * 1000; // 设置过期时间为2分钟

setItemWithExpiration("read_rule", true, expiration);

下面是相应的函数实现：

// 存储数据到LocalStorage，并设置过期时间（单位：毫秒）

function setItemWithExpiration(key, value, expiration) {

    const item = {

        value: value,

        expiration: Date.now() + expiration

    };

    localStorage.setItem(key, JSON.stringify(item));

}

获取值并判断是否过期

使用以下代码从localStorage中获取值，并判断其是否过期：

const retrievedData = getItemWithExpiration("read_rule");

下面是相应的函数实现：

// 从LocalStorage中获取数据，并检查是否过期

function getItemWithExpiration(key) {

    const item = JSON.parse(localStorage.getItem(key));

    if (item && Date.now() < item.expiration) {

        return item.value;

    }

    // 如果数据已过期或不存在，则返回 null 或其他默认值

    return null;

}

通过以上实现，可以方便地存储带有过期时间的值，并根据需要获取和判断其有效性。如果存储的数据已过期或不存在，函数getItemWithExpiration将返回null或

前言

每位开发人员在自己的职业生涯、学习经历中，都会出一些坏习惯，本文将列举开发人员常犯的坏习惯。希望大家能够意识和改变这些坏习惯。

不遵循项目规范

每个公司都会定义一套代码规范、代码格式规范、提交规范等，但是有些开发人员就是不遵循相关的 规范，命名不规范、魔鬼数字、提交代码覆盖他人代码等问题经常发生，如果大家能够遵循相关规范，这些问题都可以避免。

用复杂SQL语句来解决问题

程序员在开发功能时，总想着是否能用一条SQL语句来完成这个功能，于是实现的SQL语句写的非常复杂，包含各种子查询嵌套，函数转换等。这样的SQL语句一旦出现了性能问题，很难进行相关优化。

缺少全局把控思维，只关注某一块业务

新增新功能只关注某一小块业务，不考虑系统整体的扩展性，其他模块已经有相关的实现了，却又重复实现，导致重复代码严重。修改功能不考虑对其他模块的影响。

函数复杂冗长,逻辑混乱

一个函数几百行，复杂函数不做拆分，导致代码变得越来月臃肿，最后谁也不敢动。函数还是要遵循设计模式的单一职责，一个函数只做一件事情。如果函数逻辑确实复杂，需要进行拆分，保证逻辑清晰。

缺乏主动思考，拿来主义

实现相关功能，先网上百度一下，拷贝相关的代码，能够运行成功认为万事大吉。到了生产却出现了各种各样的问题，因为网上的demo程序和实际项目的在场景使用上有区别，尤其是相关的参数配置，一定要弄清楚具体的含义，不同场景下，设置参数的值不同。

核心业务逻辑,缺少相关日志和注释

很多核心的业务逻辑实现，整个方法几乎没看到相关注释和日志打印，除了自己能看懂代码逻辑，其他人根本看不懂。一旦生产出了问题，找不到有效的日志输出，问题根本无法定位。

修改代码，缺少必要测试

很多人都会存在侥幸心里，认为只是改了一个变量或者只修改一行代码，不用自测了应该没有问题，殊不知就是因为改一行代码导致了严重的bug。所以修改代码一定要进行自测。

需求没理清，直接写代码

很多程序员在接到需求后，不怎么思考就开始写代码，写着写着发现自己的理解与实际的需求有偏差，造成无意义返工。所以需要多花些时间梳理需求，整理相关思路，能规避很多不合理的问题。

讨论问题，表达没有逻辑、没有重点

讨论问题不交代背景，上来就说自己的方案，别人听得云里雾里，让你从头描述你又讲不明。需要学会沟通和表达，才能进行有效的沟通和合作。

不能从错误中吸取教训

作为一位开发人员，你会犯很多错误，这不可避免也没什么大不了的。但如果你总是犯同样的错误，不能从中吸取教训，那态度就出现问题了。

总结

关于这些坏习惯，你是否中招了，大家应该尽早规避这些坏习惯，成为一名优秀的程序员。

你是否遇到过这样的情况：想要修改子元素的样式却发现使用父元素选择器无法生效。这时，你就需要了解一下CSS样式穿透的概念。

简单介绍

一般来说，我们可以通过父级选择器来选中它下面的子元素。例如：

.parent .child {

  color: red;

}

但是，有些时候我们需要给子元素中特定的元素修改样式，而不是所有的子元素都修改。这时，我们就需要了解CSS样式穿透这个概念。

CSS样式穿透

在CSS中，我们可以使用“/deep/”、“::v-deep”、“::shadow”等方式实现CSS样式的穿透。

使用/deep/

通过使用/deep/关键字，可以达到子组件穿透自身样式的目的。例如：

.parent /deep/ .child {

  color: red;

}

这种方式相比于上述普通方法，能够选中更深层次的子元素（即使用多个空格连接的子元素）。但是，由于浏览器对“/deep/”选择器支持并不友好，因此尽量避免使用。

使用::v-deep

在Vue框架中，如果需要穿透组件样式，可以使用::v-deep或者>>>选择器。例如：

.parent ::v-deep .child {

  color: red;

}

这种方式只对Vue组件可用，且与/deep/的作用类似。

使用::shadow

在Web Components规范中，定义了Shadow DOM的概念，它能够使得元素的样式隔离开来，不会影响到其它元素。如果我们需要在Shadow DOM中修改样式，可以使用::shadow伪类。

parent::shadow .child {

  color: red;

}

这种方式相比较于上述两种方法，更加安全和规范，但需要先了解Shadow DOM的概念。

补充说明

尽管CSS样式穿透能够方便地修改子元素样式，但是在实际开发中还是应当尽可能地避免使用它们。

CSS一直致力于封装样式，降低代码耦合度，而使用CSS样式穿透会将样式的层级深度加深，增加样式的维护成本。

此外，在跨浏览器、跨框架的情况下，CSS样式穿透的表现都不尽相同，因此建议在项目中谨慎使用。

结语

CSS样式穿透虽然能够带来方便，却也需要谨慎使用，遵循代码封装的原则，保持样式的简洁、规范和易维护。

笔者是一个六年前端，没有大厂经历，也没有什么出彩的项目，所以今年以来，前端现在这种行情下并没有收到多少面试，但是为数不多的面试中，百分之九十都问到了性能优化的问题，而且问题都出奇的一致：

平时的工作中你有做过什么性能优化？

对于这个问题其实我的内心os是（各位轻喷~）：

你们怎么都这么爱问性能优化的问题？我的简历中也没有写到这个啊。

你们的业务都这么复杂吗？怎么动不动就要性能优化？

你们的代码写的这么拉吗？不优化都不能使用吗？

性能优化是一个高级前端的必要技能吗？

首先客观现实是笔者平时工作中的业务并不复杂，需要性能优化的地方确实不多，一些存在性能瓶颈的大多是使用了其他团队开发的东西，比如播放直播视频的SDK、3D地图引擎等，也找过他们进行优化，但是没用，他们也优化不动。

所以每次被问到这个问题我就很尴尬，说工作中没有遇到过性能问题，估计面试官也不信，直接说没有做过性能优化，那又显得我这个六年经验的前端太水了，连这个都不做，所以每次我只能硬说。

没吃过猪肉，还没见过猪跑吗？其实性能优化的文章我也看过很多，各种名词我还是知道一点的，比如：

• 性能问题排查：

1.数据埋点上报

2.使用控制台的NetWork、Performance等工具

3.webpack-bundle-analyzer插件分析打包产物

• http相关：

1.gzip压缩

2.强缓存、协商缓存

• 图片相关：

1.图片压缩

2.图片懒加载

3.雪碧图、使用字体图标、svg

• webpack相关：

1.优化文件搜索

2.多进程打包

3.分包

4.代码压缩

5.使用CDN

• 框架相关：

1.vue性能优化、react性能优化

2.异步组件

3.tree shaking

4.服务端渲染

• 代码实现

1.按需加载，逻辑后移，优先保证首屏内容渲染

2.复杂计算使用web worker

3.接口缓存、计算结果缓存

4.预加载

5.骨架屏

6.虚拟滚动

等等。

但这些绝大部分我并没有实践过，所以我都说不出口，说我没有机会实践也行，说我没有好奇心不好学不爱思考不主动发现问题也行，总之结果就是没有经验。

所以通常我硬着头皮只能说出以下这些：

1.开发前会花点时间梳理业务，全局视角过一遍交互和视觉，思考组件划分，找出项目中相似的部分，提取为公共组件和通用逻辑。

2.代码开发中尽量保证写出的代码清晰、可维护，比如：清晰的目录和文件结构、添加必要的注释、提取公共函数公共组件、组件单向数据流、组件功能尽量单一等。

3.时刻关注可能会存在性能问题的部分，比如：

路由组件异步加载

动态加载一些初始不需要用到的资源

频繁切换的组件使用KeepAlive进行缓存

缓存复杂或常用的计算结果

对实时性不高的接口进行缓存

同一个接口多次请求时取消上一次没有完成的请求

页面中存在很多接口时进行优先级排序，优先请求页面重要信息的接口，并关注同一时刻请求的接口数量，如果过多进行分批请求

对于一些确实比较慢的接口使用loading或骨架屏

懒加载列表，懒加载图片，对移出可视区的图片和dom进行销毁

关注页面中使用到的图片大小，推动后端进行图片压缩

地图撒点时使用聚合减少地图引擎渲染压力

对于一些频繁的操作使用防抖或节流

使用三方库或组件库尽量采用按需加载，减少打包体积

组件卸载时取消事件的监听、取消组件中的定时器、销毁一些三方库的实例

我工作中的实践也就以上这些，其实就是写代码的基本要求，另外我觉得如果业务复杂，以上这些也并不能阻止性能问题的出现，更多的还是当出现了问题，去思考如何解决。

比如我开源的一个思维导图项目mind-map，当节点数量多了会非常卡，调试分析思考后发现原因是做法不合理，每次画布上有操作后都是清空画布上的所有元素，然后重新创建所有元素，数据驱动视图，原理非常简单，但是因为是通过svg实现，所以就是DOM节点，这玩意我们都知道，当节点数量非常多以后，删除节点和创建节点都是非常耗时的，所以数据驱动视图的框架，比如Vue会通过虚拟DOM的diff算法对比来找出最小的更新部分，但是我没有做。。。所以。。。那么我就自然的做了一些优化，比如：

思维导图场景，大部分情况下操作的其实就是其中一个或部分节点，所以不需要重新删除创建所有元素，那么就可以通过节点复用的方式来优化，将真实节点缓存起来，渲染时通过数据唯一的id来检查是否存在可复用节点，如果没有，那么代表是新增节点，那么创建新节点即可；如果有，那么就判断节点数据是否发生改变，没有改变直接复用，如果发生了改变那么判断是否可以进行更新，如果更新成本高那么直接重新创建；另外也需要和上一次的缓存进行对比，找出本次渲染不需要的节点进行删除；当然，为了避免缓存节点数量无限膨胀，也通过LRU缓存算法来管理

对于不影响其他节点的操作只更新被操作的节点

通过setTimeout异步渲染节点，留一些中间时间来响应页面其他操作

将触发渲染的任务放到队列中，在下一帧进行处理，合并掉一些中间状态

对于鼠标移动和滚动的场景，通过节流来优化

进行一些取舍，早期节点激活时可以修改节点的所有样式，导致激活操作需要重新计算节点大小，更新节点样式，在多选和全选操作下非常耗时，所以后期改为只允许修改不改变节点大小的样式属性

其他一些细节优化：对于数据没有改变的操作不触发赋值或函数调用，一些不起眼的操作可能也是需要耗费时间的；改变了不涉及节点大小的属性不触发节点大小重新计算等

经过以上这些修改后，性能确实有了很大程度的提升，不过有些项目可以通过不断的优化来提升性能，但是有些可能就是设计缺陷，比如我开源的另一个白板项目，更好的方式其实是重做它。

写到这里其实并没有解决本文标题提出的问题：

为什么面试官这么爱问性能优化？

因为我没有怎么做过面试官，甚至面试经验其实都不太多，写这篇文章目的主要有两个：

1.想听听有面试官经验的各位的想法或建议

2.想看看和我有类似情况的面试者面对这个问题，或者说类似的问题是如何回答的

最后再牢骚几句：

有时会感慨时间过的真快，一转眼，作为一个前端已经工作了六年，即将三十而立却立不起来，这么多年的工作，更多的只是收获了六年的经历，但是并没有六年的能力，回过头看，当初的有些选择确实是错误的，也许这就是人生把。

作为一个普通的前端，在如今的行情下面试确实很艰难，尤其是我这种不擅长面试的人，不过话说回来，改变哪有不痛苦的，除了面对也没有其他办法。

背景

常和我们的客户端厮混，也经常陪他们发版，每次发版编译打包都可以在那边玩一局游戏了。一边幸灾乐祸，一边庆幸h5编译还好挺快的，直到我们的项目也发展成了*山，巨石项目。由于线上要给用户查看历史的推广活动，所以很多老的业务项目都还是留在项目中，导致我们的router层爆炸，打包速度直线下降，开发过程中，开了hmr稍微有点改动也要等个几秒钟，恨不得立刻重启一个新项目。但是现实告诉你，忍住，别吐，后面还有更多的业务活动加进来。那么怎么解决这个问题呢，这个时候mp的思路是个不错的选择。

关键点

打包慢，本质原因是依赖庞大，组件过多。开发过程中，我们开新的业务组件时，往往和其他业务组件是隔离的，那么我们打包的时候是不是可以把那些不相干的业务组件隔离出去，当然可以。打包工具，从入口开始进行扫描，单页面的模块引入基本都是借助router，所以，关键的是如果我们能够控制router的数量，其实就能够控制编译和打包规模了。

问题

router在vue项目中我们常用的是全家桶的库vue-router，vue-router最多提供了懒加载，动态引入功能并不支持。有小伙伴说router的引入路径可不可以动态传入，我只能说小伙子你很机智，但是vue-router并不支持动态的引入路径。因此我们换个思路，就是在入口的位置控制router的规模，通过不同规模的router实例来实现router的动态引入。当然这需要我们对router库进行一定改造，使其变的灵活易用

一般的router

通常的router如下：

// router.js



/*global require*/



const Vue = require('vue')



const Router = require('vue-router')



Vue.use(Router)



const routes = [



{



path: '/routermap',



component: (resolve) => require(['../containers/map.vue'], resolve),



name: 'routermap',



desc: '路由列表'



},



{



path: '/',



component: (resolve) => require(['../containers/index.vue'], resolve)



},



{



path: '*',



component: (resolve) => require(['../containers/nofound.vue'], resolve),



name: 'defaultPage',



desc: '默认页'



}



]



const router = new Router({



mode: 'history',



routes



})



router.afterEach((to, from) => {



///



})



export default router



// 引入 entry.js



import router from './router.js'



router.beforeEach((to, from, next) => {



///



next()



})



router.afterEach(function(to, from) {



///



})



new Vue({



el: '#app',



template: '<App/>',



router,



})

我们可以不断的往routes数组中添加新的router item来添加新的业务组件，这也是我们的项目不断变大的根本，这样既不好维护，也会导致后面的编译效率

易于维护和管理的router

其实好的管理和维护本质就是分门别类，把类似功能的放在一起，而不是一锅粥都放在一起，这样基本就能解决追踪维护的功能，对应router管理其实也不是很复杂，多建几个文件夹就行如下：

对应routes/index.js代码如下：

import testRouter from './test.js'



const routes = [



    {



        path: '/map',



        component: (resolve) => require(['../containers/map.vue'], resolve),



        name: 'map',



        desc: '路由列表'



    },



    {



        path: '/',



        component: (resolve) => require(['../containers/index.vue'], resolve)



    },



    ...testRouter,



    // 可以扩展其他router



    {



        path: '*',



        component: (resolve) => require(['../containers/nofound.vue'], resolve),



        name: 'defaultPage',



        desc: '默认页'



    }



]



// test.js



/**



* 测试相关页面路由映射



*/



/*global require*/



export default [



    {



        path: '/test/tools',



        name: 'testTools',



        component: resolve => require(['@test/tools/index.vue'], resolve),



        desc: '测试工具'



    }



]

我们通过把router分为几个类别的js，然后在通过router item的数组展开合并，就做到了分门别类，虽然看似简单，但是可以把管理和维护效果提升几个数量级。

支持mp的router

虽然上面支持了易于管理和维护，但是实际上我们如果只是单一入口的话，导出的还是一个巨大的router。那么如何支持多入口呢，其实也不用想的过于复杂，我们让类似test.js的router文件既支持router item的数组导出，也支持类似routes/index.js一样的router实例导出即可。所谓既能分也能合才是最灵活的，这里我们可以利用工厂模式做一个factory.js，如下：

/**



* app 内的页面路由映射



*/



/*global require*/



const Vue = require('vue')



const Router = require('vue-router')



Vue.use(Router)



const RouterFactory = (routes) => {



    return new Router({



        mode: 'history',



        routes: [



            {



                path: '/map',



                component: (resolve) => require(['../containers/map.vue'], resolve),



                name: 'map',



                desc: '路由列表'



            },



            {



                path: '/',



                component: (resolve) => require(['../containers/index.vue'], resolve)



            },



            ...routes,



            {



                path: '*',



                component: (resolve) => require(['../containers/nofound.vue'], resolve),



                name: 'defaultPage',



                desc: '默认页'



            }



        ]



    })



}



export default RouterFactory

这个factory.js产出的router实例和routes/index.js一模一样所以我们只需组装一下test.js即可，如下：

/*global require*/



import RouterFactory from './factory'



export const testRouter = [



    {



        path: '/test/tools',



        name: 'testTools',



        component: resolve => require(['@test/tools/index.vue'], resolve),



        desc: '测试工具'



    }



]



export default RouterFactory(developRouter)



// routes/index.js的引入变化一下即可



import testRouter from './test.js'



// 修改为=》



import { testRouter } from './test.js'

那么我们的入口该如何修改呢？也很简单：

// testEntry.js



import router from './routes/test.js'



router.beforeEach((to, from, next) => {



    ///



    next()



})



router.afterEach(function(to, from) {



    ///



})



new Vue({



    el: '#app',



    template: '<App/>',



    router,



})

我们建立了一个新的入口文件 testEntry.js 这个入口只引入了test相关的模块组件

如何灵活的和编译命令做配合呢

根据上面，我们进行mp改造的基础已经做好，关于如何多入口编译webpack或者其他打包里面都是基础知识，这里就不多赘述。这里主要聊一下如何灵活的配合命令做编译和部署。

既然router我们都可以分为不同的文件，编译文件我们同样可以拆分为不同的文件，这也使得我们的命令可以灵活多变，这里我们以webpack做为示例：

根据上图示例 我们的webpack的配置文件仅仅改动了entry，我们稍微改造一下build.js，使其能够接受不同的编译命令：

// build.js



let page = 'all'



if (process.argv[2]) {



    page = process.argv[2]



}



let configMap = {



    'all': require('./webpack.prod.conf'),



    'app': require('./webpack.app.conf')



}



let webpackConfig = configMap[page]



// dev-server.js



let page = 'all'



if (process.argv[2]) {



    page = process.argv[2]



}



let configMap = {



    'all': require('./webpack.dev.conf'),



    'app': require('./webpack.app.dev.conf')



}



let webpackConfig = configMap[page]

对应的脚本配置：

// package.json



"scripts": {



    "dev": "node build/dev-server.js",



    "build": "node build/build.js",



    "build:app": "node build/build.js app",



    "dev:app": "node build/dev-server.js app"



},

以上app对应test。最后，我们只需要在命令行执行相应命令，即可实现我们可控的router规模的开发，基本随便来新的需求，咱都可以夜夜做新郎，怎么搞都是飞速。当然部署的话我们也可以单独执行一部分页面的部署命令到单独的域名，换个思路也可以作为一种预发测试的部署方法。

# 整体项目的开发编译



npm run dev



# 单独的app，也即test项目的开发编译



npm run dev:app



# 整体项目的部署



npm run build



# 单独的app，也即test项目的部署



npm run build:app

结语

以上，即如何利用mp思路，提高我们的编译开发效率。时常有人会在提高网页性能的时候说到mp，但mp本质上并不能提高页面的性能，比如白屏优化。而路由中使用懒加载其实才是提高部分网页性能的出力者，关于白屏优化，本篇文章不作展开讨论。

这几天在医院对身体各方面进行了一次比较全面的检查，结果比较令人满意。一转眼，接受肾移植已经 5 周年了，写一篇博文，对这些年的身体以及治疗情况进行了一个汇总。

发病

在 30 岁左右进行体检时，已经发现肾功能指标不太理想，因此进行了有针对性的调整。但随着时间的推移和工作的繁忙，逐渐也放松了对健康的重视。尽管发病前几个月进行体检时，各方面的指标也还说得过去。但病来如山倒，对于肾脏疾病来说，后期恶化的速度是十分迅猛的。

当时手里有几个项目正在进行，资金的压力也比较大。尽管身体已经发出了明显的信号，但总想着再坚持一下，即使家人一再催促，我也始终没有进行必要的检查。直到几乎完全无法进食（吃任何东西都马上会吐）才不得已去了医院，确诊十分迅速，因为已经没有了讨论的必要。此时，肌酐在 2100+，血红蛋白 46，按照医生的话来说，能活着走到医院已经属于大惊喜了。

由于贫血严重，输了几次血，但血红蛋白并没有得到太大的改善。为了尽快进行较彻底的透析，在与医生商量后，尽管血红蛋白不足 60，还是强行进行了植入透析管的手术，开启了我的透析生涯。

透析

透析有两种形式：一种是血液透析（大多数人知道的透析方式），另一种是腹膜透析。血液透析通常在指定的血液透析中心（或医院）进行，每周三次，每次四个小时。腹膜透析则可以在家中进行，每天透析次数根据患者的身体情况而有所变化，通常为 2 到 5 次，每次透析液置换时间约为 20 分钟。

我选择了腹膜透析。相较于血液透析，腹膜透析的场地和时间更自由。另外，腹膜透析通常对残肾功能保护比较好，有利于日后的移植。腹膜透析也有两种方式，一种是手动，就是每天手工进行几次透析液的置换操作。另一种则是自动透析（APD），通常是每天临睡前将腹部的透析管连接到设备上。在患者睡眠的过程中，设备会进行多次的液体交换。早上醒来的时候便将腹透管与设备断开，白天与正常人一样可以自由行动。有这么多的优势，我自然会选择自动透析的方式。

理想很丰满，现实很残酷。透析后发现我的腹膜滲透能力不是太好。仅依赖夜间的透析机进行透析完全无法满足排出毒素和水分的需要。因此，在此基础上逐渐增加了白天的手动透析操作。到移植前，我白天需要进行 5 次手工操作，夜间进行 12 个小时的机器自动透析。已然创下了我所在地区的透析记录。

经过几个月的透析治疗，随着身体状况的逐步改善，家人便联系了移植医院，催促我进行移植手术。但是，处于某种考虑，当时我并没有太基于进行移植。在外人看来，透析是一种无趣、繁琐、束缚人的治疗方式，但对我来说，它是一种身心调理。在这几年的透析治疗中，我的心态发生了巨大的转变，变得更加平和从容。此外，透析还让我的生活变得十分有规律，为我日后的健康生活打下了基础。

移植

最终，在进行了四年的透析后，我选择进行肾移植。为了能够更好地应对这次手术，我在准备移植前已经进行了一年有针对性的锻炼。再加上之前有意无意地“错过”了几次移植的机会，在接到医院的电话时，我十分平静。内心很笃定手术会成功。

不过事情似乎没有想的那么顺利。手术当天还是出现了不理想的状况，本来只需要 4 到 6 个小时的手术进行了接近 10 个小时。而且在手术后的第五天，从很多指标上看，手术似乎出现了明显失败的迹象。最重要的是，医生怀疑移植肾出现了破碎的可能，于是又进行了一次手术。在第二次手术前，尽管从各方面的指标上来看问题不小，但我个人感觉异常良好，因此我是抱着十分轻松的心态接受第二次手术。事后从妻子的口中得知，当时医生已经让家人做最坏打算了。第二次手术进行的时间不比第一次少，而且同第一次一样，出现了十分严重的术后反应。经过 ICU 的洗礼，人没有太大的事情。好消息是，第二次手术确认了第一次手术没有太大的问题，移植肾也无大碍。

在突破了该医院移植的最长住院记录后，经过 35 天，我终于回到了家，进入了术后康复阶段。

康复

回到家后马上遇到了几个十分棘手的问题。

第一个是体能太差。这是因为在进行第二次手术后，创口部分又出现了一次比较严重的出血情况。为了加快速度，两个医生在加护病房中对创口进行了紧急处置。经过这次治疗，我被要求只能用一个姿势躺着。经过了 20 多天的卧床，虽然伤口问题不大了，但下肺萎缩严重。刚回到家一个月里，即使在静息的状态下，心率也在 100 以上。为了改善体能，我从手术后 2 个月便开始恢复体能锻炼，并将这个习惯一直保持至今，现在每天也会进行一到两个小时的健身。

第二个症状是神经震颤，这是药物他克莫司所具备的副作用，强度因人而异，而我显然是反应比较大的那个。当时手已经很难拿住筷子了，情况与帕金森症很类似。为了改善这种情况，我尝试每天写毛笔字，不是为了练字，主要是提高自己的控制力。随着药量的减少、身体对药物的逐步适应，在手术一年后，这个症状得到了明显的改善。目前除了做一些很精细的操作外，基本上看不出有什么异常。

第三点是脑子出现了问题。大量的麻醉以及短期内高剂量的激素治疗让我的思维出现了明显的窒塞。在手术后的三到四个月中，我几乎无法通过短信发出一段没有错误的文字，基本上是脑子知道想要什么，但表述总是有问题。好在自己对这种情况有清晰的认识，努力尝试通过阅读、思考、交流、学习来改善这种状况。学习 Swift、SwiftUI、Core Data 也是在这个背景下自己主动采用的一种治疗措施，想了解这段时间的情况，可以阅读 老人新兵 —— 一款 iOS APP 的开发手记一文。

应该说，几年的透析生活给了我相当大的帮助。在移植手术后的这几年，我保持了相当健康的生活方式和乐观的心态。经过数年的调养，身体的指标也越来越好。

这是我每个月经常性检查的一些指标，通过这些指标可以看出，我的肾功指标在移植后逐年好转直至正常。大多数移植患者的指标在移植后很短的时间（几天到几周）都会恢复正常，然后随着时间的推移逐渐再出现问题。而我至少到目前来看，指标还处于上升通道中。希望能够继续保持下去。

只有经过长时间的积累，才能看出数据的价值。使用“健康笔记”App，我不仅对自己的身体指标有了清晰的认识，而且这些数据给我和医生提供了重要的参考指标，让我能有针对性地调整身体。如果你或你的家人、朋友需要长期跟踪健康数据，可以尝试使用该应用程序。请注意，该应用程序最初是为我自己编写的，对新手不够友好，但功能非常实用。

未来

尽管这些年，身体出现了或多或少的问题，不过我还是非常幸运的。遇到了善良的器官捐赠者，有最爱我的家人，总能转危为安的运气、一直碰到不错的医护，以及获得了很多朋友的支持。

明年我就到了知天命的年龄，希望能以平和的心态继续积极、健康地生活下去，做一些自己想做并且对社会有意义的事情。

祝大家身体健康。

前言

大家好，我是 simple ，我的理想是利用科技手段来解决生活中遇到的各种问题。

众所周知，感觉是最不靠谱的东西，这完全取决于主观意识。我们做性能优化一定要取决于一些指标，而Performance API向我们提供了访问和测量浏览器性能相关信息的方式。通过它，我们可以获取有关页面加载时间、资源加载性能、用户交互延迟等详细信息，用于性能分析和优化，而不是完全靠自己的感官意识，感觉更快了或者更慢了。

指标收集

1. Navigation Timing API - 页面加载时间

// 获取页面加载时间相关的性能指标

const navigationTiming = performance.timing;

console.log('页面开始加载时间: ', navigationTiming.navigationStart);

console.log('DOMContentLoaded 事件发生时间: ', navigationTiming.domContentLoadedEventEnd);

console.log('页面加载完成时间: ', navigationTiming.loadEventEnd);

console.log('页面从加载到结束所需时间',navigationTiming.loadEventEnd - navigationTiming.navigationStart)

2. Resource Timing API - 资源加载性能

// 获取资源加载性能数据

const resources = performance.getEntriesByType('resource');

resources.forEach(resource => {

  console.log('资源 URL: ', resource.name);

  console.log('资源开始加载时间: ', resource.startTime);

  console.log('资源加载结束时间: ', resource.responseEnd);

  console.log('资源加载持续时间: ', resource.duration);

});