Spring 状态机与事件机制插件开发示例

我将为您演示一个完整的 Spring 状态机实现，包含状态机配置、事件机制和可扩展的插件体系。以下是一个订单处理系统的示例：

1. 添加依赖（pom.xml）

<dependencies>

    <!-- Spring State Machine -->

    <dependency>

        <groupId>org.springframework.statemachine</groupId>

        <artifactId>spring-statemachine-starter</artifactId>

        <version>4.2.0</version>

    </dependency>

    

    <!-- Spring Event 相关 -->

    <dependency>

        <groupId>org.springframework</groupId>

        <artifactId>spring-context-support</artifactId>

        <version>6.0.9</version>

    </dependency>

</dependencies>

2. 定义核心接口和类

2.1 状态和事件枚举

// 状态枚举

public enum OrderState {

    NEW, 

    PAYMENT_PENDING, 

    PAID, 

    SHIPPED, 

    DELIVERED, 

    CANCELLED

}



// 事件枚举

public enum OrderEvent {

    CREATE_ORDER, 

    INITIATE_PAYMENT, 

    PAYMENT_COMPLETED, 

    SHIP_ORDER, 

    DELIVERY_CONFIRMED, 

    CANCEL_ORDER

}

2.2 插件接口定义

// 状态变更监听器接口

public interface StateChangeListener {

    void onStateChange(OrderState from, OrderState to, String orderId);

}



// 订单操作插件接口

public interface OrderOperationPlugin {

    void execute(String orderId, OrderState currentState);

}



// 插件管理器接口

public interface PluginManager {

    void registerStateChangeListener(StateChangeListener listener);

    void notifyStateChange(OrderState from, OrderState to, String orderId);

    void executePlugins(String orderId, OrderState currentState);

}

3. 实现状态机配置

@Configuration

@EnableStateMachine

public class OrderStateMachineConfig extends EnumStateMachineConfigurerAdapter<OrderState, OrderEvent> {



    @Autowired

    private List<OrderOperationPlugin> plugins;



    @Override

    public void configure(StateMachineStateConfigurer<OrderState, OrderEvent> states) throws Exception {

        states

            .withStates()

            .initial(OrderState.NEW)

            .state(OrderState.PAYMENT_PENDING)

            .junction(OrderState.PAID)

            .end(OrderState.DELIVERED)

            .end(OrderState.CANCELLED)

            .fork(OrderState.SHIPPED);

    }



    @Override

    public void configure(StateMachineTransitionConfigurer<OrderState, OrderEvent> transitions) throws Exception {

        transitions

            .withExternal()

                .source(OrderState.NEW).target(OrderState.PAYMENT_PENDING)

                .event(OrderEvent.CREATE_ORDER)

                

            .and().withExternal()

                .source(OrderState.PAYMENT_PENDING).target(OrderState.PAID)

                .event(OrderEvent.INITIATE_PAYMENT)

                

            .and().withExternal()

                .source(OrderState.PAID).target(OrderState.SHIPPED)

                .event(OrderEvent.SHIP_ORDER)

                

            .and().withExternal()

                .source(OrderState.SHIPPED).target(OrderState.DELIVERED)

                .event(OrderEvent.DELIVERY_CONFIRMED)

                

            .and().withExternal()

                .source(OrderState.NEW).target(OrderState.CANCELLED)

                .event(OrderEvent.CANCEL_ORDER)

                

            .and().withExternal()

                .source(OrderState.PAYMENT_PENDING).target(OrderState.CANCELLED)

                .event(OrderEvent.CANCEL_ORDER);

    }

    

    @Bean

    public PluginManager pluginManager() {

        return new DefaultPluginManager(plugins);

    }

}

4. 插件实现

4.1 默认插件管理器

@Component

public class DefaultPluginManager implements PluginManager {

    private final List<StateChangeListener> stateChangeListeners = new ArrayList<>();

    private final List<OrderOperationPlugin> operationPlugins;



    public DefaultPluginManager(List<OrderOperationPlugin> plugins) {

        this.operationPlugins = plugins;

    }



    @Override

    public void registerStateChangeListener(StateChangeListener listener) {

        stateChangeListeners.add(listener);

    }



    @Override

    public void notifyStateChange(OrderState from, OrderState to, String orderId) {

        stateChangeListeners.forEach(listener -> listener.onStateChange(from, to, orderId));

    }



    @Override

    public void executePlugins(String orderId, OrderState currentState) {

        operationPlugins.forEach(plugin -> plugin.execute(orderId, currentState));

    }

}

4.2 示例插件实现

// 日志记录插件

@Component

public class LoggingPlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        System.out.println("订单 " + orderId + " 当前状态: " + currentState + " - 正在记录日志");

    }

}



// 邮件通知插件

@Component

public class EmailNotificationPlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        System.out.println("订单 " + orderId + " 当前状态: " + currentState + " - 发送邮件通知");

    }

}



// 库存管理插件

@Component

public class InventoryUpdatePlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        if (currentState == OrderState.PAID) {

            System.out.println("订单 " + orderId + " 已支付，正在更新库存");

        }

    }

}

5. 状态监听器实现

@Component

public class AuditStateChangeListener implements StateChangeListener {

    @Override

    public void onStateChange(OrderState from, OrderState to, String orderId) {

        System.out.println("订单状态变更: " + orderId + " 从 " + from + " 到 " + to + " - 审计记录已创建");

    }

}

6. 服务层实现

@Service

public class OrderService {



    @Autowired

    private StateMachine<OrderState, OrderEvent> stateMachine;



    @Autowired

    private PluginManager pluginManager;



    public OrderService() {

        // 注册监听器

        pluginManager.registerStateChangeListener(new AuditStateChangeListener());

    }



    public void handleOrderEvent(String orderId, OrderEvent event) {

        try {

            stateMachine.start();

            OrderState currentState = stateMachine.getState().getId();

            

            // 发送事件

            stateMachine.sendEvent(event);

            

            OrderState newState = stateMachine.getState().getId();

            

            // 触发状态变更监听器

            if (currentState != newState) {

                pluginManager.notifyStateChange(currentState, newState, orderId);

            }

            

            // 执行操作插件

            pluginManager.executePlugins(orderId, newState);

            

        } catch (Exception e) {

            System.err.println("处理订单事件失败: " + e.getMessage());

        } finally {

            stateMachine.stop();

        }

    }

}

7. 控制器示例

@RestController

@RequestMapping("/orders")

public class OrderController {



    @Autowired

    private OrderService orderService;



    @PostMapping("/{orderId}/events")

    public ResponseEntity<String> sendEvent(@PathVariable String orderId, @RequestParam String event) {

        try {

            OrderEvent orderEvent = OrderEvent.valueOf(event.toUpperCase());

            orderService.handleOrderEvent(orderId, orderEvent);

            return ResponseEntity.ok("事件已处理: " + event);

        } catch (IllegalArgumentException e) {

            return ResponseEntity.badRequest().body("无效的事件类型: " + event);

        }

    }

    

    @GetMapping("/{orderId}/status")

    public ResponseEntity<String> checkStatus(@PathVariable String orderId) {

        // 这里应该从存储中获取当前状态，为简化示例返回固定值

        return ResponseEntity.ok("订单 " + orderId + " 当前状态: 示例状态");

    }

}

8. 可扩展性说明

如何添加新插件：

@Component

public class NewFeaturePlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        // 新功能逻辑

    }

}

如何添加新状态监听器：

@Component

public class NewStateChangeListener implements StateChangeListener {

    @Override

    public void onStateChange(OrderState from, OrderState to, String orderId) {

        // 新监听器逻辑

    }

}

使用示例：

# 创建订单

POST /orders/123/events?event=CREATE_ORDER



# 发起支付

POST /orders/123/events?event=INITIATE_PAYMENT



# 发货

POST /orders/123/events?event=SHIP_ORDER



# 确认送达

POST /orders/123/events?event=DELIVERY_CONFIRMED



# 取消订单

POST /orders/123/events?event=CANCEL_ORDER

这个实现具有以下特点：

您可以根据具体业务需求扩展更多状态、事件和插件功能。

前言

在只有使用docker安装的容器，没有使用docker-compose或者其他客户端工具，如果要增加或者修改容器端口，也是可以增加或者修改容器端口映射=

容器端口映射

重新安装

这种方法简单粗暴，就是重新把docker容器移除，然后重新用

docker run -p 

重新做端口映射

修改配置文件

这里以rabbitmq为例子
1、 首先使用

  docker ps

查看容器id

2、 然后使用

docker inspace 容器id

查看容器配置文件放止于哪里

这里放置于/var/lib/docker/containers/29384a9aa22f4fb53eda66d672b039b997143dc7633694e3455fc12f7dbcac5d
然后使用Linux进入到该目录

3、先把docker容器停止了

 systemctl stop docker.socket

4、 修改hostconfig文件，找到里面的json数据中的PortBindings

这里将5672端口修改为5673

保存文件

5、 修改config.v2.json文件中的内容，找到里面中的ExposedPorts，把5673端口开放出来

保存文件

6、 启动docker服务

systemctl start docker.socket

这个时候就会发现5673端口映射了

总结

修改docker容器映射开放端口方法很多，现在也有很多优秀的客户端可以进行配置

在当今快速发展的软件开发领域，灵活性和动态性是开发者不可或缺的能力。.NET 提供的反射机制和代码生成技术，为开发者提供了强大的工具，能够在运行时动态地探索和操作代码。这些技术不仅能够提升开发效率，还能实现一些传统静态代码无法完成的功能。本文将深入探讨 .NET 反射机制的核心功能、高级技巧以及代码生成的实际应用，帮助你在开发中更好地利用这些强大的工具。

.NET 反射：运行时的魔法

反射是 .NET 中一个极其强大的特性，它允许开发者在运行时动态地检查和操作类型信息。通过反射，你可以获取类型信息、动态创建对象、调用方法，甚至访问私有成员。这种能力在许多场景中都非常有用，比如实现插件系统、动态调用方法、序列化和反序列化等。

反射基础

反射的核心是 System.Type 类，它代表了一个类型的元数据。通过 Type 类，你可以获取类的名称、基类、实现的接口、方法、属性等信息。System.Reflection 命名空间提供了多个关键类，如 Assembly、MethodInfo、PropertyInfo 和 FieldInfo，帮助你更深入地探索类型信息。

获取 Type 对象有三种常见方式：

反射的常见操作

反射可以完成许多强大的操作，以下是一些常见的用法：

获取类型信息

通过 Type 对象，你可以获取类的各种信息，例如类名、基类、是否泛型等。

Type type = typeof(List<int>);

Console.WriteLine($"类名: {type.Name}"); // 输出：List`1

Console.WriteLine($"基类: {type.BaseType?.Name}"); // 输出：Object

Console.WriteLine($"是否泛型: {type.IsGenericType}"); // 输出：True

动态调用方法

假设你有一个类 Calculator，你可以通过反射动态调用它的方法。

public class Calculator

{

    public int Add(int a, int b) => a + b;

}



Calculator calc = new Calculator();

Type type = calc.GetType();

MethodInfo? method = type.GetMethod("Add");

if (method != null) {

    int result = (int)method.Invoke(calc, new object[] { 5, 3 })!;

    Console.WriteLine(result); // 输出：8

}

访问私有成员

反射可以绕过访问修饰符的限制，访问私有字段或方法。

public class SecretHolder

{

    private string _secret = "Hidden Data";

}



var holder = new SecretHolder();

Type type = holder.GetType();

FieldInfo? field = type.GetField("_secret", BindingFlags.NonPublic | BindingFlags.Instance);

if (field != null) {

    string secret = (string)field.GetValue(holder)!;

    Console.WriteLine(secret); // 输出：Hidden Data

}

动态创建对象

通过 Activator.CreateInstance 方法，你可以动态实例化对象。

Type type = typeof(StringBuilder);

object? instance = Activator.CreateInstance(type);



StringBuilder sb = (StringBuilder)instance!;

sb.Append("Hello");

Console.WriteLine(sb.ToString()); // 输出：Hello

高级反射技巧

反射的高级用法可以让你在开发中更加灵活，以下是一些进阶技巧：

调用泛型方法

如果方法带有泛型参数，你需要先使用 MakeGenericMethod 指定类型。

public class GenericHelper

{

    public T Echo<T>(T value) => value;

}



var helper = new GenericHelper();

Type type = helper.GetType();

MethodInfo method = type.GetMethod("Echo")!;

MethodInfo genericMethod = method.MakeGenericMethod(typeof(string));



string result = (string)genericMethod.Invoke(helper, new object[] { "Hello" })!;

Console.WriteLine(result); // 输出：Hello

性能优化

反射调用比直接调用慢很多，因此在高性能场景下，可以缓存 MethodInfo 或使用 Delegate 来优化性能。

MethodInfo method = typeof(Calculator).GetMethod("Add")!;

var addDelegate = (Func<Calculator, int, int, int>)Delegate.CreateDelegate(

    typeof(Func<Calculator, int, int, int>),

    method

);



Calculator calc = new Calculator();

int result = addDelegate(calc, 5, 3);

Console.WriteLine($"result: {result}"); // 输出：8

动态加载插件

假设你有一个插件系统，所有插件都实现了 IPlugin 接口，你可以通过反射动态加载插件。

public interface IPlugin

{

    void Execute();

}



public class HelloPlugin : IPlugin

{

    public void Execute() => Console.WriteLine("Hello from Plugin!");

}



Assembly assembly = Assembly.LoadFrom("MyPlugins.dll");

var pluginTypes = assembly.GetTypes()

    .Where(t => typeof(IPlugin).IsAssignableFrom(t) && !t.IsAbstract);



foreach (Type type in pluginTypes)

{

    IPlugin plugin = (IPlugin)Activator.CreateInstance(type);

    plugin.Execute();

}

代码生成：运行时的创造力

在某些高级场景中，你可能需要在运行时生成新的类型或方法。.NET 提供的 System.Reflection.Emit 命名空间允许你在运行时构建程序集、模块、类型和方法。

使用 Reflection.Emit 生成动态类

以下是一个示例，展示如何使用 Reflection.Emit 生成一个动态类 Person，并为其添加一个 SayHello 方法。

using System;

using System.Reflection;

using System.Reflection.Emit;



public class DynamicTypeDemo

{

    public static void Main()

    {

        // 创建一个动态程序集

        AssemblyName assemblyName = new AssemblyName("DynamicAssembly");

        AssemblyBuilder assemblyBuilder =

            AssemblyBuilder.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);



        // 创建一个模块

        ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule("MainModule");



        // 定义一个类：public class Person

        TypeBuilder typeBuilder = moduleBuilder.DefineType(

            "Person",

            TypeAttributes.Public

        );



        // 定义一个方法：public void SayHello()

        MethodBuilder methodBuilder = typeBuilder.DefineMethod(

            "SayHello",

            MethodAttributes.Public,

            returnType: typeof(void),

            parameterTypes: Type.EmptyTypes

        );



        // 生成 IL 代码，等价于 Console.WriteLine("Hello from dynamic type!");

        ILGenerator il = methodBuilder.GetILGenerator();

        il.Emit(OpCodes.Ldstr, "Hello from dynamic type!");

        il.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine", new[] { typeof(string) })!);

        il.Emit(OpCodes.Ret);



        // 创建类型

        Type personType = typeBuilder.CreateType();



        // 实例化并调用方法

        object personInstance = Activator.CreateInstance(personType)!;

        personType.GetMethod("SayHello")!.Invoke(personInstance, null);

    }

}

运行上述代码后，你将看到输出：

Hello from dynamic type!

表达式树：更安全的代码生成

如果你希望在运行时生成代码行为，但又不想深入 IL 层，表达式树（System.Linq.Expressions）是一个更现代、更安全的替代方案。以下是一个示例，展示如何使用表达式树生成一个简单的 SayHello 方法。

using System;

using System.Linq.Expressions;



public class ExpressionTreeDemo

{

    public static void Main()

    {

        // 表达式：() => Console.WriteLine("Hello from expression tree!")

        var writeLineMethod = typeof(Console).GetMethod("WriteLine", new[] { typeof(string) });



        // 构建常量表达式 "Hello from expression tree!"

        var messageExpr = Expression.Constant("Hello from expression tree!");



        // 调用 Console.WriteLine(string) 的表达式

        var callExpr = Expression.Call(writeLineMethod!, messageExpr);



        // 构建 lambda 表达式：() => Console.WriteLine(...)

        var lambda = Expression.Lambda<Action>(callExpr);



        // 编译成委托并执行

        Action sayHello = lambda.Compile();

        sayHello();

    }

}

运行上述代码后，你将看到输出：

Hello from expression tree!

Source Generator：编译期代码生成

Source Generator 是 .NET 提供的一种编译期代码生成工具，可以在编译过程中注入额外的源代码。它不依赖反射，无运行时开销，适合构建高性能、可维护的自动化代码逻辑。

以下是一个简单的 Source Generator 示例，展示如何为类自动生成一个 SayHello 方法。

运行上述代码后，你将看到输出：

Hello from Source Generator!

总结

反射和代码生成是 .NET 中非常强大的特性，它们为开发者提供了运行时动态探索和操作代码的能力。反射机制允许你在运行时检查类型信息、动态创建对象、调用方法，甚至访问私有成员。代码生成技术则让你能够在运行时生成新的类型和方法，或者在编译期生成代码，从而提升开发效率和代码的灵活性。

在实际开发中，反射虽然功能强大，但需要注意性能开销。在需要高性能的场景下，可以考虑使用 Delegate 缓存、表达式树，或 .NET 6 的 Source Generators 来替代反射。通过合理使用这些技术，你可以在开发中更加灵活地应对各种复杂场景，提升代码的可维护性和性能。

希望这篇文章能帮助你更好地理解和应用 .NET 反射和代码生成技术，让你在开发中更加得心应手！

观察者模式的困境

在Java中实现观察者模式通常需要手动管理监听器注册、事件分发等逻辑，这会带来以下问题：

下面，我们用一个待办事项的例子说明这个问题。同时利用信号机制的方法改写传统方式，进行对比。

示例：待办事项应用

我们以经典的待办事项应用为例，需要监听以下事件：

• 当单个Todo项发生以下变化时：
  
  
  
  
  • 标题变更
  
  
  • 完成状态切换
  
  
  
  


• 当TodoList发生以下变化时：
  
  
  
  
  • 新增条目
  
  
  • 删除条目
  
  
  
  

传统实现方案

​​1. 基础监听器模式​​

// 监听器接口

public interface Listener {

    void onTitleChanged(Todo todo);

    void onCompletionChanged(Todo todo);

    void onItemAdded(Todo entity, Collection<Todo> todos);

    void onItemRemoved(Todo entity, Collection<Todo> todos);

}



// 具体实现

public class ConsoleListener implements Listener {

    @Override

    public void onTitleChanged(Todo todo) {

        System.out.printf("任务标题变更为: %s%n", todo.getTitle());

    }

    // 其他事件处理...

}



// 被观察对象（侵入式改造）

public class TodosList {

    private final List<Listener> listeners = new ArrayList<>();

    

    public void addListener(Listener listener) {

        listeners.add(listener);

    }

    

    public void removeListener(Listener listener) {

        listeners.remove(listener);

    }

    

    public Todo add(String title) {

        Todo todo = new Todo(UUID.randomUUID(), title, false);

        listeners.forEach(l -> l.onItemAdded(todo, todos));

        return todo;

    }

    // 其他操作方法...

}

​​2. Java 内置的 Observable（已弃用）​​

// 被观察的Todo类

@Getter @AllArgsConstructor

public class Todo extends Observable {

    private UUID id;

    @Setter private String title;

    @Setter private boolean completed;

    

    public void setTitle(String title) {

        this.title = title;

        setChanged();

        notifyObservers(this); // 通知所有观察者

    }

    // 其他setter同理...

}



// 观察者实现

public class BasicObserver implements Observer {

    @Override

    public void update(Observable o, Object arg) {

        if (o instanceof Todo todo) {

            System.out.println("[Observer] 收到Todo更新事件: " + todo);

        }

    }

}

信号机制（Signals）解决方案

​​核心思想​​：将属性变化抽象为可观察的信号（Signal），通过声明式编程实现事件监听

​​1. 信号基础用法​​

// 信号定义（使用第三方库com.akilisha.oss:signals）

public class Todo {

    private final Signal<String> title = Signals.signal("");

    private final Signal<Boolean> completed = Signals.signal(false);

    

    public void setTitle(String newTitle) {

        title.set(newTitle); // 自动触发订阅的副作用

    }

    

    public void observeTitleChanges(Consumer<String> effect) {

        Signals.observe(title, effect); // 注册副作用

    }

}

​​2. 待办事项列表实现​​

public class TodosList {

    private final SignalCollection<Todo> todos = Signals.signal(new ArrayList<>());

    

    public Todo add(String title) {

        Todo todo = Todo.from(title);

        todos.add(todo); // 自动触发集合变更事件

        

        // 声明式监听集合变化

        Signals.observe(todos, (event, entity) -> {

            switch (event) {

                case "add": 

                    System.out.printf("新增任务: %s%n", entity);

                    break;

                case "remove":

                    System.out.printf("删除任务: %s%n", entity);

                    break;

            }

        });

        

        return todo;

    }

}

​​3. 效果注册与取消​​

public class Main {

    public static void main(String[] args) {

        TodosList list = new TodosList();

        

        // 注册副作用（自动绑定到Todo属性）

        list.add("学习Signals")

            .observeTitleChanges(title -> 

                System.out.printf("任务标题变更为: %s%n", title)

            );

            

        list.add("实践Signals")

            .observeCompletionChanges(completed -> 

                System.out.printf("任务完成状态: %s%n", completed)

            );

            

        // 触发事件

        list.todos.get(0).getTitle().set("深入学习Signals");

    }

}

技术对比

关键优势

使用建议

通过这种现代化的事件处理方式，可以显著提升代码的可维护性和可测试性，特别适合需要精细控制状态变化的复杂业务场景。

速通 GO 垃圾回收机制

前言

垃圾回收(Garbage Collection，简称 GC)是编程语言中自动管理内存的一种机制。Go 语言从诞生之初就带有垃圾回收机制，经过多次优化，现在已经相当成熟。本文将带您深入了解 Go 语言的垃圾回收机制。

下面先一起了解下涉及到的垃圾回收相关知识。

标记清除

标记清除(Mark-Sweep)是最基础的垃圾回收算法，分为两个阶段：

标记清除示例

考虑以下场景：

type Node struct {

    next *Node

    data int

}



func createLinkedList() *Node {

    root := &Node{data: 1}

    node2 := &Node{data: 2}

    node3 := &Node{data: 3}

    

    root.next = node2

    node2.next = node3

    

    return root

}



func main() {

    list := createLinkedList()

    // 此时内存中有三个对象，都是可达的

    

    list.next = nil

    // 此时node2和node3变成了不可达对象，将在下次GC时被回收

}

在这个例子中：

// 伪代码展示标记清除过程

func MarkSweep() {

    // 标记阶段

    for root := range roots {

        mark(root)

    }

    

    // 清除阶段

    for object := range heap {

        if !marked(object) {

            free(object)

        }

    }

}

标记清除算法的优点是实现简单，但存在以下问题：

• 需要 STW(Stop The World)，即在垃圾回收时需要暂停程序运行


• 会产生内存碎片，因为清除后最终剩下的活跃对象在堆中的分布是零散不连续的


• 标记和清除的效率都不高

内存碎片示意图

%%{init: {"flowchart": {"htmlLabels": false}} }%%

flowchart LR

    subgraph Before["GC前的堆内存"]

        direction LR

        A1["已分配"] --- B1["已分配"] --- C1["空闲"] --- D1["已分配"] --- E1["已分配"]

    end

    

    Before ~~~ After

    

    subgraph After["GC后的堆内存"]

        direction LR

        A2["已分配"] --- B2["空闲"] --- C2["空闲"] --- D2["已分配"] --- E2["空闲"]

    end



    classDef default fill:#fff,stroke:#333,stroke-width:2px;

    classDef allocated fill:#a8d08d,stroke:#333,stroke-width:2px;

    classDef free fill:#f4b183,stroke:#333,stroke-width:2px;

    

    class A1,B1,D1,E1 allocated;

    class C1 free;

    class A2,D2 allocated;

    class B2,C2,E2 free;

如图所示，GC后的内存空间虽然有足够的总空间，但是由于碎片化，可能无法分配较大的连续内存块。

三色标记

为了优化标记清除算法，Go 语言采用了三色标记算法。主要的目的是为了缩短 STW 的时间，提高程序在垃圾回收过程中响应速度。

三色标记将对象分为三种颜色：

• 白色：未被标记的对象


• 灰色：已被标记但其引用对象未被标记的对象


• 黑色：已被标记且其引用对象都已被标记的对象

三色标记过程图解

graph TD

    subgraph "最终状态"

    A4[Root] --> B4[Object 1]

    B4 --> C4[Object 2]

    B4 --> D4[Object 3]

    D4 --> E4[Object 4]

    

    style A4 fill:#000000

    style B4 fill:#000000

    style C4 fill:#000000

    style D4 fill:#000000

    style E4 fill:#000000

    end

    

    subgraph "处理灰色对象"

    A3[Root] --> B3[Object 1]

    B3 --> C3[Object 2]

    B3 --> D3[Object 3]

    D3 --> E3[Object 4]

    

    style A3 fill:#000000

    style B3 fill:#808080

    style C3 fill:#FFFFFF

    style D3 fill:#FFFFFF

    style E3 fill:#FFFFFF

    end

    

    subgraph "标记根对象为灰色"

    A2[Root] --> B2[Object 1]

    B2 --> C2[Object 2]

    B2 --> D2[Object 3]

    D2 --> E2[Object 4]

    

    style A2 fill:#808080

    style B2 fill:#FFFFFF

    style C2 fill:#FFFFFF

    style D2 fill:#FFFFFF

    style E2 fill:#FFFFFF

    end

    

    subgraph "初始状态"

    A1[Root] --> B1[Object 1]

    B1 --> C1[Object 2]

    B1 --> D1[Object 3]

    D1 --> E1[Object 4]

    

    style A1 fill:#D3D3D3

    style B1 fill:#FFFFFF

    style C1 fill:#FFFFFF

    style D1 fill:#FFFFFF

    style E1 fill:#FFFFFF

    end

在垃圾回收器开始工作时，所有对象都为白色，垃圾回收器会先把所有根对象标记为灰色，然后后续只会从灰色对象集合中取出对象进行处理，把取出的对象标为黑色，并且把该对象引用的对象标灰加入到灰色对象集合中，直到灰色对象集合为空，则表示标记阶段结束了。

三色标记实际示例

type Person struct {

    Name string

    Friends []*Person

}



func main() {

    alice := &Person{Name: "Alice"}

    bob := &Person{Name: "Bob"}

    charlie := &Person{Name: "Charlie"}

    

    // Alice和Bob是朋友

    alice.Friends = []*Person{bob}

    bob.Friends = []*Person{alice, charlie}

    

    // charlie没有朋友引用（假设bob的引用被删除）

    bob.Friends = []*Person{alice}

    // 此时charlie将在下次GC时被回收

}

详细标志过程如下：

// 三色标记伪代码

func TriColorMark() {

    // 初始化，所有对象设为白色

    for obj := range heap {

        setWhite(obj)

    }

    

    // 根对象入灰色队列

    for root := range roots {

        setGrey(root)

        greyQueue.Push(root)

    }

    

    // 处理灰色队列

    for !greyQueue.Empty() {

        grey := greyQueue.Pop()

        scan(grey)

        setBlack(grey)

    }

    

    // 清除白色对象

    sweep()

}

需要注意的是，三色标记清除算法本身是不支持和用户程序并行执行的，因为在标记过程中，用户程序可能会进行修改对象指针指向等操作，导致最终出现误清除掉活跃对象等情况，这对于内存管理而言，是十分严重的错误了。

并发标记的问题示例

func main() {

    var root *Node

    var finalizer *Node

    

    // GC开始，root被标记为灰色

    root = &Node{data: 1}

    

    // 用户程序并发修改引用关系

    finalizer = root

    root = nil

    

    // 如果这时GC继续运行，finalizer指向的对象会被错误回收

    // 因为从root开始已经无法到达该对象

}

所以为了解决这个问题，在一些编程语言中，常见的做法是，三色标记分为 3 个阶段：

通过这样的设计，至少可以使得标记耗时较长的阶段可以和用户程序并行执行，大幅度缩短了 STW 的时间，但是由于最后一阶段需要重复扫描对象，所以 STW 的时间还是不够理想，因此引入了内存屏障等技术继续优化。

内存屏障技术

三色标记算法在并发环境下会出现对象丢失的问题，为了解决这个问题，Go 引入了内存屏障技术。

内存屏障技术是一种屏障指令，确保屏障指令前后的操作不会被越过屏障重排。

内存屏障工作原理图解

graph TD

    subgraph "插入写屏障"

    A1[黑色对象] -->|新增引用| B1[白色对象]

    B1 -->|标记为灰色| C1[灰色对象]

    end

    

    subgraph "删除写屏障"

    A2[黑色对象] -->|删除引用| B2[白色对象]

    B2 -->|标记为灰色| C2[灰色对象]

    end

垃圾回收中的屏障更像是一个钩子函数，在执行指定操作前通过该钩子执行一些前置的操作。

对于三色标记算法，如果要实现在并发情况下的正确标记，则至少要满足以下两种三色不变性中的其中一种：

• 强三色不变性： 黑色对象不指向白色对象，只会指向灰色或黑色对象


• 弱三色不变性：黑色对象可以指向白色对象，但是该白色对象必须被灰色对象保护着（被其他的灰色对象直接或间接引用）

插入写屏障

插入写屏障的核心思想是：在对象新增引用关系时，将被引用对象标记为灰色。

// 插入写屏障示例

type Object struct {

    refs []*Object

}



func (obj *Object) AddReference(ref *Object) {

    // 写屏障：在添加引用前将新对象标记为灰色

    shade(ref)

    obj.refs = append(obj.refs, ref)

}



// 插入写屏障伪代码

func writePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {

    shade(ptr) // 将新引用的对象标记为灰色

    *slot = ptr

}

插入写屏障是一种相对保守的策略，相当于有可能存活的对象都会被标灰，满足了强三色不变行，缺点是会产生浮动垃圾（没有被引用但却没被回收的对象），要到下一轮垃圾回收时才会被回收。

浮动垃圾示例

func main() {

    obj1 := &Object{}

    obj2 := &Object{}

    

    // obj1引用obj2

    obj1.AddReference(obj2)  // obj2被标记为灰色

    

    // 立即删除引用

    obj1.refs = nil

    

    // 此时obj2虽然已经不可达

    // 但因为已被标记为灰色，要等到下一轮GC才会被回收

}

栈上的对象在垃圾回收中也是根对象，但是如果栈上的对象也开启插入写屏障，那么对于写指针的操作会带来较大的性能开销，所以很多时候插入写屏障只针对堆对象启用，这样一来，要保证最终标记无误，在最终标记结束阶段就需要 STW 来重新扫描栈空间的对象进行查漏补缺。实际上这两种方式各有利弊。

删除写屏障

删除写屏障的核心思想是：在对象删除引用关系时，将被解引用的对象标记为灰色。
这种方法可以保证弱三色不变性，缺点是回收精度低，同样也会产生浮动垃圾。

// 删除写屏障示例

func (obj *Object) RemoveReference(index int) {

    // 写屏障：在删除引用前将被删除的对象标记为灰色

    shade(obj.refs[index])

    obj.refs = append(obj.refs[:index], obj.refs[index+1:]...)

}



// 删除写屏障伪代码

func writePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {

    shade(*slot) // 将被删除引用的对象标记为灰色

    *slot = ptr

}

混合写屏障

Go 1.8 引入了混合写屏障，同时应用了插入写屏障和删除写屏障，结合了二者的优点：

// 混合写屏障示例

func (obj *Object) UpdateReference(index int, newRef *Object) {

    // 删除写屏障

    shade(obj.refs[index])

    // 更新引用

    obj.refs[index] = newRef

    // 插入写屏障

    shade(newRef)

}



// 混合写屏障伪代码

func writePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {

    shade(*slot)  // 删除写屏障

    *slot = ptr

    shade(ptr)    // 插入写屏障

}

GO 中垃圾回收机制

大致演进与版本改进

• ​​Go 1.3之前​​：传统标记-清除，全程STW（秒级停顿）。


• ​​Go 1.5​​：引入并发三色标记，STW降至毫秒级。


• ​​Go 1.8​​：混合写屏障优化，STW缩短至微秒级。


• ​​Go 1.12+​​：并行标记优化，提升吞吐量。

在 GO 1.7 之前，主要是使用了插入写屏障来保证强三色不变性，由于垃圾回收的根对象包括全局变量、寄存器、栈对象，如果要对所有的 Goroutine 都开启写屏障，那么对于写指针操作肯定会造成很大的性能损耗，所以 GO 并没有针对栈开启写屏障。而是选择了在标记完成时 STW、重新扫描栈对象（将所有栈对象标灰重新扫描），避免漏标错标的情况，但是这一过程是比较耗时的，要占用 10 ~ 100 ms 时间。

于是，GO 1.8 开始就使用了混合写屏障 + 栈黑化 的方案优化该问题，GC 开始时全部栈对象标记为黑色，以及标记过程中新建的栈、堆对象也标记为黑色，防止新建的对象都错误回收掉，通过这样的机制，栈空间的对象都会为黑色，所以最后也无需重新扫描栈对象，大幅度地缩短了 STW 的时间。当然，与此同时也会有产生浮动垃圾等方面的牺牲，没有完成的方法，只有根据实际需求的权衡取舍。

主要特点

垃圾回收触发条件

• 内存分配达到阈值


• 定期触发


• 手动触发(runtime.GC())

GC 过程

GC触发示例

func main() {

    // 1. 内存分配达到阈值触发

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

        _ = make([]byte, 1024) // 大量分配内存

    }

    

    // 2. 定期触发

    // Go运行时会自动触发GC

    

    // 3. 手动触发

    runtime.GC()

}

总结

Go 语言的垃圾回收机制经过多次优化，已经达到了很好的性能。它采用三色标记算法，配合混合写屏障技术，实现了高效的并发垃圾回收。虽然还有一些不足，如不支持分代回收，但对于大多数应用场景来说已经足够使用。

性能优化建议

要优化 Go 程序的 GC 性能，可以：

参考资料：

• Go GC: Prioritizing low latency and simplicity


• Getting to Go: The Journey of Go's Garbage Collector


• Go 语言垃圾收集器的实现原理 | Go 语言设计与实现

前言

“技术是人类对需求的回应。”

大家好，这里是知行小栈。

最近，一位运营的同学突然给我发来了一串加密的手机号，类似这样：

2f731fb2aea9fb5069adef6e4aa2624e

他让我帮忙解下密，想拿到具体的手机号。

我看了下，也不是啥大事儿。于是找到了对应的项目，直接调用里面的解密方法，将这些号码都打印了出来，给到了他。

本以为事情到此就结束了，结果他隔三岔五的让我去做这个操作（心里os）。判断了下情况，这种需求可能会不间断的发生。顿时，我的大脑就应激了，必须弄个一劳永逸的方案！

命令行

我最先想到的就是命令行。为啥呢？因为命令行有两个特点：

只要制作一个自定义的命令行工具，下次就可以通过这种方式减少繁琐的操作，增加摸鱼的时间。

原先项目中，已经有手机号加解密的功能。基于职业的基本素养（不重复造轮子），之前已有的功能我是不会重写的，而是想办法能直接通过命令行调用。类似：

java -jar xxx.jar

这个命令虽然看起来有点长，但可以通过为其起别名的方式，简化命名。实现 ll 等价于 ls -l 的效果。

Spring Shell

想要通过 shell 调用 Java 指定类中的指定方法，方式有许多。我思考了 $1\frac{1}{3}$ 秒，就决定采用 Spring Shell（因为它与我想要实现的场景匹配度高达 99.999%）。

首先，我仅需要在原先的项目中多引入一个依赖

<dependency>

  <groupId>org.springframework.shell</groupId>

  <artifactId>spring-shell-starter</artifactId>

  <version>2.1.15</version>

</dependency>

然后，实现一个自定义的命令组件

// @ShellComponent 类似 @Component 表明是 Spring 中的一个组件

@ShellComponent

public class Cipher {



    // @ShellMethod 定义了一个命令，key 属性是命令的名称，value 属性是命令的描述

    // @ShellOption 定义了命令中的参数

    @ShellMethod(key = "decrypt", value = "解密操作")

    public String decrypt(@ShellOption String cipherText, @ShellOption String key) {

        // 调用项目中已有的解密方法

        return AesUtil.decrypt(cipherText, key);

    }



    @ShellMethod(key = "encrypt", value = "加密操作")

    public String encrypt(@ShellOption String text, @ShellOption String key) {

        // 调用项目中已有的加密方法

        return AesUtil.encrypt(text, key);

    }

}

最后，重新将 Shell 组件所在的项目打个包，运行项目

执行命令，验证

到这里，还不行。因为我可不会每次都去执行 java -jar xxx.jar 这么长的命令来启动 Spring Shell。windows 终端我一直用的 Git-Bash，这种类 Unix 的终端都可以采用相同的方式为长命令设置一个别名。

于是，我在 .bash_profile 文件中，给这段长命令起了一个别名：

alias shell='java -jar encrypt.jar'

接下来，就可以通过简单的 shell 命令调用 Spring Shell 终端，执行之前定义好的命令了

知行有话

Spring Shell 简直就是开发者的利器。试想一下，我们把日常学习或工作中频繁的操作都弄成这样的终端命令，是不是会节约我们大量的时间？还有一个值得提的点就是它对 Java 开发者十分友好。只要你懂 Java，就可以轻松上手开发自定义的终端命令。

docker 项目的部署，具有一次构建，多地部署的通用性。所以，你可以在本地 docker 环境部署、nas环境部署、云服务器环境部署。

3.1 部署环境 - 脚本

通过以下脚本，安装mysql、redis等。

3.2 项目部署 - 脚本

镜像，liwenchao_test/riderwuyou-admin:1.0 如果使用阿里云Docker仓库，那么可以使用 image: crpi-ioutcr0ojmsa4ham.cn-beijing.personal.cr.aliyuncs.com/liwenchao_test/riderwuyou-admin:1.0-SNAPSHOT 或者用 docker tag crpi-ioutcr0ojmsa4ham.cn-beijing.personal.cr.aliyuncs.com/liwenchao_test/riderwuyou-admin:1.0-SNAPSHOT liwenchao_test/riderwuyou-admin:1.0 设定镜像名称。

4. 服务部署

4.1 上传脚本

4.2 执行脚本

• 执行脚本01；docker-compose -f docker-compose-environment-aliyun.yml up -d
• 执行脚本02；docker-compose -f docker-compose-app-v1.0.yml up -d
• 运行完成后，就可以运行测试了

本文首发于公众号：托尼学长，立个写 1024 篇原创技术面试文章的flag，欢迎过来视察监督~

最近有好几个同学跟我说，他在技术面试过程中被问到这个问题了，让我找时间系统地讲解一下。

其实从某种意义上来说，这并不是一个严谨的面试题，接下来 show me the SQL，我们一起来看一下。

如下图所示，一张有 3000多万行记录的 user 表，执行全表 count 操作需要 14.8 秒的时间。

接下来我们稍作调整再试一次，神奇的一幕出现了，执行全表 count 操作竟然连 1 毫秒的时间都用不上。

这是为什么呢？

其实原因很简单，第一次执行全表 count 操作的时候，我用的是 MySQL InnoDB 存储引擎，而第二次则是用的 MySQL MyISAM 存储引擎。

这两者的差别在于，前者在执行 count(*)  操作的时候，需要将表中每行数据读取出来进行累加计数，而后者已经将表的总行数存储下来了，只需要直接返回即可。

当然，InnoDB 存储引擎对 count(*)  操作也进行了一些优化，如果该表创建了二级索引，其会通过全索引扫描的方式来代替全表扫描进行累加计数，

毕竟，二级索引值只存储了索引列和主键列两个字段，遍历计数肯定比存储所有字段的数据表的 IO 次数少很多，也就意味着其执行效率更高。

而且，MySQL 的优化器会选择最小的那个二级索引的索引文件进行遍历计数。

所以，这个技术面试题严谨的问法应该是 —— MySQL InnoDB 存储引擎单表过亿数据，如何优化 count(*) 全表的操作？

下面我们就来列举几个常见的技术解决方案，如下图所示：

（1）Redis 累加计数

这是一种最主流且简单直接的实现方式。

由于我们基本上不会对数据表执行 delete 操作，所以当有新的数据被写入表的时候，通过 Redis 的 incr 或 incrby 命令进行累加计数，并在用户查询汇总数据的时候直接返回结果即可。

如下图所示：

该实现方式在查询性能和数据准确性上两者兼得，Redis 需要同时负责累加计数和返回查询结果操作，缺点在于会引入缓存和数据库间的数据一致性的问题。

（2）MySQL 累加计数表 + 事务

这种实现方式跟“Redis 累加计数”大同小异，唯一的区别就是将计数的存储介质从 Redis 换成了 MySQL。

如下图所示：

但这么一换，就可以将写入表操作和累加计数操作放在一个数据库事务中，也就解决了缓存和数据库间的数据一致性的问题。

该实现方式在查询性能和数据准确性上两者兼得，但不如“Redis 累加计数”方式的性能高，在高并发场景下数据库会成为性能瓶颈。

（3）MySQL 累加计数表 + 触发器

这种实现方式跟“MySQL 累加计数表 + 事务”的表结构是一样的，如下图所示：

****

唯一的区别就是增加一个触发器，不用在工程代码中通过事务进行实现了。

CREATE TRIGGER `user_count_trigger` AFTER INSERT ON `user` FOR EACH ROW BEGIN    UPDATE user_count SET count = count + 1 WHERE id = NEW.id;END

该实现方式在查询性能和数据准确性上两者兼得，与“MySQL 累加计数表 + 事务”方式相比，最大的好处就是不用污染工程代码了。

（4）MySQL 增加并行线程

在 MySQL 8.014 版本中，总算增加了并行查询的新特性，其通过参数 innodb_parallel_read_threads 进行设定，默认值为 4。

下面我们做个实验，将这个参数值调得大一些：

set local innodb_parallel_read_threads = 16;

然后，我们再来执行一次上文中那个 3000 多万行记录 user 表的全表 count 操作，结果如下所示：

参数调整后，执行全表 count 操作的时间由之前的 14.8 秒，降低至现在的 6.1 秒，是可以看到效果的。

接下来，我们继续将参数值调整得大一些，看看是否还有优化空间：

set local innodb_parallel_read_threads = 32;

然后，我们再来执行一次上文中那个 3000 多万行记录 user 表的全表 count 操作，结果如下所示：

参数调整后，执行全表 count 操作的时间竟然变长了，从原来的 6.1 秒变成了 6.8 秒，看样子优化空间已经达到上限了，再多增加执行线程数量只会适得其反。

该实现方式一样可以保证数据准确性，在查询性能上有所提升但相对有限，其最大优势是只需要调整一个数据库参数，在工程代码上不会有任何改动。

不过，如果数据库此时的负载和 IOPS 已经很高了，那开启并行线程或者将并行线程数量调大，会加速消耗数据库资源。

（5）MySQL 增加二级索引

还记得我们在上文中说的内容吗？

InnoDB 存储引擎对 count()  操作也进行了一些优化，如果该表创建了二级索引，其会通过全索引扫描的方式来代替全表扫描进行累加计数，*

毕竟，二级索引值只存储了索引列和主键列两个字段，遍历计数肯定比存储所有字段的数据表的IO次数少很多，也就意味着执行效率更高。

而且，MySQL 的优化器会选择最小的那个二级索引的索引文件进行遍历计数。

为了验证这个说法，我们给 user 表中最小的 sex 字段加一个二级索引，然后通过 EXPLAIN 命令看一下 SQL 语句的执行计划：

果然，这个 SQL 语句的执行计划会使用新建的 sex 索引，接下来我们执行一次看看时长：

果不其然，执行全表 count 操作走了 sex 二级索引后，SQL 执行时间由之前的 14.8 秒降低至现在的 10.6 秒，还是可以看到效果的。

btw：大家可能会觉得效果并不明显，这是因为我们用来测试的 user 表中算上主键 ID 只有七个字段，而且没有一个大字段。

反之，user 表中的字段数量越多，且包含的大字段越多，其优化效果就会越明显。

该实现方式一样可以保证数据准确性，在查询性能上有所提升但相对有限，其最大优势是只需要创建一个二级索引，在工程代码上不会有任何改动。

（6）SHOW TABLE STATUS

如下图所示，通过 SHOW TABLE STATUS 命令也可以查出来全表的行数：

我们常用于查看执行计划的 EXPLAIN 命令也能实现：

只不过，通过这两个命令得出来的表记录数是估算出来的，都不太准确。那到底有多不准确呢，我们来计算一下。

公式为：33554432 / 33216098 = 1.01

就这个 case 而言，误差率大概在百分之一左右。

该实现方式一样可以保证查询性能，无论表中有多大量级的数据都能毫秒级返回结果，且在工程代码方面不会有任何改动，但数据准确性上相差较多，只能用作大概估算。

背景：

最近开始尝试做自媒体，录点视频。刚开始就遇到了字幕的问题，于是想先搞个字幕生成工具（为了这点醋才包的这顿饺子😄）：SubGen。

这个工具用 Tauri + Rust 做外壳，把 FFmpeg 和 Whisper.cpp 集成进去，能一键把视频转成 SRT 字幕。

这篇文章记录下笔者做这个工具的过程，也分享下用到的核心组件和代码结构。

架构设计

SubGen 采用分层架构，核心组件的交互关系如下：

┌─────────────┐        ┌──────────────┐

│   React UI  │        │   Rust Core  │

│ (TypeScript)│ <----> │  (Tauri API) │

└─────────────┘        └─────┬────────┘

                              │

                ┌─────────────┴───────────────┐

                │                             │

           ┌────▼────┐                   ┌────▼────┐

           │ FFmpeg  │                   │Whisper  │

           │ 提取音频 │                   │ 离线识别 │

           └─────────┘                   └─────────┘

为什么用 Tauri？

最开始笔者也考虑过 Electron，但它打包太大了（动辄 100MB 起步），而且资源占用高。后来发现 Tauri，它用 Rust 做后端，前端还是用 React 或者任意 Web 技术，这样：

• 打包后体积很小（十几 MB）。


• 跨平台方便（Windows / macOS / Linux）。


• Rust 调用本地二进制（FFmpeg 和 Whisper）非常顺手。

笔者主要是用 React + TypeScript 写了一个简单的 UI，用户选视频、点按钮，剩下的活就交给 Rust。

FFmpeg：用它来“扒”音频

FFmpeg 是老牌的音视频处理工具了，笔者直接内置了一个编译好的 ffmpeg.exe/ffmpeg 到资源目录，调用它来：

Rust 这边的调用很简单：

use std::process::Command;



Command::new("resources/ffmpeg")

    .args(["-i", &video_path, "-ar", "16000", "-ac", "1", "audio.wav"])

    .status()

    .expect("FFmpeg 执行失败");

这样一行命令就能把视频转成标准 WAV。

Whisper.cpp：核心的离线识别

笔者选的是 Whisper.cpp，因为它比 Python 版 Whisper 更轻量，直接编译一个 whisper-cli 就能用，不需要装乱七八糟的依赖。

更重要的一点是支持CPU运行，默认4个线程，即使用 ggml-large-v3 也可以跑出来结果，只是稍微慢点。这对于没有好的显卡的童鞋很有用！

调用命令大概是这样：

whisper-cli -m ggml-small.bin -f audio.wav -osrt -otxt

最后会输出一个 output.srt，直接能用。

Rust 里调用也是 Command::new() 一把梭：

Command::new("resources/whisper-cli")

    .args(["-m", "resources/models/ggml-small.bin", "-f", "audio.wav", "-l", "zh", "--output-srt"])

    .status()

    .expect("Whisper 执行失败");

代码结构和流程

笔者的项目大概是这样分层的：

subgen/

├── src/                     # 前端 React + TypeScript

│   └── main.tsx             # UI入口

├── src-tauri/               # Tauri + Rust

│   ├── commands.rs          # Rust命令逻辑

│   ├── resources/           # ffmpeg、whisper二进制、模型文件

│   └── main.rs              # 程序入口

前端用 @tauri-apps/api 的 invoke 调 Rust：

import { invoke } from '@tauri-apps/api';



async function handleGenerate(videoPath: string) {

  const result = await invoke<string>('extract_subtitles', { videoPath });

  console.log('字幕生成完成：', result);

}

Rust 后端的核心命令：

#[tauri::command]

fn extract_subtitles(video_path: String) -> Result<String, String> {

    // 1. 调 FFmpeg

    // 2. 调 Whisper.cpp

    // 3. 返回 SRT 路径

    Ok("output.srt".to_string())

}

用下来的感受

整个工具现在已经能做到“拖进视频 → 等几十秒 → 出字幕”这种体验了。

几个感受：

• Tauri 真香：比 Electron 清爽太多，Rust 后端很适合做这些底层调用。


• FFmpeg 是万能的，直接抽音频，性能还不错。


• Whisper.cpp 虽然 CPU 跑慢点，但好在准确率挺高，还不用联网。

后续想做的事

• 支持批量处理视频。


• 集成一个简单的字幕编辑功能。


• 尝试 GPU 加速 Whisper（Metal / Vulkan）。

截图

主界面：

生成的 SRT：

如果你也想做个自己的字幕工具，可以直接参考 SubGen 的架构，自己改改就能用。

代码已开源：github.com/byteroycai/…

jwt，过滤器，拦截器介绍

JWT令牌

JWT介绍

JWT全称 JSON Web Token 。

jwt可以将原始的json数据格式进行安全的封装，这样就可以直接基于jwt在通信双方安全的进行信息传输了。

JWT的组成

JWT令牌由三个部分组成，三个部分之间使用英文的点来分割

• 第一部分：Header(头）， 记录令牌类型、签名算法等。 例如：{"alg":"HS256","type":"JWT"}
• 第二部分：Payload(有效载荷），携带一些自定义信息、默认信息等。 例如：{"id":"1","username":"Tom"}
• 第三部分：Signature(签名），防止Token被篡改、确保安全性。将header、payload，并加入指定秘钥，通过指定签名算法计算而来。

JWT将原始的JSON格式数据转变为字符串的方式：

• 其实在生成JWT令牌时，会对JSON格式的数据进行一次编码：进行base64编码
• Base64：是一种基于64个可打印的字符来表示二进制数据的编码方式。既然能编码，那也就意味着也能解码。所使用的64个字符分别是A到Z、a到z、 0- 9，一个加号，一个斜杠，加起来就是64个字符。任何数据经过base64编码之后，最终就会通过这64个字符来表示。当然还有一个符号，那就是等号。等号它是一个补位的符号
• 需要注意的是Base64是编码方式，而不是加密方式。

生成和校验

1.要想使用JWT令牌，需要先引入JWT的依赖：

<dependency>

    <groupId>io.jsonwebtokengroupId>

    <artifactId>jjwtartifactId>

    <version>0.9.1version>

dependency>

引入完JWT来赖后，就可以调用工具包中提供的API来完成JWT令牌的生成和校验。

2.生成JWT代码实现：

@Test

public void testGenJwt() {

    Map<String, Object> claims = new HashMap<>();

    claims.put("id", 10);

    claims.put("username", "itheima");



    String jwt = Jwts.builder().signWith(SignatureAlgorithm.HS256, "aXRjYXN0")

        .addClaims(claims)

        .setExpiration(new Date(System.currentTimeMillis() + 12 * 3600 * 1000))

        .compact();



    System.out.println(jwt);

}

3. 实现了JWT令牌的生成，下面我们接着使用Java代码来校验JWT令牌(解析生成的令牌)：

@Test

public void testParseJwt() {

    Claims claims = Jwts.parser().setSigningKey("aXRjYXN0")

        .parseClaimsJws("eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MTAsInVzZXJuYW1lIjoiaXRoZWltYSIsImV4cCI6MTcwMTkwOTAxNX0.N-MD6DmoeIIY5lB5z73UFLN9u7veppx1K5_N_jS9Yko")

        .getBody();

    System.out.println(claims);

}

篡改令牌中的任何一个字符，在对令牌进行解析时都会报错，所以JWT令牌是非常安全可靠的。

JWT令牌过期后，令牌就失效了，解析的为非法令牌。

过滤器Filter

Filter介绍

• Filter表示过滤器，是 JavaWeb三大组件(Servlet、Filter、Listener)之一。
• 过滤器可以把对资源的请求拦截下来，从而实现一些特殊的功能
  • 使用了过滤器之后，要想访问web服务器上的资源，必须先经过滤器，过滤器处理完毕之后，才可以访问对应的资源。
• 过滤器一般完成一些通用的操作，比如：登录校验、统一编码处理、敏感字符处理等。

定义过滤器

public class DemoFilter implements Filter {

    //初始化方法, web服务器启动, 创建Filter实例时调用, 只调用一次

    public void init(FilterConfig filterConfig) throws ServletException {

        System.out.println("init ...");

    }



    //拦截到请求时,调用该方法,可以调用多次

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {

        System.out.println("拦截到了请求...");

    }



    //销毁方法, web服务器关闭时调用, 只调用一次

    public void destroy() {

        System.out.println("destroy ... ");

    }

}

配置过滤器

在定义完Filter之后，Filter其实并不会生效，还需要完成Filter的配置，Filter的配置非常简单，只需要在Filter类上添加一个注解：@WebFilter，并指定属性urlPatterns，通过这个属性指定过滤器要拦截哪些请求

@WebFilter(urlPatterns = "/*") //配置过滤器要拦截的请求路径（ /* 表示拦截浏览器的所有请求 ）

public class DemoFilter implements Filter {

    //初始化方法, web服务器启动, 创建Filter实例时调用, 只调用一次

    public void init(FilterConfig filterConfig) throws ServletException {

        System.out.println("init ...");

    }



    //拦截到请求时,调用该方法,可以调用多次

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {

        System.out.println("拦截到了请求...");

    }



    //销毁方法, web服务器关闭时调用, 只调用一次

    public void destroy() {

        System.out.println("destroy ... ");

    }

}

在Filter类上面加了@WebFilter注解之后，还需要在启动类上面加上一个注解@ServletComponentScan，通过这个@ServletComponentScan注解来开启SpringBoot项目对于Servlet组件的支持。

@ServletComponentScan //开启对Servlet组件的支持

@SpringBootApplication

public class TliasManagementApplication {

    public static void main(String[] args) {

        SpringApplication.run(TliasManagementApplication.class, args);

    }

}

在过滤器Filter中，如果不执行放行操作，将无法访问后面的资源。 放行操作：chain.doFilter(request, response);

过滤器的执行流程

过滤器当中我们拦截到了请求之后，如果希望继续访问后面的web资源，就要执行放行操作，放行就是调用 FilterChain对象当中的doFilter()方法，在调用doFilter()这个方法之前所编写的代码属于放行之前的逻辑。

测试代码：

@WebFilter(urlPatterns = "/*") 

public class DemoFilter implements Filter {

    

    @Override //初始化方法, 只调用一次

    public void init(FilterConfig filterConfig) throws ServletException {

        System.out.println("init 初始化方法执行了");

    }

    

    @Override

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

        

        System.out.println("DemoFilter   放行前逻辑.....");



        //放行请求

        filterChain.doFilter(servletRequest,servletResponse);



        System.out.println("DemoFilter   放行后逻辑.....");

        

    }



    @Override //销毁方法, 只调用一次

    public void destroy() {

        System.out.println("destroy 销毁方法执行了");

    }

}

过滤器的拦截路径配置

拦截路径	urlPatterns值	含义
拦截具体路径	/login	只有访问 /login 路径时，才会被拦截
目录拦截	/emps/*	访问/emps下的所有资源，都会被拦截
拦截所有	/*	访问所有资源，都会被拦截

测试代码：

@WebFilter(urlPatterns = "/login")  //拦截/login具体路径

public class DemoFilter implements Filter {

    @Override

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

        System.out.println("DemoFilter   放行前逻辑.....");



        //放行请求

        filterChain.doFilter(servletRequest,servletResponse);



        System.out.println("DemoFilter   放行后逻辑.....");

    }





    @Override

    public void init(FilterConfig filterConfig) throws ServletException {

        Filter.super.init(filterConfig);

    }



    @Override

    public void destroy() {

        Filter.super.destroy();

    }

}

过滤器链

过滤器链指的是在一个web应用程序当中，可以配置多个过滤器，多个过滤器就形成了一个过滤器链。

过滤器链上过滤器的执行顺序：注解配置的Filter，优先级是按照过滤器类名（字符串）的自然排序。 比如：

• AbcFilter
• DemoFilter

这两个过滤器来说，AbcFilter 会先执行，DemoFilter会后执行。

拦截器Interceptor

• 拦截器是一种动态拦截方法调用的机制，类似于过滤器。
• 拦截器是Spring框架中提供的，用来动态拦截控制器方法的执行。
• 拦截器的作用：拦截请求，在指定方法调用前后，根据业务需要执行预先设定的代码。

自定义拦截器

实现HandlerInterceptor接口，并重写其所有方法

//自定义拦截器

@Component

public class DemoInterceptor implements HandlerInterceptor {

    //目标资源方法执行前执行。 返回true：放行    返回false：不放行

    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        System.out.println("preHandle .... ");

        

        return true; //true表示放行

    }



    //目标资源方法执行后执行

    @Override

    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {

        System.out.println("postHandle ... ");

    }



    //视图渲染完毕后执行，最后执行

    @Override

    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {

        System.out.println("afterCompletion .... ");

    }

}

• preHandle方法：目标资源方法执行前执行。 返回true：放行 返回false：不放行
• postHandle方法：目标资源方法执行后执行
• afterCompletion方法：视图渲染完毕后执行，最后执行

注册配置拦截器

在 com.itheima下创建一个包，然后创建一个配置类 WebConfig， 实现 WebMvcConfigurer 接口，并重写 addInterceptors 方法

@Configuration  

public class WebConfig implements WebMvcConfigurer {



    //自定义的拦截器对象

    @Autowired

    private DemoInterceptor demoInterceptor;



    

    @Override

    public void addInterceptors(InterceptorRegistry registry) {

       //注册自定义拦截器对象

        registry.addInterceptor(demoInterceptor).addPathPatterns("/**");//设置拦截器拦截的请求路径（ /** 表示拦截所有请求）

    }

}

拦截器的拦截路径配置

首先我们先来看拦截器的拦截路径的配置，在注册配置拦截器的时候，我们要指定拦截器的拦截路径，通过addPathPatterns("要拦截路径")方法，就可以指定要拦截哪些资源。

在入门程序中我们配置的是/**，表示拦截所有资源，而在配置拦截器时，不仅可以指定要拦截哪些资源，还可以指定不拦截哪些资源，只需要调用excludePathPatterns("不拦截路径")方法，指定哪些资源不需要拦截。

@Configuration  

public class WebConfig implements WebMvcConfigurer {



    //拦截器对象

    @Autowired

    private DemoInterceptor demoInterceptor;



    @Override

    public void addInterceptors(InterceptorRegistry registry) {

        //注册自定义拦截器对象

        registry.addInterceptor(demoInterceptor)

                .addPathPatterns("/**")//设置拦截器拦截的请求路径（ /** 表示拦截所有请求）

                .excludePathPatterns("/login");//设置不拦截的请求路径

    }

}

在拦截器中除了可以设置/**拦截所有资源外，还有一些常见拦截路径设置：

拦截路径	含义	举例
/*	一级路径	能匹配/depts，/emps，/login，不能匹配 /depts/1
/**	任意级路径	能匹配/depts，/depts/1，/depts/1/2
/depts/*	/depts下的一级路径	能匹配/depts/1，不能匹配/depts/1/2，/depts
/depts/**	/depts下的任意级路径	能匹配/depts，/depts/1，/depts/1/2，不能匹配/emps/1

拦截器的执行流程

• 当我们打开浏览器来访问部署在web服务器当中的web应用时，此时我们所定义的过滤器会拦截到这次请求。拦截到这次请求之后，它会先执行放行前的逻辑，然后再执行放行操作。而由于我们当前是基于springboot开发的，所以放行之后是进入到了spring的环境当中，也就是要来访问我们所定义的controller当中的接口方法。
• Tomcat并不识别所编写的Controller程序，但是它识别Servlet程序，所以在Spring的Web环境中提供了一个非常核心的Servlet：DispatcherServlet（前端控制器），所有请求都会先进行到DispatcherServlet，再将请求转给Controller。
• 当我们定义了拦截器后，会在执行Controller的方法之前，请求被拦截器拦截住。执行preHandle()方法，这个方法执行完成后需要返回一个布尔类型的值，如果返回true，就表示放行本次操作，才会继续访问controller中的方法；如果返回false，则不会放行（controller中的方法也不会执行）。
• 在controller当中的方法执行完毕之后，再回过来执行postHandle()这个方法以及afterCompletion() 方法，然后再返回给DispatcherServlet，最终再来执行过滤器当中放行后的这一部分逻辑的逻辑。执行完毕之后，最终给浏览器响应数据。

过滤器和拦截器之间的区别：

• 接口规范不同：过滤器需要实现Filter接口，而拦截器需要实现HandlerInterceptor接口。
• 拦截范围不同：过滤器Filter会拦截所有的资源，而Interceptor只会拦截Spring环境中的资源。

作者：丧心病狂汤姆猫
来源：juejin.cn/post/7527869985345339392

当你在浏览器里输入 http://www.example.com 并按下回车，看似平平无奇的一次访问，其实暗藏着 SSL/TLS 的三次握手、对称与非对称加密的轮番上阵、CA 证书的“身份核验”以及防中间人攻击的多重机关。

一、SSL、TLS、HTTPS 到底是什么关系？

• SSL（Secure Sockets Layer）：早期网景公司设计的加密协议，1999 年后停止更新。


• TLS（Transport Layer Security）：SSL 的直系升级版，目前主流版本为 TLS 1.2/1.3。


• HTTPS：把 HTTP 报文塞进 TLS 的“安全信封”里，再交给 TCP 传输。简而言之，HTTPS = HTTP + TLS/SSL。

二、HTTPS 握手

三、为什么必须有 CA？

没有 CA，任何人都可以伪造公钥，中间人攻击将防不胜防。CA 通过可信第三方背书，把“公钥属于谁”这件事写死在证书里，浏览器才能放心地相信“这就是真正的服务器”。

四、证书到底怎么防伪？

证书 = 域名 + 公钥 + 有效期 + CA 数字签名。

CA（Certificate Authority）用自己的私钥对整个证书做哈希签名。浏览器内置 CA 公钥，可解密签名并对比哈希值，一旦被篡改就立即报警。

没有 CA 签名的自签证书？浏览器会毫不留情地显示“红色警告”。

五、对称与非对称加密的分工

• 非对称加密（RSA/ECC）：只在握手阶段用一次，解决“如何安全地交换对称密钥”。


• 对称加密（AES/ChaCha20）：握手完成后，所有 HTTP 报文都用对称密钥加解密，性能高、延迟低。

一句话：非对称加密“送钥匙”，对称加密“锁大门”。

六、中间人攻击的两张面孔

总结

下次当你在地址栏看到那把绿色小锁时，背后是一场涉及四次握手、两把密钥、一张证书和全球信任链的加密大戏。

当功能开发完成dev 稳定后合并进 test，然后QA 回归测试环境；如发现问题，在 hotfix/xxx 修复后继续合并回 test（实际开发中，为了简化开发流程，大家都是直接在test修改bug）。

3. 预发布验证

测试通过，临近上线时，会从 test 合并进 pre。pre 仅用于业务验证、客户预览，不会在开发新功能；遇到bug的话，必须基于pre拉一个hotfix分支，修复完通过验证后，在合并回pre。

4. 正式上线

从 pre 合并到 prod ，并部署上线；

为什么不能直接在pre修改bug

pre 是预发布环境分支，作用是：模拟线上环境，确保代码上线前是可靠的，它应只接收已审核通过的改动，而不是“随便修的东西”。

如果直接在 pre 上修改，会出现很多意料之外的问题。如：

• 代码来源不清晰，审查流程被绕过
• 多人协作下容易引发冲突和覆盖（bug重现）

这样时间久了我们根本不知道哪个 bug 是从哪冒出来的，代码就会变得难以维护和溯源。

因此，基于pre拉一个hotfix/xxx 分支是团队开发的规范流程：

• 创建热修分支（hotfix 分支）

从 pre 分支上拉一个新的临时分支，命名建议规范些，如：

git checkout pre

git pull origin pre        # 确保是最新代码

git checkout -b hotfix/fix-button-not-working

• 2在 hotfix 分支中修复 bug

进行代码修改、调试、测试。

• 创建合并请求

bug修复且通过qa验证后，我们就可以合并至pre等待审核。

使用hotfix，大家一看到这个分支名字，大家就知道这是线上急修的问题，容易跟踪、回溯和管理。你直接在 pre 改，其他人甚至都不知道发生了 bug。

总结

通过本文，大家应该也进一步了解pre环境的bug处理规范，如果你还觉得小问题在pre直接修改问题不大，可以看看这个示例：

你是一个信誉良好的企业老板，你的样品准备提交客户的时候突然发现了问题。你正常的流程应该是：

• 回原材料工厂排查修理
• 重新打样
• 提交新样品
• 送给客户

除非你是黑心老板，样品有问题直接凑合修一下直接给客户。

问题描述

昨天下班的时候，运营反馈了一个问题，明明设置的是两天后解封，为什么提示却是三天后呢。

比如今天(6.16)被拉入黑名单了，用户报名会提示 “6.19号恢复报名”，但是现在却提示6月20号才能报名，经过排查发现，就是解封的时间被多加了 1s 中，本来应该是存2025-06-18 23:59:59，但是数据库却是2025-06-19 00:00:00。

看了数据库有接近一半的数据是正确的，有一半的数据是第二天0晨（百思不得其解啊🤣）

代码逻辑实现：

LocalDateTime currentTime = LocalDateTime.now();

LocalDateTime futureTime = currentTime.plus(2, ChronoUnit.DAYS);

// 设置了为当天的最后一秒啊

LocalDateTime resultTime = futureTime.withHour(23).withMinute(59).withSecond(59);

BlackAccount entity = new BlackAccount();

// 实体字段类型为Date，数据库是timestamp

entity.setDeblockTime(Date.from(resultTime.atZone(ZoneId.systemDefault()).toInstant()));

blackAccountService.save(entity);

❓看到上面的代码，有没有大佬已经发现问题了。确实上面的代码存在问题

解决过程

排查思路

一、排除代码问题

1.确认了项目中所有设置DeblockTime的地方 只有1出。排除了代码逻辑问题，被其他代码覆盖问题；

二、问问AI：

LocalDateTime futureTime = currentTime.plus(oaConfigActivityBlacklist.getBlockDay(), ChronoUnit.DAYS);

LocalDateTime resultTime = futureTime.withHour(23).withMinute(59).withSecond(59);

Date date = Date.from(resultTime.atZone(ZoneId.systemDefault()).toInstant())；

这种写法能保证最后的date 的时分秒为 23时59分59秒么?

ai的答案如下 :

1. 夏令时（DST）影响

• 场景：若时区在目标日期存在夏令时调整（如时钟回拨或前拨），可能导致时间偏差。
• 示例：
  • 假设系统时区为 Europe/Paris，2023 年 10 月 29 日凌晨 3 点时钟回拨到 2 点。
  • 若 futureTime 是该日，设置 23:59:59 后，转换为 UTC 时可能变为 21:59:59Z 或 22:59:59Z，取决于时钟调整规则。

2. 时区转换问题

• 场景：若 currentTime 是其他时区的时间（如 UTC），直接转换可能导致时间偏移。
• 示例：
  • 若 currentTime 是 UTC 时间 2023-10-01T16:00:00Z，系统时区为 Asia/Shanghai（UTC+8）。
  • 添加 1 天后得到 2023-10-02T16:00:00Z，设置为 23:59:59 后转换为 Date，实际对应 UTC 时间 2023-10-02T15:59:59Z。

看了数据的时间分布，任何时间点 都存在 23:59:59 和 00:00:00的情况，就算创建时间相差几分钟的情况下，都存在这两种数据。

三、批量插入数据测试

看看能不能复现这个问题，会不会插入时候精度等其他问题：

for (int i = 0; i < 100; i++) {

    Thread.sleep(100);

   LocalDateTime currentTime = LocalDateTime.now();

   LocalDateTime futureTime = currentTime.plus(2, ChronoUnit.DAYS); 

   // 设置了为当天的最后一秒啊 LocalDateTime resultTime = futureTime.withHour(23).withMinute(59).withSecond(59);

   BlackAccount entity = new BlackAccount(); 

   // 实体字段类型为Date，数据库是timestamp 

   entity.setDeblockTime(Date.from(resultTime.atZone(ZoneId.systemDefault()).toInstant())); 

   blackAccountService.save(entity);

}

果然还真复现了，有一半的数据是2025-06-19 23:59:59 有一半的数据是2025-06-20 00:00:00

定位问题

通过demo的复现，可以确认是在存数据库的时候出了问题。 因为Date的精度是控制在毫秒，pgsql 中TimeStamp 的精度用的默认值，精确到秒，所以在插入的时候Date的毫秒部分大于等于500的时候就会加1秒处理。入库之后就变成了第二天的00:00:00呢

解决方案

要么将java对象的时间精度和 数据库的精度保持一致，要么就将java对象多余的精度置为0，解决方案如下：

• 方案1：代码中清空秒后面的数据
  修改前： futureTime.withHour(23).withMinute(59).withSecond(59);
  修改后： futureTime.withHour(23).withMinute(59).withSecond(59).withNano(0);
• 方案2：调整数据库TimeStamp精度不小于java（date）对象的精度
  修改前： 
  修改后： 

知识扩展

1. Date 和 LocalDateTime

特性	java.util.Date (Java 1.0)	java.time.LocalDateTime (Java 8+)
精度	毫秒级（1/1000 秒）	纳秒级（1/1,000,000,000 秒）
包路径	java.util.Date	java.time.LocalDateTime
可变性	可变（修改会影响原对象）	不可变（所有操作返回新对象）
时区感知	不存储时区，但内部时间戳基于 UTC	无时区，仅表示本地日期和时间

2. mysql 中的timestamp 和 datetime

特性	DATETIME	TIMESTAMP
存储范围	1000-01-01 00:00:00 到 9999-12-31 23:59:59	1970-01-01 00:00:01 UTC 到 2038-01-19 03:14:07 UTC
精度	5.6.4 版本后支持 fractional seconds（如DATETIME(6)）最高精度微妙，设置0的话就表示精确到秒	同上（如TIMESTAMP(6)）
存储空间	8 字节	4 字节（时间戳范围小）
时区感知	不存储时区信息，直接存储字面量	自动转换时区：存储时转换为 UTC，读取时转换为会话时区
默认值	无默认值（除非显式设置DEFAULT）	支持DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP
自动更新	不支持	支持自动更新为当前时间（ON UPDATE）

3.适用场景建议

1. java 中尽量用LocalDateTime吧，毕竟LocalDateTime 主要就是用来取代Date对象的,区别如下

场景类型	java.util.Date（旧 API）	java.time.LocalDateTime（新 API）
简单本地时间记录	可使用，但 API 繁琐（需配合Calendar）	推荐使用（无需时区，代码简洁）
带时区的时间处理	不推荐（时区处理易混淆）	推荐使用ZonedDateTime或OffsetDateTime
多线程环境	不推荐（非线程安全）	推荐（不可变设计，线程安全）
数据库交互（JDBC 4.2+）	需转换为java.sql.Timestamp	直接支持（如pstmt.setObject(1, localDateTime)）
时间计算与格式化	需依赖SimpleDateFormat（非线程安全）	推荐（DateTimeFormatter线程安全）
高精度需求（纳秒级）	仅支持毫秒级	支持纳秒级（1/1,000,000,000 秒

2. 数据库到底是用timestamp 还是 datetime呢,跨国业务用timestamp 其他场景建议用datetime：

场景	推荐类型	原因
存储历史事件时间（如订单创建时间）	DATETIME	不依赖时区，固定记录用户输入的时间
记录服务器本地时间（如定时任务执行时间）	DATETIME	无需时区转换，直接反映服务器时间
多时区应用（如跨国业务）	TIMESTAMP	自动处理时区转换，确保数据一致性（如登录时间）
需要自动更新时间戳	TIMESTAMP	支持ON UPDATE CURRENT_TIMESTAMP特性
存储范围超过 2038 年	DATETIME	TIMESTAMP仅支持到 【2038】 年
微秒级精度需求	DATETIME(6)或TIMESTAMP(6)	根据是否需要时区转换选择

总结

本文主要讲述了在处理用户解封时间时，因 Java 代码中时间精度与数据库TIMESTAMP类型精度不一致，导致约一半数据存储时间比预期多 1 秒的问题。通过排查与测试，定位问题并给出了 Java 对象时间精度和调整数据库精度两种解决方案，同时对比了 Java 和数据库中多种时间类型的特性及适用场景 。

作者：提前退休的java猿
来源：juejin.cn/post/7517119131856191500

原文：Alexander Belanger - 2025.06.03

如同地球上几乎所有人一样，过去的几个月里，我们也一直在关注着 Agent 的发展。

特别值得一提的是，我们观察到 Agent 的采用推动了我们编排平台的增长，这让我们对哪些技术栈和框架——或者干脆没有框架——在此领域表现良好有了一些见解。

我们看到的一个更有趣的现象是混合技术栈的激增：一个典型的 Next.js 或 FastAPI 后端，搭配着一个用 Go 语言编写的 Agent，甚至在非常早期阶段就如此。

作为一名长期的 Go 语言开发者，这着实令人兴奋；下面我将解释为何我认为这将成为未来更普遍的做法。

什么是 Agent？

这里的术语有些混乱，但通常我指的是一个在循环中执行的进程，该进程对其执行路径中的下一步操作拥有一定的自主权。这与预定义的执行路径（例如定义为有向无环图的一组步骤，我们称之为工作流）形成对比。Agent 通常包含一个基于最大深度或满足某个条件（如“测试通过”）的退出条件。

当 Agent 开始规模化（即：拥有实际用户）时，它们通常具有一些共同特征：

让我们将这一系列特征转化为对运行时的要求。为了限定问题范围，假设我们正在处理一个在远程执行的 Agent，而非在用户本地机器上（尽管 Go 对于分发本地 Agent 也是一个绝佳选择）。在远程执行的情况下，为每次 Agent 执行运行一个单独的容器成本会高得惊人。因此，在大多数情况下（尤其是当我们的 Agent 主要是简单的 I/O 和 LLM 调用时），我们最终会得到大量并发运行的轻量级进程。每个进程可以处于特定状态（例如，“搜索文件中”、“生成代码中”、“测试中”）。请注意，不同 Agent 执行的状态顺序可能并不相同。

这种包含许多并发、长时间运行进程的系统，与大约十年前的传统 Web 架构截然不同。在传统架构中，对服务器的请求处理速度要快得多，使用一些缓存、高效的处理程序和 OLTP 数据库就能高效地服务数千名日活用户。

事实证明，这种架构转变非常适合 Go 语言的并发模型、依赖通道（channel）进行通信、集中的取消机制以及围绕 I/O 构建的工具链。

高并发性

让我们从最明显的一点开始——Go 拥有极其简单且强大的并发模型。创建一个新的 goroutine 所需的内存和时间成本非常低，因为每个 goroutine 只有 2KB 的预分配内存。

这实际上意味着你可以同时运行许多 goroutine 而开销很小，并且它们在底层运行在多个操作系统线程上，能够利用服务器中的所有 CPU 核心。这一点非常重要，因为如果你碰巧在某个 goroutine 中执行非常消耗 CPU 的操作（比如反序列化一个大型 JSON 结构），其影响会比你使用单线程运行时（如 Node.js）要小（在 Node.js 中，你需要为阻塞线程的操作创建 worker 线程或子进程），或者比使用 Python 的 async/await 也要好。

这对于 Agent 意味着什么？因为 Agent 的运行时间比典型的 Web 请求长得多，所以并发性就成为了一个更关键的问题。在 Go 中，相比于在 Python 中为每个 Agent 运行一个线程，或者在 Node.js 中为每个 Agent 运行一个 async 函数，你受到为每个 Agent 生成一个 goroutine 的限制要小得多。再加上较低的基础内存占用和编译成单一二进制文件的特点，在轻量级基础设施上同时运行数千个并发 Agent 执行变得异常简单。

通过通信共享内存

对于那些不了解的人，Go 语言有一个常见的习语：不要通过共享内存来通信；相反，通过通信来共享内存。

在实践中，这意味着不需要尝试跨多个并发进程同步内存内容（这是使用类似 Python 的 multithreading 库时的常见问题），每个进程可以通过在通道（channel）上获取和释放对象来获得该对象的所有权。这样做的效果是，每个进程只在拥有对象所有权时关心该对象的本地状态，而其他时候不需要协调所有权——无需互斥锁（mutex）！

老实说——在我编写过的大多数 Go 程序中，我使用等待组（wait groups）和互斥锁（mutexes）的次数往往比使用通道（channels）更多，因为这样通常更简单（这也符合 Go 社区的建议），并且只有一个地方需要并发访问数据。

但是，在建模 Agent 时，这种范式非常有用，因为 Agent 通常需要异步响应用户或其他 Agent 发来的消息，并且将应用程序实例视为一个 Agent 池来思考是很有帮助的。

为了更具体说明，让我们编写一些示例代码来表示 Agent 循环的核心逻辑：

// 注意：在真实世界的例子中，我们需要一种机制来优雅地

// 关闭循环并防止通道关闭；

// 这是一个简化示例。

func Agent(in <-chan Message, out chan<- Output, status chan<- State) {

    internal := make(chan Message, 10) // 内部缓冲区大小为 10 的通道



    for {

        select {

        case msg := <-internal: // 从内部通道读取消息

            processMessage(msg, internal, out, status)

        case msg := <-in: // 从外部输入通道读取消息

            processMessage(msg, internal, out, status)

        }

    }

}



func processMessage(msg Message, internal chan<- Message, out chan<- Output, status chan<- State) {

    result := execute(msg) // 执行消息处理

    status <- State{msg.sessionId, result.status} // 发送状态更新



    if next := result.next(); next != nil { // 获取下一步消息（如果有）

        internal <- next // 将下一步消息发送到内部通道

    }



    out <- result // 发送处理结果

}

(请注意，<-chan 表示接收者只能从通道读取，而 chan<- 表示接收者只能向通道写入。)

这个 Agent 是一个长时间运行的进程，它等待消息到达 in 通道，处理消息，然后异步地将结果发送到 out 通道。status 通道用于发送关于 Agent 状态的更新，这对于监控或向用户发送增量结果很有用；而 internal 通道用于处理 Agent 的内部循环。例如，内部循环可以实现下图中的“直到测试通过”循环：

尽管我们使用 for 循环来运行 Agent，但该 Agent 的实例在消息之间不需要维护任何内部状态。它本质上是一个无状态归约器，其决策执行路径的下一步操作不依赖于某些内部状态。重要的是，这意味着任何 Agent 实例都能够处理下一条消息。这也允许 Agent 在消息之间使用持久化边界，例如将消息写入数据库或消息队列。

使用 context.Context 的集中取消机制

还记得 Agent 执行成本很高吗？假设一个用户触发了一个价值 10 美元的执行任务，但突然改变主意并点击“停止生成”——为了节省成本，你希望取消这次执行。

事实证明，在 Node.js 和 Python 中取消长时间运行的工作极其困难，原因有很多：

幸运的是，Go 采用 context.Context 使得取消工作变得轻而易举，因为绝大多数库都预期并尊重这种模式。即使某些库不支持：由于 Go 只有一种并发模型，因此有像 goleak 这样的工具，可以更容易地检测出泄漏的 goroutine 和有问题的库。

丰富的标准库

当你开始使用 Go 时，你会立即注意到 Go 的标准库非常丰富且质量很高。它的许多部分也是为 Web I/O 构建的——比如 net/http、encoding/json 和 crypto/tls——这些对于 Agent 的核心逻辑非常有用。

Go 还有一个隐含的假设：所有 I/O 在 goroutine 内部都是阻塞的——再次强调，因为 Go 只有一种方式运行并发工作——这鼓励你将业务逻辑的核心编写为直线式程序。你不需要担心用 await 包装每个函数调用来将执行推迟给调度器。

与 Python 对比：库开发者需要考虑 asyncio、多线程（multithreading）、多进程（multiprocessing）、eventlet、gevent 以及其他一些模式，几乎不可能同等地支持所有并发模型。因此，如果你用 Python 编写 Agent，你需要研究每个库对你所采用的并发模型的支持情况，并且如果你的第三方库不完全支持你想要的模式，你可能需要采用多种模式。

（Node.js 的情况要好得多，尽管 Bun 和 Deno 等其他运行时的加入增加了一些不兼容的层面。）

性能剖析（Profiling）

由于其有状态性（statefulness）和大量长时间运行的进程，Agent 似乎特别容易出现内存泄漏和线程泄漏。Go 在 runtime/pprof 中提供了出色的工具，可以使用堆（heap）和分配（alloc）配置文件找出内存泄漏的来源，或者使用 goroutine 配置文件找出 goroutine 泄漏的来源。

额外优势：LLM 擅长编写 Go 代码

由于 Go 语法非常简单（一个常见的批评是 Go 有点“啰嗦”）并且拥有丰富的标准库，LLM 非常擅长编写符合 Go 语言习惯的代码。我发现它们在编写表格测试（table tests）方面尤其出色，这是 Go 代码库中的一种常见模式。

Go 工程师也往往反对框架（anti-framework），这意味着 LLM 不需要跟踪你使用的是哪个框架（或框架的哪个版本）。

不足之处

尽管有以上诸多好处，仍然有很多理由让你可能不会选择 Go 来开发你的 Agent：

前言

最近公司来了个新同事，年轻有活力，就是查日志的方式让我有点裂开。

事情是这样的：他写的代码在测试环境报错了，报警信息也被钉钉机器人发到了我们群里。作为资深摸鱼战士，我寻思正好借机摸个鱼顺便指导一下新人，就凑过去看了眼。

结果越看我越急，差点当场喊出：“兄弟你是来写代码的，还是和日志谈恋爱的？”

来看看他是怎么查日志的

他先敲了一句：

tail -f a.log | grep "java.lang.NullPointerException"

想着等下次报错就能立刻看到。等了半天，终于蹦出来一行：

2025-07-03 11:38:48.339 [http-nio-8960-exec-1] [47gK4n32jEYvTYX8AYti48] [INFO] [GlobalExceptionHandler] java.lang.NullPointerException, ex: java.lang.NullPointerException

java.lang.NullPointerException: null

我提醒他：“这样看不到堆栈信息啊。”

他“哦”了一声，灵机一动，用 vi把整个文件打开，/NullPointerException 搜关键词，一个 n 一个 n 地翻……半分钟过去了，异常在哪都没找全，我都快给他跪下了。

于是我当场掏出了一套我压箱底的“查日志组合拳”，一招一式手把手教他。他当场就“悟了”，连连称妙，并表示想让我写成文章好让他发给他前同事看——因为他前同事也是这样查的……

现在，这套组合拳我也分享给你，希望你下次查日志的时候，能让你旁边的同事开开眼。

正式教学

核心的工具其实还是 grep 命令，下面我将分场景给你讲讲我的实战经验，保证你能直接套用！

场景一：查异常堆栈，不能只看一行！

Java 异常堆栈通常都是多行的，仅仅用 grep "NullPointerException" 只能看到最上面那一行，问题根源在哪你压根找不到。

这时候使用 **grep** 的 **-A** (After) 参数来显示匹配行之后的N行。

# 查找 NullPointerException，并显示后面 50 行

grep -A 50 "java.lang.NullPointerException" a.log

如果你发现异常太多，屏幕一闪而过，也可以用less加上分页查看：

grep -A 50 "java.lang.NullPointerException" a.log | less

在 less 视图中，你可以：

• 使用 箭头↑↓ 或 Page Up/Down 键来上下滚动


• 输入 G 直接翻到末尾，方便快速查看最新的日志


• 输入 /Exception 继续搜索


• 按 q 键退出

这样你就能第一时间拿到完整异常上下文信息，告别反复 vi + / 的低效操作！

场景二：实时看新日志怎么打出来的

如果你的应用正在运行，并且你怀疑它会随时抛出异常，你可以实时监控日志文件的增长。

使用 tail -f 结合 grep：

# 实时监控 a.log 文件的新增内容，并只显示包含 "java.lang.NullPointerException" 的行及其后50行

tail -f a.log | grep -A 50 "java.lang.NullPointerException"

只要异常一出现，它就会自动打出来，堆栈信息也一并送到你面前！

• 想停下？Ctrl + C


• 想更准确？加 -i 忽略大小写，防止大小写拼错找不到

场景三：翻历史日志 or 查压缩日志

服务器上的日志一般都会按天或按大小分割并压缩，变成 .log.2025-07-02.gz 这种格式，查找这些文件的异常信息怎么办？

🔍 查找当前目录所有 .log 文件：

# 在当前目录下查找所有以 .log 结尾的文件，-H 参数可以顺便打印出文件名

grep -H -A 50 "java.lang.NullPointerException" *.log

其中 -H 会帮你打印出是哪个文件中出现的问题，防止你找完还不知道是哪天的事。

🔍 查找 .gz 文件（压缩日志）：

zgrep -H -A 50 "java.lang.NullPointerException" *.gz

zgrep 是专门处理 .gz 的 grep，它的功能和 grep 完全一样，无需手动解压，直接开整！

场景四：统计异常数量（快速判断异常是否频繁）

有时候你需要知道某个异常到底出现了多少次，是偶发还是成灾，使用 grep -c（count）：

grep -c "java.lang.NullPointerException" a.log

如果你要统计所有日志里的数量：

grep -c "java.lang.NullPointerException" *.log

其他常用的 grep 参数

比如：

grep -C 25 "java.lang.NullPointerException" a.log

这个命令就能让你一眼看到异常前后的上下文，帮助定位代码逻辑是不是哪里先出问题了。

尾声

好了，这套组合拳我已经传授给你了，要是别人问你在哪学的，记得报我杆师傅的大名（doge）。

其实还有其他查日志的工具，比如awk、wc 等。

但是我留了一手，没有全部教给我这个同事，毕竟江湖规则，哪有一出手就把看家本领全都交出去的道理？

如果你也想学，先拜个师交个学费（点赞、收藏、关注），等学费凑够了，我下次再开新课，传授给大家~

Tailwind 曾经是我最爱的工具，直到它让我维护不下去整个项目。

前情提要：我是如何变成 Tailwind 重度用户的

作为一个多年写 CSS 的前端，我曾经深陷“命名地狱”：

什么 .container-title, .btn-primary, .form-item-error，一个项目下来能写几百个类名，然后改样式时不知道该去哪动刀，甚至删个类都心慌。

直到我遇见了 Tailwind CSS——一切原子化，想改样式就加 class，别管名字叫什么，直接调属性即可。

于是我彻底拥抱它，团队项目里我把所有 SCSS 全部清除，组件中也只保留了 Tailwind class，一切都干净、轻便、高效。

但故事从这里开始转变。

三个月后的重构期，我被 Tailwind“反噬”

我们的后台管理系统迎来一次大版本升级，我负责重构 UI 样式逻辑，目标是：

• 统一设计规范；


• 提高代码可维护性；


• 降低多人协作时的样式冲突。

刚开始我信心满满，毕竟 Tailwind 提供了：

• 原子化 class；


• @apply 合成组件级 class；


• 配置主题色/字体/间距系统；


• 插件支持动画/form 控件/typography；

但随着项目深入，我开始发现 几个巨大的问题，并最终决定停用 Tailwind。

一、class 污染：结构和样式纠缠成灾

来看一个真实例子：

<div class="flex items-center justify-between bg-white p-4 rounded-lg shadow-sm border border-gray-200">

  <h2 class="text-lg font-semibold text-gray-800">订单信息</h2>

  <button class="text-sm px-2 py-1 bg-blue-500 text-white rounded hover:bg-blue-600">编辑</button>

</div>

你能看出这个组件的“设计意图”吗？

你能快速改它的样式吗？

一个看似简单的按钮，一眼看不到设计语言，只看到一坨 class，你根本不知道：

• px-2 py-1 是从哪里决定的？


• bg-blue-500 是哪个品牌色？


• hover:bg-blue-600 是统一交互吗？

Tailwind 让样式变得快，但也让样式“变得不可读”。

二、复用失败：想复用样式还得靠 SCSS

我天真地以为 @apply 能帮我合成组件级样式，比如：

.btn-primary {

  @apply text-white bg-blue-500 px-4 py-2 rounded;

}

但问题来了：

• @apply 不能用在媒体查询内；


• @apply 不支持复杂嵌套、hover/focus 的组合；


• 响应式、伪类写在 HTML 里更乱，如：lg:hover:bg-blue-700；


• 没法动态拼接 class，逻辑和样式混在组件逻辑层了。

最终结果就是：复用失败、样式重复、维护困难。

三、设计规范无法沉淀

我们设计系统中定义了若干基础变量：

• 主色：#0052D9


• 次色：#A0AEC0


• 字体尺寸规范：12/14/16/18/20/24/32px


• 组件间距：8/16/24

本来我们希望 Tailwind 的 theme.extend 能承载这套设计系统，结果发现：

• tailwind.config.js 修改后，需要全员重启 dev server；


• 新增设计 token 非常繁琐，不如直接写 SCSS 变量；


• 多人改配置时容易冲突；


• 和设计稿同步代价高。

这让我明白：配置式设计系统不适合快速演进的产品团队。

四、多人协作混乱：Tailwind 并不直观

当我招了一位新同事，给他一个组件代码时，他的第一句话是：

“兄弟，这些 class 是从设计稿复制的吗？”

他根本看不懂 gap-6, text-gray-700, tracking-wide 分别是什么意思，只看到一堆“魔法 class” 。

更糟糕的是，每个人心中对 text-sm、text-base 的视觉认知不同，导致多个组件在微调时出现样式不一致、间距不统一的问题。

Tailwind 的语义脱离了设计意图，协作就失去了基础。

最终决定：我切回了 SCSS + BEM + 设计 token

我们开始回归传统模式：

• 所有组件都有独立 .scss 文件；


• 使用 BEM 命名规范：.button, .button--primary, .button--disabled；


• 所有颜色/间距/字体等统一放在 _variables.scss 中；


• 每个组件样式文件都注释设计规范来源。

这种模式虽然看起来“原始”，但它：

• 清晰分离结构和样式；


• 强制大家遵守设计规范；


• 组件样式可复用，可继承，可重写；


• 新人一眼看懂，不需要会 Tailwind 语法。

总结：Tailwind 不是错，是错用的代价太高

Tailwind 在以下场景表现极好：

• 个人项目 / 小程序：快速开发、无需复用；


• 组件库原型：试验颜色、排版效果；


• 纯前端工程师独立开发的项目：没有协作负担。

但在以下情况，Tailwind 会成为维护灾难：

• 多人协作；


• UI 不断迭代，设计语言需频繁调整；


• 有强复用需求（组件抽象）；


• 与设计系统严格对齐的场景；

我为什么写这篇文章？

不是为了黑 Tailwind，而是为了让你在选择技术栈时更慎重。

就像当年我们争论 Sass vs Less，今天的 Tailwind vs 原子/语义 CSS 并没有标准答案。

Tailwind 很强，但不是所有团队都适合。

也许你正在享受它的爽感，但三个月后你可能会像我一样，把所有 .w-full h-screen text-gray-800 替换成 .layout-container。

尾声：如果你非要继续用 Tailwind，我建议你做这几件事

一、Docker 不再万能，我们该何去何从？

过去十年，Docker 改变了整个软件开发世界。它以“一次构建，到处运行”的理念，架起了开发者和运维人员之间的桥梁，推动了 DevOps 与微服务架构的广泛落地。

从自动化部署、持续集成到快速交付，Docker 一度是不可或缺的技术基石。

然而到了 2025 年，越来越多开发者开始重新审视 Docker。

系统规模在不断膨胀，开发场景也更加多元，不再是当初以单一后端应用为主的架构。

如今，开发者面临的不只是如何部署一个服务，更要关注架构的可扩展性、容器的安全性、本地与云端的适配性，以及资源的最优利用。

在这种背景下，Docker 开始显得不再那么“全能”，它在部分场景下的臃肿、安全隐患和与 Kubernetes 的解耦问题，使得不少团队正在寻找更轻、更适合自身的替代方案。

之所以写下这篇文章就是为了帮助你认清 Docker 当前的局限，了解新的技术趋势，并发现适用于不同场景的下一代容器化工具。

二、Docker 的贡献与瓶颈

不可否认，Docker 曾是容器化革命的引擎。从过去到现在，它的最大价值在于降低了环境配置的复杂度，让开发与运维团队之间的协作更加顺畅，带动了整个容器生态的发展。

很多团队正是依赖 Docker 才实现了快速构建镜像、构建流水线、部署微服务的能力。

但与此同时，Docker 本身也逐渐显露出局限性。比如，它高度依赖守护进程，导致资源占用明显高于预期，启动速度也难以令人满意。

更关键的是，Docker 默认以 root 权限运行容器，极易放大潜在攻击面，在安全合规日益严格的今天，这一点令人担忧。Kubernetes 的官方运行时也已从 Docker 切换为 containerd 与 runc，表明行业主流已在悄然转向。

这并不意味着 Docker 已过时，它依旧在许多团队中扮演重要角色。但如果你期待更高的性能、更低的资源消耗和更强的安全隔离，那么，是时候拓宽视野了。

三、本地开发的难题与新解法

特别是在本地开发场景中，Docker 的“不够轻”问题尤为突出。为了启动一个简单的 PHP 或 Node 项目，很多人不得不拉起庞大的容器，等待镜像下载、构建，甚至调试端口映射，最终电脑风扇轰鸣，开发体验直线下降。

一些开发者试图回归传统，通过 Homebrew 或 apt 手动配置开发环境，但这又陷入了“版本冲突”“依赖错位”等老问题。

这时，ServBay 的出现带来了新的可能。作为专为本地开发设计的轻量级工具，ServBay 不依赖 Docker，也无需繁琐配置。用户只需一键启动，即可在本地运行 PHP、Python、Golang、Java 等多种语言环境，并能自由切换版本与服务组合。它不仅启动迅速，资源占用也极低，非常适合 WordPress、Laravel、ThinkPHP 等项目的本地调试与开发。

更重要的是，ServBay 不再强制开发者理解复杂的镜像构建与容器编排逻辑，而是将本地开发流程变得像打开编辑器一样自然。对于 Web 后端和全栈开发者来说，它提供了一种“摆脱 Docker”的全新路径。

四、当 Docker 不再是运行时的唯一选择

容器运行时的格局也在悄然生变。containerd 和 runc 成为了 Kubernetes 官方推荐的运行时，它们更轻、更专注，仅提供核心的容器管理功能，剥离了不必要的附加组件。与此同时，CRI-O 正在被越来越多团队采纳，它是专为 Kubernetes 打造的运行时，直接对接 CRI 接口，减少了依赖层级。

另一款备受好评的是 Podman，它的最大亮点在于支持 rootless 模式，使容器运行更加安全。同时，它的命令行几乎与 Docker 完全兼容，开发者几乎不需要重新学习。

对于安全隔离要求极高的场景，还可以选择 gVisor 或 Kata Containers。前者通过用户态内核方式拦截系统调用，构建沙箱化环境；后者则将轻量虚拟机与容器结合，兼顾性能与隔离性。这些方案正在逐步替代传统 Docker，成为新一代容器架构的基石。

五、容器编排：Kubernetes 之后的路在何方？

虽然 Kubernetes 仍然是企业级容器编排的标准选项，但它的复杂性和陡峭的学习曲线也让不少中小团队望而却步。一个简单的应用部署可能涉及上百行 YAML 文件，过度的抽象与组件拆分反而拉高了运维门槛。

这也促使“微型 Kubernetes”方案逐渐兴起。K3s 是其中的代表，它对 Kubernetes 进行了极大简化，专为边缘计算和资源受限场景优化。此外，像 KubeEdge 等项目，也在积极拓展容器编排在边缘设备上的适配能力。

与此同时，AI 驱动的编排平台正在探索新路径。CAST AI、Loft Labs 等团队推出的智能调度系统，可以自动分析工作负载并进行优化部署，最大化资源利用率。更进一步，Serverless 与容器的融合也逐渐成熟，比如 AWS Fargate、Google Cloud Run 等服务，让开发者无需再关心节点管理，容器真正变成了“即用即走”的计算单元。

六、未来趋势：容器走向“定制化生长”

未来的容器化，我们将看到更细化的技术选型：开发环境选择轻量灵活的本地容器，测试环境强调快速重建与自动化部署，生产环境则关注安全隔离与高可用性。

安全性也会成为核心关键词。rootless 容器、沙箱机制和系统调用过滤将成为主流实践，容器从“不可信”向“可信执行环境”演进。与此同时，人工智能将在容器调度中发挥更大作用，不仅提升弹性伸缩的效率，还可能引领“自愈系统”发展，让集群具备自我诊断与恢复能力。

容器标准如 OCI 的持续完善，将让不同运行时之间更加兼容，为整个生态的整合提供可能。而在部署端，我们也将看到容器由本地向云端、再向边缘设备的自然扩展，真正成为“无处不在的基础设施”。

七、结语：容器化的新纪元已经到来

Docker 的故事并没有结束，它依然是很多开发者最熟悉的工具，也在部分场景中继续发挥作用。但可以确定的是，它不再是唯一选择。2025 年的容器世界，早已迈入了多元化、场景化、智能化的阶段。从轻量级的 ServBay 到更安全的 Podman，从微型编排到 Serverless 混合模式，我们手中可选的工具越来越丰富，技术栈的自由度也空前提升。

下一个十年，容器不只是为了“装下服务”，它将成为构建现代基础设施的关键砖块。愿你也能在这场演进中，找到属于自己的工具组合，打造更轻、更快、更自由的开发与部署体验。

作者：程序员成长指北

原文：mp.weixin.qq.com/s/WuZlo_92q…

最近小组里的小伙伴，暂且叫小A吧，问了一个bug：

提示数据循环引用，相信不少小伙伴都遇到过类似问题，于是我问他：

我：你知道问题报错的点在哪儿吗

小A： 知道，就是下面这个代码，但不知道怎么解决。

onst a = {};

const b = { parent: a };

a.child = b; // 形成循环引用



try {

  const clone = JSON.parse(JSON.stringify(a));

} catch (error) {

  console.error('Error:', error.message); // 会报错：Converting circular structure to JSON

}

上面是我将小A的业务代码提炼为简单示例，方便阅读。

• 这里 a.child 指向 b，而 b.parent 又指回 a，形成了循环引用。


• 用 JSON.stringify 时会抛出 Converting circular structure to JSON 的错误。

我顺手查了一下小A项目里 JSON.parse(JSON.stringify()) 的使用情况：

一看有50多处都使用了， 使用频率相当高了。

我继续提问：

我：你有找解决方案吗?

小A: 我看网上说可以自己实现一个递归来解决，但是我不太会实现

于是我帮他实现了一版简单的递归深拷贝：

function deepClone(obj, hash = new Map()) {

if (typeof obj !== 'object' || obj === null) return obj;

if (hash.has(obj)) return hash.get(obj);



const clone = Array.isArray(obj) ? [] : {};

  hash.set(obj, clone);



for (const key in obj) {

    if (obj.hasOwnProperty(key)) {

      clone[key] = deepClone(obj[key], hash);

    }

  }

return clone;

}



// 测试

const a = {};

const b = { parent: a };

a.child = b;



const clone = deepClone(a);

console.log(clone.child.parent === clone); // true

此时,为了给他拓展一下，我顺势抛出新问题：

我： 你知道原生Web API 现在已经提供了一个深拷贝 API吗？

小A:？？？

于是我详细介绍了一下：

主角 structuredClone登场

structuredClone() 是浏览器原生提供的 深拷贝 API，可以完整复制几乎所有常见类型的数据，包括复杂的嵌套对象、数组、Map、Set、Date、正则表达式、甚至是循环引用。

它遵循的标准是：HTML Living Standard - Structured Clone Algorithm（结构化克隆算法）。

语法：

const clone = structuredClone(value);

一行代码，优雅地解决刚才的问题：

const a = {};

const b = { parent: a };

a.child = b; // 形成循环引用



const clone = structuredClone(a);



console.log(clone !== a); // true

console.log(clone.child !== b); // true

console.log(clone.child.parent === clone); // true，循环引用关系被保留

为什么增加 structuredClone？

在 structuredClone 出现之前，常用的深拷贝方法有：

structuredClone 是 原生、极速、支持更多数据类型且无需额外依赖 的现代解决方案。

支持的数据类型

❌ 不支持：

• 函数（Function）


• DOM 节点


• WeakMap、WeakSet

常见使用示例

1. 克隆普通对象

const obj = { a: 1, b: { c: 2 } };

const clone = structuredClone(obj);

console.log(clone);  // { a: 1, b: { c: 2 } }

console.log(clone !== obj); // true

2. 支持循环引用

const obj = { name: 'Tom' };

obj.self = obj;

const clone = structuredClone(obj);

console.log(clone.self === clone);  // true

3. 克隆 Map、Set、Date、RegExp

const complex = {

  map: new Map([["key", "value"]]),

  set: new Set([1, 2, 3]),

  date: new Date(),

  regex: /abc/gi

};

const clone = structuredClone(complex);

console.log(clone);

兼容性

提到新的API，肯定得考虑兼容性问题：

• Chrome 98+


• Firefox 94+


• Safari 15+


• Node.js 17+ (global.structuredClone)

如果需要兼容旧浏览器：

• 可以降级使用 lodash.cloneDeep


• 或使用 MessageChannel Hack

很多小伙伴一看到兼容性问题，可能心里就有些犹豫：

"新API虽然好，但旧浏览器怎么办？"

但技术的发展离不开新技术的应用和推广，只有更多人开始尝试并使用，才能让新API真正普及开来，最终成为主流。

建议：

如果你的项目运行在现代浏览器或 Node.js 环境，structuredClone 是目前最推荐的深拷贝方案。 Node.js 17+：可以直接使用 global.structuredClone。