什么是抽象工厂模式

抽象工厂模式是一种创建型设计模式，它提供一个接口来创建一系列相关或相互依赖的对象家族，而无需指定它们的具体类。简单来说，抽象工厂模式是工厂模式的升级版，它不再只生产一种产品，而是生产一整套产品。

抽象工厂vs工厂方法：关键区别

• 工厂方法模式：关注单个产品的创建，一个工厂创建一种产品


• 抽象工厂模式：关注产品族的创建，一个工厂创建多种相关产品

这就像一个生产手机的工厂（工厂方法）和一个生产整套电子设备（手机、平板、耳机）的工厂（抽象工厂）的区别。

抽象工厂模式的核心实现

// 产品A接口

public interface ProductA {

    void operationA();

}



// 产品B接口

public interface ProductB {

    void operationB();

}



// 产品A1实现

public class ConcreteProductA1 implements ProductA {

    @Override

    public void operationA() {

        System.out.println("产品A1的操作");

    }

}



// 产品A2实现

public class ConcreteProductA2 implements ProductA {

    @Override

    public void operationA() {

        System.out.println("产品A2的操作");

    }

}



// 产品B1实现

public class ConcreteProductB1 implements ProductB {

    @Override

    public void operationB() {

        System.out.println("产品B1的操作");

    }

}



// 产品B2实现

public class ConcreteProductB2 implements ProductB {

    @Override

    public void operationB() {

        System.out.println("产品B2的操作");

    }

}



// 抽象工厂接口

public interface AbstractFactory {

    ProductA createProductA();

    ProductB createProductB();

}



// 具体工厂1 - 创建产品族1（A1+B1）

public class ConcreteFactory1 implements AbstractFactory {

    @Override

    public ProductA createProductA() {

        return new ConcreteProductA1();

    }

    

    @Override

    public ProductB createProductB() {

        return new ConcreteProductB1();

    }

}



// 具体工厂2 - 创建产品族2（A2+B2）

public class ConcreteFactory2 implements AbstractFactory {

    @Override

    public ProductA createProductA() {

        return new ConcreteProductA2();

    }

    

    @Override

    public ProductB createProductB() {

        return new ConcreteProductB2();

    }

}

抽象工厂模式的关键点

实际应用示例：跨平台UI组件库

下面通过一个跨平台UI组件库的例子来展示抽象工厂模式的强大应用：

// ===== 按钮组件 =====

public interface Button {

    void render();

    void onClick();

}



// Windows按钮

public class WindowsButton implements Button {

    @Override

    public void render() {

        System.out.println("渲染Windows风格的按钮");

    }

    

    @Override

    public void onClick() {

        System.out.println("Windows按钮点击效果");

    }

}



// MacOS按钮

public class MacOSButton implements Button {

    @Override

    public void render() {

        System.out.println("渲染MacOS风格的按钮");

    }

    

    @Override

    public void onClick() {

        System.out.println("MacOS按钮点击效果");

    }

}



// ===== 复选框组件 =====

public interface Checkbox {

    void render();

    void toggle();

}



// Windows复选框

public class WindowsCheckbox implements Checkbox {

    @Override

    public void render() {

        System.out.println("渲染Windows风格的复选框");

    }

    

    @Override

    public void toggle() {

        System.out.println("Windows复选框切换状态");

    }

}



// MacOS复选框

public class MacOSCheckbox implements Checkbox {

    @Override

    public void render() {

        System.out.println("渲染MacOS风格的复选框");

    }

    

    @Override

    public void toggle() {

        System.out.println("MacOS复选框切换状态");

    }

}



// ===== 文本框组件 =====

public interface TextField {

    void render();

    void getText();

}



// Windows文本框

public class WindowsTextField implements TextField {

    @Override

    public void render() {

        System.out.println("渲染Windows风格的文本框");

    }

    

    @Override

    public void getText() {

        System.out.println("获取Windows文本框内容");

    }

}



// MacOS文本框

public class MacOSTextField implements TextField {

    @Override

    public void render() {

        System.out.println("渲染MacOS风格的文本框");

    }

    

    @Override

    public void getText() {

        System.out.println("获取MacOS文本框内容");

    }

}



// ===== GUI工厂接口 =====

public interface GUIFactory {

    Button createButton();

    Checkbox createCheckbox();

    TextField createTextField();

}



// Windows GUI工厂

public class WindowsFactory implements GUIFactory {

    @Override

    public Button createButton() {

        return new WindowsButton();

    }

    

    @Override

    public Checkbox createCheckbox() {

        return new WindowsCheckbox();

    }

    

    @Override

    public TextField createTextField() {

        return new WindowsTextField();

    }

}



// MacOS GUI工厂

public class MacOSFactory implements GUIFactory {

    @Override

    public Button createButton() {

        return new MacOSButton();

    }

    

    @Override

    public Checkbox createCheckbox() {

        return new MacOSCheckbox();

    }

    

    @Override

    public TextField createTextField() {

        return new MacOSTextField();

    }

}

如何使用抽象工厂模式

// 应用类 - 与具体工厂解耦

public class Application {

    private Button button;

    private Checkbox checkbox;

    private TextField textField;

    

    // 构造函数接收一个抽象工厂

    public Application(GUIFactory factory) {

        button = factory.createButton();

        checkbox = factory.createCheckbox();

        textField = factory.createTextField();

    }

    

    // 渲染表单

    public void renderForm() {

        System.out.println("=== 开始渲染表单 ===");

        button.render();

        checkbox.render();

        textField.render();

        System.out.println("=== 表单渲染完成 ===");

    }

    

    // 表单操作

    public void handleForm() {

        System.out.println("\n=== 表单交互 ===");

        button.onClick();

        checkbox.toggle();

        textField.getText();

    }

}



// 客户端代码

public class GUIDemo {

    public static void main(String[] args) {

        // 检测当前操作系统

        String osName = System.getProperty("os.name").toLowerCase();

        GUIFactory factory;

        

        // 根据操作系统选择合适的工厂

        if (osName.contains("windows")) {

            factory = new WindowsFactory();

            System.out.println("检测到Windows系统，使用Windows风格UI");

        } else {

            factory = new MacOSFactory();

            System.out.println("检测到非Windows系统，使用MacOS风格UI");

        }

        

        // 创建并使用应用 - 注意应用不依赖于具体组件类

        Application app = new Application(factory);

        app.renderForm();

        app.handleForm();

    }

}

运行结果（Windows系统上）

检测到Windows系统，使用Windows风格UI

=== 开始渲染表单 ===

渲染Windows风格的按钮

渲染Windows风格的复选框

渲染Windows风格的文本框

=== 表单渲染完成 ===



=== 表单交互 ===

Windows按钮点击效果

Windows复选框切换状态

获取Windows文本框内容

运行结果（MacOS系统上）

检测到非Windows系统，使用MacOS风格UI

=== 开始渲染表单 ===

渲染MacOS风格的按钮

渲染MacOS风格的复选框

渲染MacOS风格的文本框

=== 表单渲染完成 ===



=== 表单交互 ===

MacOS按钮点击效果

MacOS复选框切换状态

获取MacOS文本框内容

抽象工厂模式的常见应用场景

抽象工厂模式的实际案例

许多知名框架和库使用抽象工厂模式，如：

• Java的JDBC：ConnectionFactory创建特定数据库的连接


• Spring Framework：通过BeanFactory创建和管理各种组件


• javax.xml.parsers.DocumentBuilderFactory：创建DOM解析器


• Hibernate：SessionFactory为不同数据库创建会话

抽象工厂模式的优点

抽象工厂模式的缺点

抽象工厂的实现变体

使用反射简化工厂实现

public class ReflectiveFactory implements GUIFactory {

    private String packageName;

    

    public ReflectiveFactory(String stylePrefix) {

        packageName = "com.example.gui." + stylePrefix.toLowerCase();

    }

    

    @Override

    public Button createButton() {

        return (Button) createComponent("Button");

    }

    

    @Override

    public Checkbox createCheckbox() {

        return (Checkbox) createComponent("Checkbox");

    }

    

    @Override

    public TextField createTextField() {

        return (TextField) createComponent("TextField");

    }

    

    private Object createComponent(String type) {

        try {

            Class<?> clazz = Class.forName(packageName + "." + type);

            return clazz.getDeclaredConstructor().newInstance();

        } catch (Exception e) {

            throw new RuntimeException("无法创建组件", e);

        }

    }

}

带有默认实现的抽象工厂

public abstract class BaseGUIFactory implements GUIFactory {

    // 提供默认实现

    @Override

    public TextField createTextField() {

        return new DefaultTextField(); // 所有平台通用的默认实现

    }

    

    // 其他方法需要子类实现

    @Override

    public abstract Button createButton();

    @Override

    public abstract Checkbox createCheckbox();

}

实现抽象工厂的设计考虑

抽象工厂模式最佳实践

// 使用配置驱动的工厂

public class ConfigurableGUIFactory {

    public static GUIFactory getFactory() {

        String factoryType = ConfigLoader.getProperty("ui.factory");

        

        switch (factoryType) {

            case "windows": return new WindowsFactory();

            case "macos": return new MacOSFactory();

            case "web": return new WebFactory();

            default: throw new IllegalArgumentException("未知UI工厂类型");

        }

    }

}

抽象工厂与依赖倒置原则

抽象工厂是实现依赖倒置原则的绝佳方式：高层模块不依赖于低层模块，两者都依赖于抽象。

// 不好的设计：直接依赖具体类

public class BadForm {

    private WindowsButton button; // 直接依赖具体实现

    private WindowsCheckbox checkbox;

    

    public void createUI() {

        button = new WindowsButton(); // 硬编码创建具体类

        checkbox = new WindowsCheckbox();

    }

}



// 好的设计：依赖抽象

public class GoodForm {

    private Button button; // 依赖接口

    private Checkbox checkbox;

    private final GUIFactory factory; // 依赖抽象工厂

    

    public GoodForm(GUIFactory factory) {

        this.factory = factory;

    }

    

    public void createUI() {

        button = factory.createButton(); // 通过工厂创建

        checkbox = factory.createCheckbox();

    }

}

抽象工厂模式小结

抽象工厂模式是一种强大但需谨慎使用的创建型模式。它在需要一套相关产品且系统不应依赖于产品的具体类时非常有用。这种模式有助于确保产品兼容性，并为产品族提供统一的创建接口。

适当应用抽象工厂模式可以使代码更具灵活性和可维护性，但也要避免过度设计导致的复杂性。理解产品族的概念和如何设计良好的抽象工厂接口是掌握这一模式的关键。

关注我的公众号：【编程朝花夕拾】，可获取首发内容。

01 引言

在现代微服务架构中，应用实例的数量动辄成百上千。传统的逐个登录服务器查看日志、检查状态的方式早已变得低效且不现实。

因此，一个集中化、可视化、且能提供实时健康状态的管理平台变得至关重要。Spring Boot Admin (SBA) 正是为了满足这一需求而生的强大工具。

然而，各种厂商的云服务提供了各种监控服务解决客户的各种痛点。Spring Boot Admin这样的工具似乎关注度没有那么高。小编也是无意间发现这款产品，分享给大家。

02 简介

Spring Boot Admin 是一个用于管理和监控 Spring Boot 应用程序的开源社区项目。它并非官方 Spring 项目，但在社区中备受推崇并被广泛使用。

其核心原理是：一个作为“服务器”（Server）的中央管理端，通过收集并展示众多作为“客户端”（Client）的 Spring Boot 应用的监控信息。

Spring Boot Admin 通过集成 Spring Boot Actuator 端点来获取应用数据，并提供了一个友好的 Web UI 界面来展示这些信息。

主要分为两部分：

• 服务端：监控平台


• 客户端：业务端

SpringBoot的版本和Spring Boot Admin有一定的对应关系：

GitHub地址：github.com/codecentric…

文档地址：docs.spring-boot-admin.com/

03 Admin服务端

服务的端配置相当简单，只需要引入依赖，启动增加注解。服务端的基础配置就算完成了。

3.1 基础配置

Maven依赖

<dependency>

    <groupId>de.codecentric</groupId>

    <artifactId>spring-boot-admin-starter-server</artifactId>

    <version>${latest.version}</version>

</dependency>

增加注解

@EnableAdminServer

这两个配置就可访问项目的IP+端口，进入管理页面了。

3.2 增加鉴权

为了数据安全，可以增加鉴权。拥有账号和密码方可进入。

Maven依赖

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-security</artifactId>

</dependency>

配置文件

# 设置自己的用户名和密码

spring.security.user.name=admin

spring.security.user.password=123456

输入对应的用户名和密码就可以进入了。

3.3 增加邮件推送

官方提供了各种通知，也可以自定义，如图：

我们以邮件通知为例。

Maven依赖

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-mail</artifactId>

</dependency>

配置

# 邮箱配置

spring.mail.host=smtp.163.com

spring.mail.port=25

spring.mail.username=用户名

spring.mail.password=*****[授权码]



# 发送和接受邮箱

spring.boot.admin.notify.mail.to=wsapplyjob@163.com

spring.boot.admin.notify.mail.from=wsapplyjob@163.com

客户端下线之后会触发邮件：

04 Adamin客户端

因为服务端是依赖Spring Boot Actuator 端点来获取应用数据，所以我们需要开放期其所有的服务。

4.1 基础配置

Maven依赖

<dependency>

    <groupId>de.codecentric</groupId>

    <artifactId>spring-boot-admin-starter-client</artifactId>

    <version>${latest.version}</version>

</dependency>



<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

# 服务端地址

spring.boot.admin.client.url=http://127.0.0.1:8081

# 鉴权信息

spring.boot.admin.client.username=admin

spring.boot.admin.client.password=123456



# 开发所有的暴漏的信息

management.endpoints.web.exposure.include=*

4.2 监控界面

进入之后，我们就会发现上面的页面。点击应用墙，就会展示所有监控的实例。进入之后如图：

进入之后就可以看到五大块。其中②就是我们之前看到的日志级别的控制。还包含了缓存、计划任务、映射甚至类之间的依赖关系。

因为界面支持中文，里面具体的功能就不做描述，感兴趣的可以自己的探索。

4.3 日志配置增加日志

默认的日志进去只有日志的级别，并不会打印日志。

这是官方的描述：

我们增加配置：

logging.file.name=/var/log/boot-log.log

logging.pattern.file=%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(%5p) %clr(${PID}){magenta} %clr(---){faint} %clr([.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n%wEx (2)

启动查看结果：

我们就可以看到信的菜单：日志文件

4.4 缓存

【缓存】是没有数据的：

缓存依赖

<!-- 监控缓存需要的依赖 -->

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-cache</artifactId>

</dependency>

代码

触发缓存任务之后，就会出现缓存的管理：

4.5 计划任务

【计划任务】和缓存基本一样，但是无需引入第三方依赖。使用@Scheduled即可。

监控结果：

05 小结

Spring Boot Admin 以其简洁的配置、强大的功能和友好的界面，成为了 Spring Boot 微服务监控领域的事实标准。它极大地降低了监控和运维的复杂度，让开发者能够更专注于业务逻辑开发。

对于中小型规模的微服务集群，直接使用 SBA 是一个高效且成本低廉的解决方案。

赶快去探索里面不同的功能的吧！

1. 前言

比上班更可怕的是什么？是加班。

比加班更可怕的是什么？是固定加班，也就是 996，大小周。

作为一个荣获 996 福报的牛马，我认为我的际遇已经很可怕了。

没想到还有比这更可怕的，拖着被996折腾过的疲惫身体回家后。我儿子向我展示他一天的劳动成果。

这时候你肯定会说让他收起来不就行了？这时候我应该拿出标志性的礼貌三问：你有对象吗？你有儿子吗？你让你儿子收他就收吗？

不会吧，你儿子收啊。那我和你换个儿子吧。

我对我儿子威逼利诱什么招式都试过了，他每次就3招我就没辙了：

爸爸，我累了你帮我收吧。

爸爸，地上的玩具太多了你和我一起收吧，收着收着这小子就不见了。

爸爸，我要睡觉了，晚安。

每天晚上我都要花时间收拾这个烂摊子，收过十几次后我后知后觉有了个想法。

平时我工作的时候，一个5分钟就能手写完搞定的配置我都要花10分钟写个脚本自动化。

为啥不能让收玩具这件事情自动化呢？我可是个优雅的程序员啊。重复做一个动作在我这应该是严格禁止的才对。

所以我打算做一个自动收玩具的机器。

不是哥们，这我真做不了。在我这自动化是什么意思呢？

不需要自己动手干的就是自动化，把配置做到管理后台，让运营自己去配置算不算自动化？那必须是的呀。

那么，想一种办法让我儿子自己把玩具收起来是不是自动化？那也必须是的呀。

自动化的定义就是不需要自己动手干，管是机器干还是人干，反正不要我来干。

说干就干，我儿子特别喜欢数字，迷恋加法。那不就盖了帽了。给他安排一个任务APP，收完一件玩具就加分，他肯定特满足特有成就感。

我虽然是一个前端后端运维测试攻城狮，但我的的确确没有开发过APP。除了大学要交 Android 作业抱过同学大腿喵了一眼，从那之后我就下定决定干后端去了。因为艺术细菌不是说本人没有，是本人想有但它对我不感冒啊。

但是别忘了，现在是 AI 的时代。产品的活我不会，AI 来。APP 开发我不会，AI 来。貌似不需要后端，那我只能当当测试了。

2. 正片开始

我调研了一圈，目前有几种方案可以实现：

原生做起来体验最好，但是搭个环境真是要了我的老命了，所以弃之。

flutter总体感觉不错，但是要另外学一门语言，想想我就脑壳疼，亦弃之。

uni-app 看起来不咋滴，蛮多人吐槽但也有真正的案例。但我发现它能云打包，不用我在本地配一堆乱七八糟的。下载一个HBuilder 就行了，虽然很多人吐槽这个 IDE，但关我啥事？是 AI 来写代码，又不是我写代码，尽管恶心 AI 去。选它选它

2.1 画原型图

Cursor，Gemini，claude code 我都试了，Gemini的设计感最强，豆包的体验最好。豆包的效果看起来非常的奈斯啊！

2.2 开发

有了原型那就好办了，直接贴图让cursor 或者 claude code 对着实现就行了。

这里要吐槽一下claude code，不能粘贴板直接贴图，只能把图片拖进去，差评。

现在可以粘贴图片了，Mac 可以尝试用ctrl+v（没错，不是command+v）

把所有的原型图贴进去之后，输入这句简单的Prompt，claude code 就会开始干活了。

请根据原型图，使用uniapp 开发一个app

2.3 加需求

第一版完成了他的使命，最近儿子有点腻烦了，收个玩具磨磨蹭蹭的。不行，我得想点法子，加点东西让他保持新鲜感，然后养成习惯，以后就不用我管了，想想就非常的苏胡啊。

所以为了调动他的积极性，更营造一个紧张的氛围，我加入了倒计时功能：

接下来有个新功能。我想为任务增加一个计时完成功能：



  1. 完成任务时，不再是简单的点击即可；



  2. 完成任务时，应该提供一个开始完成按钮，然后启动倒计时



  3. 创建任务时，应该配置预计完成时间



  4. 完成任务时，遵循规则：a.如果在预计时间的一半完成可以得到2倍的分数；b.如果超过一半时间完成则得到1.5倍分数；c.如果超时完成则得到1倍分数

直接把需求丢给AI实现去，自己测试测试，没问题就打包。

2.3 测试打包

先浏览器运行看看效果，可以 F12 切换成手机视图看有没有挤压之类的。

测试没问题就直接打包。因为我是尊贵的 Android 用户，所以我只跑了 Android 打包。

我坦白，uni-app部分我基本是看这个老哥的：juejin.cn/post/729631…

2.4 看看效果

在Java开发中，哈希码的使用无处不在，但许多开发者对System.identityHashCode()和Object.hashCode()的区别仍然模糊不清。本文将深入剖析二者的核心区别，并通过实际代码演示它们在不同场景下的行为差异。

一、本质定义：两种哈希码的起源

二、核心区别对比（表格速查）

三、关键差异深度解析

1. 重写行为对比（核心区别）

class CustomObject {

    private int id;

    

    // 重写hashCode（基于内容）

    @Override

    public int hashCode() {

        return id * 31;

    }

}



public static void main(String[] args) {

    CustomObject obj = new CustomObject();

    obj.id = 100;

    

    System.out.println("hashCode: " + obj.hashCode());         // 3100

    System.out.println("identityHashCode: " + System.identityHashCode(obj)); // 356573597

}

输出说明：

✅ hashCode()返回重写后的计算值

✅ identityHashCode()无视重写，返回JVM原始哈希

2. null安全性对比

Object obj = null;



// 抛出NullPointerException

try {

    System.out.println(obj.hashCode());

} catch (NullPointerException e) {

    System.out.println("调用hashCode()抛NPE");

}



// 安全返回0

System.out.println("identityHashCode(null): " 

                    + System.identityHashCode(obj)); 

3. 哈希码不变性验证

String str = "Hello";

int initialIdentity = System.identityHashCode(str);



str = str + " World!"; // 修改对象内容



// 身份哈希码保持不变

System.out.println(initialIdentity == System.identityHashCode(str)); // true

四、经典应用场景

1. 使用Object.hashCode()的场景

// 在HashMap中作为键（依赖内容哈希）

Map<Student, Grade> gradeMap = new HashMap<>();

Student s = new Student("2023001", "张三");

gradeMap.put(s, new Grade(90));



// 重写需遵守规范：内容相同则哈希码相同

class Student {

    private String id;

    private String name;

    

    @Override

    public int hashCode() {

        return Objects.hash(id, name);

    }

}

2. 使用identityHashCode()的场景

场景1：实现身份敏感的容器

// IdentityHashMap基于身份哈希而非内容

IdentityHashMap<Object, String> identityMap = new IdentityHashMap<>();

String s1 = new String("ABC");

String s2 = new String("ABC");



identityMap.put(s1, "第一对象");

identityMap.put(s2, "第二对象"); // 不同对象，均可插入



System.out.println(identityMap.size()); // 2

场景2：检测hashCode是否被重写

boolean isHashCodeOverridden(Object obj) {

    return obj.hashCode() != System.identityHashCode(obj);

}



// 测试

System.out.println(isHashCodeOverridden(new Object())); // false

System.out.println(isHashCodeOverridden(new String("Test"))); // true

场景3：调试对象内存关系

Object objA = new Object();

Object objB = objA; // 指向同一对象



// 身份哈希相同证明是同一对象

System.out.println(System.identityHashCode(objA) 

                == System.identityHashCode(objB)); // true

五、底层机制揭秘

六、总结与最佳实践

黄金准则：

• 当对象作为HashMap等内容敏感容器的键时 → 重写hashCode()+equals()


• 当需要对象身份标识（如调试、IdentityHashMap)时 → 使用identityHashCode()


• 永远不要在重写的hashCode()中调用identityHashCode()，这违反哈希契约！

通过合理选择这两种哈希码，可以避免常见的HashMap逻辑错误和身份混淆问题。理解它们的差异，将使你的Java代码更加健壮高效！

针对DeepSeek回答过于笼统的问题，可通过以下方法优化，使输出更具体、详细：

一、优化提示词设计

二、参数调整与功能设置

三、迭代优化技巧

四、进阶解决方案

若常规方法仍不理想，可尝试：

效果对比示例

通过以上方法，可系统化解决回答笼统的问题。

前言

在Vue项目开发中，弹窗组件的管理一直是一个令人头疼的问题。传统的声明式弹窗开发方式需要管理大量的状态变量、处理复杂的props传递，甚至可能面临多个弹窗嵌套时的状态管理困境。今天给大家介绍一个能够彻底改变这种开发体验的库：Vue-Command-Component。

为什么需要命令式组件？

在传统的Vue开发中，弹窗的使用通常是这样的：

<template>

  <el-dialog v-model="visible" title="提示">

    <span>这是一段信息</span>

    <template #footer>

      <span class="dialog-footer">

        <el-button @click="visible = false">取消</el-button>

        <el-button type="primary" @click="handleConfirm">确认</el-button>

      </span>

    </template>

  </el-dialog>

</template>



<script setup>

const visible = ref(false)

const handleConfirm = () => {

  // 处理确认逻辑

  visible.value = false

}

</script>

这种方式存在几个明显的问题：

Vue-Command-Component 解决方案

使用Vue-Command-Component，上述问题都可以得到优雅的解决。来看看它是如何使用的：

import { useDialog } from "@vue-cmd/element-plus";



const CommandDialog = useDialog()



// 直接调用函数显示弹窗

CommandDialog(<div>这是一段信息</div>)

是的，就是这么简单！一行代码就能唤起一个弹窗，不需要管理状态，不需要写模板，一切都变得如此流畅。

核心特性

1. 极简API设计

无需管理状态，一个函数调用搞定所有事情，符合直觉的开发体验。

2. 完整的类型支持

提供完整的TypeScript类型支持，开发体验一流。

3. 灵活的控制能力

提供了多种控制方式：

• destroy：销毁弹窗


• hide/show：控制弹窗显示/隐藏


• destroyWithResolve/destroyWithReject：支持Promise风格的控制

4. 强大的扩展性

支持多种UI框架：

• Element Plus


• Naive UI


• Vant


• ...更多框架支持中

5. 原生特性支持

完整支持原生组件的所有特性：

• 属性传递


• 事件处理


• 插槽支持


• Provide/Inject

安装

# 使用 npm

npm install @vue-cmd/core @vue-cmd/element-plus



# 使用 yarn

yarn add @vue-cmd/core @vue-cmd/element-plus



# 使用 pnpm

pnpm add @vue-cmd/core @vue-cmd/element-plus



# 使用 bun

bun add @vue-cmd/core @vue-cmd/element-plus

实战示例

基础用法

import { useDialog } from "@vue-cmd/element-plus";



const CommandDialog = useDialog()



// 基础弹窗

CommandDialog(<Content />)



// 带配置的弹窗

CommandDialog(<Content />, {

  attrs: {

    title: '标题',

    width: '500px'

  }

})

嵌套弹窗

import { useDialog } from "@vue-cmd/element-plus";



const CommandDialog = useDialog()



CommandDialog(

  <div onClick={() => {

    // 在弹窗中打开新的弹窗

    CommandDialog(<div>内层弹窗</div>)

  }}>

    外层弹窗

  </div>

)

Promise风格控制

import { useDialog } from "@vue-cmd/element-plus";

import { useConsumer } from "@vue-cmd/core";



const CommandDialog = useDialog()



// 在弹窗组件内部

const FormComponent = defineComponent({

  setup() {

    const consumer = useConsumer()

    

    const handleSubmit = (data) => {

      // 提交数据后关闭弹窗

      consumer.destroyWithResolve(data)

    }

    

    return () => <Form onSubmit={handleSubmit} />

  }

})



// Promise风格的控制

try {

  const result = await CommandDialog(<FormComponent />).promise

  console.log('表单提交结果:', result)

} catch (error) {

  console.log('用户取消或出错:', error)

}

多UI框架支持

// Element Plus

import { useDialog as useElementDialog } from "@vue-cmd/element-plus";



// Naive UI

import { useModal, useDrawer } from "@vue-cmd/naive";



// Vant

import { usePopup } from "@vue-cmd/vant";



const ElementDialog = useElementDialog()

const NaiveModal = useModal()

const VantPopup = usePopup()



// 使用不同的UI框架

ElementDialog(<Content />)

NaiveModal(<Content />)

VantPopup(<Content />)

写在最后

Vue-Command-Component 为Vue开发者带来了一种全新的弹窗开发方式。它不仅简化了开发流程，还提供了更强大的控制能力。如果你的项目中有大量弹窗交互，不妨尝试一下这个库，相信它会为你带来更好的开发体验。

相关链接

• 文档：Vue-Command-Component 文档


• GitHub：Vue-Command-Component

当我们编写 new Object() 时，JVM 背后到底发生了怎样的故事？类加载过程中的初始化阶段究竟暗藏哪些玄机？

一、引言：从一段简单代码说起

先来看一个看似简单的 Java 代码片段：

public class HelloWorld {

    public static void main(String[] args) {

        System.out.println("Hello, World!");

    }

}

当我们执行这段代码时，背后却隐藏着 JVM 复杂的类加载机制。.java 文件经过编译变成 .class 字节码文件，这些"静态"的字节码需要被 JVM 动态地加载、处理并最终执行。这就是类加载过程的神奇之处。

类加载机制是 Java 语言的核心基石，它赋予了 Java "一次编写，到处运行" 的能力。理解这一过程，不仅能帮助我们编写更高效的代码，更是面试中的高频考点。

二、类生命周期：七个阶段的完整旅程

在深入类加载过程之前，我们先来了解类的完整生命周期。一个类在 JVM 中从加载到卸载，总共经历七个阶段：

前五个阶段（加载、验证、准备、解析、初始化）统称为类加载过程。

三、类加载过程的五个步骤详解

3.1 加载阶段：寻找类的旅程

加载阶段是类加载过程的起点，主要完成三件事情：

// 示例：不同的类加载方式

public class LoadingExample {

    public static void main(String[] args) throws Exception {

        // 通过类加载器加载

        Class<?> clazz1 = ClassLoader.getSystemClassLoader().loadClass("java.lang.String");

        

        // 通过Class.forName加载（默认会初始化）

        Class<?> clazz2 = Class.forName("java.lang.String");

        

        // 通过字面常量获取（不会触发初始化）

        Class<?> clazz3 = String.class;

        

        System.out.println("三种方式加载的类是否相同: " + 

                          (clazz1 == clazz2 && clazz2 == clazz3));

    }

}

3.2 验证阶段：安全的第一道防线

验证阶段确保 Class 文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息不会危害虚拟机自身的安全。

3.3 准备阶段：零值初始化的奥秘

这是最容易产生误解的阶段！ 在准备阶段，JVM 为**类变量（static变量）**分配内存并设置初始零值，注意这不是程序员定义的初始值。

public class PreparationExample {

    // 准备阶段后 value = 0，而不是 100

    public static int value = 100;

    

    // 准备阶段后 constantValue = 200（因为有final修饰）

    public static final int constantValue = 200;

    

    // 实例变量 - 准备阶段完全不管

    public int instanceValue = 300;

}

各种数据类型的零值对照表：

关键区别：只有**类变量（static变量）**在准备阶段分配内存和初始化零值，实例变量会在对象实例化时随对象一起分配在堆内存中。

3.4 解析阶段：符号引用到直接引用的转换

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。这个过程可以在初始化之后再进行，这是为了支持Java的动态绑定特性。

解析主要针对以下四类符号引用：

3.5 初始化阶段：执行类构造器 <clinit>()

这是类加载过程的最后一步，也是真正开始执行类中定义的Java程序代码的一步。

JVM规范严格规定的六种初始化触发情况：

3.6 使用阶段：类的使命实现

当类完成初始化后，就进入了使用阶段。这是类生命周期中最长的阶段，类的所有功能都可以正常使用：

public class UsageStageExample {

    public static void main(String[] args) {

        // 类已完成初始化，进入使用阶段

        MyClass obj = new MyClass();  // 创建对象实例

        obj.instanceMethod();         // 调用实例方法

        MyClass.staticMethod();       // 调用静态方法

        int value = MyClass.staticVar;// 访问静态变量

    }

}



class MyClass {

    public static int staticVar = 100;

    public int instanceVar = 200;

    

    public static void staticMethod() {

        System.out.println("静态方法");

    }

    

    public void instanceMethod() {

        System.out.println("实例方法");

    }

}

在使用阶段，类可以：

• 创建对象实例


• 调用静态方法和实例方法


• 访问和修改静态字段和实例字段


• 被其他类引用和继承

3.7 卸载阶段：生命的终结

类的卸载是生命周期的最后阶段，但并不是必须发生的。一个类被卸载需要满足以下条件：

public class UnloadingExample {

    public static void main(String[] args) throws Exception {

        // 使用自定义类加载器加载类

        CustomClassLoader loader = new CustomClassLoader();

        Class<?> clazz = loader.loadClass("com.example.TemporaryClass");

        

        // 创建实例并使用

        Object instance = clazz.newInstance();

        System.out.println("类已加载并使用: " + clazz.getName());

        

        // 解除所有引用，使类和类加载器可被回收

        clazz = null;

        instance = null;

        loader = null;

        

        // 触发GC，可能卸载类

        System.gc();

        System.out.println("类和类加载器可能已被卸载");

    }

}



class CustomClassLoader extends ClassLoader {

    // 自定义类加载器实现

}

所以，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。

四、关键辨析：类初始化 vs. 对象实例化

这是本文的核心观点，也是大多数开发者容易混淆的概念。让我们通过一个对比表格来清晰区分：

public class InitializationVsInstantiation {

    // 类变量 - 在<clinit>()方法中初始化

    public static String staticField = initStaticField();

    

    // 实例变量 - 在<init>()方法中初始化  

    public String instanceField = initInstanceField();

    

    // 静态代码块 - 在<clinit>()方法中执行

    static {

        System.out.println("静态代码块执行");

    }

    

    // 实例代码块 - 在<init>()方法中执行

    {

        System.out.println("实例代码块执行");

    }

    

    public InitializationVsInstantiation() {

        System.out.println("构造方法执行");

    }

    

    private static String initStaticField() {

        System.out.println("静态变量初始化");

        return "static value";

    }

    

    private String initInstanceField() {

        System.out.println("实例变量初始化");

        return "instance value";

    }

    

    public static void main(String[] args) {

        System.out.println("=== 第一次创建对象 ===");

        new InitializationVsInstantiation();

        

        System.out.println("\n=== 第二次创建对象 ===");

        new InitializationVsInstantiation();

    }

}

输出结果：

静态变量初始化

静态代码块执行

=== 第一次创建对象 ===

实例变量初始化

实例代码块执行

构造方法执行



=== 第二次创建对象 ===

实例变量初始化

实例代码块执行

构造方法执行

五、深度实战：初始化顺序全面解析

现在，让我们通过一个综合示例来回答开篇的思考题：如果一个类同时包含静态变量、静态代码块、实例变量、实例代码块和构造方法，它们的执行顺序是怎样的？在存在继承关系时又会如何变化？

5.1 单类初始化顺序

public class InitializationOrder {

    // 静态变量

    public static String staticField = "静态变量";

    

    // 静态代码块

    static {

        System.out.println(staticField);

        System.out.println("静态代码块");

    }

    

    // 实例变量

    public String field = "实例变量";

    

    // 实例代码块

    {

        System.out.println(field);

        System.out.println("实例代码块");

    }

    

    // 构造方法

    public InitializationOrder() {

        System.out.println("构造方法");

    }

    

    public static void main(String[] args) {

        System.out.println("第一次实例化:");

        new InitializationOrder();

        

        System.out.println("\n第二次实例化:");

        new InitializationOrder();

    }

}

输出结果：

静态变量

静态代码块

第一次实例化:

实例变量

实例代码块

构造方法



第二次实例化:

实例变量

实例代码块

构造方法

关键发现：

5.2 继承关系下的初始化顺序

class Parent {

    // 父类静态变量

    public static String parentStaticField = "父类静态变量";

    

    // 父类静态代码块

    static {

        System.out.println(parentStaticField);

        System.out.println("父类静态代码块");

    }

    

    // 父类实例变量

    public String parentField = "父类实例变量";

    

    // 父类实例代码块

    {

        System.out.println(parentField);

        System.out.println("父类实例代码块");

    }

    

    // 父类构造方法

    public Parent() {

        System.out.println("父类构造方法");

    }

}



class Child extends Parent {

    // 子类静态变量

    public static String childStaticField = "子类静态变量";

    

    // 子类静态代码块

    static {

        System.out.println(childStaticField);

        System.out.println("子类静态代码块");

    }

    

    // 子类实例变量

    public String childField = "子类实例变量";

    

    // 子类实例代码块

    {

        System.out.println(childField);

        System.out.println("子类实例代码块");

    }

    

    // 子类构造方法

    public Child() {

        System.out.println("子类构造方法");

    }

    

    public static void main(String[] args) {

        System.out.println("第一次实例化子类:");

        new Child();

        

        System.out.println("\n第二次实例化子类:");

        new Child();

    }

}

输出结果：

父类静态变量

父类静态代码块

子类静态变量

子类静态代码块

第一次实例化子类:

父类实例变量

父类实例代码块

父类构造方法

子类实例变量

子类实例代码块

子类构造方法



第二次实例化子类:

父类实例变量

父类实例代码块

父类构造方法

子类实例变量

子类实例代码块

子类构造方法

关键发现：

5.3 进阶案例：包含静态变量初始化的复杂情况

public class ComplexInitialization {

    public static ComplexInitialization instance = new ComplexInitialization();

    public static int staticVar = 100;

    public int instanceVar = 200;

    

    static {

        System.out.println("静态代码块: staticVar=" + staticVar);

    }

    

    {

        System.out.println("实例代码块: instanceVar=" + instanceVar + ", staticVar=" + staticVar);

    }

    

    public ComplexInitialization() {

        System.out.println("构造方法: instanceVar=" + instanceVar + ", staticVar=" + staticVar);

    }

    

    public static void main(String[] args) {

        System.out.println("main方法开始");

        new ComplexInitialization();

    }

}

输出结果：

实例代码块: instanceVar=200, staticVar=0

构造方法: instanceVar=200, staticVar=0

静态代码块: staticVar=100

main方法开始

实例代码块: instanceVar=200, staticVar=100

构造方法: instanceVar=200, staticVar=100

关键发现：

六、面试常见问题与解答

6.1 高频面试题解析

Q1: 下面代码的输出结果是什么？为什么？

public class InterviewQuestion {

    public static void main(String[] args) {

        System.out.println(Child.value);

    }

}



class Parent {

    static int value = 100;

    static { System.out.println("Parent静态代码块"); }

}



class Child extends Parent {

    static { System.out.println("Child静态代码块"); }

}

A: 输出结果为：

Parent静态代码块

100

解析： 通过子类引用父类的静态字段，不会导致子类初始化，这是类加载机制的一个重要特性。

Q2: 接口的初始化与类有什么不同？

A: 接口的初始化与类类似，但有重要区别：

6.2 类加载机制的实际应用

1. 单例模式的优雅实现：

public class Singleton {

    private Singleton() {}

    

    private static class SingletonHolder {

        static {

            System.out.println("SingletonHolder初始化");

        }

        private static final Singleton INSTANCE = new Singleton();

    }

    

    public static Singleton getInstance() {

        return SingletonHolder.INSTANCE;

    }

}

这种实现利用了类加载机制的特性：只有在真正调用 getInstance() 时才会加载 SingletonHolder 类，实现了懒加载且线程安全。

2. 常量传播优化：

public class ConstantExample {

    public static final String CONSTANT = "Hello";

    

    public static void main(String[] args) {

        System.out.println(CONSTANT);

    }

}

编译时，常量 CONSTANT 的值会被直接内联到使用处，不会触发类的初始化。

七、总结与思考

通过本文的深入分析，我们可以总结出以下几个关键点：

希望本文能帮助你深入理解JVM类加载机制，下次遇到相关面试题时，相信你一定能游刃有余！

作者：Laurel W

来源：Adobe

作为一名数据科学和数学老师，我其实不介意我的学生使用像 ChatGPT 这样的 LLM，只要它是用来辅助他们学习，而不是取代学习过程。加州理工学院的申请文书指南启发了我为编程和机器学习课制定 AI 使用政策：

哪些是加州理工申请文书中不道德的 AI 使用方式？

• 直接从 AI 生成器复制粘贴


• 依赖 AI 生成内容来列提纲或起草文书


• 用 AI 生成的内容替换你独特的声音和语气


• 翻译用其他语言写的文书

哪些是加州理工申请文书中道德的 AI 使用方式？

• 使用 Grammarly 或 Microsoft Editor 这类 AI 工具检查语法拼写


• 用 AI 生成问题或练习题，帮助启动头脑风暴


• 用 AI 来研究申请流程

如果你还在想你使用 AI 是否道德，问问自己：你请一位值得信赖的大人做同样的事，合适吗？比如请老师帮你改语法错拼写错？当然可以！但让老师帮你写一篇文书草稿，然后你稍微改改就交了？绝对不行。

话虽如此，最近我收到了一些代码作业，一看就完全是 AI 写的，于是我整理了一些“AI 征兆”。当然，人类和 AI 写的代码现在越来越难分辨。但 ChatGPT / Claude / DeepSeek 这些生成的代码，还是有一些共同特征，一看就不对劲。

注释

我希望所有学生都能像 ChatGPT 那样写那么详细的注释吗？当然希望。但他们会吗？肯定不会。

🚩 注释过于详细或者风格怪异，是使用 AI 的信号。

比如，DeepSeek 生成的代码里你会看到用三引号写一段 docstring 来当注释，而不是用标准的 #，尽管那段 docstring 并没有说明参数或返回值：

def find_squares_adding_to_zero(mod):

"""Find two non-zero numbers a and b such that a^2 + b^2 ≡ 0 mod n."""

for a in range(1, mod): # Start from 1 to exclude a = 0

for b in range(a, mod): # Start from a to avoid redundant pairs

if (a2 + b2) % mod == 0:

return (a, b)

return

我觉得这用来注释一行代码的方式很不自然，尤其是我在课上明确教的是用 # 来写单行注释，而这段也不是一个正经的 docstring。

注释里用特殊符号也可能是 AI 写的。除非是我写给很多人看的代码，我自己是不会去找像 “≡” 这样的符号来写注释的。我敢说我的学生大概也不会这么做。

Lambda 表达式

别误会——我喜欢 lambda 表达式，觉得它们是 Python 中很独特且有价值的功能。我认为 lambda 是用来写简洁、临时的小函数的，直接作为参数传给像 map()、filter() 或 sorted() 这种函数才合适。用得好很亮眼。但 lambda 表达式一旦滥用、用错地方，或者还没讲到就乱用，就是个警示。

🚩 lambda 用得不合时宜，说明设计不够认真，或者太依赖 AI。

比如，要是我在还没系统讲 lambda 表达式前，收到这么一份作业代码，那我肯定第一时间就怀疑是 ChatGPT 写的：

from functools import lru_cache

fib = (lambda f: (lambda x: f(f, x)))(lambda self, n:

n if n < 2 else self(self, n-1) + self(self, n-2))

Generate the first 10 Fibonacci numbers

fib_sequence = [fib(n) for n in range(10)]

print(fib_sequence)

这种写法根本不适合用 lambda，而且太复杂了，不可能是一个第一次学 Python 的学生自己写出来的。

库的使用

库导入的位置

🚩 有时候，LLM 会把 import 放在奇怪的位置（不是在文件最上面）。

这种情况我只见过几次，但如果你已经跟学生强调过 import 要放在开头或集中在一起，那这种写法就可疑了。

用了什么库：

🚩 用某个库完成其实不需要它的任务，尤其是没讲过的冷门库，也可能是 AI 写的迹象。

我们再看看上面那段 lambda 代码：

from functools import lru_cache

fib = (lambda f: (lambda x: f(f, x)))(lambda self, n:

n if n < 2 else self(self, n-1) + self(self, n-2))

Generate the first 10 Fibonacci numbers

fib_sequence = [fib(n) for n in range(10)]

print(fib_sequence)

如果你还没讲过 functools 这个库，那学生很可能是用 Google 或 LLM 才知道的。用这些工具探索库当然没问题，但也可能说明实现方式就是 AI 生成的。

命名和格式风格不一致

这个一看就懂。如果作业要求某个字段或变量要用特定命名，AI 写出来的代码往往会给出更泛、更“解释性”的名字，但反而不自然。比如，下面这段找所有小于 n 的素数的代码，一个普通学生可能不会写得这么工整、变量名这么“讲究”：

def sieve_of_eratosthenes(limit):

"""Return a list of all prime numbers less than the given limit."""

if limit <= 2:

return []

Initialize a boolean array to track prime numbers

is_prime = [True] * limit

is_prime[0] = is_prime[1] = False # 0 and 1 are not primes

for num in range(2, int(limit**0.5) + 1):

if is_prime[num]:

Mark multiples of num as non-prime

for multiple in range(num * num, limit, num):

is_prime[multiple] = False

Collect all prime numbers

primes = [num for num, prime in enumerate(is_prime) if prime]

return primes

Example usage

limit = 50 # Change this value to find primes less than a different number

primes = sieve_of_eratosthenes(limit)

print(f"Primes less than {limit}: {primes}")

我自己可能会用 n 而不是 limit，函数名也会更随意些，比如叫 prime_finder。当然，一些特别讲究的学生也可能会写成这样，所以我一般是结合其他迹象一起判断是不是 AI 写的。

逻辑错误

逻辑错误纸面上是最明显的红旗。但实际上很难判断——到底是语言模型出错了，还是学生自己没理解透？

归根结底，LLM 是基于统计的模型，用训练数据学到的模式来预测下一个 token（比如字、词或子词）。它们擅长生成连贯、有上下文的文本，但并不真正理解、也不具备推理或算法思维。这导致它们在需要精确逻辑的任务上容易出错，比如解数学题或者写代码。有时候会给出看上去靠谱但其实错的答案，或者根本没搞清楚复杂的逻辑结构。比如我见过它们在数学题里索引错、没处理边界条件、甚至输出完全错误。

🚩 如果代码有逻辑错误或者推理错误，那可能是 AI 写的。

理想情况下，一个认真点的学生会先检查并修正这些错误再交作业。但实际情况是，很多代码交上来根本不能跑，或者输出就错了。

最后提醒一下，其实很难定一个硬性规则来判断是不是 AI 写的代码，所以我建议老师先别急着指责，而是带着好奇去了解学生的思路。如果我怀疑一个学生太依赖 AI，我可能会让他白板手写一个类似的题目，或者问问他对这个解法的理解。只要引导得当、细节到位，我希望未来能培养出的是会把 AI 当工具，而不是当拐杖的专业人士。

div {

  box-shadow: 0 0 0 5px red, 0 0 0 10px blue;

}

3. 创意设计：对于追求独特风格的网页设计，多重边框提供了无限的创意空间。可以通过调整边框的颜色、宽度、模糊度等参数，创造出各种独特的视觉效果，展现出与众不同的设计风格。

注意事项

2. 兼容性：不同浏览器对box-shadow属性的支持程度略有差异。在使用时，要确保在主流浏览器上进行充分测试，必要时可以添加浏览器前缀来保证兼容性。

CSS 的多重边框特性为前端开发者提供了一种简单而强大的方式来增强网页的视觉效果。通过合理运用这一特性，我们能够打造出更加美观、富有创意的网页界面。希望大家在今后的前端开发中，大胆尝试多重边框，让自己的网页作品更加出彩！

在数学和计算机科学的交汇处，存在着一种令人着迷的几何结构——希尔伯特曲线（Hilbert Curve）。这种由德国数学家大卫·希尔伯特于1891年提出的连续空间填充曲线，不仅挑战了我们对维度的直观认知，更在现代技术领域发挥着举足轻重的作用。

一、初识希尔伯特曲线：维度穿梭的钥匙

希尔伯特曲线的核心在于其空间填充性和连续性。想象一条无限延伸的细线，它以一种巧妙的方式弯曲、折叠，最终能够填满整个二维平面（或更高维度的空间），这就是希尔伯特曲线的魔力。尽管它是连续的，但由于其分形特性，这条曲线在任何一点都不可导。

希尔伯特曲线的构建基于递归的思想。以最经典的二维希尔伯特曲线为例，它从一个正方形开始，将其四等分，然后用一条线段连接这四个小正方形的中心点，形成一个基本的“U”形。接下来，对每个小正方形重复这个过程，不断细分、连接，最终在无限递归下，这条曲线将覆盖整个正方形内的每一个点, 如下图所示。

另一个关键特性是局部性与全局性。 在希尔伯特曲线的映射过程中，相邻的一维线段在高维空间中仍然倾向于保持局部邻近性（尽管并非绝对）。这意味着，在一维序列中相近的点，在二维或三维空间中也往往彼此靠近。

二、希尔伯特曲线家族：多样的空间填充策略

希尔伯特曲线并非孤立存在，它属于一个更大的空间填充曲线家族，每个成员都有其独特的构建方式和应用场景。

三、希尔伯特曲线的深远意义：超越几何的维度

希尔伯特曲线的意义远不止于其几何形态，它在数学、计算机科学、甚至哲学层面都产生了深远的影响。

1. 数学意义：

• 挑战维度直觉： 希尔伯特曲线证明了一维曲线可以覆盖高维空间，颠覆了人们对维度的传统认知。


• 分形几何的早期范例： 它展示了自相似性和无限递归的数学美感，为分形几何的发展奠定了基础。


• 拓扑学应用： 为连续映射和空间压缩提供了理论支持。

2. 计算机科学与工程应用：

• 空间索引： 在数据库中高效处理多维数据（如地图坐标、图像像素），通过希尔伯特排序优化范围查询。


• 图像处理： 将二维图像转换为一维序列，用于压缩或渐进传输。


• 并行计算： 分配高维数据到计算节点时，保持数据的局部性以减少通信开销。


• 路径规划： 机器人导航或PCB布线中，生成覆盖整个区域的连续扫描路径。

3. 哲学与认知影响：

希尔伯特曲线模糊了维度的界限，引发了对“维度”本质的哲学思考，挑战了传统几何学的直观认知。

四、空间填充曲线的对比：各有千秋

从上表可以看出，不同的空间填充曲线在连续性、交叉点、局部性保留等方面各有特点，适用于不同的应用场景。希尔伯特曲线以其良好的局部性保留和无交叉点的特性，在数据库索引和图像处理等领域表现出色。

总结：维度之桥，应用之光

希尔伯特曲线及其变体不仅在理论数学中揭示了维度的奇妙性质，更在计算机科学中成为处理高维数据的关键工具。其核心价值在于将高维问题映射到低维空间并保持局部性，从而在效率和实用性之间找到平衡。随着大数据和人工智能时代的到来，希尔伯特曲线及其衍生技术将在更多领域展现其独特的魅力和应用价值。 无论是理解宇宙的结构，还是优化数据的存储与查询，希尔伯特曲线都为我们提供了一把穿越维度的钥匙，一座连接理论与应用的桥梁。

计算初始化内存总长度

问题背景

在一个系统中，需要执行一系列的内存初始化操作。每次操作都会初始化一个特定地址范围的内存。这些操作范围可能会相互重叠。我们需要计算所有操作完成后，被初始化过的内存空间的总长度。

核心定义

• 操作范围: 每一次内存初始化操作由一个范围 [start, end] 定义，它代表一个左闭右开的区间 [start, end)。这意味着地址 start 被包含，而地址 end 不被包含。


• 内存长度: 对于一个操作 [start, end]，其初始化的内存长度为 end - start。

关键假设

任务要求

给定一组内存初始化操作 cmdsOfMemInit，计算所有操作完成后，被初始化过的内存空间的总长度。这等同于计算所有给定区间的并集的总长度。

输入格式

• cmdsOfMemInit: 一个二维数组（或列表的列表），代表一系列的内存初始化操作。
  
  
  
  
  • 数组长度: 1 <= cmdsOfMemInit.length <= 100000
  
  
  • 每个元素 cmdsOfMemInit[i] 是一个包含两个整数 [start, end] 的数组。
  
  
  • 区间范围: 0 <= start < end <= 10^9
  
  
  
  

输出格式

• 一个整数，表示最终被初始化过的内存空间的总长度。

样例说明

样例 1

• 输入: [[2, 4], [3, 7], [4, 6]]


• 输出: 5


• 解释:
  
  
  
  
  1. 我们有三个区间：[2, 4), [3, 7), [4, 6)。
  
  
  2. 合并 [2, 4) 和 [3, 7) : 因为它们有重叠部分（[3, 4)），所以可以合并成一个更大的区间 [2, 7)。
  
  
  3. 合并 [2, 7) 和 [4, 6) : 新的区间 [4, 6) 完全被 [2, 7) 覆盖。合并后的结果仍然是 [2, 7)。
  
  
  4. 所有操作完成后，最终被初始化的内存区域是 [2, 7)。
  
  
  5. 总长度为 7 - 2 = 5。
  
  
  
  

样例 2

• 输入: [[3, 7], [2, 4], [10, 30]]


• 输出: 25


• 解释:
  
  
  
  
  1. 我们有三个区间：[3, 7), [2, 4), [10, 30)。
  
  
  2. 合并 [3, 7) 和 [2, 4) : 它们有重叠部分，合并后的区间为 [2, 7)。
  
  
  3. 合并 [2, 7) 和 [10, 30) : 这两个区间没有重叠，因为 10 大于 7。它们是两个独立的初始化区域。
  
  
  4. 所有操作完成后，最终的初始化内存区域由两个不相交的区间组成：[2, 7) 和 [10, 30)。
  
  
  5. 总长度是这两个独立区间长度之和：(7 - 2) + (30 - 10) = 5 + 20 = 25。
  
  
  
  

import java.util.ArrayList;

import java.util.Arrays;

import java.util.Comparator;

import java.util.List;



/**

 * 解决“内存空间长度”问题的方案类。

 */

public class Solution {

    /**

     * 计算一系列内存初始化操作覆盖的总内存空间长度。

     *

     * @param cmdsOfMemInit 一个二维数组，每个内部数组 [start, end] 代表一个左闭右开的内存初始化区间。

     * @return 最终初始化的内存空间的总长度。

     */

    public long totalInitializedLength(int[][] cmdsOfMemInit) {

        // --- 1. 处理边界情况 ---

        // 如果输入为空或没有操作，则总长度为 0。

        if (cmdsOfMemInit == null || cmdsOfMemInit.length == 0) {

            return 0;

        }



        // --- 2. 按区间的起始地址（start）对所有操作进行升序排序 ---

        // 这是合并区间的关键前提步骤。

        // Comparator.comparingInt(a -> a[0]) 是一个简洁的写法，表示按内部数组a的第一个元素排序。

        Arrays.sort(cmdsOfMemInit, Comparator.comparingInt(a -> a[0]));



        // --- 3. 合并重叠和连续的区间 ---

        // 使用一个 List 来存储合并后的、不重叠的区间。

        List<int[]> mergedIntervals = new ArrayList<>();

        // 首先将第一个区间（起始地址最小）加入合并列表作为基础。

        mergedIntervals.add(cmdsOfMemInit[0]);



        // 遍历排序后的其余区间

        for (int i = 1; i < cmdsOfMemInit.length; i++) {

            int[] currentInterval = cmdsOfMemInit[i];

            // 获取合并列表中的最后一个区间，用于比较

            int[] lastMerged = mergedIntervals.get(mergedIntervals.size() - 1);



            // 检查当前区间是否与最后一个合并区间重叠或连续。

            // 因为区间是 [start, end) 左闭右开，所以当 currentInterval 的 start <= lastMerged 的 end 时，

            // 它们就需要合并。例如 [2,4) 和 [4,6) 应该合并为 [2,6)。

            if (currentInterval[0] <= lastMerged[1]) {

                // --- 合并区间 ---

                // 如果有重叠/连续，则更新最后一个合并区间的结束地址。

                // 新的结束地址是两个区间结束地址中的较大者。

                // 例如，合并 [2,7) 和 [4,6) 时，新的 end 是 max(7, 6) = 7，结果为 [2,7)。

                lastMerged[1] = Math.max(lastMerged[1], currentInterval[1]);

            } else {

                // --- 不重叠，添加新区间 ---

                // 如果没有重叠，则将当前区间作为一个新的、独立的合并区间添加到列表中。

                mergedIntervals.add(currentInterval);

            }

        }



        // --- 4. 计算合并后区间的总长度 ---

        // 使用 long 类型来存储总长度，防止因数值过大（坐标可达10^9）而溢出。

        long totalLength = 0;

        // 遍历所有不重叠的合并区间

        for (int[] interval : mergedIntervals) {

            // 累加每个区间的长度 (end - start)

            totalLength += (long) interval[1] - interval[0];

        }



        // --- 5. 返回结果 ---

        return totalLength;

    }





    public static void main(String[] args) {

        Solution sol = new Solution();



        // 样例1

        int[][] cmds1 = {{2, 4}, {3, 7}, {4, 6}};

        System.out.println("样例1 输入: [[2, 4], [3, 7], [4, 6]]");

        System.out.println("样例1 输出: " + sol.totalInitializedLength(cmds1)); // 预期: 5



        // 样例2

        int[][] cmds2 = {{3, 7}, {2, 4}, {10, 30}};

        System.out.println("\n样例2 输入: [[3, 7], [2, 4], [10, 30]]");

        System.out.println("样例2 输出: " + sol.totalInitializedLength(cmds2)); // 预期: 25



        // 边界测试

        int[][] cmds3 = {{1, 5}, {6, 10}};

        System.out.println("\n边界测试 输入: [[1, 5], [6, 10]]");

        System.out.println("边界测试 输出: " + sol.totalInitializedLength(cmds3)); // 预期: 8 (4+4)

    }

    */

}

CrossModuleResourceAccess项目

跨模块资源访问-程序包结构-应用框架 - 华为HarmonyOS开发者

根据官方文档和项目实践，以下是关于跨模块资源访问的总结：

1. 跨模块资源访问的核心目标

• 资源共享：通过 HAR（Harmony Archive）和 HSP（Harmony Shared Package）模块，实现资源（如文本、图片、样式等）的复用，减少冗余定义。


• 模块化开发：支持功能模块的独立开发和维护，提升开发效率和代码可维护性。

2. 资源访问方式

• 直接引用：
  
  
  
  • 使用 $r('app.type.name') 或 $rawfile('name') 访问当前模块资源。
  
  
  • 使用 $r('[hsp].type.name') 或 $rawfile('[hsp].name') 访问 HSP 模块资源。
  
  
  
  


• 动态 API 访问：
  
  
  
  • 通过 resourceManager 接口（如 getStringSync、getMediaContentSync）动态获取资源。
  
  
  • 使用 createModuleContext 创建其他模块的上下文，获取其 resourceManager 对象。
  
  
  
  

3. 资源优先级规则

• 优先级从高到低：
  
  
  
  1. 当前模块（HAP/HSP）：自身模块的资源优先级最高。
  
  
  2. 依赖的 HAR/HSP 模块：
     
     
     
     • 如果多个依赖模块中存在同名资源，按照依赖顺序覆盖（依赖顺序靠前的优先级更高）。
     
     
     
     
  
  
  
  

4. 官方文档补充

• 资源隔离与访问控制：
  
  
  
  • 类似腾讯云 CAM（访问管理）的权限设计，HarmonyOS 通过模块化设计实现资源的逻辑隔离。
  
  
  • 开发者可以通过显式依赖和资源命名规范避免冲突。
  
  
  
  


• 跨模块通信：
  
  
  
  • 除了资源访问，还可以通过模块间接口调用实现功能共享。
  
  
  
  

5. 最佳实践

• 命名规范：为资源文件添加模块前缀（如 hsp1_icon.png），避免命名冲突。


• 依赖管理：在 oh-package.json5 中明确模块依赖顺序，确保资源优先级符合预期。


• 动态加载：对于插件化场景，优先使用 resourceManager 动态加载资源。

6. 适用场景

• 多模块共享通用资源（如主题、图标、多语言文本）。


• 动态加载不同模块的资源（如插件化设计）。

如果需要进一步分析具体实现或优化建议，请告诉我！

相关问题

JavaScript事件循环

• 调用栈:这里存放着所有执行中的代码块(函数)。当一个函数被调用时，它被添加到栈中;当返回值被返回时它从栈中被移除。
• 消息队列:当异步事件发生时(如点击事件、文件读取完成等)，对应的回调函数会被添加到消息队列中。如果调用栈为空，事件循环将从队列中取出一个事件处理。
• 微任务队列:与消息队列类似，但处理优先级更高。微任务(如Promise的回调)在当前宏任务执行完毕后、下-个宏任务开始前执行。
• 宏任务与微任务:宏任务包括整体的脚本执行、setTimeout、setlnterval等;微任务包括Promise回调.process.nextTick等。事件循环的每个循环称为一个tick，每个tick会先执行所有可执行的微任务，再执行一个宏任务。

V8引擎中的垃圾回收机制如何工作?

V8引擎使用的垃圾回收策略主要基于“分代收集”(Generational Garbage Collection)的理念:

• 新生代(Young Generation):这部分主要存放生存时间短的小对象。新生代空间较小，使用Scavenge算法进行高效的垃圾回收。Scavenge算法采用复制的方式工作，它将新生代空间分为两半，活动对象存放在一半中，当这一半空间用完时，活动对象会被复制到另一半，非活动对象则被清除。
• 老生代(Old Generation):存放生存时间长或从新生代中晋升的大对象。老生代使用Mark-Sweep(标记-清除)和 Mark-Compact (标记-压缩)算法进行垃圾回收。标记-清除算法在标记阶段标记所有从根节点可达的对象，清除阶段则清除未被标记的对象。标记-压缩算法在清除未标记对象的同时，将存活的对象压缩到内存的一端，减少碎片。

V8 引擎是如何优化其性能的?

V8引擎通过多种方式优化JavaScript的执行性能:

• 即时编译(JIT)：V8将JavaScript代码编译成更高效的机器代码而不是传统的解释执行。V8采用了一个独特的两层编译策略，包括基线编译器(lgnition)和优化编译器(TurboFan)。lgnition生成字节码，这是一个相对较慢但内存使用较少的过程。而 TurboFan 则针对热点代码(执行频率高的代码)进行优化，生成更快的机器代码。
• 内联缓存(lnline Caching)：V8使用内联缓存技术来减少属性访问的时间。当访问对象属性时，V8会在代码中嵌入缓存信息，记录属性的位置，以便后续的属性访问可以直接使用这些信息，避免再次查找，从而加速属性访问。
• 隐藏类(Hidden Classes)：尽管JavaScript是一种动态类型语言，V8引擎通过使用隐藏类来优化对象的存储和访问。每当对象被实例化或修改时，V8会为对象创建或更新隐藏类，这些隐藏类存储了对象属性的布局信息，使得属性访问更加迅速。

引擎基础

冯·诺依曼结构

解释和编译

Java 编译为 class 文件，然后执行

JavaScript 属于解释型语言，它需要在代码执行时，将代码编译为机器语言。

ast (Abstract Syntax Tree)

• Interpreter 逐行读取代码并立即执行。

• Compiler 读取您的整个代码，进行一些优化，然后生成优化后的代码。

JavaScript引擎

JavaScript 其实有众多引擎，只不过v8 是我们最为熟知的。

• V8 （Google），用 C++编写，开放源代码，由 Google 丹麦开发，是 Google Chrome 的一部分，也用于 Node.js.
• JavascriptCore （Apple），开放源代码，用于 webkit 型浏览器，如 Safari，2008年实现了编译器和字节码解释器，升级为了 SquirreFish。苹果内部代号为“Nitro”的 Javascript 引擎也是基于 JavascriptCore 引擎的。
• Rhino，由Mozilla 基金会管理，开放源代码，完全以Java 编写，用于 HTMLUnit
• SpiderMonkey （Mozilla），第一款 Javascript 引擎，早期用于 Netscape Navigator，现时用于 Mozilla Firefox。
• Nodejs 整个架构

:::info 谷歌的Chrome 使用 V8

Safari 使用 JavaScriptCore,

Firefox 使用 SpiderMonkey。

:::

• V8的处理过程
  • 始于从网络中获取 JavaScript 代码。

V8 解析源代码并将其转化为抽象语法树（AST abstract syntax tree）。

- 基于该AST，Ignition 基线解释器可以开始做它的事情，并产生字节码。

- 在这一点上，引擎开始运行代码并收集类型反馈。

- 为了使它运行得更快，字节码可以和反馈数据一起被发送到TurboFan 优化编译器。优化编译器在此基础上做出某些假设，然后产生高度优化的机器代码。

- 如果在某些时候，其中一个假设被证明是不正确的，优化编译器就会取消优化，并回到解释器中。

垃圾回收算法

垃圾回收，又称为：GC （garbage collection）。

GC 即 Garbage Collection，程序工作过程中会产生很多垃圾，这些垃圾是程序不用的内存或者是之前用过了，以后不会再用的内存空间，而GC 就是负责回收垃圾的，因为他工作在引擎内部，所以对于我们前端来说， GC 过程是相对比较无感的，这一套引擎执行而对我们又相对无感的操作也就是常说的垃圾回收机制了当然也不是所有语言都有 GC，一般的高级语言里面会自带GC，比如 Java、Python、Javascript 等，也有无GC的语言，比如C、C++等，那这种就需要我们程序员手动管理内存了，相对比较麻烦

“垃圾”的定义

• “可达性”，有没有被引用，没有被引用的变量，“不可达的变量”
• 变量会在栈中存储，对象在堆中存储
• 我们知道写代码时创建一个基本类型、对象、函数都是需要占用内存的，但是我们并不关注这些，因为这是引擎为我们分配的，我们不需要显式手动的去分配内存，那么 JavaScript 引擎是如何发现并清理垃圾的呢？

引用计数算法

相信这个算法大家都很熟悉，也经常听说。

它的策略是跟踪记录每个变量值被使用的次数

• 当声明了一个变量并且将一个引用类型赋值给该变量的时候这个值的引用次数就为 1 如果同一个值又被赋给另一个变量，那么引用数加1
• 如果该变量的值被其他的值覆盖了，则引用次数減1
• 当这个值的引用次数变为0的时候，说明没有变量在使用，这个值没法被访问了，回收空间，垃圾回收器会在运
• 行的时候清理掉引用次数为0的值占用的内存

:::info 这个算法最怕的就是循环引用（相互引用），还有比如 JavaScript 中不恰当的闭包写法

:::

优点

• 引用计数算法的优点我们对比标记清除来看就会清晰很多，首先引用计数在引用值为0时，也就是在变成垃圾的那一刻就会被回收，所以它可以立即回收垃圾
• 而标记清除算法需要每隔一段时间进行一次，那在应用程序（JS脚本）运行过程中线程就必须要暂停去执行一段时间的GC，另外，标记清除算法需要遍历堆里的活动以及非活动对象来清除，而引用计数则只需要在引用时计数就可以

弊端

• 它需要一个计数器，而此计数器需要占很大的位置，因为我们也不知道被引用数量的上限，还有就是无法解决循环引用无法回收的问题，这也是最严重的

标记清除（Mark-Sweep）算法

:::info 从根对象进行检测，先标记再清除

:::

• 标记清除（Mark-Sweep），目前在 JavaScript引擎里这种算法是最常用的，到目前为止的大多数浏览器的 Javascript引擎都在采用标记清除算法，各大浏览器厂商还对此算法进行了优化加工，且不同浏览器的 Javascript引擎在运行垃圾回收的频率上有所差异。
• 此算法分为标记和清除两个阶段，标记阶段即为所有活动对象做上标记，清除阶段则把没有标记（也就是非活动对象）销毁
• 当变量进入执行环境时，反转某一位（通过一个二进制字符来表示标记），又或者可以维护进入环境变量和离开环境变量这样两个列表，可以自由的把变量从一个列表转移到另一个列表。
• 引擎在执行GC（使用标记清除算法）时，需要从出发点去遍历内存中所有的对象去打标记，而这个出发点有很多， 我们称之为一组根对象，而所谓的根对象，其实在浏览器环境中包括又不止于全局Window对象、文档DOM树
• 整个标记清除算法大致过程就像下面这样：
  • 垃圾收集器在运行时会给内存中的所有变量都加上一个标记，假设内存中所有对象都是垃圾，全标记为0
  • 然后从各个根对象开始遍历，把不是垃圾的节点改成1
  • 清理所有标记为O的垃圾，销毁并回收它们所占用的内存空间
  • 最后，把所有内存中对象标记修改为O，等待下一轮垃圾回收

优点

• 标记清除算法的优点只有一个，那就是实现比较简单，打标记也无非打与不打两种情况，这使得一位二进制位（0和 1）就可以为其标记，非常简单

弊端

• 标记清除算法有一个很大的缺点，就是在清除之后，剩余的对象内存位置是不变的，也会导致空闲内存空间是不连续的，出现了内存碎片（如下图），并且由于剩余空闲内存不是一整块，它是由不同大小内存组成的内存列表，这就牵扯出了内存分配的问题
• 那如何找到合适的块呢？

:::danger 在插入值的时候去解决，最大化使用内存空间，即：通过插入的形式，提升内存空间使用

:::

• 我们可以采取下面三种分配策略
  • First-fit，找到大于等于 size 的块立即返回
  • Best-fit，遍历整个空闲列表，返回大于等于 size 的最小分块
  • Worst-fit，遍历整个空闲列表，找到最大的分块，然后切成两部分，一部分 size 大小，并将该部分返回这三种策略里面 Worst-fit 的空间利用率看起来是最合理，但实际上切分之后会造成更多的小块，形成内存碎片，所以不推荐使用，对于 First-fit 和 Best-fit 来说，考虑到分配的速度和效率 First-fit 是更为明智的选择
• 综上所述，标记清除算法或者说策略就有两个很明显的缺点
  • 内存碎片化，空闲内存块是不连续的，容易出现很多空闲内存块，还可能会出现分配所需内存过大的对象时找不到合适的块
  • 分配速度慢，因为即便是使用 First-fit策略，其操作仍是一个0（n）的操作，最坏情况是每次都要遍历到最后，同时因为碎片化，大对象的分配效率会更慢

:::info 归根结底，标记清除算法的缺点在于清除之后剩余的对象位置不变而导致的空闲内存不连续，所以只要解决这一点，两个缺点都可以完美解决了

:::

标记整理（Mark-Compact）算法

:::color1 有碎片就整理，整理的过程是有消耗的，所以就会有新生代、老生代

:::

• 而标记整理（Mark-Compact）算法就可以有效地解决，它的标记阶段和标记清除算法没有什么不同，只是标记结束后，标记整理算法会将活着的对象（即不需要清理的对象）向内存的一端移动，最后清理掉边界的内存

Unix/windows/Android/iOS系统中内存碎片空间思想

内存碎片化是所有系统都面临的挑战，不同操作系统和环境中的处理策略各有侧重，但也有其共通之处。以下是不同系统在内存碎片处理上的比较：

V8引擎中的标记-整理算法

• 标记阶段：识别未使用的对象，标记为垃圾。
• 整理阶段：将存活对象移动到连续区域，释放大块内存空间，减少外部碎片。

电脑系统（Unix/Linux vs Windows）

• 内存管理：均使用分页机制，但Linux更倾向于预防碎片，Windows依赖内存压缩。
• 处理策略：Linux通过 slab 分配器优化内存分配，Windows通过内存压缩技术。
• 相同点：分页和交换机制，内存不足时回收内存。
• 不同点：Linux更注重预防，Windows依赖内存压缩，处理方式不同。

移动终端（Android vs iOS）

• 内存管理：Android基于Linux，采用内存回收和进程优先级管理；iOS使用更严格的内存管理。
• 处理策略：Android通过Activity生命周期管理内存，iOS通过ARC自动管理。
• 相同点：内存不足时回收内存，依赖垃圾回收机制。
• 不同点：Android更灵活，支持后台进程保活；iOS更严格，强制回收。

内存碎片化挑战

• 内部碎片：内存分配导致的未使用空间，需优化分配策略。
• 外部碎片：分散的空闲空间，需整理或置换策略。
• 处理目标：桌面系统注重稳定性，移动设备关注响应和功耗。

工具与分析

• Unix/Linux：使用top、htop、vmstat等工具。
• Windows：依赖任务管理器和性能监视器。
• 移动设备：Android用Android Profiler，iOS用Instruments。
  总结： 不同系统在内存碎片处理上各有特色，但都旨在优化内存使用效率。V8引擎通过标记-整理减少碎片，而操作系统如Unix/Linux和Windows，以及移动系统如Android和iOS则采用不同的内存管理策略，以适应各自的性能和资源需求。

内存管理

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

:::

新生代

• 当新加入对象时，它们会被存储在使用区。然而，当使用区快要被写满时，垃圾清理操作就需要执行。在开始垃圾回收之前，新生代垃圾回收器会对使用区中的活动对象进行标记。标记完成后，活动对象将会被复制到空闲区并进行排序。然后，垃圾清理阶段开始，即将非活动对象占用的空间清理掉。最后，进行角色互换，将原来的使用区变成空闲区，将原来的空闲区变成使用区。
• 如果一个对象经过多次复制后依然存活，那么它将被认为是生命周期较长的对象，且会被移动到老生代中进行管理。
• 除此之外，还有一种情况，如果复制一个对象到空闲区时，空闲区的空间占用超过了25%，那么这个对象会被直接晋升到老生代空间中。25%比例的设置是为了避免影响后续内存分配，因为当按照 Scavenge 算法回收完成后， 空闲区将翻转成使用区，继续进行对象内存分配。

:::info 一直在开辟空间，达到一定程度，就回晋升到老生代

:::

老生代

• 不同于新生代，老生代中存储的内容是相对使用频繁并且短时间无需清理回收的内容。这部分我们可以使用标记整理进行处理。
• 从一组根元素开始，递归遍历这组根元素，遍历过程中能到达的元素称为活动对象，没有到达的元素就可以判断为非活动对象
• 清除阶段老生代垃圾回收器会直接将非活动对象进行清除。

并行回收

:::info 思想类似于 花两个人的钱，让一个人干三个人的活

:::

全停顿标记

这个概念看字眼好像不好理解，其买如果用前端开发的术语来解释，就是阻塞。

虽然我们的 GC操作被放到了主进程与子进程中去处理，但最终的结果还是主进程被较长时间占用。

在JavaScript的V8引擎中，全停顿标记（Full Stop-the-world Marking）是垃圾回收（GC）过程中的一个重要环节。

这个过程涉及到V8的垃圾回收器暂停JavaScript程序的执行，以便进行垃圾回收的标记阶段。全停顿标记是为了确保在回收内存前正确标记所有活动对象（即正在使用的对象）和非活动对象（即可以清除的对象）。

全停顿标记的工作原理

1.停止执行：当执行到全停顿标记阶段时，V8引擎会暂停正在执行的JavaScript代码，确保没有任何Javascript代码在运行。这个停顿是必需的，因为在标记活动对象时，对象的引用关系需要保持不变。
2. 标记阶段：在这个阶段，垃圾回收器遍历所有根对象（例如全局变量、活跃的函数的局部变量等），从这些根对象开始，递归地访问所有可达的对象。每访问到一个对象，就将其标记为活动（1）的。

3. 恢复执行：标记完成后，V8引擎会恢复JavaScript代码的执行，进入垃圾回收的清除或压缩阶段。

全停顿的影响及优化

全停顿标记虽然对于确保内存被正确管理是必要的，但它会对应用程序的性能产生影响，特别是在垃圾回收发生时， 应用程序的响应时间和性能会短暂下降。为了缓解这种影响，V8引擎采用了几种策略：

• 增量标记 （Incremental Marking）：为了减少每次停顿的时间，V8实现了增量标记，即将标记过程分成多个小部分进行，介于JavaScript执行的间隙中逐步完成标记。

• 并发标记（Concurrent Marking）：V8引擎的更高版本中引入了并发标记，允许垃圾回收标记阶段与JavaScript代码的执行同时进行，进一步减少停顿时间。

• 延迟清理（Lazy Sweeping）：标记完成后的清理阶段也可以延迟执行，按需进行，以减少单次停顿的时间。

这些优化措施有助于提高应用的响应速度和整体性能，特别是在处理大量数据和复杂操作时，确保用户体验不会因垃圾回收而受到较大影响。

切片标记

• 增量就是将一次 GC标记的过程，分成了很多小步，每执行完一小步就让应用逻辑执行一会儿，这样交替多次后完成一轮 GC 标记

三色标记

我们这里的会，表示的是一个中间状态，为什么会有这个中间状态呢？

• 白色指的是未被标记的对象

• 灰色指自身被标记，成员变量（该对象的引用对象）未被标记 • 黑色指自身和成员变量皆被标记

在V8引擎中使用的三色标记算法是一种用于垃圾回收的有效方法，特别是在进行增量和并发标记时。这个算法通过给对象着色（白色、灰色、黑色）来帮助标记和回收垃圾。

工作原理

1. 初始化：

• 白色：初始状态，所有对象都标记为白色，表示这些对象可能是垃圾，如果在标记过程中没有被访问到，最终将被清理。
• 灰色：表示对象已经被标记（访问过），但该对象的引用还没有完全检查完。
• 黑色：表示该对象及其所有引用都已经被完全访问过，并且已经标记。

2. 标记过程：

• 垃圾回收开始时，从根集合（如全局变量、活跃的堆栈帧中的局部变量等）出发，将所有根对象标记为灰色。
• 逐一处理灰色对象：将灰色对象标记为黑色，并将其直接引用的所有白色对象转变为灰色。这个过程不断重复，直到没有灰色对象为止。

3. 扫描完成：

• 所有从根可达的对象最终都会被标记为黑色。所有仍然为白色的对象被认为是不可达的，因此将被视为垃圾并在清除阶段被回收。

优点

• 健壮性：三色标记算法非常适合增量和并发的垃圾回收，因为它能够确保即使在应用程序继续执行的情况下也能正确地标记活动对象。
• 防止漏标：通过灰色和黑色的严格区分，算法确保所有可达的对象都会被遍历和标记，防止错误地回收正在使用的对象。
• 效率：虽然在垃圾回收期间会有增加的计算开销，但三色标记算法可以与应用程序的执行并行进行，减少了GC停顿的时间，提高了应用的响应性和性能。

应用

• 在实际应用中，V8和其他现代JavaScript引擎使用这种算法进行内存管理，优化了动态内存的使用，减少了垃圾回收对应用性能的影响。这对于要求高性能和实时响应的Web应用程序尤其重要。

写屏障（增量中修改引用）

• 这一机制用于处理在增量标记进行时修改引用的处理，可自行修改为灰色

在V8引擎中，写屏障（Write Barrier）是垃圾回收（GC）的一个关键机制，尤其是在增量和并发垃圾回收过程中发挥着至关重要的作用。写屏障主要用来维持垃圾回收中的三色不变性，在对象写操作期间动态地更新对象的可达性信息。

作用

• 保持三色不变性，在使用三色标记算法中，写屏障帮助维持所谓的三色不变性。这意味着系统确保如果一个黑色对象（已经被完全扫描的对象）引用了一个白色对象（尚未被扫描的对象，可能是垃圾），那么这个白色对象应当转变为灰色（标记但尚未扫描完毕的对象），从而避免错误的垃圾回收。
• 处理指针更新，当一个对象的指针被更新（例如，一个对象的属性被另一个对象替换），写屏障确保关于这些对象的垃圾回收元数据得到适当的更新。这是确保垃圾回收器正确识别活动对象和非活动对象的必要步骤。

类型

• Pre-Write Barrier（预写屏障），这种类型的写屏障在实际更新内存之前执行。它主要用于某些特定类型的垃圾回收算法，比如分代垃圾回收，以保持老年代和新生代之间的引用正确性。
• Post-Write Barrier（后写屏障），这是最常见的写屏障类型，发生在对象的指针更新之后。在V8中，当黑色对象指向白色对象时，后写屏障会将该白色对象标记为灰色，确保它不会在当前垃圾回收周期中被错误地回收。

实现细节

• 在V8引擎中，写屏障通常由简短的代码片段实现，这些代码片段在修改对象属性或数组元素时自动执行。例如，每当JavaScript代码或内部的V8代码试图写入一个对象的属性时，写屏障代码会检查是否需要更新垃圾回收的元数据。

惰性清理

• 增量标记只是用于标记活动对象和非活动对象，真正的清理释放内存，则V8采用的是惰性清理（Lazy Sweeping）方案。
• 在增量标记完成后，进行清理。当增量标记完成后，假如当前的可用内存足以让我们快速的执行代码，其实我们是没必要立即清理内存的，可以将清理过程稍微延迟一下，让 Javascript 脚本代码先执行，也无需一次性清理完所有非活动对象内存，可以按需逐一进行清理直到所有的非活动对象内存都清理完毕。

并发回收

:::info 本质是切片，然后去插入，做一些动作

:::

• react 中的 Concurrent 吗？
• 我们想想 React演进过程，是不是就会觉得从并行到并发的演进变得很合了呢？
• 并发挥收其实是更进一步的切片，几乎完全不阻塞主进程。

:::success 分代式机制把一些新、小、存活时间短的对象作为新生代，采用一小块内存频率较高的快速清理，而一些大、老、存活时间长的对象作为老生代，使其很少接受检查，新老生代的回收机制及频率是不同的，可以说此机制的出现很大程度提高了垃圾回收机制的效率

:::

怎么理解内存泄露？

怎么解决内存泄露，代码层面如何优化？

• 减少查找
• 减少变量声明
• 使用 Performance + Memory 分析内存与性能

运行机制

• 浏览器主进程
  • 协调控制其他子进程（创建、销毁）
  • 浏览器界面显示，用户交互，前进、后退、收藏
  • 将渲染进程得到的内存中的Bitmap，绘制到用户界面上
  • 存储功能等
• 第三方插件进程
  • 每种类型的插件对应一个进程，仅当使用该插件时才创建
• GPU进程
  • 用于3D绘制等
• 渲染进程，就是我们说的浏览器内核
  • 排版引擎 Blink 和 JavaScript 引擎V8 都是运行在该进程中，将HTML、CSS和 JavaScript 转换为用户可以与之交互的网页

- 负责页面渲染，脚本执行，事件处理等

- 每个tab页一个渲染进程

- 出于安全考虑，渲染进程都是运行在沙箱模式下

• 网络进程
  • 负责页面的网络资源加载，之前作为一个模块运行在浏览器主进程里面，最近才独立成为一个单独的进程

浏览器事件循环

:::info 在 Chrome 中，事件循环的执行是由浏览器的渲染引擎（例如 Blink）和V8 引擎配合完成的。V8负责 JavaScript 代码的执行，Blink 负责浏览器的渲染和用户界面的更新

:::

执行任务的顺序

先执行当前执行栈同步任务，再执行（微任务），再执行（宏任务）

宏任务

:::info 在 Chrome的源码中，并未直接出现“宏任务”这一术语，但在 Javascript 运行时引擎（V8）以及事件循环 （Event Loop）相关的实现中，宏任务和微任务的概念是非常重要的。

实际上，“宏任务”这一术语来源于 Javascript 事件循环的抽象，它只是帮助我们理解任务的执行顺序和时机。

:::

可以将每次执行栈执行的代码当做是一个宏任务

• I/O
• setTimeout
• setinterval
• setImmediate
• requestAnimationFrame

微任务

当宏任务执行完，会在渲染前，将执行期间所产生的所有微任务都执行完

• process.nextTick
• MutationObserver
• Promise.then catch finally

完整鏊体流程

• 执行当前执行栈同步任务（栈中没有就从事件队列中获取）
• 执行过程中如果遇到微任务，就将它添加到微任务的任务队列中
• 执行栈同步任务执行完毕后，立即执行当前微任务队列中的所有微任务(依次执行)
• 宏任务执行完毕，开始检查渲染，然后 GUI线程接管渲染
• 渲染完毕后， JS线程继续接管，开始下一个宏任务（从事件队列中获取）

Node事件循环机制

与浏览器事件循环机制的不同

• 在 Node.js 中，为了更高效地管理和调度各种类型的异步任务。这种设计使得 Node.js 能够在单线程环境中有效地处理大量的并发任务。下
• Node.js 的事件循环（Event Loop）是一个处理异步操作的机制，它会按照顺序依次执行不同阶段任务。事件循环机制中分为多个阶段，每个阶段都有自己的任务队列，包括：
• Timers 阶段：
  • 处理 setTimeout 和 setInterval 调度的回调函数。
  • 如果指定的时间到了，回调函数会被放入这个队列。
• Pending Callbacks 阶段：
  • 处理一些1/0操作的回调，比如 TCP 错误类型的回调。
  • 这些回调并不完全由开发者控制，而是由操作系统调度的。
• Idle, Prepare 阶段：
  • 仅供内部使用的阶段。
• Poll 阶段：
  • 获取新的1/0事件，执行1/0回调函数。
  • 通常情况下，这个阶段会一直等待，直到有新的！/0 事件到来。
• Check 阶段：
  • 处理 ：setImmediate 调度的回调函数。
  • etImmediate 的回调会在这个阶段执行，比 setTimeout 更早。
• Close Callbacks 阶段：
  • 处理一些关闭的回调函数，比如 socket.on('close', ... ) °

多个队列的必要性

不同类型的异步任务有不同的优先级和处理方式。使用多个队列可以确保这些任务被正确地调度和执行：

• Timers 和 Poll 阶段的区别：
  • setTimeout 和 setInterval 的回调在 Timers 阶段执行，这些回调函数依赖于计时器的到期时间。
  • Poll 阶段处理大多数1/0 回调，这是事件循环的主要阶段，处理大部分异步1/O操作。
• mmediate 与 Timeout 的不同：
  • setImmediate 的回调函数在 Check 阶段执行，这是在当前事件循环周期结束后立即执行。
  • setTimeout 的回调函数则是在 Timers 阶段执行，它可能会延迟到下一个事件循环周期，甚至更久。
• 处理关闭回调：
  • Close Callbacks 阶段专门处理如 socket.on（'close'）这样的回调，以确保在资源释放时执行。

Chrome 任务调度机制

V8与Blink的调度系统密切相关。

:::info Blink 是 Chrome 中的渲染引擎

V8是 Chrome 中的 JavaScript 引擎

:::

Blink 是 Chrome 浏览器中的渲染引擎，负责页面的渲染和绘制任务。V8与 Blink 会协同工作，确保 JavaScript 的执行与页面渲染能够平稳进行。

Blink Scheduler：docs.google.com/document/d/…

接下来我们了解一下 Blink scheduler，一个用于优化 Blink 主线程任务调度的方案，旨在解决现有调度系统中的一些问题。

将任务不断安排到主线程的消息循环中，会导致Blink 主线程阻塞。造成诸多问题：

• 有限的优先级设置-任务按照发布顺序执行，或者可以明确地延迟，但这可能导致一些重要的任务（如输入处理） 被不那么紧急的任务占用优先执行权。
• 缺乏与系统其他部分的协调-比如图形管线虽然已知有输入事件的传递、显示刷新等时序要求，但这些信息无法及时传递给Blink。
• 无法适应不同的使用场景 -某些任务（如垃圾回收）在用户交互时进行非常不合适。

为了解决以上问题，出现了 Blink Scheduler 调度器，它能够更灵活控制任务按照给定优先级执行

• 关键特点
  • 调度器的主要功能是决定在特定时刻哪个任务应当执行。
  • 调度器提供了更高级的API替代现有的主线程任务调度接口，任务不再是抽象的回调函数，而是更具体、具有明确标签和元数据的对象。例如，输入任务会被明确标记，并附带附加元数据。
  • 调度器可以根据系统状态做出更明智的任务决策，而不是依赖给定死的静态优先级。

gitlab.mpi-klsb.mpg.de/eweyulu/qui…

• 性能验证和工具
• 为了验证调度器的效果，文章提到了多项基准测试和性能指标，例如：
  • 队列等待时间：衡量任务从发布到执行的延迟。
  • 输入事件延迟：衡量输入事件的处理时间。
  • 渲染平滑度（jank）：衡量渲染的平滑性，避免出现卡顿。
  • 页面加载时间：跟踪页面加载时间的变化。

其他资料

• V8：v8.dev/docs/torque
• chromium 中promise：chromium.googlesource.com/v8/v8/+/ref…
• V8定义：chromium.googlesource.com/v8/v8/+/ref…
• Node V8：nodejs.org/en/learn/ge…
• ibuv-in-node-js：http://www.geeksforgeeks.org/libuv-in-no…
• Faster JavaScript calls：v8.dev/blog/adapto…
• blink scheduler：docs.google.com/document/d/…

作者：若梦plus
来源：juejin.cn/post/7493386024878833715

Go 语言未来会取代 Java 吗？

（八年 Java 开发的深度拆解：从业务场景到技术底层）

开篇：面试官的灵魂拷问与行业焦虑

前年面某大厂时，技术负责人突然抛出问题：“如果让你重构公司核心系统，会选 Go 还是 Java？”

作为写了八年 Java 的老开发，我本能地想强调 Spring 生态和企业级成熟度，但对方随即展示的 PPT 让我冷汗直冒 —— 某金融公司用 Go 重构交易系统后，QPS 从 5 万飙升到 50 万，服务器成本降低 70%。这让我陷入沉思：当云原生和 AI 浪潮来袭，Java 真的要被 Go 取代了吗？

今天从 业务场景、技术本质、行业趋势 三个维度，结合实战代码和踩坑经验，聊聊我的真实看法。

一、业务场景对比：Go 的 “闪电战” vs Java 的 “持久战”

先看三个典型业务场景，你会发现两者的差异远不止 “性能” 二字。

场景 1：高并发抢购（电商大促）

Go 实现（Gin 框架） ：

func main() {

    router := gin.Default()

    router.GET("/seckill", func(c *gin.Context) {

        // 轻量级goroutine处理请求

        go func() {

            // 直接操作Redis库存

            if err := redisClient.Decr("stock").Err(); err != nil {

                c.JSON(http.StatusOK, gin.H{"result": "fail"})

                return

            }

            c.JSON(http.StatusOK, gin.H{"result": "success"})

        }()

    })

    router.Run(":8080")

}

性能数据：单机轻松支撑 10 万 QPS，p99 延迟 < 5ms。

Java 实现（Spring Boot + 虚拟线程） ：

@RestController

public class SeckillController {

    @GetMapping("/seckill")

    public CompletableFuture<ResponseEntity<String>> seckill() {

        return CompletableFuture.supplyAsync(() -> {

            // 虚拟线程处理IO操作

            if (redisTemplate.opsForValue().decrement("stock") < 0) {

                return ResponseEntity.ok("fail");

            }

            return ResponseEntity.ok("success");

        }, Executors.newVirtualThreadPerTaskExecutor());

    }

}

性能数据：Java 21 虚拟线程让 IO 密集型场景吞吐量提升 7 倍，p99 延迟从 165ms 降至 23ms。

核心差异：

• Go：天生适合高并发，Goroutine 调度和原生 Redis 操作无额外开销。


• Java：依赖 JVM 调优，虚拟线程虽大幅提升性能，但需配合线程池和异步框架。

场景 2：智能运维平台（云原生领域）

Go 实现（Ollama + gRPC） ：

func main() {

    // 启动gRPC服务处理AI推理请求

    server := grpc.NewServer()

    pb.RegisterAIAnalysisServer(server, &AIHandler{})

    go func() {

        if err := server.Serve(lis); err != nil {

            log.Fatalf("Server exited with error: %v", err)

        }

    }()

    

    // 采集节点数据（百万级设备）

    for i := 0; i < 1000000; i++ {

        go func(nodeID int) {

            for {

                data := collectMetrics(nodeID)

                client.Send(data) // 通过channel传递数据

            }

        }(i)

    }

}

优势：轻量级 Goroutine 高效处理设备数据采集，gRPC 接口响应速度比 REST 快 30%。

Java 实现（Spring Cloud + Kafka） ：

@Service

public class MonitorService {

    @Autowired

    private KafkaTemplate<String, String> kafkaTemplate;



    public void collectMetrics(int nodeID) {

        ScheduledExecutorService executor = Executors.newScheduledThreadPool(100);

        executor.scheduleAtFixedRate(() -> {

            String data =采集数据(nodeID);

            kafkaTemplate.send("metrics-topic", data);

        }, 0, 1, TimeUnit.SECONDS);

    }

}

挑战：传统线程池在百万级设备下内存占用飙升，需配合 Kafka 分区和 Consumer Gr0up 优化。

核心差异：

• Go：云原生基因，从采集到 AI 推理全链路高效协同。


• Java：生态依赖强，需整合 Spring Cloud、Kafka 等组件，部署复杂度高。

场景 3：企业 ERP 系统（传统行业）

Java 实现（Spring + Hibernate） ：

@Entity

@Table(name = "orders")

public class Order {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;



    @ManyToOne

    @JoinColumn(name = "user_id")

    private User user;



    // 复杂业务逻辑注解

    @PrePersist

    public void validateOrder() {

        if (totalAmount < 0) {

            throw new BusinessException("金额不能为负数");

        }

    }

}

优势：Spring 的事务管理和 Hibernate 的 ORM 完美支持复杂业务逻辑，代码可读性高。

Go 实现（GORM + 接口组合） ：

type Order struct {

    ID        uint   `gorm:"primaryKey"`

    UserID    uint

    Total     float64

}



func (o *Order) Validate() error {

    if o.Total < 0 {

        return errors.New("金额不能为负数")

    }

    return nil

}



func CreateOrder(ctx context.Context, order Order) error {

    if err := order.Validate(); err != nil {

        return err

    }

    return db.Create(&order).Error

}

挑战：需手动实现事务和复杂校验逻辑，代码量比 Java 多 20%。

核心差异：

• Java：企业级成熟度，框架直接支持事务、权限、审计等功能。


• Go：灵活性高，但需手动实现大量基础功能，适合轻量级业务。

二、技术本质：为什么 Go 在某些场景碾压 Java？

从 并发模型、内存管理、性能调优 三个维度，深挖两者的底层差异。

1. 并发模型：Goroutine vs 线程 / 虚拟线程

Go 的 Goroutine：

• 轻量级：每个 Goroutine 仅需 2KB 栈空间，可轻松创建百万级并发。


• 调度高效：基于 GMP 模型，避免内核级上下文切换，IO 阻塞时自动释放线程。

Java 的虚拟线程（Java 21+） ：

• 革命性改进：每个虚拟线程仅需几百字节内存，IO 密集型场景吞吐量提升 7 倍。


• 兼容传统代码：无需修改业务逻辑，直接将new Thread()替换为Thread.startVirtualThread()。

性能对比：

• HTTP 服务：Go 的 Gin 框架单机 QPS 可达 5 万，Java 21 虚拟线程 + Netty 可达 3 万。


• 消息处理：Go 的 Kafka 消费者单节点处理速度比 Java 快 40%。

2. 内存管理：逃逸分析 vs 分代 GC

Go 的逃逸分析：

• 栈优先分配：对象若未逃逸出函数，直接在栈上分配，减少 GC 压力。


• 零拷贝优化：io.Reader接口直接操作底层缓冲区，避免内存复制。

Java 的分代 GC：

• 成熟但复杂：新生代采用复制算法，老年代采用标记 - 压缩，需通过-XX:G1HeapRegionSize等参数调优。


• 内存占用高：同等业务逻辑下，Java 堆内存通常是 Go 的 2-3 倍。

典型案例：

某金融公司用 Go 重构风控系统后，内存占用从 8GB 降至 3GB，GC 停顿时间从 200ms 缩短至 10ms。

3. 性能调优：静态编译 vs JIT 编译

Go 的静态编译：

• 启动快：编译后的二进制文件直接运行，无需预热 JVM。


• 可预测性强：性能表现稳定，适合对延迟敏感的场景（如高频交易）。

Java 的 JIT 编译：

• 动态优化：运行时将热点代码编译为机器码，长期运行后性能可能反超 Go。


• 依赖调优经验：需通过-XX:CompileThreshold等参数平衡启动时间和运行效率。

实测数据：

• 启动时间：Go 的 HTTP 服务启动仅需 20ms，Java Spring Boot 需 500ms。


• 长期运行：持续 24 小时压测，Java 的吞吐量可能比 Go 高 10%（JIT 优化后）。

三、行业趋势：Go 在蚕食 Java 市场，但 Java 不会轻易退场

从 市场数据、生态扩展、技术演进 三个维度，分析两者的未来走向。

1. 市场数据：Go 在高速增长，Java 仍占主导

• 份额变化：Go 在 TIOBE 排行榜中从 2020 年的第 13 位升至 2025 年的第 7 位，市场份额突破 3%。


• 薪资对比：Go 开发者平均薪资比 Java 高 20%，但 Java 岗位数量仍是 Go 的 5 倍。

典型案例：

• 字节跳动：核心推荐系统用 Go 重构，QPS 提升 3 倍，成本降低 60%。


• 招商银行：核心交易系统仍用 Java，但微服务网关和监控平台全面转向 Go。

2. 生态扩展：Go 拥抱 AI，Java 深耕企业级

Go 的 AI 集成：

• 工具链完善：通过 Ollama 框架可直接调用 LLM 模型，实现智能运维告警。


• 性能优势：Go 的推理服务延迟比 Python 低 80%，适合边缘计算场景。

Java 的企业级护城河：

• 大数据生态：Hadoop、Spark、Flink 等框架仍深度依赖 Java。


• 移动端统治力：尽管 Kotlin 流行，Android 系统底层和核心应用仍用 Java 开发。

3. 技术演进：Go 和 Java 都在进化

Go 的发展方向：

• 泛型完善：Go 1.18 + 支持泛型，减少重复代码（如PrintSlice函数可适配任意类型）。


• WebAssembly 集成：计划将 Goroutine 编译为 Wasm，实现浏览器端高并发。

Java 的反击：

• Project Loom：虚拟线程已转正，未来将支持更细粒度的并发控制。


• Project Valhalla：引入值类型，减少对象装箱拆箱开销，提升性能 15%。

四、选型建议：Java 开发者该如何应对？

作为八年 Java 老兵，我的 技术选型原则 是：用最合适的工具解决问题，而非陷入语言宗教战争。

1. 优先选 Go 的场景

• 云原生基础设施：API 网关、服务网格、CI/CD 工具链（如 Kubernetes 用 Go 开发）。


• 高并发实时系统：IM 聊天、金融交易、IoT 数据采集（单机 QPS 需求 > 1 万）。


• AI 推理服务：边缘计算节点、实时推荐系统（需低延迟和高吞吐量）。

2. 优先选 Java 的场景

• 复杂企业级系统：ERP、CRM、银行核心业务（需事务、权限、审计等功能）。


• Android 开发：系统级应用和性能敏感模块（如相机、传感器驱动）。


• 大数据处理：离线分析、机器学习训练（Hadoop/Spark 生态成熟）。

3. 混合架构：Go 和 Java 共存的最佳实践

• API 网关用 Go：处理高并发请求，转发到 Java 微服务。


• AI 推理用 Go：部署轻量级模型，结果通过 gRPC 返回给 Java 业务层。


• 数据存储用 Java：复杂查询和事务管理仍由 Java 服务处理。

代码示例：Go 调用 Java 微服务

// Go客户端

conn, err := grpc.Dial("java-service:8080", grpc.WithInsecure())

if err != nil {

    log.Fatalf("连接失败: %v", err)

}

defer conn.Close()



client := pb.NewJavaServiceClient(conn)

resp, err := client.ProcessData(context.Background(), &pb.DataRequest{Data: "test"})

if err != nil {

    log.Fatalf("调用失败: %v", err)

}

fmt.Println("Java服务返回:", resp.Result)

// Java服务端

@GrpcService

public class JavaServiceImpl extends JavaServiceGrpc.JavaServiceImplBase {

    @Override

    public void processData(DataRequest request, StreamObserver<DataResponse> responseObserver) {

        String result =复杂业务逻辑(request.getData());

        responseObserver.onNext(DataResponse.newBuilder().setResult(result).build());

        responseObserver.onCompleted();

    }

}

五、总结：焦虑源于未知，成长来自行动

回到开篇的问题：Go 会取代 Java 吗？  我的答案是：短期内不会，但长期会形成互补格局。

• Java 的不可替代性：企业级成熟度、Android 生态、大数据框架，这些优势难以撼动。


• Go 的不可阻挡性：云原生、高并发、AI 集成，这些领域 Go 正在建立新标准。

作为开发者，与其焦虑语言之争，不如：

最后分享一个真实案例：某电商公司将支付核心用 Java 保留，抢购服务用 Go 重构，大促期间 QPS 从 5 万提升到 50 万，系统总成本降低 40%。这说明，语言只是工具，业务价值才是终极目标。

最近，我在我们前端团队里推行了一个“强制性”的规定：所有新项目，必须使用pnpm作为包管理工具；所有老项目，必须在两个月内，逐步迁移到pnpm。

这个决定，一开始在团队里是有阻力的。

有同事问：“老大，npm用得好好的，为啥非要换啊？我们都习惯了。”

也有同事说：“yarn不也挺快的吗？再换个pnpm，是不是在瞎折腾？”

我理解大家的疑问。但我之所以要用“强制”这个词，是因为在我看来，在2025年的今天，继续使用npm或yarn，就像是明明有高铁可以坐，你却非要坚持坐绿皮火车一样，不是不行，而是没必要。

这篇文章，我就想把我的理由掰开揉碎了，讲给大家听。

npm和yarn的“原罪”：那个又大又慢的node_modules

在聊pnpm的好处之前，我们得先搞明白，npm和yarn（特指yarn v1）到底有什么问题。

它们最大的问题，都源于一个东西——扁平化的node_modules。

你可能觉得奇怪，“扁平化”不是为了解决npm v2时代的“依赖地狱”问题吗？是的，它解决了老问题，但又带来了新问题：

1. “幽灵依赖”（Phantom Dependencies）

这是我最不能忍受的一个问题。

举个例子：你的项目只安装了A包（npm install A）。但是A包自己依赖了B包。因为是扁平化结构，B包也会被提升到node_modules的根目录。

结果就是，你在你的代码里，明明没有在package.json里声明过B，但你却可以import B from 'B'，而且代码还能正常运行！

这就是“幽灵依赖”。它像一个幽灵，让你的项目依赖关系变得混乱不堪。万一有一天，A包升级了，不再依赖B了，你的项目就会在某个意想不到的地方突然崩溃，而你甚至都不知道B是从哪来的。

2. 磁盘空间的巨大浪费

如果你电脑上有10个项目，这10个项目都依赖了lodash，那么在npm/yarn的模式下，你的磁盘上就会实实在在地存着10份一模一样的lodash代码。

对于我们这些天天要开好几个项目的前端来说，电脑的存储空间就这么被日积月累地消耗掉了。

3. 安装速度的瓶颈

虽然npm和yarn都有缓存机制，但在安装依赖时，它们仍然需要做大量的I/O操作，去复制、移动那些文件。当项目越来越大，node_modules动辄上G的时候，那个安装速度，真的让人等到心焦。

pnpm是怎么解决这些问题的？——“符号链接”

好了，现在主角pnpm登场。pnpm的全称是“performant npm”，意为“高性能的npm”。它解决上面所有问题的核心武器，就两个字：链接。

pnpm没有采用扁平化的node_modules结构，而是创建了一个嵌套的、有严格依赖关系的结构。

1. 彻底告别“幽灵依赖”

在pnpm的node_modules里，你只会看到你在package.json里明确声明的那些依赖。

你项目里依赖的A包，它自己所依赖的B包，会被存放在node_modules/.pnpm/这个特殊的目录里，然后通过 符号链接（Symbolic Link） 的方式，链接到A包的node_modules里。

这意味着，在你的项目代码里，你根本访问不到B包。你想import B？对不起，直接报错。这就从结构上保证了，你的项目依赖关系是绝对可靠和纯净的。

2. 磁盘空间的“终极节约”

pnpm会在你的电脑上创建一个“全局内容可寻址存储区”（content-addressable store），通常在用户主目录下的.pnpm-store里。

你电脑上所有项目的所有依赖，都只会在这个全局仓库里，实实在在地只存一份。

当你的项目需要lodash时，pnpm不会去复制一份lodash到你的node_modules里，而是通过 硬链接（Hard Link） 的方式，从全局仓库链接一份过来。硬链接几乎不占用磁盘空间。

这意味着，就算你有100个项目都用了lodash，它在你的硬盘上也只占一份的空间。这个特性，对于磁盘空间紧张的同学来说，简直是福音。

3. 极速的安装体验

因为大部分依赖都是通过“链接”的方式实现的，而不是“复制”，所以pnpm在安装依赖时，大大减少了磁盘I/O操作。

它的安装速度，尤其是在有缓存的情况下，或者在安装一个已经存在于全局仓库里的包时，几乎是“秒级”的。这种“飞一般”的感觉，一旦体验过，就再也回不去了。

为什么我要“强制”？

聊完了技术优势，再回到最初的问题：我为什么要“强制”推行？

因为包管理工具的统一，是前端工程化规范里最基础、也最重要的一环。

如果一个团队里，有人用npm，有人用yarn，有人用pnpm，那就会出现各种各样的问题：

• 不一致的lock文件：package-lock.json, yarn.lock, pnpm-lock.yaml互相冲突，导致不同成员安装的依赖版本可能不完全一致，引发“在我电脑上是好的”这种经典问题。


• 不一致的依赖结构：用npm的同事，可能会不小心写出依赖“幽灵依赖”的代码，而用pnpm的同事拉下来，代码直接就跑不起来了。

在一个团队里，工具的统一，是为了保证环境的一致性和协作的顺畅。而pnpm，在我看来，就是当前这个时代下，包管理工具的“最优解”。

所以，这个“强制”，不是为了搞独裁，而是为了从根本上提升我们整个团队的开发效率和项目的长期稳定性。

最后的经验

从npm到yarn，再到pnpm，前端的包管理工具一直在进化。

pnpm用一种更先进、更合理的机制，解决了过去遗留下的种种问题。它带来的不仅仅是速度的提升，更是一种对“依赖关系纯净性”和“工程化严谨性”的保障。

我知道，改变一个人的习惯很难。但作为团队的负责人，我有责任去选择一条更高效、更正确的路，然后带领大家一起走下去。

如果你还没用过pnpm，我强烈建议你花十分钟，在你的新项目里试一试🙂。

多线程爬虫的使用主要是为了提高网络爬虫的效率和性能。以下是几个关键原因：

多线程爬取网站案例

# -*- coding: UTF-8 -*-

'''

@Project ：网络爬虫 

@File    ：11-多线程爬虫案例.py

@IDE     ：PyCharm 

@Author  ：慕逸

@Date    ：09/11/2024 19:54 

'''





# https://www.doutupk.com/search?type=photo&more=1&keyword=%E9%9D%93%E4%BB%94&page=3



import requests

from urllib import request

from lxml import etree

import threading

from queue import Queue

import winsound





class Producer(threading.Thread):

    headers = {

        'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36'

    }



    def __init__(self, page_queue, img_queue):

        super().__init__()

        self.page_queue = page_queue

        self.img_queue = img_queue



    def run(self):

        while True:

            if self.page_queue.empty():

                break

            url = self.page_queue.get()

            self.parse_page(url)



    def parse_page(self, url):

        response = requests.get(url, headers=self.headers)

        text = response.text

        # print(text)

        html = etree.HTML(text)

        imgs = html.xpath("//div[@class='pic-content text-center']//img[@class!='gif']")

        img_names = html.xpath(

            "//div[@class='pic-content text-center']//img[@class!='gif']/following-sibling::p/text()")



        for img, img_name in zip(imgs, img_names):

            img_url = img.get('data-original')

            # request.urlretrieve(img_url, 'E:/Study/code/Python/图片爬取/斗图啦/{}'.format(img_name) + str(random.randint(1, 10000)) + '.jpg')

            # print(img_name + "-下载完成~~" + img_url)

            self.img_queue.put((img_url, img_name))





class Consumer(threading.Thread):

    def __init__(self, page_queue, img_queue):

        super().__init__()

        self.page_queue = page_queue

        self.img_queue = img_queue



    def run(self):

        while True:

            if self.img_queue.empty() and self.page_queue.empty():

                break

            img = self.img_queue.get()

            img_url, file_name = img

            file_name = file_name.replace('.','').replace('?','')

            request.urlretrieve(img_url, 'E:/Study/code/Python/图片爬取/斗图啦/{}.jpg'.format(file_name))

            print(file_name + "-下载完成~~" + img_url)





def main():

    winsound.Beep(1500, 500)

    page_queue = Queue(100)

    img_queue = Queue(500)



    for i in range(1, 18):

        url = "https://www.doutupk.com/search?type=photo&more=1&keyword=%E9%9D%93%E4%BB%94&page={}".format(i)

        # parse_page(url)

        page_queue.put(url)

        # break



    # 创建5个线程

    for i in range(5):

        t = Producer(page_queue, img_queue)

        t.start()



    for i in range(5):

        t = Consumer(page_queue, img_queue)

        t.start()





if __name__ == '__main__':

    main()

    winsound.Beep(1000, 500)

• 生产者类负责从队列中获取页面 URL，解析页面并提取图片信息，然后将图片信息放入图片队列中。


• 消费者类负责从图片队列中获取图片信息，下载图片并保存到本地。

前言

最近在研究 Tauri 2.0 如何自动更新，跟着官网教程来了一遍，发现并不顺利，踩了很多坑，不过好在最后终于走通了，今天整理一下供大家参考。

第一步

自动更新利用的是 Tauri 的 Updater 组件，所以这里需要安装一下：

PNPM 执行这个（笔者用的 PNPM）：

pnpm tauri add updater

NPM 执行这个：

npm run tauri add updater

接着在 /src-tauri/tauri.conf.json 文件中添加以下配置：

{

  "bundle": {

    "createUpdaterArtifacts": true

  },

  "plugins": {

    "updater": {

      "pubkey": "你的公钥",

      "endpoints": ["https://releases.myapp.com/latest.json"]

    }

  }

}

其中：

• createUpdaterArtifacts 为是否创建更新包，设置为 true 即可。根据官网介绍，未来发布的 V3 版本将无需设置。


• pubkey 是公钥，用于和私钥匹配（私钥在开发环境配置，并在打包时自动携带）。但此时我们还没有，所以需要生成一下，执行以下命令生成密钥对：
  
  

  PNPM 执行这个：

  
  

  pnpm tauri signer generate -w ~/.tauri/myapp.key
  
  

  
  

  NPM 执行这个：

  
  

  npm run tauri signer generate -- -w ~/.tauri/myapp.key
  
  

  
  

  执行时会要求输入一个密码用来保护密钥，也可以直接按回车跳过，建议还是输入一个：

  
  

  

  
  

  输入（或跳过）之后，将会继续生成，生成之后进入刚才我们指定的目录 ~/.tauri：

  
  

  

  
  

  打开公钥 myapp.key.pub 然后将上面的 pubkey 替换掉。

  
  

  私钥的话，打开 myapp.key 然后执行以下方法设置到环境变量：

  
  

  macOS 和 Linux 执行这个（笔者是 macOS）：

  
  

  export TAURI_SIGNING_PRIVATE_KEY="你的私钥"
  
  export TAURI_SIGNING_PRIVATE_KEY_PASSWORD="你刚才输入的密码，没有就不用设置。"
  
  

  
  

  Windows 使用 Powershell 执行这个:

  
  

  $env:TAURI_SIGNING_PRIVATE_KEY="你的私钥"
  
  $env:TAURI_SIGNING_PRIVATE_KEY_PASSWORD="你刚才输入的密码，没有就不用设置。"
  
  

  
  


• endpoints 用于 Tauri 检查更新，是一个数组，所以可以设置多个，将会依次尝试可用的 URL，URL 指向放置在服务器的用于存储版本信息的 JSON 文件（也可以使用 API 的形式，这里不介绍了），格式如下：
  
  

  {
  
    "version": "1.0.1",
  
    "notes": "更新说明",
  
    "pub_date": "2025-05-21T03:29:28.626Z",
  
    "platforms": {
  
      "darwin-aarch64": {
  
        "signature": "dW50cnVzdGVkIGNvbW1lbnQ6IHNpZ25hdHVyZSBmcm9tIHRhdXJpIHNlY3JldCBrZXkKUlVTU0xJb2k1U3J6ZVFoUWo3R2lMTm5EdzhoNUZTKzdsY0g1NktOOTFNL2RMM0JVVVl4b0k3bFB0MkhyL3pKOHRYZ0x0RVdUYzdyWVJvNDBtRDM0OGtZa2d0RWl0VTBqSndrPQp0cnVzdGVkIGNvbW1lbnQ6IHRpbWVzdGFtcDoxNzQ3Nzk1MTY5CWZpbGU6bXktdGF1cmktYXBwLmFwcC50YXIuZ3oKS1N0UDl5MHRteUd0RHJ6anlSMXBSWmNJUlNKb1pYTDFvK2EvUjArTlBpbXVGN3pnQlA0THhhVUd4S3JrZy9lNHBNbWVSU2VoaCswN25xNEFPcmtUQnc9PQo=",
  
        "url": "macOS 包下载地址"
  
      }
  
    }
  
  }
  
  

  
  

  将此 JSON 文件放置在服务器，然后将上面的 endpoints 数组里的地址替换为这个 JSON 的真实地址。

  
  

  其中：

  
  
  
  
  • version 是版本号，升级时需要大于当前用户使用的版本。
  
  
  • notes 是更新说明，可以向用户说明本次更新的内容。
  
  
  • pub_date 是更新日期，非必填。
  
  
  • platform 是更新的平台，这里我以 macOS 为例，Windows 同理。
  
  
  • signature 是每次打包后的签名，所以每次都不一样，macOS 默认在 /src-tauri/target/release/bundle/macos/my-tauri-app.app.tar.gz.sig 这个位置，将这个文件打开，复制里面的内容替换即可。
  
  
  
  

第二步

配置好以后，就可以在应用内调用 check 方法进行更新了，比如在用户每次应用启动后。以下是从检查更新到更新完成的全流程的必要代码：

import { check } from '@tauri-apps/plugin-updater'

import { relaunch } from '@tauri-apps/plugin-process'



const fetchVersion = async () => {

  const update = await check()



  if (update) {

    console.log(`found update ${update.version} from ${update.date} with notes ${update.body}`)

    let downloaded = 0

    let contentLength = 0

    // 也可以分开调用 update.download() 和 update.install()

    await update.downloadAndInstall(event => {

      switch (event.event) {

        case 'Started':

          contentLength = event.data.contentLength

          console.log(`started downloading ${event.data.contentLength} bytes`)

          break

        case 'Progress':

          downloaded += event.data.chunkLength

          console.log(`downloaded ${downloaded} from ${contentLength}`)

          break

        case 'Finished':

          console.log('download finished')

          break

      }

    })



    console.log('update installed')

    // 此处 relaunch 前最好询问用户

    await relaunch()

  }

}

代码已经很简洁了，相信大家能看懂，但还是简单说一下：

首先调用 check 方法。检查之后，check 方法会返回一个 update 对象，如果检查到有更新，该对象会包含上面的版本更新信息，也包含一个 downloadAndInstall 方法。

执行 downloadAndInstall 方法，该方法执行完之后就代表安装成功了，会在下次启动时更新为新版本。当然也可以立即生效，只需要调用 relaunch 方法重启应用即可，但重启前最好提醒用户。

源码（经测试已经成功实现自动更新）已经上传到 Github：github.com/reallimengz…

背景

最近公司对代码质量抓得很严, 出台了一系列组合拳:

今天先说说，在本地使用git提交代码时进行代码质量检查如何实现。现在进入主题

Step1 配置ESLint校验规则

在这一步，踩了一个大坑。现在安装ESLint, 安装的都是ESLint v9.x版本，ESLint v9+的配置文件与之前不太一样了。不管是问大模型，还是上网搜，搜出来的ESLint安装配置方式90%以上都是ESLint V8及以下版本的配置方法。按照那种方式配，会吃很多瘪。

能看懂的，简单一点的报错比如说：

• .eslintignore文件不再被支持，应该在 eslint.config.js 或 eslint.config.ts 配置文件中，使用 ignores 属性来指定哪些文件或目录需要被忽略。
  (node:13688) ESLintIgnoreWarning: The ".eslintignore" file is no longer supported. Switch to using the "ignores" property in "eslint.config.js": https://eslint.org/docs/latest/use/configure/migration-guide#ignoring-files (Use node --trace-warnings ... to show where the warning was created) Oops! Something went wrong! :( ESLint: 9.25.1)，


• 改成ignores又报错， 对象字面量只能指定已知属性，并且“ignores”不在类型“ESLintConfig”中，被大模型忽悠了一回。在 ESLint 9.x 中，应该使用 ignorePatterns 来指定要忽略的文件或文件夹，而不是 ignores。


• jiti包版本不匹配, 需要升级
  Oops! Something went wrong! :( ESLint: 9.25.1 Error: You are using an outdated version of the 'jiti' library. Please update to the latest version of 'jiti' to ensure compatibility and access to the latest features.


• 未安装eslint-define-config模块
  Oops! Something went wrong! :( ESLint: 9.25.1 Error: Cannot find module 'eslint-define-config'

不太容易看懂的报错比如说 ESLint 没有找到适用于文件 src/main.ts 的配置规则。0:0 warning File ignored because no matching configuration was supplied ， 按照大模型的提示，逐一检查了ESLint 配置文件的路径是否正确，确保 root: true 配置生效; TypeScript 和 Vue 插件及解析器配置是否正确; ignorePatterns 是否误忽略了 src 文件夹; 检查 tsconfig.json 中的 include 配置; 手动检查文件是否被 ESLint 正确解析

pnpm eslint --config ./eslint.config.ts src/main.ts

忙活了一圈，未能解决问题。大模型排查技术工具最新版本的故障问题能力偏弱。无奈只能在网上搜，一篇一篇的看与试错。最终验证通过是方案是采用@eslint/config生成eslint v9版本的配置文件。

pnpm create @eslint/config

做7个选择（每个选项的含义一眼就能看懂）之后，就能妥妥地生成eslint配置文件。

Step2 配置Husky

这一步比较简单，虽然Husky最新版本的配置方法与先前的版本不一样了。但新版本的配置比老版本的要简单一些。

✅ 1. 安装Husky v9+版本

pnpm add -D husky

✅ 2. Husky v9+版本初始化

npx husky init

这会自动：

• 创建 .husky/ 目录


• 在.husky/下添加 pre-commit hook 示例


• 在package.json中添加 "prepare": "husky install" 脚本

这一步有个小坑，就是如果npx husky init第一次因为某种原因运行失败,第二次再运行，不会生成.husky目录。解决方法也很简单粗暴，卸载husky重新安装。

✅ 3. 在package.json配置检查指令

{

  "scripts": {

    "lint": "run-s lint:*",

    "lint:eslint": "eslint src/**/*.{ts,tsx,vue}  --debug --cache",

    "lint:prettier": "prettier --check ./",

    "lint:style": "stylelint \"src/**/*.{vue,css,less}\" --fix",

  },

}

✅ 4. 修改 .husky/pre-commit hook

# 检查指令

pnpm lint

Step3 配置ESLint增量检测

为什么要配置增量检测呢，原因有两点：

那么如何做增量检查呢？最质朴的思路就是利用git能监测暂存区代码变更的能力，然后利用ESlint对变更的文件执行代码质量检查。这里有两处要注意一下，一是检查暂存区变更的文件，要过滤掉删除的文件,只检查新增，修改，重命名,复制的文件。另外，当没有匹配类型的文件时，files=$(git diff --cached --name-only --diff-filter=AMRC | grep -E '\.(ts|tsx|vue)$')会抛出一个exit 1的异常，造成改了(ts|tsx|vue)之外的文件不能正常提交，所以要在后面加一个|| true进行兜底。

#!/bin/bash

# set -e

# set -x

trap 'echo "Error at line $LINENO"; exit 1' ERR



# 注意这里加了 || true

files=$(git diff --cached --name-only --diff-filter=AMRC | grep -E '\.(ts|tsx|vue)$' || true)



if [ -z "$files" ]; then

  echo "No changed ts/tsx/vue files to check."

  exit 0

fi



echo "Running ESLint on the following files:"

echo "$files"



# 用 xargs -r 只有在有输入时才执行

echo "$files" | xargs -r npx eslint



echo "All files passed ESLint."

exit 0

Step4 测试效果

修改 src 下的某个 main.ts 文件，故意触发代码质量问题，然后提交。

• 情形1 通过命令行提交，eslint校验未通过，阻断提交，且是增量校验。

git add . && git commit -m "测试"

• 情形2 通过UI界面提交，成功阻断提交
  

至此大功告成，结果令人满意，如果你的项目也需要实现这样的功能的话，拿走不谢。

后记

业务背景是这样的：gitlab上有个填写公司的仓库，有个提交代码的仓库，现在要将提交代码的仓库的代码变更记录，添加到填写工时的议题评论列表中，只要按照 feat: 跨项目提交测试 #194(#194是填写工时的议题id)这样的格式填写提交语，就能实现在评论列表添加代码变更链接的效果。

在.husky目录下添加prepare-commit-msg文件，内容如下：

#!/bin/sh

. "$(dirname "$0")/_/husky.sh"



# 仅当手动写 commit message 时执行

if [ "$2" = "merge" ] || [ "$2" = "squash" ]; then

  exit 0

fi



file="$1"

msg=$(cat "$file")



# 查找是否包含 #数字 格式的 Issue 编号

issue_number=$(echo "$msg" | grep -Eo '#[0-9]+' | head -n1 | sed 's/#//')



if [ -n "$issue_number" ]; then

  # 自定义项目路径

  project_path="research-and-development/algorithm/项目名"



  # 如果已经包含路径，则不重复添加

  echo "$msg" | grep -q "$project_path" && exit 0



  echo "" >>"$file"

  echo "Related to $project_path#$issue_number" >>"$file"

fi

需要注意的是，你使用的gitlab版本必须大于v15,才支持跨项目议题关联功能

最近，和往常一样在刷 GitHub Trending 热榜时，突然看到又一个开源项目冲上了 Trending 榜单。

一天之内就狂揽数千 star，仅仅用两三天时间，star 数就迅速破万，增长曲线都快干垂直了！

出于好奇，点进去看了看。

好家伙，这居然还是小米开源的项目，相信不少小伙伴也刷到了。

这个项目名为：ha_xiaomi_home。

全称：Xiaomi Home Integration for Home Assistant。

原来这就是小米开源的 Home Assistant 米家集成，一个由小米官方提供支持的 Home Assistant 集成组件，它可以让用户在 Home Assistant 平台中使用和管理小米 IoT 智能设备。

Home Assistant 大家知道，这是一款开源的家庭自动化智能家居平台，以其开放性和兼容性著称，其允许用户将家中的智能设备集成到一个统一的系统中进行管理和控制，同时支持多种协议和平台。

通过 Home Assistant，用户可以轻松地实现智能家居的自动化控制，如智能灯光、智能安防、智能温控等，所以是不少智能家居爱好者的选择。

另外通过安装集成（Integration），用户可以在 Home Assistant 上实现家居设备的自动化场景创建，并且还提供了丰富的自定义功能，所以一直比较受 DIY 爱好者们的喜爱。

大家知道，小米在智能家居领域的战略布局一直还挺大的，IoT 平台的连接设备更是数以亿记，大到各种家电、电器，小到各种摄像头、灯光、开关、传感器，产品面铺得非常广。

那这次小米开源的这个所谓的米家集成组件，讲白了就是给 Home Assistant 提供官方角度的支持。

而这对于很多喜欢折腾智能家居或者 IoT 物联网设备的小伙伴来说，无疑也算是一个不错的消息。

ha_xiaomi_home 的安装方法有好几种，包括直接 clone 安装，借助 HACS 安装，或者通过 Samba 或 FTPS 来手动安装等。

但是官方是推荐直接使用 git clone 命令来下载并安装。

cd config

git clone https://github.com/XiaoMi/ha_xiaomi_home.git

cd ha_xiaomi_home

./install.sh /config

原因是，这样一来当用户想要更新至特定版本时，只需要切换相应 Tag 即可，这样会比较方便。

比如，想要更新米家集成版本至 v1.0.0，只需要如下操作即可。

cd config/ha_xiaomi_home

git checkout v1.0.0

./install.sh /config

安装完成之后就可以去 Home Assistant 的设置里面去添加集成了，然后使用小米账号登录即可。