前言

“所有直觉性的 “当然应该加分号” 都是保守的、未经深入思考的草率结论。” —— 尤雨溪。

重新认识分号在代码中的作用，为什么要写分号？又为什么可以没有分号？

踩的坑

写一个方法将秒数转为“xx天xx时xx分xx秒”的形式

const ONEDAYSECOND = 24 * 60 * 60

const ONEHOURSECOND = 60 * 60

const ONEMINUTESECOND = 60



function getQuotientandRemainder(dividend,divisor){

	const remainder = dividend % divisor

	const quotient = (dividend - remainder) / divisor

	return [quotient,remainder]

}



function formatSeconds(time){

	let restTime,day,hour,minute

	restTime = time

	[day,restTime] = getQuotientandRemainder(restTime,ONEDAYSECOND)

	[hour,restTime] = getQuotientandRemainder(restTime,ONEHOURSECOND)

	[minute,restTime] = getQuotientandRemainder(restTime,ONEMINUTESECOND)

	return day + '天' + hour + '时' + minute + '分' + restTime + '秒'

}

console.log(formatSeconds(time)) // undefined天undefined时undefined分NaN,NaN秒

按照这段代码执行完后，day、hour、minute这些变量得到的都是 undefined，而 restTime 则好像得到一个数组。

问题就在于 13、14、15、16 行之间没有添加分号，导致解析时，没有将这三行解析成三条语句，而是解析成一条语句。最终的表达式就是这样的：

restTime = time[day,restTime] = getQuotientandRemainder(restTime,ONEDAYSECOND)[hour,restTime] = getQuotientandRemainder(restTime,ONEHOURSECOND)[minute,restTime] = getQuotientandRemainder(restTime,ONEMINUTESECOND)

那执行的过程相当于给 restTime 进行赋值，表达式从左往右执行，最终表达式的值为右值。最右边的值就是 getQuotientandRemainder(restTime,ONEMINUTESECOND)，由于在计算过程中 restTime 还没有被赋值，一直是 undefined，所以经过 getQuotientandRemainder 计算后得到的数组对象每个成员都是 NaN，最终赋值给 restTime 就是这样一个数组。

分号什么时候会“自动”出现

有时候好像不写分号也不会出问题，比如这种情况：

let a,b,c

a = 1

b = 2

c = 3

console.log(a,b,c) // 1 2 3

这是因为，JS 进行代码解析的时候，能够识别出语句的结束位置并“自动添加分号“，从而能够解析出“正确”的抽象语法树，最终执行的结果也就是我们所期待的。

JS 有一个语法特性叫做 ASI (Automatic Semicolon Insertion)，就是上面说到的”自动添加分号”的东西，它有一定的插入规则，在满足时会为代码自动添加分号进行断句，在我们不写分号的时候，需要了解这个规则，才能不踩坑。（当然这里说的加分号并不是真正的加分号，只是一种解析规则，用分号来代表语句间的界限）

ASI 规则

JS 只有在出现换行符的时候才会考虑是否添加分号，并且会尽量“少”添加分号，也就是尽量将多行语句合成一行，仅在必要时添加分号。

1. 行与行之间合并不符合语法时，插入分号

比如上面那个自动添加分号的例子，就是合并多行时会出现语法错误。

a = 1b = 2 这里 1b 是不合法的，因此会加入分号使其合法，变为 a = 1; b = 2

2. 在规定[no LineTerminator here]处，插入分号

这种情况很有针对性，针对一些特定的关键字，如 return continue break throw async yield，规定在这些关键字后不能有换行符，如果在这些关键字后有了换行符，JS 会自动在这些关键字后加上分号。
看下面这个例子🌰：

function a(){

	return

	123

}

console.log(a()) // undefined



function b(){

	return 123

}

console.log(b()) // 123

在函数a中，return 后直接换行了，那么 return 和 123 就会被分成两条语句，所以其实 123 根本不会被执行到，而 return 也是啥也没返回。

3. ++、--这类运算符，若在一行开头，则在行首插入分号

++ 和 -- 既可以在变量前，也可以在变量后，如果它们在行首，当多行进行合并时，会产生歧义，到底是上一行变量的运算，还是下一行变量的运算，因此需要加入分号，处理为下一行变量的运算。

a

++

b

// 添加分号后

a

++b

如果你的预期是：

a++ 

b

那么就会踩坑了。

4. 在文件末尾发现语法无法构成合法语句时，会插入分号

这条和 1 有些类似

不写分号时需要注意⚠️

上面的 ASI 规则中，JS 都是为了正确运行代码，必须按照这些规则来分析代码。而它不会做多余的事，并且在遵循“尽量合并多行语句”的原则下，它会将没有语法问题的多行语句都合并起来。这可能违背了你的逻辑，你想让每行独立执行，而不是合成一句。开头贴出的例子，就是这样踩坑的，我并不想一次次连续的对数组进行取值🌚。

因此我们要写出明确的语句，可以被合并的语句，明确是多条语句时需要加上分号。

(如果你的项目中使用了某些规范，它不想让你用分号，别担心，它只是不想让你在行尾用分号，格式化时它会帮你把分号移到行首）像这样：

// before lint

restTime = time;

[day, restTime] = getQuotientandRemainder(restTime, ONEDAYSECOND);

[hour, restTime] = getQuotientandRemainder(restTime, ONEHOURSECOND);

[minute, restTime] = getQuotientandRemainder(restTime, ONEMINUTESECOND);



// after lint

restTime = time

;[day, restTime] = getQuotientandRemainder(restTime, ONEDAYSECOND)

;[hour, restTime] = getQuotientandRemainder(restTime, ONEHOURSECOND)

;[minute, restTime] = getQuotientandRemainder(restTime, ONEMINUTESECOND)

参考

• juejin.cn/post/686413…


• juejin.cn/post/693286…


• developer.aliyun.com/article/916…


• http://www.zhihu.com/question/20…

我们知道 localStorage 中的数据是长期保存的，除非手动删除，否则他会一直存在。如果我们想实现一种数据有过期时间的存储方式，该怎么实现呢？

首先应该想到的是 cookie，cookie 本身就有有效期的配置，当某个 cookie 时，浏览器自动清理该 cookie。可是使用 cookie 存储数据，有个不好的地方，很多我们存储的数据，本就是我们前端自己用到的，后端根本用不到。可是存储到 cookie 中后，页面中所有的 cookie 都会随着请求发送给后端，造成传输的 cookie 比较长，而且没有必要。

因此，我们可以基于 localStorage 来实现一套这样的有过期时间的存储方式。我们在之前的文章 如何重写 localStorage 中的方法 中，也了解了一些重写 localStorage 的方法。这里我们是自己在外层封装一层的方式，来调用 localStorage。

我这里封装的类名叫： LocalExpiredStorage，即有过期时间的 localStorage。

1. 实现与 localStorage 基本一致的 api

我们为了实现跟 localStorage 使用上的一致性体验，这里我们自己的 api 名称和实现方式跟 localStorage 基本一致。

interface SetItemOptions {

  maxAge?: number; // 从当前时间往后多长时间过期

  expired?: number; // 过期的准确时间点，优先级比maxAge高

}



class LocalExpiredStorage {

  private prefix = "local-"; // 用于跟没有过期时间的key进行区分



  constructor(prefix?: string) {

    if (prefix) {

      this.prefix = prefix;

    }

  }



  setItem(key: string, value: any, options?: SetItemOptions) {}

  getItem(key: string): any {}

  removeItem(key: string) {}

  clearAllExpired() {}

}

const localExpiredStorage = new LocalExpiredStorage();

export default localExpiredStorage;

可以看到我们实现的类里，有三个变化：

上面是我们的大致框架，接下来我们来具体实现下这些方法。

2. 具体实现

接下来我们来一一实现这些方法。

2.1 setItem

这里我们新增了一个 options 参数，用来配置过期时间：

• expired: 固定的过期时间点，比如点击关闭按钮，当天不再展示，那过期时间就是今天晚上的 23:59:59，可以使用该属性；


• maxAge: 从当前时间起，设置多长时间后过期；比如点击某个提示，3 天内不再展示，使用该属性就比较方便；

假如两个属性都设置了，我这里约定 expired 属性的优先级更高一些。

class LocalExpiredStorage {

  private prefix = "local-"; // 用于跟没有过期时间的key进行区分



  constructor(prefix?: string) {

    if (prefix) {

      this.prefix = prefix;

    }

  }



  setItem(key: string, value: any, options?: SetItemOptions) {

    const now = Date.now();

    let expired = now + 1000 * 60 * 60 * 3; // 默认过期时间为3个小时



    // 这里我们限定了 expired 和 maxAge 都是 number 类型，

    // 您也可以扩展支持到 string 类型或者如 { d:2, h:3 } 这种格式

    if (options?.expired) {

      expired = options?.expired;

    } else if (options?.maxAge) {

      expired = now + options.maxAge;

    }



    // 我们这里用了 dayjs 对时间戳进行格式化，方便快速识别

    // 若没这个需要，也可以直接存储时间戳，减少第三方类库的依赖

    localStorage.setItem(

      `${this.prefix}${key}`,

      JSON.stringify({

        value,

        start: dayjs().format("YYYY/MM/DD hh:mm:ss"), // 存储的起始时间

        expired: dayjs(expired).format("YYYY/MM/DD hh:mm:ss"), // 存储的过期时间

      })

    );

  }

}

我们在过期时间的实现过程中，目前只支持了 number 类型，即需要传入一个时间戳，参与运算。您也可以扩展到 string 类型（比如'2024/11/23 14:45:34'）或者其他格式{ d:2, h:3 } 这种格式。

设置好过期时间后，我们将 value，存储的起始时间和过期时间，转义成 json string 存储起来。我们这里用了 dayjs 对时间戳进行格式化，方便开发者可以快速地识别。若没有这个需要，也可以直接存储时间戳，减少第三方类库的依赖。

该方法并没有支持永久存储的设定，若您需要永久存储，可以直接使用 localStorage 来存储。

2.2 getItem

获取某 key 存储的值，主要是对过期时间的判断。

class LocalExpiredStorage {

  private prefix = "local-"; // 用于跟没有过期时间的key进行区分



  constructor(prefix?: string) {

    if (prefix) {

      this.prefix = prefix;

    }

  }



  getItem(key: string): any {

    const result = localStorage.getItem(`${this.prefix}${key}`);

    if (!result) {

      // 若key本就不存在，直接返回null

      return result;

    }

    const { value, expired } = JSON.parse(result);

    if (Date.now() <= dayjs(expired).valueOf()) {

      // 还没过期，返回存储的值

      return value;

    }

    // 已过期，删除该key，然后返回null

    this.removeItem(key);

    return null;

  }

  removeItem(key: string) {

    localStorage.removeItem(`${this.prefix}${key}`);

  }

}

在获取 key 时，主要经过 3 个过程：

这里我们在删除数据时，使用了this.removeItem()，即自己实现的删除方法。本来我们也是要实现这个方法的，那就直接使用了吧。

2.3 clearAllExpired

localStorage 中的数据并不会自动清理，我们需要一个方法用来手动批量清理已过期的数据。

class LocalExpiredStorage {

  private prefix = "local-"; // 用于跟没有过期时间的key进行区分



  clearAllExpired() {

    let num = 0;



    // 判断 key 是否过期，然后删除

    const delExpiredKey = (key: string, value: string | null) => {

      if (value) {

        // 若value有值，则判断是否过期

        const { expired } = JSON.parse(value);

        if (Date.now() > dayjs(expired).valueOf()) {

          // 已过期

          localStorage.removeItem(key);

          return 1;

        }

      } else {

        // 若 value 无值，则直接删除

        localStorage.removeItem(key);

        return 1;

      }

      return 0;

    };



    const { length } = window.localStorage;

    const now = Date.now();



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

      const key = window.localStorage.key(i);



      if (key?.startsWith(this.prefix)) {

        // 只处理我们自己的类创建的key

        const value = window.localStorage.getItem(key);

        num += delExpiredKey(key, value);

      }

    }

    return num;

  }

}

在项目的入口处添加上该方法，用户每次进入项目时，都会自动清理一次已过期的 key。

3. 完整的代码

上面我们是分步讲解的，这里我们放下完整的代码。同时，我也在 GitHub 上放了一份：wenzi0github/local-expired-storage。

interface SetItemOptions {

  maxAge?: number; // 从当前时间往后多长时间过期

  expired?: number; // 过期的准确时间点，优先级比maxAge高

}



class LocalExpiredStorage {

  private prefix = "local-"; // 用于跟没有过期时间的key进行区分



  constructor(prefix?: string) {

    if (prefix) {

      this.prefix = prefix;

    }

  }



  // 设置数据

  setItem(key: string, value: any, options?: SetItemOptions) {

    const now = Date.now();

    let expired = now + 1000 * 60 * 60 * 3; // 默认过期时间为3个小时



    // 这里我们限定了 expired 和 maxAge 都是 number 类型，

    // 您也可以扩展支持到 string 类型或者如 { d:2, h:3 } 这种格式

    if (options?.expired) {

      expired = options?.expired;

    } else if (options?.maxAge) {

      expired = now + options.maxAge;

    }



    // 我们这里用了 dayjs 对时间戳进行格式化，方便快速识别

    // 若没这个需要，也可以直接存储时间戳，减少第三方类库的依赖

    localStorage.setItem(

      `${this.prefix}${key}`,

      JSON.stringify({

        value,

        start: dayjs().format("YYYY/MM/DD hh:mm:ss"), // 存储的起始时间

        expired: dayjs(expired).format("YYYY/MM/DD hh:mm:ss"), // 存储的过期时间

      })

    );

  }



  getItem(key: string): any {

    const result = localStorage.getItem(`${this.prefix}${key}`);

    if (!result) {

      // 若key本就不存在，直接返回null

      return result;

    }

    const { value, expired } = JSON.parse(result);

    if (Date.now() <= dayjs(expired).valueOf()) {

      // 还没过期，返回存储的值

      return value;

    }

    // 已过期，删除该key，然后返回null

    this.removeItem(key);

    return null;

  }



  // 删除key

  removeItem(key: string) {

    localStorage.removeItem(`${this.prefix}${key}`);

  }



  // 清除所有过期的key

  clearAllExpired() {

    let num = 0;



    // 判断 key 是否过期，然后删除

    const delExpiredKey = (key: string, value: string | null) => {

      if (value) {

        // 若value有值，则判断是否过期

        const { expired } = JSON.parse(value);

        if (Date.now() > dayjs(expired).valueOf()) {

          // 已过期

          localStorage.removeItem(key);

          return 1;

        }

      } else {

        // 若 value 无值，则直接删除

        localStorage.removeItem(key);

        return 1;

      }

      return 0;

    };



    const { length } = window.localStorage;

    const now = Date.now();



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

      const key = window.localStorage.key(i);



      if (key?.startsWith(this.prefix)) {

        // 只处理我们自己的类创建的key

        const value = window.localStorage.getItem(key);

        num += delExpiredKey(key, value);

      }

    }

    return num;

  }

}

const localExpiredStorage = new LocalExpiredStorage();

export default localExpiredStorage;

使用：

localExpiredStorage.setItem("key", "value", { maxAge: 5000 }); // 有效期为5000毫秒

localExpiredStorage.setItem("key", "value", {

  expired: Date.now() + 1000 * 60 * 60 * 12,

}); // 有效期为 12 个小时，自己计算到期的时间戳



// 获取数据

localExpiredStorage.getItem("key");



// 删除数据

localExpiredStorage.removeItem("key");



// 清理所有过期的key

localExpiredStorage.clearAllExpired();

4. 总结

这个功能本身不难，也有很多开发者自己实现过。这里我也是总结下之前实现的过程。

• wenzi0github/local-expired-storage

各位朋友听我一句劝，写代码提供方法给别人调用时，不管是内部系统调用，还是外部系统调用，还是被动触发调用（比如MQ消费、回调执行等），一定要加上必要的条件校验。千万别信某些同事说的这个条件肯定会传、肯定有值、肯定不为空等等。这不，临过年了我就被坑了一波，弄了个生产事故，年终奖基本是凉了半截。

为了保障系统的高可用和稳定，我发誓以后只认代码不认人。文末总结了几个小教训，希望对你有帮助。

一、事发经过

我的业务场景是：业务A有改动时，发送MQ，然后应用自身接受到MQ后，再组合一些数据写入到Elasticsearch。以下是事发经过：

SELECT xxx,xxx,xxx,xxx FROM 一张大表

6. 立马Kill掉几个慢会话之后，发现系统仍然没有完全恢复，为啥呢？现在数据库已经正常了，怎么还没完全恢复呢？又继续看了应用监控，发现用户中心的10个Pod里有2个Pod异常了，CPU和内存都爆了。难怪使用时出现偶发性的异常呢。于是赶紧重启Pod，先把应用恢复。


7. 问题找到了，接下来就继续排查为什么用户中心的Pod挂掉了。从以下几个怀疑点开始分析：
   
   
   
   
   1. 同步数据到Elasticsearch的代码是不是有问题，怎么会出现连不上Redis的情况呢？
   
   
   2. 会不会是异常过多，导致发送异常告警消息的线程池队列满了，然后就OOM？
   
   
   3. 哪里会对那张业务A的大表做不带条件的全表查询呢？
   
   
   
   


8. 继续排查怀疑点a，刚开始以为：是拿不到Redis链接，导致异常进到了线程池队列，然后队列撑爆，导致OOM了。按照这个设想，修改了代码，升级，继续观察，依旧出现同样的慢SQL 和 用户中心被干爆的情况。因为没有异常了，所以怀疑点b也可以被排除了。


9. 此时基本可以肯定是怀疑点c了，是哪里调用了业务A的大表的全表查询，然后导致用户中心的内存过大，JVM来不及回收，然后直接干爆了CPU。同时也是因为全表数据太大，导致查询时的元数据锁时间过长造成了连接不能够及时释放，最终几乎被耗尽。


10. 于是修改了查询业务A的大表必要校验条件，重新部署上线观察。最终定位出了问题。

嗨，我们又见面了！今天我要和大家分享一个前端工程师都会遇到的问题：如何优化移动端网络请求。相信很多人都用过 axios 或 fetch API，但你是否觉得处理分页逻辑、缓存、请求防抖等很麻烦呢？别担心，我找到了一个解决方案——Alova.js。

Alova.js 是一个轻量级的请求策略库，它可以帮助我们简化网络请求的编写，让我们更专注于业务逻辑。它提供了多种服务端数据缓存模式，比如内存模式和持久化模式，这些都能提升用户体验，同时降低服务端的压力。而且，Alova.js 只有 4kb+，体积是 axios 的 30%，非常适合移动端使用。

Alova.js 的基础请求功能非常简单，比如你可以这样请求数据：

const todoDetail = alova.Get('/todo', { params: { id: 1 } });

const { loading, data, error } = useRequest(todoDetail);

它还提供了分页请求、表单提交、验证码发送、文件上传等多种请求策略，大大减少了我们的工作量。比如，使用分页请求策略，你只需要这样：

const {

  loading,

  data,

  isLastPage,

  page,

  pageSize,

  pageCount,

  total,

} = usePagination((page, pageSize) => queryStudents(page, pageSize));

怎么样，是不是很简单？Alova.js 还支持 Vue、React、React Native、Svelte 等多种前端框架，以及 Next、Nuxt、SvelteKit 等服务端渲染框架，非常适合现代前端开发。

感兴趣的话，可以去 Alova.js 的官网看看：Alova.js 官网。也可以在评论区分享你对 Alova.js 的看法哦！嘿嘿，今天就聊到这里，下次见！👋
有任何问题，你可以加入以下群聊咨询，也可以在github 仓库中发布 Discussions，如果遇到问题，也请在github 的 issues中提交，我们会在最快的时间解决。

有一定规模的 IT 公司，只要几年，必然存在大量的代码，比如腾讯，2019 年一年增加 12.9 亿行代码，现在只会更多。不管是对于公司，还是对于个人，怎么低成本的了解这些代码的对应业务，所提供的能力，都是非常有必要的！

今天，阿七就带大家破解这个难题，根据这个文档，你能使用 AI 编程技术，根据包含 Java 完整代码的项目实现可视化下面三个方面的内容：

• 模块和功能：应用内部的业务模块和功能，及相互间的关系，为用户提供应用的整体视图。


• 类和接口：应用模块提供的业务能力以及对应的类和接口，以及接口对应业务流程语义化。


• 方法实现语义化：方法实现逻辑的语义化和可视化；

一、先秀一下成果

一）Java 项目概览图

根据一个 Java 项目，可以生成下面这样的项目整体概览图，对于不需要了解实现细节的产品、运营同学，直接看这个图，就能够了解这个 Java 项目在干什么、能提供什么能力。

对于部分技术同学，不需要了解代码详情的，也可以直接看这个图即可。满足新入职同学对于接手不常变更项目的理解和全局业务的了解！

PS：由于保密需要，所有的成果图仅为示例图。实际的图会更好看、更震撼，因为一个 Java 项目的功能模块可能很多，提供的能力可能很多。

对于需要了解技术细节的同学，点击入口，能看到当前方法的流程图，快速了解当前方法提供的能力，具体的细节。还能迅速发现流程上可能存在的问题，快速纠正。

二）具体方法流程图

有了上面的两层可视化图表，不管是产品、技术、测试、运营以及小领导，都能快速的根据一个 Java 项目获取到他所需要的层级的信息，降低开发人员通过阅读代码梳理业务逻辑和代码逻辑的时间，尤其是新入职的同学。这个时间据统计，基本上在 25%-30%（百度、阿里等大公司调研数据更大，为 55%-60%），对于新同学，这个比例会更大！

二、实现步骤

一）整体概述图怎么生成？

一个 Java 项目所有对外接口在做的事情，就是一个 Java 项目的核心业务。这个对外接口包括：HTTP 接口、Dubbo 接口、定时任务。

1、获取一个 Java 项目所有对外接口

1）通过 Trace 平台

可以查询到一个 Java 项目所有对外的 HTTP 接口和 Dubbo 接口，通过注解可以查询一个 Java 项目所有定时任务。

优点：

• 数据准确，跑出来的数据，一定是还在用的接口；
  缺点：


• 需要依赖 Trace 平台数据，部分公司可能没有 Trace 平台。

2）通过 JavaParser 工具

可以通过 JavaParser 工具，扫描整个 Java 项目代码。找到所有的对外入口。

优点：

• 不依赖 Trace 数据；
  缺点：


• 可能不准确，因为有些接口已经不被使用了。

2、获取对外接口的方法内容

1）根据 HTTP 的接口 url 可以反解析出来这个 url 对应的方法的全路径。

具体来说，在项目中获取 Spring 上下文，Spring 上下文中有一个 Bean 叫 RequestMappingHandlerMapping，这个 Bean 中提供了一个方法 getHandlerMethods，这个方法中保存了一个 Java 项目中所有的对外 HTTP 方法。

这个方法返回一个 Map对象，key 是 HTTP 接口的 URL，value 就是这个 URL 对应方法的全路径名称。

2）根据方法全路径，获取方法内容

根据上面的全路径名，使用 Spoon 框架我们能拿到对应方法的方法体。

    fr.inria.gforge.spoon

    spoon-core

我们让 ChatGPT 帮我们写代码，提示词：

写一个 Java 方法，使用 Spoon 框架解析 Java 方法的完整内容
其中入参是方法全路径名

PS：这个代码一会还有用，我们往下递归的话，能拿到这个 Controller 方法调用的所有方法体。

3、根据方法内容生成方法注释

就和 GitHub Copilot 和百度 Comate 代码助手一样，GPT 可以根据代码生成方法注释，提示词：

角色： 你是一个 Java 技术专家。

任务： # 号开头的是一个 Java 方法。请你逐行阅读代码，然后为这个 Java 方法生成一句话注释。

限制：不要超过 20 个字

举个例子，我有个工具方法，使用 GPT 为他生成注释，如下：

4、生成 Java 项目一句话描述

角色： 你是一个 Java 技术专家。

任务： --- 符号以上的是一个 Java 项目中所有对外方法的注释，请你逐行阅读这些注释，然后给这个 Java 项目生成一句话描述。

限制： 结果不要超过两句话。

这个利用的是 GPT 的总结概要的能力，GPT 能总结论文、总结文章，他也能总结一段描述 Java 项目的文字。这样就能获取对于一个 Java 项目的一句话描述，也就是项目概览图的第一层。

5、总结：生成项目概览图

我们要求 GPT 根据 Java 项目的一句话描述，和所有对完方法的方法注释，生成思维导图数据。为了项目概览图的层级更可读、更清晰，我们可以要求 GPT 根据方法注释的相似性进行分类，形成项目概览图的第二层。第三层就是所有项目中对外方法的注释。

生成思维导图，可以让 GPT 根据结构内容生成 puml 格式的思维导图数据，我们把 puml 格式的数据存储为 puml 文件，然后使用 xmind 或者在线画图工具 processOn 打开就能看到完整的思维导图。

参考提示词如下：

应用代码：appCodeValue

项目描述：appCodeDescValue

项目描述：appCodeDescValue

方法描述：methodDescListValue

角色：你是一个有多年经验的 Java 技术专家，在集成 Java 项目方面有丰富的经验。

任务：根据 Java 项目中所有公共接口的描述信息生成思维导图。

要求：思维导图只有四个层级。

详细要求：思维导图的中心主题是 appCodeValue，第一层分支是 appCodeDescValue；第二层分支是公共接口的分类；下层分支是每个分类下方法的描述信息。

返回正确格式的 opml 思维导图 xml 数据，并且内容是中文。

二）流程图怎么生成？

1、获取递归代码

直接问 GPT，让 GPT 改造上面的获取方法体的方法。

prompt;

{获取方法体的方法}

上面的 Java 代码是使用 Spoon 框架解析 Java 方法的完整内容
其中入参是方法全路径名

任务：现在要求你改造这个方法，除了打印当前方法的完整内容，还要求递归打印所有调用方法的方法体内容，包含被调用方法调用的方法

这样，我们能获取到一个 controller 方法所有递归调用的方法，每个方法生成自己的流程图，最后通过流程图嵌套的形式进行展示。

比如这个例子，当前能看到的是当前方法的流程图，带 + 号的内容，是当前方法调用方法的流程图。这样方便我们按照自己需要的深度去了解当前方法的具体实现流程！

2、无效代码剪枝

按照上面生成的流程图可能分支很多，还有一些无效的信息，影响用户判断，我们可以通过删除一些业务无关代码的方法，精简流程图。

比如，我们可以删除日志、监控等与业务逻辑无关的代码，删除没有调用的代码（现在市面上有些这种技术方案，可以检测当前项目中没有被实际调用的代码）。

3、生成流程图

先让 GPT 根据代码生成结构化的 Json 数据。

给你一段 Java 代码，请你使用 spoon 输出结构化的 Json 数据。要求：请你直接输出结构的 json 结果数据，不需要过程代码

然后，可以让 GPT 根据 Json 数据生成流程图数据，使用流程图工具打开即可。

给你一段 Spoon 结构化 Java 代码的 Json 数据，整理对应 Java 代码的意思，生成一个流程图数据，流程图使用 PlantUML。现在请输出能直接绘制 PlantUML 图的数据

三、改进方案

我们可以从下面几个方面改进这个项目，从而实现真正落地，解决实际公司需求：

四、总结

AI 在编程领域，除了大厂都在卷的代码助手，结合自己公司还有很多可探索的地方，比如本文说的可视化 Java 项目，还可以通过分析日志，进行异常、故障的根因分析，做到快速定位问题，帮助快速解决问题，减少影响。

如果故障根因分析这个工具做出来了，阿里云的 P0 故障，滴滴的 P0 故障，还有很多大中小厂的故障，是不是能更快恢复？减少声誉、金钱损失？

就说，项目可视化这个需求，据我了解的内部消息，有些互联网中大厂已经在使用这个方式进行落地了。另外，我陪伴群里也有同学接触到了类似不少甲方的类似的强需求，如果想深入这块技术的同学，不管是进互联网大厂还是做自己的副业产品都是不错的方向！

一、背景

刚入职了一家新公司，摸鱼式的把每个项目都打开看了下。不够五分钟便惊出了一身冷汗，午饭时分，便和领导聊了下这些项目中的通病。其中就有一个问题就是代码复用的问题，一个Vue文件6000多行代码，多个文件中还有很多重复的代码。领导听了休息了片刻便拍案而起，好的小陈你就把这几个类似的页面抽出来吧！我:。。。。默默扒饭。

二、问题和方案

类似登录页这种几百年不变的页面，多个项目不管是逻辑还是UI基本上都是一样的，多个项目要用。虽然CV也挺快，但是如果逻辑一改的话，yi那其实还是挺麻烦的。（领导视角）

方案一：Iframe嵌入主项目❌

一开始是想把要引入的页面打包然后通过Iframe引入，但是这样的话会存在域不同的问题，而无法随心所欲的操作本地存储之类的东西。虽然可以用postMessage的方法进行通信传输数据，但是要传输到主页面的信息一多的话，很难分清楚哪个数据是所需要的。在尝试了半天之后，PASS了这个方案。

方案二：将页面打包成组件，然后在主项目中注册且使用✔

通过采用lib库模式打包Vue页面为组件，然后在主项目中引入，便可以实现页面的复用。然后引入组件也可以自由的访问本地存储等东西。
打包命令：

vue-cli-service build --target lib --name main --dest lib src/components/index.js

详情可以参考官网的指南
构建目标 | Vue CLI (vuejs.org)

接下来便是痛苦且折磨的试错之路😖

初步实现

接下来看下这两个文件的具体内容

Main下面的index.js

components下面的index.js

看了下这两个文件的内容，写过Vue插件的铁铁们应该都很熟悉，对其实就是把页面当成组件了。有的铁铁举手问，小陈那个initRouter是啥呀，小陈后面为铁铁们解答，我们一步一步慢慢实现。

Main页面如下

接下来便是通过命令行打包成组件的步骤了

现在打包的项目这边的任务就告一段落，后面我们看下主项目要如何引用这个被打包的组件。

只需要在主项目的main中注册我们打包的组件就可以使用了，然后结构出来的Main和About正是刚才我们在components下index.js暴露的两个组件，componentPage则是components下index.js暴露的默认的install方法用于注册。启动下主项目试试就发现我们引入的两个组件都加到主项目路由里面去了。心头一甜但是隐约觉得事情没这么简单。😱

三、遇到的问题及解决策略

问题、组件需要使用主项目的路由

以登录页为例子，在用户验证完身份之后，需要跳转到主项目中的其他页面。例如跳转home需要跳转到主项目的home页面，在主项目中点击会报错，因为组件路由根本没有这个路由配置，所以需要把主项目的路由引入到组件中，那要怎么做捏？容小陈慢慢解释。

解决：在注册的时候引入主项目的路由

通过initRouter在注册组件的时候，把主项目的路由引入到组件中，然后在需要使用主项目路由的时候，使用getCurRouter给组件路由赋值成主项目的路由即可。只不过在使用router的js文件都需要使用getCurRouter。Vue文件中则不需要做任何配置，因为this.router/this.route访问的均是主项目的路由。

组件的路由文件配置

组件下components的index.js配置

Main中跳转的方法

顺便一提：判断生产还是开发环境都是为了开发的时候，不用做额外的配置，只是方法比较笨。如果大佬们有更好的方法麻烦踢一下小陈。

总结

这是小陈第一次在掘金上写文章，可能这篇文章的作用不是很大，但也是记录小陈解决问题的载体。文章有啥不清楚的或者不合理的地方还麻烦铁铁们和小陈促膝长谈。但是此次的实践还是让小陈对Vue的一些知识这块有了新的理解。然后日后还请大佬们多多指教。

Demo的地址: only-for-test: 仅用来测试的仓库 (gitee.com)

前言

最近负责了一个产品的前端代码Code Review的工作，90%代码是从之前做过的一个项目merge过来的，由于当时开发周期紧张，没有做好足够的Code Review流程，导致代码质量很差，而产品的代码质量要求就很高。

前端开发30个左右，技术经验高的10年左右，低的2-3年，经过几轮的code review，整理几个比较常见，比较典型的例子，简单的总结下。

ESLint

首先，可以引入 ESLint 静态代码检测工具，它可以保证高质量的代码，尽量减少和提早发现一些错误。同时也支持IDE自动检查提示。

具体可以参考之前的文章：
ESLint配合VSCode 统一团队前端代码规范

IDE Format

当然也离不开Code Format格式化，需要配置一套固定的Format格式，保证团队内所有代码格式化统一。

我不太喜欢 Prettier 的换行机制，弄得大片大片的换行，可读性也差。团队大多用的VSCode，所以就用VSCode内置的Format功能，再加下可配置项，这样只要用VSCode开发，就会默认使用统一的代码格式化。

具体可以参考之前的文章：只用VSCode自带的Format功能，满足可配置的代码格式化需求

代码规范及习惯

下面介绍一些团队内经常遇到的代码规范、质量问题，还有一些很不好的开发习惯。

大小写

catch

这里一般是指请求后台api的catch，而且common已经封装好了fetch方法，并处理了公共异常，比如根据status提示不一样的提示语弹框：

减少非必要的可选链操作符 (?.)

产品里经常用到的操作符，用的很无脑，经常遇到这种代码：

// 1

const a = obj?.a?.b?.c?.d;



// 2

<div>{this.state?.name}</div>



// 3

const arr = list.filter(item=> ...);

if (arr?.length) { ... }



// 4

if(item.a) { ... }

fn(item?.b);



// 5

if (item) {

    fn(item?.b);

}

common 控件属性

在使用common或第三方控件时：

sessionStorage 和 localStorage

思考两个问题：

async await

这里对于新手，会有很多不正确的用法，但代码运行没问题，只是用法不规范：

fn = async () => {

    // 整个方法内部都没有用到await

}



fn = async () => {

    return await request(); // 不需要加async await

}



fn = async () => {

    const result = await request();

    return Promise.resolve(result); // 可以直接return

}

深拷贝

React Hooks

这里指React官方提供的Hooks，比如 useEffect useCallback useMemo memo 这几个“常用”的。

发现业务中使用的很频繁，这里简单说下我的理解：

• useEffect：注意第二个参数 deps，有些情况下，不是所有用到的参数都加到 deps里，会导致bug。


• useCallback、memo：大多数地方都是不需要的使用的（90%以上）。


• useMemo：复杂逻辑可以用，其它情况不需要。


• 以上，如果用的不对，反而会导致 业务bug，负优化，甚至 反向优化


• 这里说的比较浅，总结一个大致结论，详细说明网上很多。

如果提升代码经验和意识

简单总结几点:

总结

本文写的比较杂、也都比较浅，因为涉及到的知识点、经验太多了，不是三言两语就能说明白，详细的重要的点，也会在后续文章中详细讲解。

共享数据库，共享表

描述

所有租户的数据都在同一个数据库表内，以租户字段：tenant_id来区分。

优点

成本低，实现方式简单，适合中小型项目的快速实现。

缺点

• 数据隔离性差，某一个租户的数据量大的时候，会影响其他租户数据的操作效率。


• 需要在表上增加租户字段，对系统有一定的侵入性。


• 数据备份困难，因为所有租户的数据混合在一起，所以针对某个租户数据的备份、恢复会比较麻烦。

实现方式

**方式一：**编写Mybatis拦截器，拦截增删改查操作，动态的增加租户条件，如：

SELECT * FROM sys_user;

修改成：

SELECTG * FROM sys_user WHERE tenant_id = 100;

这种方案并不靠谱，因为动态修改SQL语句不是一个好的处理方式，如果SQL解析没有做好，或者出现复杂SQL，那么很容易产生bug。

**方式二：**编写Mybatis拦截器，拦截增删改查操作，判断是否有租户条件，如：

SELECT * FROM sys_user WHERE id=1;

使用jsqlparser工具解析SQL，判断出该SQL语句没有tenant_id的条件，那么抛出异常，不允许执行。

这种方案比较稳妥，因为只做判断不做修改。

查询操作的优先级不高，如果不在乎数据敏感，可以不拦截。

要注意的是修改操作，稍不注意容易被某一个租户影响其他租户的数据。

共享数据库，独立一张表

描述

所有租户的数据都在同一个数据库中，但是各自有一个独立的表，如：

# 1号租户的用户表

sys_user_1



# 2号租户的用户表

sys_user_2



...

优点

成本低，数据隔离性比共享表稍好，并且不用新增租户字段，对系统没有侵入性。

缺点

• 数据隔离性虽然比共享表好了些，但是因为仍在同一数据库下，所以某一个租户影响其他租户的数据操作效率问题依然存在。


• 数据备份困难的问题依然存在。

实现方式

**方式一：**编写Mybatis拦截器，拦截增删改查操作，动态的修改表名称，如：

SELECT * FROM sys_user;

修改成：

SELECT * FROM sys_user_1;

同样的，这种动态修改SQL语句的方式并不推荐，所以我们有另一种方式。

**方式二：**将表名作为参数传入

本来在Mapper.xml中，查询语句是这样的：

SELECT * FROM sys_user WHERE id = #{userId};

现在改成：

SELECT * FROM #{tableName} WHERE id = #{userId};

这样可以避免动态修改SQL语句操作。

独立数据库

描述

每个租户都单独分配一个数据库，数据完全独立，如：

database_1;

database_2;

...

优点

• 数据隔离性最好，不需要添加租户id字段，租户之间不会被彼此影响。


• 便于数据备份和恢复。


• 便于扩展。

缺点

• 经费成本高，尤其在有多个租户的情况下。


• 运维成本高。

结论

一般来说，当数据量不高的时候，选择共享数据库共享表的方式，表内加个租户id字段做区分，数据量或者用户量多起来，就可以直接升级到独立数据库的方式，因为独立表的方式处理起来是有些麻烦的，倒不如加个字段来的方便。

我发现了 Android 指纹认证 Api 内存泄漏

目前很多市面上的手机基本都有指纹登陆功能。Google 也提供了调用相关功能 API，安全类的App 也基本都在使用。接下来就一起捋一捋今天的主角 BiometricPrompt

先说问题，使用BiometricPrompt 会造成内存泄漏，目前该问题试了 Android 11 到 13 都发生，而且没有什么好的办法。目前想到的最好的方法是漏的少一点。当然谁有好的办法欢迎留言。

问题再现

先看动画

动画中操作如下

以下是使用 BiometricPrompt 的代码

public fun showBiometricPromptDialog() {

    val keyguardManager = getSystemService(

        Context.KEYGUARD_SERVICE

    ) as KeyguardManager;



    if (keyguardManager.isKeyguardSecure) {

        var biometricPromptBuild = BiometricPrompt.Builder(this).apply {// this is SecondActivity

            setTitle("verify")

            setAllowedAuthenticators(BiometricManager.Authenticators.DEVICE_CREDENTIAL or BiometricManager.Authenticators.BIOMETRIC_WEAK)

        }

        val biometricPromp = biometricPromptBuild.build()

        biometricPromp.authenticate(CancellationSignal(), mExecutor, object :

            BiometricPrompt.AuthenticationCallback() {



        })

    }

    else {

        Log.d("TAG", "showLockScreen:  isKeyguardSecure is false");

    }

}

以上逻辑 biometricPromp 是局部变量，应该没有问题才对。

内存泄漏如下

可以看到每启动一次生物认证，创建的 BiometricPrompt 都不会被回收。

规避方案：

修改方案也简单

方案一：

方案一存在的问题，SecondActivity 可能频繁创建，所以 biometricPromp 还会存在多个实例。

方案二（目前想到的最优方案）：

修改后，App memory 中只存在一个 biometricPromp ，且没有 Activity 被泄漏。

想到这里，应该会觉得奇怪，biometricPromp 为什么不会被回收？提供的 API 都看过了，没有发现什么方法可以解决这个问题。直觉告诉我这个可能是系统问题，下来分析下BiometricPrompt 吧。

BiometricPrompt 源码分析

App 相关信息通过 BiometricPrompt 传递到 System 进程，System 进程再通知 SystemUI 显示认证界面。

App 信息传递到 System 进程，应该会使用 Binder。这个查找 BiometricPrompt 使用哪些 Binder。

private final IBiometricServiceReceiver mBiometricServiceReceiver =

            new IBiometricServiceReceiver.Stub() {



        ......

}

源码中发现 IBiometricServiceReceiver 比较可疑，IBiometricServiceReceiver 是匿名内部类，内部是持有 BiometricPrompt 对象的引用。

接下来看下 System Server 进程信息（注：系统是 UserDebug 的手机，才可以查看，买的手机版本是不支持的）

再看下 AuthSession 的实例数

果然 AuthSession 也存在三个。

这里有个知识点，binder 也是有生命周期的，三个 Proxy 这篇文章也是解释了的。有兴趣的可以了看下。

Binder | 对象的生命周期

一开始，我以为 AuthSession 没有被置空，看下代码，发现 AOSP 的代码，还是比较严谨的，有置空的操作。

细心的同学发现，上图中 AuthSession 没有被任何对象引用，AuthSession 就是 GC Root，哈哈哈。

问题解密

一个实例什么情况可以作为GC Root，有兴趣的同学，可以自行百度，这里就不卖关子了，直接说问题吧。

Binder.linkToDeath()

public void linkToDeath(@NonNull DeathRecipient recipient, int flags) {

}

需要传递 IBinder.DeathRecipient ,这个 DeathRecipient 会被作为 GC root。当调用 unlinkToDeath(@NonNull DeathRecipient recipient, int flags),GC root 才被收回。

AuthSession 初始化的时候，会调用 IBiometricServiceReceiver .linkToDeath。

public final class AuthSession implements IBinder.DeathRecipient {

    AuthSession(@NonNull Context context,

     ......

            @NonNull IBiometricServiceReceiver clientReceiver,

     ......

           ) {

        Slog.d(TAG, "Creating AuthSession with: " + preAuthInfo);

       ......

        try {

            mClientReceiver.asBinder().linkToDeath(this, 0 /* flags */);//this 变成 GC root

        } catch (RemoteException e) {

            Slog.w(TAG, "Unable to link to death");

        }



        setSensorsToStateUnknown();

    }

}

Jni 中 通过 env->NewGlobalRef(object)，告诉虚拟机 AuthSession 是 GC Root。

core/jni/android_util_Binder.cpp



static void android_os_BinderProxy_linkToDeath(JNIEnv* env, jobject obj,

        jobject recipient, jint flags) // throws RemoteException

{

    if (recipient == NULL) {

        jniThrowNullPointerException(env, NULL);

        return;

    }



    BinderProxyNativeData *nd = getBPNativeData(env, obj);

    IBinder* target = nd->mObject.get();



    LOGDEATH("linkToDeath: binder=%p recipient=%p\n", target, recipient);



    if (!target->localBinder()) {

        DeathRecipientList* list = nd->mOrgue.get();

        sp<JavaDeathRecipient> jdr = new JavaDeathRecipient(env, recipient, list);//java 中 DeathRecipient 会被封装为 JavaDeathRecipient

        status_t err = target->linkToDeath(jdr, NULL, flags);

        if (err != NO_ERROR) {

            // Failure adding the death recipient, so clear its reference

            // now.

            jdr->clearReference();

            signalExceptionForError(env, obj, err, true /*canThrowRemoteException*/);

        }

    }

}



JavaDeathRecipient(JNIEnv* env, jobject object, const sp<DeathRecipientList>& list)

        : mVM(jnienv_to_javavm(env)), mObject(env->NewGlobalRef(object)),// object -> DeathRecipient 变为 GC root

          mObjectWeak(NULL), mList(list)

    {

        // These objects manage their own lifetimes so are responsible for final bookkeeping.

        // The list holds a strong reference to this object.

        LOGDEATH("Adding JDR %p to DRL %p", this, list.get());

        list->add(this);



        gNumDeathRefsCreated.fetch_add(1, std::memory_order_relaxed);

        gcIfManyNewRefs(env);

    }

unlinkToDeath 最终会在 Jni 中 通过 env->DeleteGlobalRef(mObject)，告诉虚拟机 AuthSession 不是GC root。

virtual ~JavaDeathRecipient()

{

    //ALOGI("Removing death ref: recipient=%p\n", mObject);

    gNumDeathRefsDeleted.fetch_add(1, std::memory_order_relaxed);

    JNIEnv* env = javavm_to_jnienv(mVM);

    if (mObject != NULL) {

        env->DeleteGlobalRef(mObject);// object -> DeathRecipient GC root 被撤销

    } else {

        env->DeleteWeakGlobalRef(mObjectWeak);

    }

}

解决方式

AuthSession 置空的时候调用 IBiometricServiceReceiver 的 unlinkToDeath 方法。

总结

以上梳理的其实就是 Binder 的造成的内存泄漏。

问题严重性来看，也不算什么大问题，因为调用 BiometricPrompt 的进程被杀，system 进程相关实例也就回收释放了。一般 app 也不太可能出现，常驻进程，而且还频繁调用手机认证的。

这里主要介绍了一种容易被忽略的内存泄漏，Binder.linktoDeath()。
Google issuetracker

参考资料

Binder | 对象的生命周期

前言

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

正文

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

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

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

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

禁用右键和F12键

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

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

    e.preventDefault();

    return false;

  });

  

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

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

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

      if (

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

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

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

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

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

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

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

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

      ) {

        e.preventDefault();

        return false;

      }

    });

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

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

禁用控制台

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

function resize() {

      var threshold = 100;

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

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

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

      if (widthThreshold || heightThreshold) {

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

      }

    }

  window.addEventListener("resize", resize);

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

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

  setInterval(() => {

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

    }, 500);

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

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

//获取dom

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

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

 //img转成canvas

  canvas.width = img.width;

  canvas.height = img.height;

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

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

  document.body.removeChild(img);

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

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

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

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

MutationObserver

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

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

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

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


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


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

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

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

<style>

//定义水印的样式

    #watermark {

        width: 100vw;

        height: 100vh;

        position: absolute;

        left: 0;

        top: 0;

        font-size: 34px;

        color: #32323238;

        font-weight: 700;

        display: flex;

        flex-wrap: wrap;

        justify-content: space-evenly;

        align-content: space-evenly;

        z-index: 9999999;

      }

      #watermark span {

        transform: rotate(45deg);

      }

</style>



 <script>

 //获取水印dom

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

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

    const _watermark = watermark.cloneNode(true);

    //获取水印dom的父节点

    const d = watermark.parentNode;

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

    let referenceNode;

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

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

    });

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

    const prop = {

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

      attributes: true,//属性变化

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

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

    };

    //定义MutationObserver

    const observer = new MutationObserver(function (mutations) {

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

      mutations.forEach((item) => {

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

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

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

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

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

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

              v.remove();

            }

          });

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

          const __watermark = _watermark.cloneNode(true);

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

          //监听第二次克隆的dom

          this.observe(__watermark, prop);

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

          d.insertBefore(__watermark, referenceNode);

        }

      });

    });

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

    observer.observe(watermark, prop);

  </script>

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

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

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

结尾

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

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

异步方法

随着硬件和软件的高度发展，现代应用变得更加复杂和要求更高。由于

高需求，工程师总是试图寻找新的方法来提高应用程序性能和响应能力。慢节奏应用程序的一种解决方案是实施异步方法。异步处理是一种执行任务并发运行的进程或函数，无需等待一个任务完成后再开始另一个任务。在本文中，我将尝试探索 Spring Boot 中的异步方法和 @Async 注解，试图解释多线程和并发之间的区别，以及何时使用或避免它。

Spring中的@Async是什么？

Spring 中的 @Async 注解支持方法调用的异步处理。它指示框架在单独的线程中执行该方法，允许调用者继续执行而无需等待该方法完成。这

提高了应用程序的整体响应能力和吞吐量。

要使用@Async，您必须首先通过将@EnableAsync注释添加到配置类来在应用程序中启用异步处理：

@Configuration

@EnableAsync

public class AppConfig {

}

接下来，用@Async注解来注解你想要异步执行的方法：

@Service

public class AsyncService {

    @Async

    public void asyncMethod() {

        // Perform time-consuming task

    }

}

@Async 与多线程和并发有何不同？

有时，区分多线程和并发与并行执行可能会让人感到困惑，但是，两者都与并行执行相关。他们每个人都有自己的用例和实现：

• @Async 注解是 Spring 框架特定的抽象，它支持异步执行。它提供了轻松使用异步的能力，在后台处理所有艰苦的工作，例如线程创建、管理和执行。这使用户能够专注于业务逻辑而不是底层细节。


• 多线程是一个通用概念，通常指操作系统或程序同时管理多个线程的能力。由于 @Async 帮助我们自动完成所有艰苦的工作，在这种情况下，我们可以手动处理所有这些工作并创建一个多线程环境。 Java 具有Thread和ExecutorService等必要的类来创建和使用多线程。


• 并发是一个更广泛的概念，它涵盖多线程和并行执行技术。它是
  
  系统在一个或多个处理器上同时执行多个任务的能力。

综上所述，@Async是一种更高层次的抽象，它为开发人员简化了异步处理，而多线程和并发更多的是手动管理并行执行。

何时使用 @Async 以及何时避免它。

使用异步方法似乎非常直观，但是，必须考虑到这种方法也有注意事项。

在以下情况下使用@Async：

• 您拥有可以并发运行的独立且耗时的任务，而不会影响应用程序的响应能力。


• 您需要一种简单而干净的方法来启用异步处理，而无需深入研究低级线程管理。

在以下情况下避免使用 @Async：

• 您想要异步执行的任务具有复杂的依赖性或需要大量的协调。在这种情况下，您可能需要使用更高级的并发 API，例如CompletableFuture或反应式编程库，例如 Project Reactor。


• 您必须精确控制线程的管理方式，例如自定义线程池或高级同步机制。在这些情况下，请考虑使用 Java 的ExecutorService或其他并发实用程序。

在 Spring Boot 应用程序中使用 @Async。

在此示例中，我们将创建一个简单的 Spring Boot 应用程序来演示 @Async 的使用。

让我们创建一个简单的订单管理服务。

@SpringBootApplication

@EnableAsync

public class AsyncDemoApplication {

    public static void main(String[] args) {

        SpringApplication.run(AsyncDemoApplication.class, args);

  }

}

@Configuration

@EnableAsync

public class ApplicationConfig {}

   @Configuration

   @EnableAsync

   public class ApplicationConfig {



     @Bean

     public Executor getAsyncExecutor() {

       ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();

       executor.setCorePoolSize(5);

       executor.setMaxPoolSize(10);

       executor.setQueueCapacity(100);

       executor.setThreadNamePrefix("");

       executor.initialize();

       return executor;

       }

   }

通过此配置，我们可以控制最大和默认线程池大小。以及其他有用的定制。

@Service

public class OrderService {



  @Async

  public void saveOrderDetails(Order order) throws InterruptedException {

    Thread.sleep(2000);

    System.out.println(order.name());

  }



  @Async

  public CompletableFuture<String> saveOrderDetailsFuture(Order order) throws InterruptedException {

    System.out.println("Execute method with return type + " + Thread.currentThread().getName());

    String result = "Hello From CompletableFuture. Order: ".concat(order.name());

    Thread.sleep(5000);

    return CompletableFuture.completedFuture(result);

  }



  @Async

  public CompletableFuture<String> compute(Order order) throws InterruptedException {

    String result = "Hello From CompletableFuture CHAIN. Order: ".concat(order.name());

    Thread.sleep(5000);

    return CompletableFuture.completedFuture(result);

  }

}

我们在这里所做的是创建 3 种不同的异步方法。第一个saveOrderDetails服务是一个简单的异步

服务，它将开始异步计算。如果我们想使用现代异步Java功能，

例如CompletableFuture，我们可以通过服务来实现saveOrderDetailsFuture。通过这个服务，我们可以调用一个线程来等待@Async的结果。应该注意的是，CompletableFuture.get()在结果可用之前会阻塞。如果我们想在结果可用时执行进一步的异步操作，我们可以使用thenApply、thenAccept或 CompletableFuture 提供的其他方法。

@RestController

public class AsyncController {



 private final OrderService orderService;



  public OrderController(OrderService orderService) {

    this.orderService = orderService;

  }



  @PostMapping("/process")

  public ResponseEntity<Void> process(@RequestBody Order order) throws InterruptedException {

    System.out.println("PROCESSING STARTED");

    orderService.saveOrderDetails(order);

    return ResponseEntity.ok(null);

  }



  @PostMapping("/process/future")

  public ResponseEntity<String> processFuture(@RequestBody Order order) throws InterruptedException, ExecutionException {

    System.out.println("PROCESSING STARTED");

    CompletableFuture<String> orderDetailsFuture = orderService.saveOrderDetailsFuture(order);

    return ResponseEntity.ok(orderDetailsFuture.get());

  }



  @PostMapping("/process/future/chain")

  public ResponseEntity<Void> processFutureChain(@RequestBody Order order) throws InterruptedException, ExecutionException {

    System.out.println("PROCESSING STARTED");

    CompletableFuture<String> computeResult = orderService.compute(order);

    computeResult.thenApply(result -> result).thenAccept(System.out::println);

    return ResponseEntity.ok(null);

  }

}

现在，当我们访问/process端点时，服务器将立即返回响应，同时

继续saveOrderDetails()在后台执行。 2秒后，服务完成。第二个端点 -/process/future将使用我们的第二个选项，CompletableFuture在这种情况下，5 秒后，服务将完成，并将结果存储在CompletableFuture我们可以进一步使用future.get()来访问结果。在最后一个端点 - 中/process/future/chain，我们优化并使用了异步计算。控制器使用相同的服务方法CompletableFuture，但不久之后，我们将使用thenApply,thenAccept方法。服务器立即返回响应，我们不需要等待5秒，计算将在后台完成。在这种情况下，最重要的一点是对异步服务的调用，在我们的例子中compute()必须从同一类的外部完成。如果我们在一个方法上使用@Async并在同一个类中调用它，它将不起作用。这是因为Spring使用代理来添加异步行为，并且在内部调用方法会绕过代理。为了使其发挥作用，我们可以：

• 将 @Async 方法移至单独的服务或组件。


• 使用 ApplicationContext 获取代理并调用其上的方法。

总结

Spring 中的 @Async 注解是在应用程序中启用异步处理的强大工具。通过使用@Async，我们不需要陷入并发管理和多线程的复杂性来增强应用程序的响应能力和性能。但要决定何时使用 @Async 或使用替代并发

使用程序，了解其局限性和用例非常重要。

一、问题描述

在工作的过程中会遇到要将dom变成图片并下载的问题，刚开始使用的html2canvas进行转换的，但是我老大告诉我说，咱们做的是面向国外的网页，插件太大会导致页面加载慢的问题（国外部分地区网络没有国内这么发达），就让我用原生dom或一些比较小的插件，在原生dom下载的时候遇到了context.drawImage(element, 0, 0, width, height)这一方法传入参数要传类型HTMLCanvasElement的问题，所以要将一个HTMLElement转换成HTMLCanvasElement，但是经过一些信息的查找，我发现有个很好用且轻量化的插件，可以完美解决这一问题，所以这里给大家推荐一个轻量级的插件dom-to-image（23kb），这个插件可以不用进行类型转换，直接将dom元素转换成需要的文件格式。

二、dom-to-image的使用

2.1 dom-to-image的安装

在终端输入以下代码进行dom-to-image安装

npm install dom-to-image

2.2 dom-to-image引入

2.2.1 vue项目引入

在需要使用这个插件的页面使用以下代码进行局部引入

import domToImage from 'dom-to-image';

然后就可以通过以下代码进行图片的转换了

const palGradientGap = document.getElementById('element')

      const canvas = document.createElement('canvas')

      canvas.width = element.offsetWidth

      canvas.height = element.offsetHeight

      this.domtoimage.toPng(element).then(function (canvas) {

        const link = document.createElement('a')

        link.href = canvas

        link.download = 'image.png' // 下载文件的名称

        link.click()

      })

当然也可以进行全局引入
创建一个domToImage.js文件写入以下代码

import Vue from 'vue'; 

import domToImage from 'dom-to-image'; 

const domToImagePlugin = { 

    install(Vue) { 

        Vue.prototype.$domToImage = domToImage; 

     } 

};

Vue.use(domToImagePlugin);

然后再入口文件main.js写入以下代码全局引入插件

import Vue from 'vue'

import App from './App.vue' 

import './domToImage.js'; // 引入全局插件 

Vue.config.productionTip = false 

new Vue({ render: h => h(App), }).$mount('#app')

三、dom-to-image相关方法