一. 分模块设计与开发

分模块设计的核心是 “高内聚，低耦合”。

• 高内聚：一个模块只负责一个独立的、明确的职责（如：订单模块只处理所有订单相关业务）。模块内部的代码关联性非常强。


• 低耦合：模块与模块之间的依赖关系尽可能的简单和清晰。一个模块的变化，应该尽量减少对其他模块的影响。

通过Maven，我们可以轻松地实现这一思想。每个模块都是一个独立的Maven项目，它们通过父子工程和依赖管理有机地组织在一起。

以一个经典的电商平台为例，我们可以将其拆分为以下模块：

将pojo和utils模块分出去

)

在tilas-web-management中的pom.xml中引入pojo，utils模块

<dependency>

     <groupId>org.example</groupId>

     <artifactId>tlias-pojo</artifactId>

     <version>1.0-SNAPSHOT</version>

</dependency>

<dependency>

     <groupId>org.example</groupId>

     <artifactId>tlias-utils</artifactId>

     <version>1.0-SNAPSHOT</version>

</dependency>

分模块的好处

• 代码清晰，职责分明：每个开发人员可以专注于自己的模块，易于理解和维护。


• 并行开发，提升效率：多个模块可以由不同团队并行开发，只需约定好接口即可。


• 构建加速：Maven支持仅构建更改的模块及其依赖模块（使用 mvn -pl 命令），大大节省构建时间。


• 极高的复用性：像 core、dao 这样的模块，可以直接被其他新项目引用，避免重复造轮子。


• 便于单元测试：可以针对单个业务模块进行独立的、深入的测试。

二. 继承

2.1 继承配置

tlias-pojo、tlias-utils、tlias-web-management 中都引入了一个依赖 lombok 的依赖。我们在三个模块中分别配置了一次。

我们可以再创建一个父工程 tlias-parent ，然后让上述的三个模块 tlias-pojo、tlias-utils、tlias-web-management 都来继承这个父工程 。 然后再将各个模块中都共有的依赖，都提取到父工程 tlias-parent中进行配置，只要子工程继承了父工程，依赖它也会继承下来，这样就无需在各个子工程中进行配置了。

将tilas-parent中的pom.xml设置成pom打包方式

Maven打包方式：

• jar：普通模块打包，springboot项目基本都是jar包（内嵌tomcat运行）


• war：普通web程序打包，需要部署在外部的tomcat服务器中运行


• pom：父工程或聚合工程，该模块不写代码，仅进行依赖管理

<packaging>pom</packaging>

通过parent来配置父工程

<parent>

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

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

        <version>3.2.8</version>

        <!--   父工程的pom.xml的相对路径  如果不配置就直接从中央仓库调取    -->

        <relativePath/> <!-- lookup parent from repository -->

</parent>

子工程配置 通过relativePath配置父工程的路径

<parent>

        <groupId>org.example</groupId>

        <artifactId>tlias-parent</artifactId>

        <version>1.0-SNAPSHOT</version>

        <relativePath>../tilas-parent/pom.xml</relativePath>

</parent>

2.2 版本锁定

如果项目拆分的模块比较多，每一次更换版本，我们都得找到这个项目中的每一个模块，一个一个的更改。 很容易就会出现，遗漏掉一个模块，忘记更换版本的情况。

在maven中，可以在父工程的pom文件中通过 来统一管理依赖版本。

<!--统一管理依赖版本-->

<dependencyManagement>

    <dependencies>

       <!--JWT令牌-->

    		<dependency>

        		<groupId>io.jsonwebtoken</groupId>

        		<artifactId>jjwt</artifactId>

        		<version>0.9.1</version>

    		</dependency>

    		······

    </dependencies>

</dependencyManagement>

这样在子工程中就不需要进行version版本设置了

<dependencies>

    <!--JWT令牌-->

    <dependency>

        <groupId>io.jsonwebtoken</groupId>

        <artifactId>jjwt</artifactId>

    </dependency>

</dependencies>

注意！！！

• 在父工程中所配置的 dependencyManagement只能统一管理依赖版本，并不会将这个依赖直接引入进来。 这点和 dependencies 是不同的。


• 子工程要使用这个依赖，还是需要引入的，只是此时就无需指定 版本号了，父工程统一管理。变更依赖版本，只需在父工程中统一变更。

2.3 自定义属性

<properties>

    <lombok.version>1.18.34</lombok.version>

</properties>

通过${属性名}引用属性

<dependency>

    <groupId>org.projectlombok</groupId>

    <artifactId>lombok</artifactId>

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

</dependency>

三. 聚合

聚合（Aggregation） 和继承（Inheritance） 是Maven支持分模块设计的两个核心特性，它们目的不同，但又相辅相成。
简单来说，继承是为了统一管理，而聚合是为了统一构建。

在聚合工程中通过modules>module来配置聚合

<!-- 聚合其他模块 -->

<modules>

    <module>你要聚合的模块路径</module>

</modules>

四. 私服

私服是一种特殊的远程仓库，它代理并缓存了位于互联网的公共仓库（如MavenCentral），同时允许企业内部部署自己的私有构件（Jar包）。
你可以把它理解为一个 “架设在公司内网里的Maven中央仓库”。

项目版本说明：

• RELEASE(发布版本)：功能趋于稳定、当前更新停止，可以用于发行的版本，存储在私服中的RELEASE仓库中。


• SNAPSHOT(快照版本)：功能不稳定、尚处于开发中的版本，即快照版本，存储在私服的SNAPSHOT仓库中。

4.1 私服下载

下载Nexus私服 help.sonatype.com/en/download…

在D:\XXXXXXXX\bin目录下 cmd运行nexus /run nexus 显示这个就表示开启成功啦！

浏览器输入localhost:8081

私服仓库说明：

• RELEASE：存储自己开发的RELEASE发布版本的资源。


• SNAPSHOT：存储自己开发的SNAPSHOT发布版本的资源。


• Central：存储的是从中央仓库下载下来的依赖

4.2 资源上传与下载

设置私服的访问用户名/密码（在自己maven安装目录下的conf/settings.xml中的servers中配置）

<server>

    <id>maven-releases</id>

    <username>admin</username>

    <password>admin</password>

</server>

    

<server>

    <id>maven-snapshots</id>

    <username>admin</username>

    <password>admin</password>

</server>

设置私服依赖下载的仓库组地址（在自己maven安装目录下的conf/settings.xml中的mirrors中配置）

<mirror>

    <id>maven-public</id>

    <mirrorOf>*</mirrorOf>

    <url>http://localhost:8081/repository/maven-public/</url>

</mirror>

设置私服依赖下载的仓库组地址（在自己maven安装目录下的conf/settings.xml中的profiles中配置）

<profile>

    <id>allow-snapshots</id>

    <activation>

        <activeByDefault>true</activeByDefault>

    </activation>

    <repositories>

        <repository>

            <id>maven-public</id>

            <url>http://localhost:8081/repository/maven-public/</url>

            <releases>

                <enabled>true</enabled>

            </releases>

            <snapshots>

                <enabled>true</enabled>

            </snapshots>

        </repository>

    </repositories>

</profile>

IDEA的maven工程的pom文件中配置上传（发布）地址(直接在tlias-parent中配置发布地址)

<distributionManagement>

    <!-- release版本的发布地址 -->

    <repository>

        <id>maven-releases</id>

        <url>http://localhost:8081/repository/maven-releases/</url>

    </repository>

    <!-- snapshot版本的发布地址 -->

    <snapshotRepository>

        <id>maven-snapshots</id>

        <url>http://localhost:8081/repository/maven-snapshots/</url>

    </snapshotRepository>

</distributionManagement>

打开maven控制面板双击deploy

由于当前我们的项目是SNAPSHOT版本，所以jar包是上传到了snapshot仓库中

整条链路里，我们到底需要几个对象？

三、从数据库开始：PO

PO是Persistent Object的简写 PO 就是“一行数据一个对象”，字段名、类型和数据库保持一一对应，不改表就不改它。

// 表：t_order

@Data

@TableName("t_order")

public class OrderPO {

    private Long id;          // 主键

    private Long userId;      // 用户ID

    private Long productId;   // 商品ID

    private String sku;       // 规格JSON

    private BigDecimal price; // 原价

    private BigDecimal payAmount; // 实付

    private Integer status;   // 订单状态

    private LocalDateTime createTime;

    private LocalDateTime updateTime;

}

注意：PO 里绝不能出现业务方法，它只是一个“数据库搬运工”。

四、核心业务：DO

DO 是“有血有肉的对象”，它把业务规则写成方法，让代码自己说话。

// 领域对象：订单

public class OrderDO {



    private Long id;

    private UserDO user;      // 聚合根

    private MilkTeaDO milkTea; // 商品

    private SpecDO spec;      // 规格

    private Money price;      // Money是值对象，防精度丢失

    private OrderStatus status;



    // 业务方法：计算最终价格

    public Money calcFinalPrice() {

        // 会员折扣

        Money discount = user.getVipDiscount();

        // 商品促销

        Money promotion = milkTea.getPromotion(spec);

        return price.minus(discount).minus(promotion);

    }



    // 业务方法：下单前置校验

    public void checkBeforeCreate() {

        if (!milkTea.hasStock(spec)) {

            throw new BizException("库存不足");

        }

    }

}

DO 可以引用别的 DO，形成聚合根。它不关心数据库，也不关心网络。

五、面向用例：BO

BO 是“场景大管家”，把多个 DO 攒成一个用例，常出现在 Service 层。

@Service

public class OrderBO {



    @Resource

    private OrderRepository orderRepository; // 操作PO

    @Resource

    private InventoryService inventoryService; // RPC或本地

    @Resource

    private PaymentService paymentService;



    // 用例：下单

    @Transactional

    public OrderDTO createOrder(CreateOrderDTO cmd) {



        // 1. 构建DO

        OrderDO order = OrderAssembler.toDO(cmd);



        // 2. 执行业务校验

        order.checkBeforeCreate();



        // 3. 聚合逻辑：扣库存、算价格

        inventoryService.lock(order.getSpec());

        Money payAmount = order.calcFinalPrice();



        // 4. 落库

        OrderPO po = OrderAssembler.toPO(order, payAmount);

        orderRepository.save(po);



        // 5. 返回给前端需要的数据

        return OrderAssembler.toDTO(po);

    }

}

BO 的核心是编排，它把 DO、外部服务、PO 串成一个完整的业务动作。

六、跨进程/服务：DTO

DTO 是“网络快递员”，字段被压缩成最少，只带对方需要的数据。

1）入口 DTO：前端 → 后端

@Data

public class CreateOrderDTO {

    @NotNull

    private Long userId;

    @NotNull

    private Long productId;

    @Valid

    private SpecDTO spec; // 规格

}

2）出口 DTO：后端 → 前端

@Data

public class OrderDTO {

    private Long orderId;

    private String productName;

    private BigDecimal payAmount;

    private String statusDesc;

    private LocalDateTime createTime;

}

DTO 的字段命名常带 UI 友好词汇（如 statusDesc），并且绝不暴露敏感字段（如 userId 在返回给前端时可直接省略）。

七、最后一步：VO

VO 是“前端专属快递”，字段可能二次加工，甚至带 HTML 片段。

@Data

public class OrderVO {

    private String orderId; // 用字符串避免 JS long 精度丢失

    private String productImage; // 带 CDN 前缀

    private String priceText; // 已格式化为“￥18.00”

    private String statusTag; // 带颜色：green/red

}

VO 通常由前端同学自己写 TypeScript/Java 类，后端只负责给 DTO，再让前端 BFF 层转 VO。如果你用 Node 中间层或 Serverless，VO 就出现在那儿。

八、一张图记住流转过程

前端页面

   │ JSON

   ▼

CreateOrderVO (前端 TS)

   │ 序列化

   ▼

CreateOrderDTO (后端入口)

   │ BO.createOrder()

   ▼

OrderDO (充血领域模型)

   │ 聚合、计算

   ▼

OrderPO (落库)

   │ MyBatis

   ▼

数据库

返回时反向走一遍：

数据库

   │ SELECT

OrderPO

   │ 转换

OrderDTO

   │ JSON

OrderVO (前端 TS 渲染)

九、常见疑问答疑

0. 为什么 DO 和 PO 不合并？ 数据库加索引、加字段不影响业务；业务改规则不改表结构。隔离变化。
1. DTO 和 VO 能合并吗？ 小项目可以，但一上微服务或多端（App、小程序、管理后台），立马爆炸。比如后台需要用户手机号，App 不需要，合并后前端会拿到不该看的数据。
2. BO 和 Service 有什么区别？ BO 更贴近用例，粒度更粗。Service 可能细分读写、缓存等。命名随意，关键看团队约定。

十、一句话背下来

数据库里叫 PO，业务里是 DO，编排靠 BO，网络走 DTO，前端看 VO。

下次面试官再问，你就把奶茶故事讲给他听，保证他频频点头。

本期内容到这儿就结束了

我是晓凡，再小的帆也能远航

我们下期再见 ヾ(•ω•`)o (●'◡'●)

🧠 本节谈

我们聚焦真实业务模块中的 Code Review，涵盖：

• 🔐 表单校验逻辑


• 🧩 动态权限控制


• 🧱 页面逻辑复杂度管理


• ⚠️ 接口调用规范


• ♻️ 组件解耦重构


• 🧪 单元测试提示

每一条都配备真实反面代码 + 改进建议 + 原因说明，并总结通用审核 checklist。

📍 场景 1：复杂表单校验逻辑

❌ 错误示例：耦合 + 不可维护

const onSubmit = () => {

  if (!form.name || form.name.length < 3 || !form.age || isNaN(form.age)) {

    message.error('请填写正确信息')

    return

  }

  // ...

}

问题：

• 所有校验写死在事件里，不可复用


• 无法做提示区分

✅ 改进方式：抽离校验 + 可扩展

const validateForm = (form: UserForm) => {

  if (!form.name) return '姓名不能为空'

  if (form.name.length < 3) return '姓名过短'

  if (!form.age || isNaN(Number(form.age))) return '年龄格式错误'

  return ''

}



const onSubmit = () => {

  const msg = validateForm(form)

  if (msg) return message.error(msg)

  // ...

}

👉 Review 要点：

• 校验逻辑是否可复用？


• 是否便于单测？


• 提示是否明确？

📍 场景 2：权限控制逻辑写死

❌ 反例

<Button v-if="user.role === 'admin'">删除</Button>

问题：

• 无法集中管理


• 用户身份切换时易出错


• 无法与服务端权限匹配

✅ 推荐：

const hasPermission = (perm: string) => user.permissions.includes(perm)

<Button v-if="hasPermission('can_delete')">删除</Button>

👉 Review 要点：

• 权限是否统一处理？


• 是否可扩展到路由、接口层？


• 是否易于调试？

📍 场景 3：复杂页面组件未解耦

❌ 嵌套组件塞一堆逻辑

// 页面结构

<Table data={data}>

  {data.map(row => (

    <tr>

      <td>{row.name}</td>

      <td>

        <Button onClick={() => doSomething(row.id)}>操作</Button>

      </td>

    </tr>

  ))}

</Table>

• 所有数据/逻辑/视图耦合一起


• 无法复用


• 改动难以测试

✅ 推荐：

<TableRow :row="row" @action="handleRowAction" />

// TableRow.vue

<template>

  <tr>

    <td>{{ row.name }}</td>

    <td><Button @click="emit('action', row.id)">操作</Button></td>

  </tr>

</template>

👉 Review 要点：

• 是否具备清晰的“数据流 → 逻辑流 → 视图层”结构？


• 是否把组件职责划分清楚？


• 是否拆分足够颗粒度便于测试？

📍 场景 4：接口调用未封装

❌ 直接 axios 写在组件中：

axios.get('/api/list?id=' + id).then(res => {

  this.list = res.data

})

问题：

• 接口不可复用


• 无法集中处理错误


• 改动接口时无法追踪引用

✅ 推荐：

// services/user.ts

export const getUserList = (id: number) =>

  request.get('/api/list', { params: { id } })



// 页面中

getUserList(id).then(res => (this.list = res.data))

👉 Review 要点：

• 是否将接口层抽离为服务？


• 是否统一请求拦截、错误处理？


• 是否易于 Mock 和调试？

📍 场景 5：测试个锤子🔨

❌ 错误写法：组件中逻辑混杂难以测试

if (user.age > 18 && user.vipLevel > 3 && user.region === 'CN') {

  return true

}

问题：

• 没有语义抽象


• 不可测试

✅ 改进写法：

const isPremiumUser = (user: User) =>

  user.age > 18 && user.vipLevel > 3 && user.region === 'CN'

👉 Review 要点：

• 是否具备良好的可测试性？


• 是否便于 Jest/Vitest 测试用例编写？

✅ 最佳实践总结

Review 高级 Checklist

🎯 尾声：从 Code Review 走向“架构推动者”

掌握 Code Review 不止是“找错”，而是：

• 帮助他人提升思维方式


• 用标准统一团队技术认知


• 用习惯推动系统演进

• Nginx特点


• 
  
  
  
  • 正向代理与反向代理
  
  
  • 负载均衡
  
  
  • 动静分离
  
  
  
  


• Nginx的优势


• 
  
  
  
  • 可操作性大
  
  
  • 网络依赖小
  
  
  • 安装简单
  
  
  • 支持健康检查以及请求重发
  
  
  
  


• LVS 的优势


• 
  
  
  
  • 抗负载能力强
  
  
  • 配置性低
  
  
  • 工作稳定
  
  
  • 无流量
  
  
  
  

今天总结一下负载均衡中LVS与Nginx的区别,好几篇博文一开始就说LVS是单向的,Nginx是双向的,我个人认为这是不准确的,LVS三种模式中,虽然DR模式以及TUN模式只有请求的报文经过Director,但是NAT模式,Real Server回复的报文也会经过Director Server地址重写:

图片

首先要清楚的一点是,LVS是一个四层的负载均衡器,虽然是四层,但并没有TCP握手以及分手,只是偷窥了IP等信息,而Nginx是一个七层的负载均衡器,所以效率势必比四层的LVS低很多,但是可操作性比LVS高,后面所有的讨论都是基于这个区别。

为什么四册比七层效率高?

四层是TCP层，使用IP+端口四元组的方式。只是修改下IP地址，然后转发给后端服务器，TCP三次握手是直接和后端连接的。只不过在后端机器上看到的都是与代理机的IP的established而已,LVS中没有握手。

7层代理则必须要先和代理机三次握手后，才能得到7层（HTT层）的具体内容，然后再转发。意思就是代理机必须要与client和后端的机器都要建立连接。显然性能不行，但胜在于七层，人工可操作性高,能写更多的转发规则。

Nginx特点

Nginx 专为性能优化而开发，性能是其最重要的要求，十分注重效率，有报告 Nginx 能支持高达 50000 个并发连接数。

另外，Nginx 系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。

正向代理与反向代理

正向代理 ：局域网中的电脑用户想要直接访问服务器是不可行的，服务器可能Hold不住,只能通过代理服务器来访问，这种代理服务就被称为正向代理,特点是客户端知道自己访问的是代理服务器。

图片

反向代理 ：客户端无法感知代理，因为客户端访问网络不需要配置，只要把请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据，然后再返回到客户端。

此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器 IP 地址。

图片

负载均衡

客户端发送多个请求到服务器，服务器处理请求，有一些可能要与数据库进行交互，服务器处理完毕之后，再将结果返回给客户端。

普通请求和响应过程如下图：

图片

但是随着信息数量增长，访问量和数据量增长，单台的Server以及Database就成了系统的瓶颈,这种架构无法满足日益增长的需求,这时候要么提升单机的性能,要么增加服务器的数量。

关于提升性能,这儿就不赘述,提提如何增加服务器的数量，构建集群，将请求分发到各个服务器上，将原来请求集中到单个服务器的情况改为请求分发到多个服务器，也就是我们说的负载均衡。

图解负载均衡：

图片

关于服务器如何拆分组建集群,这儿主要讲讲负载均衡,也就是图上的Proxy,可以是LVS,也可以是Nginx。假设有 15 个请求发送到代理服务器，那么由代理服务器根据服务器数量，这儿假如是平均分配，那么每个服务器处理 5 个请求，这个过程就叫做负载均衡。

动静分离

为了加快网站的解析速度，可以把动态页面和静态页面交给不同的服务器来解析，加快解析的速度，降低由单个服务器的压力。

动静分离之前的状态

图片

动静分离之后

图片

光看两张图可能有人不理解这样做的意义是什么,我们在进行数据请求时,以淘宝购物为例,商品详情页有很多东西是动态的,随着登录人员的不同而改变,例如用户ID,用户头像,但是有些内容是静态的,例如商品详情页,那么我们可以通过CDN(全局负载均衡与CDN内容分发)将静态资源部署在用户较近的服务器中,用户数据信息安全性要更高,可以放在某处集中,这样相对于将说有数据放在一起,能分担主服务器的压力,也能加速商品详情页等内容传输速度。

Nginx的优势

可操作性大

Nginx是一个应用层的程序,所以用户可操作性的空间大得多,可以作为网页静态服务器，支持 Rewrite 重写规则；支持 GZIP 压缩，节省带宽；可以做缓存；可以针对 http 应用本身来做分流策略，静态分离，针对域名、目录结构等相比之下 LVS 并不具备这样的功能，所以 nginx 单凭这点可以利用的场合就远多于 LVS 了；但 nginx 有用的这些功能使其可调整度要高于 LVS，所以经常要去触碰，人为出现问题的几率也就大

网络依赖小

nginx 对网络的依赖较小，理论上只要 ping 得通，网页访问正常，nginx 就能连得通，nginx 同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；LVS 就比较依赖于网络环境，目前来看服务器在同一网段内并且 LVS 使用 direct 方式分流，效果较能得到保证。另外注意，LVS 需要向托管商至少申请多于一个 ip 来做 visual ip

安装简单

nginx 安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS 的安装和配置、测试就要花比较长的时间，因为同上所述，LVS 对网络依赖性比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦的多

nginx 也同样能承受很高负载且稳定，但负载度和稳定度差 LVS 还有几个等级：nginx 处理所有流量所以受限于机器 IO 和配置；本身的 bug 也还是难以避免的；nginx 没有现成的双机热备方案，所以跑在单机上还是风险比较大，单机上的事情全都很难说

支持健康检查以及请求重发

nginx 可以检测到服务器内部的故障（健康检查），比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前 LVS 中 ldirectd 也能支持针对服务器内部的情况来监控，但 LVS 的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，nginx 会把上传切到另一台服务器重新处理，而 LVS 就直接断掉了。

LVS 的优势

抗负载能力强

因为 LVS 工作方式的逻辑是非常简单的，而且工作在网络的第 4 层，仅作请求分发用，没有流量，所以在效率上基本不需要太过考虑。LVS 一般很少出现故障，即使出现故障一般也是其他地方（如内存、CPU 等）出现问题导致 LVS 出现问题

配置性低

这通常是一大劣势同时也是一大优势，因为没有太多的可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率

工作稳定

因为其本身抗负载能力很强，所以稳定性高也是顺理成章的事，另外各种 LVS 都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，LVS 会自动判别，所以系统整体是非常稳定的

无流量

LVS 仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的 IO 性能不会受到大流量的影响

LVS 基本上能支持所有应用，因为 LVS 工作在第 4 层，所以它可以对几乎所有应用做负载均衡，包括 http、数据库、聊天室等。

在日常开发中，经常会遇到这样的场景：

需要在 大小写不敏感 或 格式化字段 的情况下进行表关联。

如果在 JOIN 或 WHERE 中直接使用函数，往往会带来严重的性能问题。

本文用一个新的示例来说明问题和优化方法。

一、问题场景

假设我们有两张表：

• 用户表 user_info
  
  

  user_id   | username
  
  ----------+------------
  
  1         | Alice
  
  2         | Bob
  
  3         | Charlie
  
  

  
  


• 订单表 order_info
  
  

  order_id  | buyer_name
  
  ----------+------------
  
  1001      | alice
  
  1002      | BOB
  
  1003      | dave
  
  

  
  

我们希望根据用户名和买家名称进行关联（忽略大小写）。

原始写法（低效）

SELECT o.order_id, u.user_id, u.username

FROM order_info o

LEFT JOIN user_info u

    ON LOWER(o.buyer_name) = LOWER(u.username);

问题：

• LOWER() 包裹了字段，导致数据库无法使用索引。


• 每一行都要执行函数运算，性能下降。

二、优化方法

1. 子查询提前计算

通过子查询生成派生列，再进行关联。

SELECT o.order_id, u.user_id, u.username

FROM (

    SELECT order_id, buyer_name, LOWER(buyer_name) AS buyer_name_lower

    FROM order_info

) o

LEFT JOIN (

    SELECT user_id, username, LOWER(username) AS username_lower

    FROM user_info

) u

    ON o.buyer_name_lower = u.username_lower;

优点：

• 避免在 JOIN 时重复调用函数。


• 优化器有机会物化子查询并建立临时索引。

2. 建立函数索引（推荐）

如果这种需求非常频繁，可以在表上建立函数索引。

PostgreSQL 示例：

CREATE INDEX idx_username_lower ON user_info(LOWER(username));

CREATE INDEX idx_buyer_name_lower ON order_info(LOWER(buyer_name));

之后即使写：

SELECT ...

FROM order_info o

LEFT JOIN user_info u

    ON LOWER(o.buyer_name) = LOWER(u.username);

数据库也能走索引，性能大幅提升。

3. 数据入库时统一格式

如果业务允许，可以在入库时统一转为小写，避免查询时做转换。

INSERT INTO user_info (user_id, username)

VALUES (1, LOWER('Alice'));

这样关联时直接比较即可：

ON o.buyer_name = u.username

三、总结

• 在 JOIN 或 WHERE 中直接使用函数，会 导致索引失效，影响性能。


• 优化方法：
  
  
  
  
  1. 子查询提前计算，避免在关联时重复调用函数；
  
  
  2. 建立函数索引（或虚拟列索引）；
  
  
  3. 入库时统一数据格式，彻底消除函数依赖。
  
  
  
  

📌 记忆要点：

• 函数写在 JOIN → 慢


• 子查询提前算 → 好


• 函数索引 / 数据规范化 → 最优解

转眼间已经是 2025 年的 Q4 了，年终越来越近，领导给予的 okr 压力越来越大，前段时间，领导提出了一个非常搞的想法，当然也是急需解决的痛点——线上一键翻译功能。

小包当前负责是开发开发面向全球各国的活动，因此活动中不免就会出现各种各样的语言，此时就出现了一个困扰已久的难题，线上体验的同学看不懂，体验过程重重受阻，很容易遗漏掉一些环节，导致一些问题很难暴露出来。

为了这个问题，小包跟进了一段时间了，主要有两个地方的文案来源

• 代码渲染的文本


• 切图中的静态文本

大多数文本来源于是切图中，因此如何应对各种各样的切图成为难题。由此小包提出了两种解决方案：

第一种方案被直接拒绝了，主要由于当前的技术架构和同事们的一些抵触，业务中使用的 img、txt 信息都存储在配置平台中，存储两份就需要维护两类配置，严重增加了心智负担。

那我是这么思考的，第一次上传图片资源时，自动进行图片翻译，存储在另一个配置字段中，当开启一键翻译功能后，切换翻译后的图片。

由于是内部使用的工具，因此不需要非常准确，为了节省 token，只在第一次进行翻译。

图片翻译需要两个过程，首先进行 OCR，识别出图片中的文字；其次对识别出的文字进行翻译。

尝试了好几款 OCR 工具，都有些不尽人意，整个过程中，体验最好的是上个月PaddleOCR推出的PP-OCRv5。

在一段时间内，都一直盯着 PaddleOCR 的最新进度，昨天，百度发布并开源自研多模态文档解析模型 PaddleOCR-VL，该模型在最新 OmniDocBench V1.5 榜单中，综合性能全球第一，四项核心能力SOTA，模型已登顶HF全球第一。

这么说我的 OKR 有救了啊，快马加鞭的来试一下。

对于线上翻译，有两种指标是必须要达到的

• 文字区域识别的准确性


• 支持语言的多样性

下面逐一地体验一下

OKR 需求测试

先随便找了一张较为简单的韩服的设计稿，识别效果见右图，识别的区域非常准确，精准的区分开文字区域和图像区域。

右侧有三个 tab，其中第一个 tab：Markdown Preview 预览还支持翻译功能，翻译的文案也是非常准确的

激动了啊，感觉 PaddleOCR-VL 自己就可以解决当前的需求啊。

再换一种比较复杂的语言，阿拉伯语。支持效果也是出奇的好啊，阿语活动开发过程和体验过程是最难受的啊，目前也是最严重的卡点

对于阿语的翻译的效果也非常好，这点太惊喜了，阿服的字体又细又长，字间距又窄，能做到这么好的识别真是让人惊艳

经过一番简单的测试，PaddleOCR-VL 完全可以应对领导的 OKR 要求了（毕竟天下第一难语言阿服都可以较为完美的应对，撒花），爽啊！只需要把 demo 跑出来，就可以去申请经费啦。

更多测试

作为一个程序员，除了要干好本职的工作，更要积极的探索啊，多来几个场景，倒要看看 PaddleOCR VL 能做到什么程度。

糊图识别

日常中经常有这种需求，领导给了一张扫描了一万次或者扫描的一点都不清楚的图片，阅读难度甚大，那时候就想能不能有一种方案直接把内容提取出来。

例如就像下面的糊糊的作文，连划去的内容都成功提取出来了，牛

元素级识别

PaddleOCR-VL 除了文档解析能力，还提供了元素级识别能力，例如公式识别、表格内容识别等，诸如此类都是图片识别中的超难点。

先来个简单公式试一下

效果这么好的吗，全对了，那就要上难度了啊

黑板中的公式繁杂，混乱，且是手写体，没想到识别的整体内容都是非常准确的，只有最后一个公式错误的乘在一起了，效果有些令人惊叹啊。

总结

PaddleOCR-VL 效果真是非常惊艳啊，年底的 okr 实现的信心大增。

PaddleOCR-VL 文字识别感觉像戴了高精度眼镜一般，后续遇到类似的文字识别需求，可以首选 PaddleOCR-VL 啊。

此外小小看了一下论文，PaddleOCR-VL 采用创新的两阶段架构：第一阶段由 PP-DocLayoutV2 模型负责版面检测与阅读顺序预测；第二阶段由 PaddleOCR-VL-0.9B 识别并结构化输出文字、表格、公式、图表等元素。相较端到端方案，能够在复杂版面中更稳定、更高效，有效避免多模态模型常见的幻觉与错位问题。

PaddleOCR-VL在性能、成本和落地性上实现最佳平衡，具备强实用价值。后续遇到文字识别的需求，PaddleOCR-VL 是当之无愧的首选。

体验链接：

• Github：github.com/PaddlePaddl…


• huggingface：huggingface.co/PaddlePaddl…


• Technical report：arxiv.org/pdf/2510.14…


• Technical Blog：
  
  
  
  • English: ernie.baidu.com/blog/posts/…
  
  
  • Chinese: ernie.baidu.com/blog/zh/pos…
  
  
  
  

今天早上（2025.10.17），知乎突然出现疑似大规模服务故障，导致多数用户无法访问，“知乎崩了”瞬间登上热搜榜。

一．当前故障表现为：

1.全平台功能异常：

• 网页端： 无法进入，显示 525 错误（服务器配置错误）。


• App 端： 首页可显示，但点击任何问题或回答均无法加载详情，部分用户还出现反复登出、匿名状态异常等。

2.技术特征分析：

• 故障表现似乎为核心数据接口响应失败，与 2023 年 4 月，2025 年 7 月的情况高度吻合，推测是中心化服务器集群在高压并发下的处理能力不足。


• 有部分用户提到 App 内出现 503 错误（服务不可用），这通常与服务器过载或后端服务中断有关。

二．网站崩溃可能造成的损失：

网站监控是保障业务稳定和用户体验的核心环节，其本质是提前发现问题、减少损失，做到“防患于未然”，避免因网站问题导致用户流失或业务损失。

根据最新的行业报告以及权威研究机构分析：

1.直接财务损失：

Gartner 指出

• 金融行业每分钟停机成本可达15 万美元。


• 电商与零售业每分钟停机成本可达 1 万美元。


• 制造业停产每分钟损失可达4 万美元。

2.隐形、持久损失：

• 客户信任与品牌声誉受损：一次严重的停机时间可能导致客户的永久丢失。负面舆情传播极快，会造成潜在客户“望而却步”


• 市场竞争力下降：竞争对手可能趁机抢占市场份额的事情屡见不鲜。像之前某旅游平台因预订系统故障，导致客户转而通过竞品平台下单；某打车软件长时间瘫痪，竞争对手趁机发布平台优惠福利，司机和乘客大面积流失，后通过超过半年的时间才恢复。


• 合规风险与法律责任：金融、医疗等受到严格监管的行业可能面临高额罚款、内部追责、未履行 SLA 造成的法律纠纷或赔偿等。

三．网站监控为什么重要？

1.通过Applications Manager监控网站

Applications Manager 是一款企业级应用性能监控（APM）与可观测性解决方案，能够监控到业务系统各个组成部分，支持 150 + 技术栈，覆盖 Java/.NET/Node.js 等应用服务器、Oracle/MySQL/MongoDB 等数据库、AWS/Azure/GCP 等云平台，以及 Kubernetes/Docker 容器环境。通过无侵入式字节码注入技术，实现从代码级到基础设施层的端到端性能追踪，精准定位慢事务、SQL 查询和线程瓶颈。

对于网站监控，通过卓豪 APM 能够实现：

2.网站可用性监控：

l HTTP 配置检查：

支持 POST/GET 方式。可以设置基于状态码的阈值告警。例如设置>200都作为告警触发，比如这次知乎响应状态码为 525，平台会立刻发出可用性 down 的告警；支持验证以及添加请求参数（可选）等。

l 内容检查：

在HTTP 配置检查均正常时，可以通过网站内容检查来识别“假运行”状态。支持正则表达式

3.应用性能监控：

URL监控能够监控网站上重要URL的可用性和性能，无论它们是在互联网上还是内部网上。这通过监控单个URL的响应时间来确保网站的顺利运行，在网站的页面加载时间出现任何延迟时提供即时通知。在URL序列监控的帮助下，可以模拟在线访问者通常访问的URL的序列，并分析它们以识别和解决任何潜在问题。

4.网站证书监控：

不断检查网站的SSL/TLS证书状态，以确保网站访问者的真实性、安全性和可靠性。如果网站证书接近到期日，会立即收到通知，以便采取必要措施按时续订。除此之外还可以查看SSL/TLS证书的域名、组织和组织单位等信息，以供快速参考。

5.真实用户访问监控：

真实用户监控（RUM）能够通过实时见解增强网站的数字最终用户体验。它根据实际流量，从全球不同地点全天候监控网站的前端性能，跟踪关键指标，并提供有关真实用户如何与网站互动的深入见解。它根据浏览器、设备、ISP、地理等参数提供有关网站性能的详细信息。可以查看前端、后端和网络响应时间，还可以深入了解网络事务、用户会话、AJAX调用、Javascript错误等。

结语：

除了网站监控之外，APM还可以对业务系统从服务器/操作系统到中间件、数据库等各个组成部分的应用性能监控，保障业务正常运行，避免故障停机导致的损失。从基础架构到前端响应，立即发现、及时预警，保障用户访问网站畅通无阻！

一、前言

在Lambda表达式没有出现之前，很多功能的实现需要写冗长的匿名类，这样的代码不仅难以维护，还让人难以理解，用 Lambda 表达式后，代码变得更加简洁，易于维护。今天我们就来聊聊Lambda表达式的一些使用。

二、Lambda表达式的使用

我们之前的编程习惯是利用匿名类去实现一些接口的行为，比如线程的执行，然而，这种写法会导致代码膨胀和冗长，我们先来看看传统的写法：

public static void main(String[] args) {

    Thread thread = new Thread(new Runnable() {

        @Override

        public void run() {

            System.out.println("hello world");

        }

    });

    thread.start();

}

其实上面那段代码是非常冗长的，我们直接来对比一下Lambda表达式的写法就知道了：

    public static void main(String[] args) {

        //使用Lambda表达式

        Thread thread = new Thread(() -> System.out.println("hello world"));

        thread.start();

    }

简洁明了，只用一行简洁的代码，我们就完成了线程的创建和启动。我们来看一下Lambda表达式的标准格式：

(parameters) -> expression

说明：

• (parameters) 是传递给 Lambda 表达式的参数，可以是零个或多个。例如，在我们上面的例子中传递的是 () ->，表示没有参数。


• -> 是箭头操作符，表示 Lambda 表达式的开始，指向 Lambda 体。


• expression 是 Lambda 表达式的主体，也就是我们要执行的代码。

使用前提

上文中提到，lambda表达式可以在⼀定程度上简化接口的实现。但是，并不是所有的接口都可以使用lambda表达式来简化接口的实现的。

先说结论，lambda表达式，只能实现函数式接口。lambda表达式毕竟只是⼀个匿名方法。

什么是函数式接口？

函数式接口在 Java 中是指： 有且仅有一个抽象方法的接口 。
函数式接口，即适用于函数式编程场景的接口。而 Java 中的函数式编程体现就是Lambda，所以函数式接口就是可以适用于Lambda使用的接口。只有确保接口中有且仅有一个抽象方法，Java中的 Lambda才能顺利地进行推导。

Java 8 中专门为函数式接口引入了一个新的注解：@FunctionalInterface。一旦使用该注解来定义接口，编译器将会强制检查该接口是否确实有且仅有一个抽象方法，否则将会报错。需要注意的是，即使不使用该注解，只要满足函数式接口的定义，这仍然是一个函数式接口。以下为示例代码：

@FunctionalInterface

public interface TestFunctionalInterface {

    void testMethod();

}

语法简化

1.参数类型简化：由于在接口的方法中，已经定义了每⼀个参数的类型是什么。而且在使用lambda表达式实现接口的时候，必须要保证参数的数量和类 型需要和接口中的方法保持⼀致。因此，此时lambda表达式中的参数的类型可以省略不写。例子：

Test test = (name,age)  -> {

    System.out.println(name+" "+age);

};

2.参数小括号简化：如果方法的参数列表中的参数数量 有且只有⼀个，此时，参数列表的小括号是可以省略不写的。例子：

Test test = name -> {

    System.out.println(name);

};

3.方法体部分的简化：当⼀个方法体中的逻辑，有且只有⼀句的情况下，大括号可以省略。例子：

Test test = name -> System.out.println(name);

4.return部分的简化：如果⼀个方法中唯⼀的⼀条语句是⼀个返回语句， 此时在省略掉大括号的同时， 也必须省略掉return。例子：

Test test = (a,b) -> a+b;

三、总结

本文从Lambda表达式的基础概念、基本使用几方面完整的讨论了这一Java8新增的特性，实际开发中确实为我们提供了许多便利，简化了代码。

在上一章 过滤器策略 (FilterPolicy) 中，我们学习了 LevelDB 如何利用布隆过滤器这样的巧妙设计，在访问磁盘前就过滤掉大量不存在的键查询，从而避免了无谓的 I/O 操作。

至此，我们已经探索了 LevelDB 从用户接口到底层数据结构，再到性能优化的几乎所有核心组件。但我们忽略了一个最基础的问题：LevelDB 是一个 C++ 库，它需要运行在真实的操作系统上。它是如何在不同的操作系统（如 Linux, Windows, macOS）上读写文件、创建线程、获取当前时间的呢？难道 LevelDB 的核心代码里充斥着大量的 #ifdef __linux__ 和 #ifdef _WIN32 这样的条件编译指令吗？

如果真是这样，代码将会变得难以维护，移植到新平台也会是一场噩梦。为了优雅地解决这个问题，LevelDB 引入了它的基石——环境（Env）。

什么是环境 (Env)？

Env 是对操作系统底层功能的一个抽象层。你可以把它想象成一个万能工具箱。LevelDB 的核心逻辑（比如 合并 (Compaction) 线程、排序字符串表 (SSTable) 的读写）在工作时，并不直接调用操作系统的原生函数（如 open, read, CreateFileW），而是从这个标准的“工具箱”里取工具来用。

这个工具箱里有什么呢？它定义了一套标准的工具接口：

• NewWritableFile(...): 给我一把能写文件的“扳手”。


• StartThread(...): 给我一个能启动新线程的“马达”。


• NowMicros(): 给我一个能读取当前微秒时间的“秒表”。


• SleepForMicroseconds(...): 让我休息一下的“闹钟”。

有了这个标准的工具箱接口，LevelDB 的核心逻辑就可以完全不关心自己到底运行在哪个操作系统上。它只管向 Env 索要工具。

那么，具体的工具是从哪里来的呢？LevelDB 为每个它支持的平台，都提供了一个具体的工具箱实现。

• 在 Linux/macOS (POSIX) 上，它提供一个 PosixEnv。这个工具箱里的“扳手”是用 open() 和 write() 实现的。


• 在 Windows 上，它提供一个 WindowsEnv。这个工具箱里的“扳手”则是用 CreateFileA() 和 WriteFile() 实现的。

这种设计带来了巨大的好处：可移植性。当需要将 LevelDB 移植到一个新的操作系统（比如 Fuchsia）时，开发者几乎不需要修改任何核心逻辑代码。他们只需要为新平台实现一个新的 Env 子类——也就是打造一个新的、符合标准的工具箱——然后整个 LevelDB 就可以在这个新平台上运行了。

graph BT

    subgraph "具体的平台实现"

        C["PosixEnv (Linux, macOS)"]

        D["WindowsEnv (Windows)"]

        E["MemEnv (用于测试)"]

    end

    

    subgraph "LevelDB 核心逻辑"

        A["DBImpl, Compaction, SSTable, 等..."]

    end



    subgraph "Env 抽象接口 (标准工具箱)"

        B(Env)

        B -- "提供 NewWritableFile()" --> A

        B -- "提供 StartThread()" --> A

    end

    





    A -- "调用" --> B

    C -- "实现" --> B

    D -- "实现" --o B

    E -- "实现" --o B

    

    style A fill:#cde

    style B fill:#f9f

我们如何使用 Env？

对于绝大多数用户来说，你几乎不需要直接与 Env 交互。LevelDB 会在后台为你处理好一切。

当你打开一个数据库时，选项 (Options) 对象里有一个 env 成员。如果你不设置它，它的默认值就是 Env::Default()。

Env::Default() 是一个静态方法，它会根据编译时确定的操作系统，返回一个对应平台的 Env 单例对象。在 Linux 上，它返回 PosixEnv 的实例；在 Windows 上，它返回 WindowsEnv 的实例。

#include "leveldb/db.h"

#include "leveldb/env.h"



int main() {

  leveldb::Options options;

  

  // 我们没有设置 options.env，

  // 所以 LevelDB 会自动使用 Env::Default()

  // 在 Linux 上就是 PosixEnv，在 Windows 上就是 WindowsEnv

  

  leveldb::DB* db;

  // DB::Open 内部会从 options.env 获取环境对象，

  // 并在需要时用它来操作文件、启动线程等。

  leveldb::Status status = leveldb::DB::Open(options, "/tmp/testdb", &db);

  

  // ...

  

  delete db;

  return 0;

}

所以，Env 虽然至关重要，但它就像空气一样，默默地支撑着一切，而我们通常感觉不到它的存在。

Env 内部是如何工作的？

Env 的强大之处在于它的多态设计。Env 本身是一个抽象基类，定义了所有平台都需要提供的功能接口。

1. Env 的接口定义 (include/leveldb/env.h)

Env 类定义了许多纯虚函数（以 = 0 结尾），这意味着任何想要成为一个“合格” Env 的子类都必须实现这些函数。

// 来自 include/leveldb/env.h (简化后)

class LEVELDB_EXPORT Env {

 public:

  virtual ~Env();



  // 返回一个适合当前操作系统的默认 Env

  static Env* Default();



  // 创建一个用于顺序读取的文件对象

  virtual Status NewSequentialFile(const std::string& fname,

                                   SequentialFile** result) = 0;



  // 创建一个用于随机读取的文件对象

  virtual Status NewRandomAccessFile(const std::string& fname,

                                     RandomAccessFile** result) = 0;



  // 创建一个用于写操作的文件对象

  virtual Status NewWritableFile(const std::string& fname,

                                 WritableFile** result) = 0;

  

  // 启动一个新线程

  virtual void StartThread(void (*function)(void* arg), void* arg) = 0;



  // 返回当前的微秒时间戳

  virtual uint64_t NowMicros() = 0;

  // ... 还有很多其他接口, 如文件删除、目录创建等 ...

};

这个接口就是 LevelDB 核心逻辑所依赖的“标准工具箱”的蓝图。

2. POSIX 平台的实现 (util/env_posix.cc)

PosixEnv 类继承自 Env，并使用 POSIX 标准的系统调用来实现这些接口。

让我们看看 NewWritableFile 的实现：

// 来自 util/env_posix.cc (简化后)

Status PosixEnv::NewWritableFile(const std::string& filename,

                                 WritableFile** result) {

  // 使用 POSIX 的 open() 系统调用来创建文件

  int fd = ::open(filename.c_str(),

                  O_TRUNC | O_WRONLY | O_CREAT, 0644);

  if (fd < 0) {

    *result = nullptr;

    return PosixError(filename, errno); // 返回错误状态

  }



  // 创建一个 PosixWritableFile 对象来包装文件描述符

  *result = new PosixWritableFile(filename, fd);

  return Status::OK();

}

这里，PosixEnv 将对“写文件”这个抽象请求，转换成了对 ::open() 这个具体的 POSIX 系统调用。

3. Windows 平台的实现 (util/env_windows.cc)

与之对应，WindowsEnv 则使用 Windows API 来实现同样的功能。

// 来自 util/env_windows.cc (简化后)

Status WindowsEnv::NewWritableFile(const std::string& filename,

                                   WritableFile** result) {

  // 使用 Windows API 的 CreateFileA() 来创建文件

  ScopedHandle handle = ::CreateFileA(

      filename.c_str(), GENERIC_WRITE, /*share_mode=*/0,

      /*security=*/nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,

      /*template=*/nullptr);

  if (!handle.is_valid()) {

    *result = nullptr;

    return WindowsError(filename, ::GetLastError());

  }



  // 创建一个 WindowsWritableFile 对象来包装文件句柄

  *result = new WindowsWritableFile(filename, std::move(handle));

  return Status::OK();

}

WindowsEnv 将同样的抽象请求，转换成了对 ::CreateFileA() 这个具体的 Windows API 调用。LevelDB 的上层代码完全不知道也不关心这些差异。

Env::Default() 的魔法

Env::Default() 是如何知道该返回哪个实现的呢？这通常是通过编译时的预处理宏来完成的。

// 位于 env.cc 或平台相关的 env_*.cc 文件中 (概念简化)

#include "leveldb/env.h"



#if defined(LEVELDB_PLATFORM_POSIX)

#include "util/env_posix.h"

#elif defined(LEVELDB_PLATFORM_WINDOWS)

#include "util/env_windows.h"

#endif



namespace leveldb {

Env* Env::Default() {

  // 静态变量保证了全局只有一个实例

  static SingletonEnv<

#if defined(LEVELDB_PLATFORM_POSIX)

    PosixEnv

#elif defined(LEVELDB_PLATFORM_WINDOWS)

    WindowsEnv

#else

    // Fallback or error for unsupported platforms

#endif

  > env_container;

  return env_container.env();

}

} // namespace leveldb

在编译时，构建系统会根据目标平台定义 LEVELDB_PLATFORM_POSIX 或 LEVELDB_PLATFORM_WINDOWS，从而使得 Env::Default() 的代码在编译后，就“硬编码”为返回正确的平台特定 Env 实例。

用于测试的 MemEnv

Env 抽象层的另一个巨大好处是可测试性。LevelDB 提供了一个完全在内存中模拟文件系统的 MemEnv（位于 helpers/memenv/memenv.h）。在进行单元测试时，可以使用 MemEnv 来代替真实的 PosixEnv 或 WindowsEnv。这使得测试可以：

• 非常快：因为没有实际的磁盘 I/O。


• 完全隔离：不会在文件系统上留下任何垃圾文件。


• 可控：可以方便地模拟文件读写错误等异常情况。

总结与回顾

在本章中，我们探索了 LevelDB 的根基——Env 环境抽象层。

• Env 是一个对操作系统功能的抽象接口，它将 LevelDB 的核心逻辑与具体的平台实现解耦。


• 这个“万能工具箱”的设计使得 LevelDB 具有极高的可移植性。


• 我们通常通过 Env::Default() 间接使用它，它会自动返回适合当前操作系统的 Env 实现（如 PosixEnv 或 WindowsEnv）。


• Env 的抽象也使得编写快速、隔离的单元测试成为可能，例如使用内存文件系统 MemEnv。

至此，我们已经完成了 LevelDB 核心概念的探索之旅！让我们一起回顾一下走过的路：

我们从最基础的数据表示 数据切片 (Slice) 开始，学习了如何通过 选项 (Options)] 配置我们的 数据库实例 (DB)。我们掌握了如何使用 批量写 (WriteBatch) 和 迭代器 (Iterator) 与数据库高效交互。

然后，我们深入内部，揭开了数据持久化的第一道防线 预写日志 (Log / WAL)，看到了数据在内存中的临时住所 内存表 (MemTable)，并最终见证了它们在磁盘上的永久归宿 排序字符串表 (SSTable)。我们理解了 LevelDB 是如何通过后台的 合并 (Compaction) 任务来保持整洁，以及如何通过 版本集 (VersionSet / Version) 来管理数据快照。

我们还深入到了 SSTable 的微观世界，探索了 数据块 (Block) 的紧凑结构，并了解了 缓存 (Cache) 如何为读取加速。我们学会了用 比较器 (Comparator) 定义秩序，用 过滤器策略 (FilterPolicy) 避免无效查询。最后，我们认识了支撑这一切的平台基石 环境 (Env)。

希望这个系列能帮助你建立起对 LevelDB 内部工作原理的清晰理解。现在，你不仅知道如何使用 LevelDB，更重要的是，你明白了它为何能如此高效、稳定地工作。恭喜你完成了这段旅程！

Spec-Kit WBS：技术团队的项目管理新方式

📋 WBS基本概念

什么是WBS？

WBS (Work Breakdown Structure) = 工作分解结构

• 定义: 将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程


• 目标: 确保项目范围完整，工作不遗漏，便于估算、计划、执行和控制


• 本质: 把复杂项目像搭积木一样，一层一层地分解成可管理的小任务

WBS的核心价值

🔄 WBS与PDCA的关系

PDCA循环在项目管理中的应用

Plan (计划)

├── 项目范围定义

├── WBS创建 ← 关键工具

├── 时间估算

├── 资源分配

└── 风险管理



Do (执行)

├── 按WBS执行任务

├── 团队协作

├── 质量保证

└── 进度跟踪



Check (检查)

├── 里程碑检查

├── 质量审查

├── 进度评估

└── 偏差分析



Act (行动)

├── 纠正措施

├── 预防措施

├── 经验总结

└── 流程改进

WBS与PDCA的协同效应

关键理解: WBS是PDCA循环中Plan阶段的核心工具，它将抽象的项目目标转化为具体的、可执行的任务，确保项目管理的系统性和完整性。

🏗️ WBS实际示例：开发一个电商网站

1. 项目概述

项目名称: 开发一个在线购物网站

项目目标: 让用户可以浏览商品、下单购买、管理账户

2. WBS分解过程

第一层：主要阶段

电商网站项目

├── 1. 需求分析阶段

├── 2. 设计阶段  

├── 3. 开发阶段

├── 4. 测试阶段

└── 5. 部署上线阶段

第二层：每个阶段的工作包

电商网站项目

├── 1. 需求分析阶段

│   ├── 1.1 用户需求调研

│   ├── 1.2 功能需求分析

│   └── 1.3 技术需求分析

├── 2. 设计阶段

│   ├── 2.1 界面设计

│   ├── 2.2 数据库设计

│   └── 2.3 系统架构设计

├── 3. 开发阶段

│   ├── 3.1 前端开发

│   ├── 3.2 后端开发

│   └── 3.3 数据库开发

├── 4. 测试阶段

│   ├── 4.1 功能测试

│   ├── 4.2 性能测试

│   └── 4.3 安全测试

└── 5. 部署上线阶段

    ├── 5.1 服务器配置

    ├── 5.2 数据迁移

    └── 5.3 上线发布

第三层：具体活动（最详细的任务）

电商网站项目

├── 1. 需求分析阶段

│   ├── 1.1 用户需求调研

│   │   ├── 1.1.1 设计用户问卷

│   │   ├── 1.1.2 进行用户访谈

│   │   └── 1.1.3 分析用户反馈

│   ├── 1.2 功能需求分析

│   │   ├── 1.2.1 列出所有功能点

│   │   ├── 1.2.2 确定功能优先级

│   │   └── 1.2.3 编写需求文档

│   └── 1.3 技术需求分析

│       ├── 1.3.1 确定技术栈

│       ├── 1.3.2 评估性能要求

│       └── 1.3.3 制定技术方案

├── 2. 设计阶段

│   ├── 2.1 界面设计

│   │   ├── 2.1.1 设计首页布局

│   │   ├── 2.1.2 设计商品列表页

│   │   ├── 2.1.3 设计购物车页面

│   │   └── 2.1.4 设计用户中心

│   ├── 2.2 数据库设计

│   │   ├── 2.2.1 设计用户表

│   │   ├── 2.2.2 设计商品表

│   │   ├── 2.2.3 设计订单表

│   │   └── 2.2.4 设计购物车表

│   └── 2.3 系统架构设计

│       ├── 2.3.1 设计整体架构

│       ├── 2.3.2 设计API接口

│       └── 2.3.3 设计安全方案

├── 3. 开发阶段

│   ├── 3.1 前端开发

│   │   ├── 3.1.1 搭建前端框架

│   │   ├── 3.1.2 开发首页组件

│   │   ├── 3.1.3 开发商品展示组件

│   │   ├── 3.1.4 开发购物车组件

│   │   └── 3.1.5 开发用户中心组件

│   ├── 3.2 后端开发

│   │   ├── 3.2.1 搭建后端框架

│   │   ├── 3.2.2 开发用户管理API

│   │   ├── 3.2.3 开发商品管理API

│   │   ├── 3.2.4 开发订单管理API

│   │   └── 3.2.5 开发支付接口

│   └── 3.3 数据库开发

│       ├── 3.3.1 创建数据库

│       ├── 3.3.2 创建数据表

│       ├── 3.3.3 插入测试数据

│       └── 3.3.4 优化数据库性能

├── 4. 测试阶段

│   ├── 4.1 功能测试

│   │   ├── 4.1.1 测试用户注册登录

│   │   ├── 4.1.2 测试商品浏览功能

│   │   ├── 4.1.3 测试购物车功能

│   │   └── 4.1.4 测试下单支付功能

│   ├── 4.2 性能测试

│   │   ├── 4.2.1 测试页面加载速度

│   │   ├── 4.2.2 测试并发用户处理

│   │   └── 4.2.3 测试数据库查询性能

│   └── 4.3 安全测试

│       ├── 4.3.1 测试SQL注入防护

│       ├── 4.3.2 测试XSS攻击防护

│       └── 4.3.3 测试用户数据安全

└── 5. 部署上线阶段

    ├── 5.1 服务器配置

    │   ├── 5.1.1 购买云服务器

    │   ├── 5.1.2 配置服务器环境

    │   └── 5.1.3 安装必要软件

    ├── 5.2 数据迁移

    │   ├── 5.2.1 备份开发数据

    │   ├── 5.2.2 迁移到生产环境

    │   └── 5.2.3 验证数据完整性

    └── 5.3 上线发布

        ├── 5.3.1 部署代码到服务器

        ├── 5.3.2 配置域名和SSL

        └── 5.3.3 监控系统运行状态

3. WBS编号规则

1. 第一层：1, 2, 3, 4, 5 (主要阶段)

2. 第二层：1.1, 1.2, 1.3 (工作包)

3. 第三层：1.1.1, 1.1.2, 1.1.3 (具体活动)

4. WBS与PDCA的结合

Plan阶段 (创建WBS)

✅ 1.1.1 设计用户问卷

✅ 1.1.2 进行用户访谈  

✅ 1.1.3 分析用户反馈

Do阶段 (执行WBS)

🔄 2.1.1 设计首页布局

🔄 2.1.2 设计商品列表页

⏳ 2.1.3 设计购物车页面

Check阶段 (检查WBS)

✅ 4.1.1 测试用户注册登录 - 通过

✅ 4.1.2 测试商品浏览功能 - 通过

❌ 4.1.3 测试购物车功能 - 发现bug

Act阶段 (改进WBS)

🔧 修复购物车bug

📝 更新测试用例

🔄 重新测试购物车功能

5. 实际项目管理中的应用

任务分配表

进度跟踪

项目进度: 15%

├── 需求分析阶段: 60% (3/5个任务完成)

├── 设计阶段: 0% (0/8个任务开始)

├── 开发阶段: 0% (0/12个任务开始)

├── 测试阶段: 0% (0/9个任务开始)

└── 部署阶段: 0% (0/8个任务开始)

🎯 WBS的优势体现

A. 完整性

• ✅ 确保所有工作都被识别


• ✅ 不会遗漏重要任务


• ✅ 项目范围清晰

B. 可管理性

• ✅ 每个任务都有明确的交付物


• ✅ 任务大小适中，便于管理


• ✅ 可以分配给不同的人员

C. 可跟踪性

• ✅ 可以跟踪每个任务的进度


• ✅ 识别瓶颈和风险点


• ✅ 及时调整计划

D. 可估算性

• ✅ 每个任务可以估算时间和成本


• ✅ 便于制定项目预算


• ✅ 便于资源分配

E. 责任分配

• ✅ 每个任务可以分配给特定的人员


• ✅ 明确的责任分工


• ✅ 便于团队协作

🔧 WBS在Spec-Kit中的应用

传统WBS vs Spec-Kit WBS

核心区别对比

分解思路

• 传统WBS：按项目阶段分解（需求→设计→开发→测试→部署）


• Spec-Kit WBS：按技术实现分解（环境→测试→实现→集成→完善）

测试策略

• 传统WBS：测试放在最后，问题发现太晚


• Spec-Kit WBS：测试先行(TDD)，质量更有保障

任务标识

• 传统WBS：无特殊标识，按顺序执行


• Spec-Kit WBS：[P]标识并行任务，提高开发效率

适用场景

• 传统WBS：通用项目管理（建筑、市场、产品发布）


• Spec-Kit WBS：软件开发项目（API开发、系统集成、技术重构）

文件管理

• 传统WBS：通用描述，适合各种项目


• Spec-Kit WBS：具体文件路径，便于开发执行

传统WBS

电商网站项目

├── 1. 需求分析 (5个任务)

├── 2. 设计 (8个任务)

├── 3. 开发 (12个任务)

├── 4. 测试 (9个任务)

└── 5. 部署 (8个任务)

Spec-Kit的WBS

联调12个接口

├── 阶段 3.1: 环境设置 (3个任务)

├── 阶段 3.2: 测试先行 (13个任务) [P]

├── 阶段 3.3: 核心实现 (14个任务)

├── 阶段 3.4: 集成 (4个任务)

└── 阶段 3.5: 完善 (4个任务)

Spec-Kit WBS的特点

Spec-Kit WBS示例

联调12个接口

├── 阶段 3.1: 环境与项目设置

│   ├── T001: 创建目录结构

│   ├── T002: 初始化项目

│   └── T003 [P]: 配置工具

├── 阶段 3.2: 测试先行 (TDD)

│   ├── T004-T015: 12个接口的合约测试 [P]

│   └── T016: 集成测试

├── 阶段 3.3: 核心实现

│   ├── T017-T018: 数据模型和服务层

│   └── T019-T030: 12个接口实现

├── 阶段 3.4: 集成

│   ├── T031-T033: 服务连接和配置

│   └── T034: 集成测试

└── 阶段 3.5: 完善

    ├── T035-T037: 测试和文档

    └── T038: 最终验证

📝 总结

WBS是项目管理的核心工具，它将复杂的项目分解为可管理的小任务。与PDCA循环结合使用，可以确保项目的系统性、完整性和可跟踪性。

关键要点:

• WBS是PDCA循环中Plan阶段的核心工具


• 通过层次化分解确保项目完整性


• 每个任务都有明确的交付物和责任人


• 支持进度跟踪和风险管理


• 在Spec-Kit中与规范驱动开发完美结合

实际应用建议:

Changelog

V1.0 (2025-09-29)

• [新增] 初稿完成 - 文档基础框架建立


• [新增] 初稿完成 - 基础版本


• [新增] 添加WBS基本概念和实际应用示例


• [新增] 新增传统WBS vs Spec-Kit WBS对比分析


• [新增] 完善文档结构和可读性 - 用户体验

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

01 引言

在现代Web应用开发中，模板引擎是实现前后端分离和视图渲染的重要工具。SpringBoot作为流行的Java开发框架，天然支持多种模板引擎。

每一个项目使用单一的模板引擎是标准输出。但是，总有一些老项目经历多轮迭代，人员更替，不同的开发都只是用自己熟悉的模版引擎，导致一个项目中包含了多种模板引擎。从而相互影响，甚至出现异常。这也是小编正在经历的痛苦。

本文将详细介绍如何在SpringBoot项目中同时集成JSP、Freemarker和Thymeleaf三种模板引擎，包括配置方法、使用场景、常见问题及解决方案。

02 项目搭建

本文基于Springboot 3.0.13，因为不同版本（2.x）对于部分包的做了更改。由于JSP的配置会影响其他的模板引擎，所以JSP的配置，放到最后说明。

2.1 Maven依赖

<!-- freemarker 模版引擎 -->

<dependency>

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

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

</dependency>

<!-- thymeleaf 模版引擎 -->

<dependency>

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

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

</dependency>

<dependency>

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

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

</dependency>

2.3 配置

#配置freemarker

spring.freemarker.template-loader-path=classpath:/templates/ftl/

spring.freemarker.suffix=.ftl

spring.freemarker.cache=false



# 配置thymeleaf

spring.thymeleaf.prefix=classpath:/templates/html/

spring.thymeleaf.suffix=.html

spring.thymeleaf.cache=false

2.4 最佳实践

页面

控制层

@Controller

@RequestMapping("/page")

public class PageController {

    

    @RequestMapping("{engine}")

    public String toPage(@PathVariable("engine") String engine, Model model) {

        model.addAttribute("date", new Date());

        return engine + "_index";

    }

}

2.5 测试

到这里，会发现一切顺利。Thymeleaf和Freemarker都可以顺利解析。但是，引入JSP之后，发现不能生效。

03 SpringBoot继续集成JSP

3.1 Maven依赖

<!-- JSP支持 -->

<dependency>

    <groupId>org.apache.tomcat.embed</groupId>

    <artifactId>tomcat-embed-jasper</artifactId>

</dependency>

<!-- jstl 工具 -->

<dependency>

    <groupId>jakarta.servlet.jsp.jstl</groupId>

    <artifactId>jakarta.servlet.jsp.jstl-api</artifactId>

</dependency>

<dependency>

    <groupId>org.glassfish.web</groupId>

    <artifactId>jakarta.servlet.jsp.jstl</artifactId>

</dependency>

这里要说明的jstl，低版本（3.x一下）的需要引入:

<dependency>

    <groupId>javax.servlet</groupId>

    <artifactId>jstl</artifactId>

    <version>1.2</version>

</dependency>

具体的依赖可以在Springboot官方文档中查看。

3.2 配置

spring.mvc.view.prefix=/WEB-INF/jsp/

spring.mvc.view.suffix=.jsp

3.3 创建包结构

因为SpringBoot默认不支持JSP，所以需要我们自己配置支持JSP。

包的路径地址：\src\main\webapp\WEB-INF

3.4 修改pom打包

在build下增加resource

<resources>

    <!-- 打包时将jsp文件拷贝到META-INF目录下-->

    <resource>

        <!-- 指定处理哪个目录下的资源文件 -->

        <directory>src/main/webapp</directory>

        <!--注意此次必须要放在此目录下才能被访问到-->

        <targetPath>META-INF/resources</targetPath>

        <includes>

            <include>**/**</include>

        </includes>

    </resource>

</resources>

3.5 测试

其他两个不受影响，但是发现配置的JSP并不生效，根据报错信息来看，默认使用了Thymeleaf解析的。

04 源码追踪

关键的类：org.springframework.web.servlet.view.ContentNegotiatingViewResolver

断点调试发现，图中①根据jsp_index视图，可以发现两个候选的View：ThymelearView和JstlView。

图中②获取最优的视图返回了ThymelearView，从而解析错误。从getBestView()源码可以看到，仅仅做了遍历操作，并没有个给句特殊的规则去取。如图：

所以影响视图解析器的就是候选视图的顺序。

我们继续看候选视图的取值：

这里仍是只是遍历，我们需要继续追溯this.viewResolvers的来源：

关键代码AnnotationAwareOrderComparator.sort(this.viewResolvers)会对所有的视图排序，所以我们只需要指定JSP的视图为第一个就可以了。

05 配置JSP视图的顺序

因为JSP的视图使用的是InternalResourceViewResolver，所以我们只需要设置其顺序即可。

@Configuration

public class BeanConfig {



    @Autowired

    InternalResourceViewResolver resolver;



    @PostConstruct

    public void init() {

        resolver.setOrder(1);

    }

由于其他的视图解析器默认是最级别，所以这里的设置只要比Integr.MAX小即可。

测试

我们发现源代码已经将JstlView变成了第一个，最优的视图自然也选择了JstlView，如图：

效果

我们发现JSP是正常显示了，但是其他两个又不好了。

真实让人头大!

06 解决JSP混合问题

6.1 解决方案

其实这里要使用一个属性可以永久的解决问题：viewName，

每一个ViewResolver都有一段关键的源码：

这里是匹配关系，可以通过配置的view-names过滤不符合条件的视图：

6.2 重新修改配置

###配置freemarker

spring.freemarker.template-loader-path=classpath:/templates/

spring.freemarker.view-names=ftl/*

spring.freemarker.suffix=.ftl

spring.freemarker.cache=false

#

### 配置thymeleaf

spring.thymeleaf.prefix=classpath:/templates/

spring.thymeleaf.view-names=html/*

spring.thymeleaf.suffix=.html

spring.thymeleaf.cache=false

##

### 配置JSP

spring.mvc.view.prefix=/WEB-INF/

spring.mvc.view.suffix=.jsp

这里的和之前不同的就是增加了spring.thymeleaf.view-names、spring.freemarker.view-names，并且classpath的路径少了一部分移动到view-names里面了。

JSP的spring.mvc.view.prefix同样少了一部分需要配置。

6.3 重新修改Java配置

@Configuration

public class BeanConfig {



    @Autowired

    InternalResourceViewResolver resolver;



    @PostConstruct

    public void init() {

        resolver.setViewNames("jsp/*");

    }

也可以使用Bean定义。使用Bean定义需要删除配置文件关于JSP的配置。

@Bean

public ViewResolver jspViewResolver() {

    InternalResourceViewResolver resolver = new InternalResourceViewResolver();

    resolver.setPrefix("/WEB-INF/");

    resolver.setSuffix(".jsp");

    resolver.setViewNames("jsp/*");

    return resolver;

}

6.4 修改控制层

@Controller

@RequestMapping("/page")

public class PageController {

 

    @RequestMapping("{engine}")

    public String toFtl(@PathVariable("engine") String engine, Model model) {

        model.addAttribute("date", new Date());

        return engine + "/" + engine + "_index";

    }

}

6.5 效果

JVM内存公寓清洁指南：G1与ZGC清洁工大比拼 🧹

引言：当内存公寓遇上"清洁工天团"

当 Java 应用中的对象在"内存公寓"里肆意"开派对"后，未被引用的对象便成了散落各处的"垃圾"，此时就需要专业的"清洁团队"——垃圾回收器登场。JVM 内存区域如同"内存公寓"的不同房间，其中线程共享区的堆是最大的"活动空间"，按对象生命周期分为新生代（Eden 区占 8/10、Survivor 区各占 1/10）和老年代，如同公寓的"青年宿舍"与"长者公寓"；方法区（元空间）则类似"物业档案室"，存储类元数据等。

为什么有的"清洁工"习惯按区域分片打扫，有的却能以"闪电速度"完成全屋清洁？这就不得不提到 G1 和 ZGC 两位"王牌清洁工"——前者以"分区管理"策略著称，后者则追求"低延迟闪电清洁"，其设计目标是将应用暂停（STW）时间控制在 10ms 以内，且停顿时间不会随堆大小或活跃对象增加而延长。

核心差异预告：G1 采用分代分区管理模式，擅长平衡吞吐量与停顿；ZGC 则通过创新算法突破堆大小限制，主打"毫秒级响应"。本文将拆解两者的"清洁秘籍"（垃圾回收算法）与"工资参数"（调优参数），揭秘谁能成为"内存公寓"的最优解。

G1回收器：精打细算的"分区清洁队长"

Garbage-First (G1) 垃圾收集器作为默认低延迟收集器，其核心设计理念可类比为"内存公寓"的分区清洁管理系统。与传统收集器将堆内存划分为固定大小新生代与老年代的方式不同，G1采用"分区垃圾袋"式的Region机制，将整个堆内存划分为最多2048个独立Region，每个Region容量可在1MB至32MB之间动态调整（默认根据堆大小自动选择）。这些Region并非固定归属新生代或老年代，而是根据应用内存分配模式动态标记为Eden区、Survivor区或Old区，实现内存资源的弹性调度。这种动态分区机制使G1能够灵活应对不同类型应用的内存需求，尤其适用于堆内存4GB至32GB的常规企业应用场景。

G1的垃圾回收策略采用"混合清洁模式"（Mixed GC），其工作流程可形象比喻为"先集中清理垃圾密集的房间（新生代），再抽空打扫老房间（老年代）"。G1优先对新生代Region执行Minor GC，通过复制算法快速回收短期存活对象；当老年代Region占比达到参数-XX:InitiatingHeapOccupancyPercent（默认45%）设定的阈值时，触发Mixed GC，在新生代收集的同时，选取部分垃圾占比高的老年代Region进行回收。这种选择性回收策略使G1能够集中资源处理垃圾密集区域，从而更精准地控制停顿时间，避免传统收集器对整个老年代进行全区域扫描的高昂成本。

在实际调优中，启用G1需通过JVM参数显式配置，基础命令示例如下：java -XX:+UseG1GC -Xms4g -Xmx4g -XX:MaxGCPauseMillis=200 -jar app.jar。某电商交易系统优化案例显示，在未调优状态下GC停顿时间常达300ms，通过设置MaxGCPauseMillis=200并调整Region大小后，停顿时间稳定降至180ms，同时吞吐量保持98%以上。核心调优参数及说明如下表所示：

💡 调优技巧：设置合理的停顿目标（如200ms）是平衡延迟与吞吐量的关键。G1会根据历史回收数据动态调整Region回收数量，过度严苛的停顿目标（如50ms）会迫使收集器频繁进行小范围压缩，反而导致GC次数激增。建议通过-XX:G1HeapRegionSize参数将Region大小设置为堆内存的1/2048，确保每个Region既能容纳大对象，又避免过小Region导致的管理开销。

🚨 常见误区：不要将-Xms和-Xmx设置为不同值！动态堆扩容会导致"内存公寓"频繁调整垃圾袋大小，引发额外性能开销，就像清洁工频繁更换垃圾桶尺寸一样影响效率。

以下是G1调优前后的GC日志对比：

# 调优前（停顿300ms）

[GC pause (G1 Evacuation Pause) (young) 1024M->768M(4096M) 302.5ms]

​

# 调优后（停顿180ms）

[GC pause (G1 Evacuation Pause) (young) 1024M->768M(4096M) 178.3ms]

ZGC回收器：闪电般的"极速清洁特工"

ZGC作为JVM内存管理的"极速清洁特工"，其核心竞争力体现在毫秒级停顿与超大堆支持两大特性上。设计目标明确为停顿时间不超过10ms，且该指标不会随堆大小或活跃对象数量的增加而退化，从根本上解决了传统回收器在大堆场景下的停顿痛点。

ZGC的"闪电清洁"秘籍

ZGC实现"边打扫边让住户正常活动"的核心技术在于染色指针与内存多重映射。染色指针技术在64位指针中嵌入4位元数据，可实时存储对象的标记状态与重定位信息，相当于清洁工佩戴的"AR智能眼镜"，能在不中断住户活动的情况下完成垃圾标记。内存多重映射则通过将物理内存同时映射到Marked0、Marked1、Remapped三个虚拟视图，实现并发重定位操作，确保回收过程与应用线程几乎无干扰。实测数据显示，ZGC停顿时间平均仅1.09ms，99.9%分位值为1.66ms，远低于10ms的设计阈值。

大堆管理：从16MB到16TB的"超级公寓"

与G1固定大小的Region（最大32MB）不同，ZGC采用动态Region机制，将内存划分为小页（2MB）、中页（32MB）和大页（N×2MB，最大支持16TB），如同"能伸缩的智能垃圾袋"，可根据对象大小自动调整容量。这种设计使其支持从8MB到16TB的堆内存范围，而G1在堆大小超过64GB时易出现停顿失控[1]。动态Region不仅提升了内存利用率，还解决了大对象分配效率问题，实现"小到零食包装，大到家具"的全覆盖管理。

调优参数实战

启用与核心参数配置

启用ZGC需在JDK15+环境中使用以下命令：

java -XX:+UseZGC -Xms16g -Xmx16g -XX:ZCollectionInterval=60 -jar app.jar

该配置指定16GB堆空间（初始与最大堆相同），至少每60秒执行一次回收。以下为核心参数说明：

💡 调优黄金法则：ZGC在32GB以上大堆场景优势显著，此时其停顿稳定性远超G1；而8GB以下小堆场景建议保留G1，因ZGC的吞吐量损失（通常<15%）在小堆下性价比更低。

🚨 误区警示：ZGC在JDK15才正式发布，JDK11-14为实验性版本，存在功能限制；JDK11以下版本完全不支持，切勿尝试在低版本JDK中启用。

性能对比与GC日志示例

在64GB堆环境下，ZGC与G1的表现差异显著：

# ZGC日志（停顿8ms）

[0.875s][info][gc] GC(0) Pause Relocate Start 1.56ms

[0.877s][info][gc] GC(0) Pause Relocate End 0.89ms

​

# G1日志（停顿520ms）

[GC pause (G1 Evacuation Pause) (mixed) 5890M->4520M(65536M) 520.3ms]

某支付系统迁移案例显示，将G1替换为ZGC后，峰值GC停顿从280ms降至8ms，交易成功率提升0.5%，验证了ZGC在关键业务场景的性能优势。

G1 vs ZGC：清洁团队终极PK

衡量垃圾收集器的三项重要指标包括内存占用（Footprint）、吞吐量（Throughput）和延迟（Latency）。吞吐量和延迟通常不可兼得，关注吞吐量的收集器和关注延迟的收集器在算法选择上存在差异。以下从核心能力与场景适配两方面对比 G1 与 ZGC 的差异：

核心能力对比表

电商订单系统：用户下单高峰期需避免卡顿，ZGC 小于 10 ms 的停顿特性可保障交易流畅性。

大数据批处理：当堆大小适中（如 32 GB）且吞吐量优先时，G1 更具成本效益。

实时游戏服务：毫秒级响应要求下，ZGC 是唯一能满足低延迟需求的选择。

总结：选对清洁工，内存公寓更舒心

回到"内存公寓"的管理视角，垃圾回收器的选择本质是匹配"公寓规模"与"住户需求"的过程——正如现实中没有万能的清洁工，JVM 内存管理也不存在绝对最优解，只有最适配场景的选择。

G1 作为"精打细算的分区管理员"，擅长处理 4GB~32GB 堆内存的常规企业应用，通过区域化内存布局与增量回收机制，在延迟控制与吞吐量之间取得平衡，成为大多数标准业务场景的默认选择。其设计理念如同经验丰富的物业经理，通过精细化分区管理确保日常运营的稳定高效。

ZGC 则是"追求极致速度的闪电特工"，专为 8MB~16TB 超大堆场景打造，尤其适用于金融交易等对停顿时间（<10ms）要求严苛的低延迟应用。它突破传统回收器的性能瓶颈，如同配备尖端装备的特种清洁团队，能在不干扰住户正常活动的前提下完成超大空间的极速清理。

调优核心口诀："小堆 G1 看停顿，大堆 ZGC 保延迟，参数设置要合理，日志监控不能停"。这一实践准则强调：堆内存规模与延迟需求是选型的首要依据，而持续的参数优化与监控分析则是维持长期稳定的关键。

选择合适的垃圾回收器并合理配置参数（如元空间大小、回收阈值等），是确保"内存公寓"长期整洁（避免内存溢出、减少 GC 停顿）的核心保障。你的内存公寓需要哪种清洁工？评论区聊聊你的调优故事吧！🎉

Explain总览图 这篇文章主要看图

Explain是啥

1、Explain工具介绍

使用EXPLAIN关键字可以模拟优化器执行SQL语句，分析你的查询语句或是结构的性能瓶颈， 在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询会返回执行计划的信息，而不是执行这条SQL。

注意：如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中。

2、Explain分析示例

参考官方文档：dev.mysql.com/doc/refman/…

# 示例表：



DROP TABLE IF EXISTS `actor`;

CREATE TABLE `actor` (

`id` int(11) NOT NULL,

`name` varchar(45) DEFAULT NULL,

`update_time` datetime DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;





INSERT INTO `actor` (`id`, `name`, `update_time`) VALUES (1,'a','2017‐12‐22

15:27:18'), (2,'b','2017‐12‐22 15:27:18'), (3,'c','2017‐12‐22 15:27:18');



DROP TABLE IF EXISTS `film`;

CREATE TABLE `film` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(10) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `idx_name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;





INSERT INTO `film` (`id`, `name`) VALUES (3,'film0'),(1,'film1'),(2,'film2');



DROP TABLE IF EXISTS `film_actor`;

CREATE TABLE `film_actor` (

`id` int(11) NOT NULL,

`film_id` int(11) NOT NULL,

`actor_id` int(11) NOT NULL,

`remark` varchar(255) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `idx_film_actor_id` (`film_id`,`actor_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;



INSERT INTO `film_actor` (`id`, `film_id`, `actor_id`) VALUES (1,1,1),(2,1,2),(3,2,1);





explain select * from actor;

 

# 在查询中的每个表会输出一行，如果有两个表通过 join 连接查询，那么会输出两行。

3、explain 两个变种

• 1）explain extended：

会在 explain 的基础上额外提供一些查询优化的信息。紧随其后通过 show warnings 命令可 以得到优化后的查询语句，从而看出优化器优化了什么。额外还有 filtered 列，是一个半分比的值，rows * filtered/100 可以估算出将要和 explain 中前一个表进行连接的行数（前一个表指 explain 中的id值比当前表id值小的表）

explain extended select * from film where id = 1;

show warnings;

• 2）explain partitions：

相比 explain 多了个 partitions 字段，如果查询是基于分区表的话，会显示查询将访问的分区。

4、explain中的列

4.1. id列

id列的编号是 select 的序列号，有几个 select 就有几个id，并且id的顺序是按 select 出现的顺序增长的。 id列越大执行优先级越高，id相同则从上往下执行，id为NULL最后执行。

4.2. select_type列

select_type 表示对应行是简单还是复杂的查询。

• 1）simple：简单查询。查询不包含子查询和union;


• 2）primary：复杂查询中最外层的select ;


• 3）subquery：包含在 select 中的子查询（不在 from 子句中）;


• 4）derived：包含在 from 子句中的子查询。MySQL会将结果存放在一个临时表中；


• 5）union：在 union 中的第二个和随后的 select；

explain select * from film where id = 2;

用这个例子来了解 primary、subquery 和 derived 类型：

#关闭mysql5.7新特性对衍生表的合并优化

set session optimizer_switch='derived_merge=off';



explain select (select 1 from actor where id = 1) from (select * from film where id = 1) der;

#还原默认配置

set session optimizer_switch='derived_merge=on'; 

explain select 1 union all select 1;

4.3. table列

这一列表示 explain 的一行正在访问哪个表。
当 from 子句中有子查询时，table列是格式，表示当前查询依赖 id=N 的查询，于是先执行 id=N 的查询。当有 union 时，UNION RESULT 的 table 列的值为，1和2表示参与 union 的 select 行id。

4.4. type列

这一列表示关联类型或访问类型，即MySQL决定如何查找表中的行，查找数据行记录的大概范围。 依次从最优到最差分别为：system > const > eq_ref > ref > range > index > ALL 。
一般来说，得保证查询达到range级别，最好达到ref ；

NULL：

mysql能够在优化阶段分解查询语句，在执行阶段用不着再访问表或索引。例如：在索引列中选取最小值，可 以单独查找索引来完成，不需要在执行时访问表

mysql> explain select min(id) from film;

const, system：

mysql能对查询的某部分进行优化并将其转化成一个常量（可以看show warnings 的结果）。用于 primary key 或 unique key 的所有列与常数比较时，所以表最多有一个匹配行，读取1次，速度比较快。system是 const的特例，表里只有一条元组匹配时为system；

explain extended select * from (select * from film where id = 1) tmp;

show warnings;

eq_ref：

primary key 或 unique key 索引的所有部分被连接使用 ，最多只会返回一条符合条件的记录。这可能是在 const 之外最好的联接类型了，简单的 select 查询不会出现这种 type。

explain select * from film_actor left join film on film_actor.film_id = film.id;

ref：相比 eq_ref，不使用唯一索引，而是使用普通索引或者唯一性索引的部分前缀，索引要和某个值相比较，可能会 找到多个符合条件的行。

简单 select 查询，name是普通索引（非唯一索引）

explain select * from film where name = 'film1';

关联表查询，idx_film_actor_id是film_id和actor_id的联合索引，这里使用到了film_actor的左边前缀film_id部分。

explain select film_id from film left join film_actor on film.id = film_actor.fi
lm_id;

range：

范围扫描通常出现在 in(), between ,> ,= 等操作中。使用一个索引来检索给定范围的行。

explain select * from actor where id > 1;

index：

扫描全索引就能拿到结果，一般是扫描某个二级索引，这种扫描不会从索引树根节点开始快速查找，而是直接 对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般为使用覆盖索引，二级索引一般比较小，所以这 种通常比ALL快一些。

explain select * from film;

ALL：

即全表扫描，扫描你的聚簇索引的所有叶子节点.通常情况下这需要增加索引来进行优化。

explain select * from actor;

4.5. possible_keys列

这一列显示查询可能使用哪些索引来查找 explain 时可能出现 possible_keys 有列，而 key 显示 NULL 的情况，这种情况是因为表中数据不多，mysql认为索引对此查询帮助不大，选择了全表查询。 如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查 where 子句看是否可以创造一个适当的索引来提 高查询性能，然后用 explain 查看效果。

4.6. key列

这一列显示mysql实际采用哪个索引来优化对该表的访问。 如果没有使用索引，则该列是 NULL。如果想强制mysql使用或忽视possible_keys列中的索引，在查询中使用 force index、ignore index。

4.7. key_len列

这一列显示了mysql在索引里使用的字节数，通过这个值可以算出具体使用了索引中的哪些列。 举例来说，film_actor的联合索引 idx_film_actor_id 由 film_id 和 actor_id 两个int列组成，并且每个int是4字节。通 过结果中的key_len=4可推断出查询使用了第一个列：film_id列来执行索引查找。

explain select * from film_actor where film_id = 2;

key_len计算规则如下：

     字符串：

                    char(n)：如果存汉字长度就是 3n 字节       

                    varchar(n)：如果存汉字则长度是 3n + 2 字节，加的2字节用来存储字符串长度，

                                        因为 varchar是变长字符串

char(n)和varchar(n)，5.0.3以后版本中，n均代表字符数，而不是字节数，
如果是 utf-8，一个数字 或字母占1个字节，一个汉字占3个字节 ；

    数值类型：

                    tinyint：1字节

                    smallint：2字节

                    int：4字节

                    bigint：8字节

     时间类型：

                    date：3字节

                    timestamp：4字节

                    datetime：8字节

如果字段允许为 NULL，需要1字节记录是否为 NULL ；索引最大长度是768字节，当字符串过长时，mysql会做一个类似左前缀索引的处理，将前半部分的字符提取出来做索引。

4.8. ref列

这一列显示了在key列记录的索引中，表查找值所用到的列或常量，
常见的有：const（常量），字段名（例：film.id）

4.9. rows列

这一列是mysql估计要读取并检测的行数，注意这个不是结果集里的行数。

4.10. Extra列

这一列展示的是额外信息。常见的重要值如下：

1）Using index：使用覆盖索引

覆盖索引定义：mysql执行计划explain结果里的key有使用索引，如果select后面查询的字段都可以从这个索引的树中 获取，这种情况一般可以说是用到了覆盖索引，extra里一般都有using index；覆盖索引一般针对的是辅助索引，整个 查询结果只通过辅助索引就能拿到结果，不需要通过辅助索引树找到主键，再通过主键去主键索引树里获取其它字段值。

explain select film_id from film_actor where film_id = 1;

2）Using where：

使用 where 语句来处理结果，并且查询的列未被索引覆盖

explain select * from actor where name = 'a';

3）Using index condition：

查询的列不完全被索引覆盖，where条件中是一个前导列的范围；

explain select * from film_actor where film_id > 1;

4）Using temporary：

mysql需要创建一张临时表来处理查询。出现这种情况一般是要进行优化的，首先是想到用索 引来优化。

actor.name没有索引，此时创建了张临时表来distinct

explain select distinct name from actor;

film.name建立了idx_name索引，此时查询时extra是using index,没有用临时表

explain select distinct name from film;

5）Using filesort：

将用外部排序而不是索引排序，数据较小时从内存排序，否则需要在磁盘完成排序。这种情况下一 般也是要考虑使用索引来优化的

1 mysql> explain select * from actor order by name
2. film.name建立了idx_name索引,此时查询时extra是using index

explain select * from film order by name;

6）Select tables optimized away：

使用某些聚合函数（比如 max、min来访问存在索引的某个字段是

explain select min(id) from film;

索引最佳实践

# 示例表：

CREATE TABLE `employees` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',

`age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',

`position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',

`hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间',

PRIMARY KEY (`id`),

 KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COMMENT='员工记录表';



INSERT INTO employees(name,age,position,hire_time) VALUES('LiLei',22,'manager',NOW());

INSERT INTO employees(name,age,position,hire_time) VALUES('HanMeimei',

23,'dev',NOW());

INSERT INTO employees(name,age,position,hire_time) VALUES('Lucy',23,'dev',NOW());

5.1.全值匹配

1 EXPLAIN SELECT * FROM employees WHERE name= 'LiLei';

1 EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22;

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager';

5.2.最左前缀法则

如果索引了多列，要遵守最左前缀法。则指的是查询从索引的最左前列开始并且不跳过索引中的列。

1 EXPLAIN SELECT * FROM employees WHERE name = 'Bill' and age = 31;
2 EXPLAIN SELECT * FROM employees WHERE age = 30 AND position = 'dev';
3 EXPLAIN SELECT * FROM employees WHERE position = 'manager'

5.3.不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描

1 EXPLAIN SELECT * FROM employees WHERE name = 'LiLei';
2 EXPLAIN SELECT * FROM employees WHERE left(name,3) = 'LiLei';
给hire_time增加一个普通索引：

1 ALTER TABLE employees ADD INDEX idx_hire_time (hire_time) USING BTREE ;
2 EXPLAIN select * from employees where date(hire_time) ='2018‐09‐30';

转化为日期范围查询，有可能会走索引：

1 EXPLAIN select * from employees where hire_time >='2018‐09‐30 00:00:00' and hire_time <='2018‐09‐30 23:59:59';

还原最初索引状态

1 ALTER TABLE employees DROP INDEX idx_hire_time;

5.4.存储引擎不能使用索引中范围条件右边的列

1 EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager';
2 EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age > 22 AND position ='manager';

5.5.尽量使用覆盖索引（只访问索引的查询（索引列包含查询列）），减少 select * 语句

1 EXPLAIN SELECT name,age FROM employees WHERE name= 'LiLei' AND age = 23 AND position='manager';

1 EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 23 AND position ='manager';

5.6.mysql在使用不等于（！=或者<>），not in ，not exists 的时候无法使用索引会导致全表扫描 < 小于、 > 大于、 = 这些，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引

1 EXPLAIN SELECT * FROM employees WHERE name != 'LiLei';

5.7.is null,is not null 一般情况下也无法使用索引

1 EXPLAIN SELECT * FROM employees WHERE name is null

5.8.like以通配符开头（'$abc...'）mysql索引失效会变成全表扫描操作

1 EXPLAIN SELECT * FROM employees WHERE name like '%Lei'

1 EXPLAIN SELECT * FROM employees WHERE name like 'Lei%'

问题：解决like'%字符串%'索引不被使用的方法？
a）使用覆盖索引，查询字段必须是建立覆盖索引字段

1 EXPLAIN SELECT name,age,position FROM employees WHERE name like '%Lei%';

b）如果不能使用覆盖索引则可能需要借助搜索引擎

5.9.字符串不加单引号索引失效

1 EXPLAIN SELECT * FROM employees WHERE name = '1000'; 2 EXPLAIN SELECT * FROM employees WHERE name = 1000;

5.10.少用or或in，

用它查询时，mysql不一定使用索引，mysql内部优化器会根据检索比例、表大小等多个因素整体评 估是否使用索引，详见范围查询优化

1 EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' or name = 'HanMeimei';

5.11.范围查询优化 给年龄添加单值索引

1 ALTER TABLE employees ADD INDEX idx_age (age) USING BTREE ;
2 explain select * from employees where age >=1 and age <=2000;

没走索引原因：mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引。比如这个例子，可能是 由于单次数据量查询过大导致优化器最终选择不走索引 。
优化方法：可以将大的范围拆分成多个小范围。

1 explain select * from employees where age >=1 and age <=1000;
2 explain select * from employees where age >=1001 and age <=2000;

还原最初索引状态

1 ALTER TABLE employees DROP INDEX idx_age;

6、索引使用总结

PS：like KK%相当于=常量，%KK和%KK% 相当于范围

团队曾为一个订单状态显示问题加班至深夜：并非业务逻辑出错，而是前期封装的订单类过度隐藏核心字段，连获取支付时间都需多层调用，最终只能通过反射绕过封装临时解决，后续还需承担潜在风险。这一典型场景，正是 “乱封装” 埋下的隐患 —— 封装本是保障代码安全、提升可维护性的工具，但违背其核心原则的 “乱封装”，反而会让代码从 “易扩展” 走向 “高耦合”，成为开发流程中的阻碍。

一、乱封装的三类典型形态：偏离封装本质的错误实践

乱封装并非 “不封装”，而是未遵循 “最小接口暴露、合理细节隐藏” 原则，表现为三种具体形态，与前文所述的过度封装、虚假封装、混乱封装高度契合，且每一种都直接破坏代码可用性。

1. 过度封装：隐藏必要扩展点，制造使用障碍

为追求 “绝对安全”，将本应开放的核心参数或功能强行隐藏，仅保留僵化接口，导致后续业务需求无法通过正常途径满足。例如某文件上传工具类，将存储路径、上传超时时间等关键参数设为私有且未提供修改接口，仅支持默认配置。当业务需新增 “临时文件单独存储” 场景时，既无法调整路径参数，又不能复用原有工具类，最终只能重构代码，造成开发资源浪费。

反例代码：

// 文件上传工具类（过度封装）

public class FileUploader {

    // 关键参数设为私有且无修改途径

    private String storagePath = "/default/path";

    private int timeout = 3000;

    

    // 仅提供固定逻辑的上传方法，无法修改路径和超时时间

    public boolean upload(File file) {

        // 使用默认storagePath和timeout执行上传

        return doUpload(file, storagePath, timeout);

    }

    

    // 私有方法，外部无法干预

    private boolean doUpload(File file, String path, int time) {

        // 上传逻辑

    }

}

问题：当业务需要 "临时文件存 /tmp 目录" 或 "大文件需延长超时时间" 时，无法通过正常途径修改参数，只能放弃该工具类重新开发。

正确做法：暴露必要的配置接口，隐藏实现细节：

public class FileUploader {

    private String storagePath = "/default/path";

    private int timeout = 3000;

    

    // 提供修改参数的接口

    public void setStoragePath(String path) {

        this.storagePath = path;

    }

    

    public void setTimeout(int timeout) {

        this.timeout = timeout;

    }

    

    // 保留核心功能接口

    public boolean upload(File file) {

        return doUpload(file, storagePath, timeout);

    }

2. 虚假封装：形式化隐藏细节，未实现数据保护

表面通过访问控制修饰符（如private）隐藏变量，也编写getter/setter方法，但未在接口中加入必要校验或逻辑约束，本质与 “直接暴露数据” 无差异，却增加冗余代码。以订单类为例，将orderStatus（订单状态）设为私有后，setOrderStatus()方法未校验状态流转逻辑，允许外部直接将 “已发货” 状态改为 “待支付”，违背业务规则，既未保护数据完整性，也失去了封装的核心价值。

反例代码：

// 订单类（虚假封装）

public class Order {

    private String orderStatus; // 状态：待支付/已支付/已发货

    

    // 无任何校验的set方法

    public void setOrderStatus(String status) {

        this.orderStatus = status;

    }

    

    public String getOrderStatus() {

        return orderStatus;

    }

}



// 外部调用可随意修改状态，违背业务规则

Order order = new Order();

order.setOrderStatus("已发货");

order.setOrderStatus("待支付"); // 非法状态流转，封装未阻止

问题：允许状态从 "已发货" 直接变回 "待支付"，违反业务逻辑，封装未起到数据保护作用，和直接用 public 变量没有本质区别。

正确做法：在接口中加入校验逻辑：

public class Order {

    private String orderStatus;

    

    public void setOrderStatus(String status) {

        // 校验状态流转合法性

        if (!isValidTransition(this.orderStatus, status)) {

            throw new IllegalArgumentException("非法状态变更");

        }

        this.orderStatus = status;

    }

    

    // 隐藏校验逻辑

    private boolean isValidTransition(String oldStatus, String newStatus) {

        // 定义合法的状态流转规则

        return (oldStatus == null && "待支付".equals(newStatus)) ||

               ("待支付".equals(oldStatus) && "已支付".equals(newStatus)) ||

               ("已支付".equals(oldStatus) && "已发货".equals(newStatus));

    }

}

3. 混乱封装：混淆职责边界，堆砌无关逻辑

将多个独立功能模块强行封装至同一类或组件中，未按职责拆分，导致代码耦合度极高。例如某项目的 “CommonUtil” 工具类，同时包含日期转换、字符串处理、支付签名校验三类无关功能，且内部逻辑相互依赖。后续修改支付签名算法时，误触日期转换模块的静态变量，导致多个依赖该工具类的功能异常，排查与修复耗时远超预期。

反例代码：

// 万能工具类（混乱封装）

public class CommonUtil {

    // 日期处理

    public static String formatDate(Date date) { ... }

    

    // 字符串处理

    public static String trim(String str) { ... }

    

    // 支付签名（与工具类无关）

    public static String signPayment(String orderNo, BigDecimal amount) {

        // 使用了类内静态变量，与其他方法产生耦合

        return MD5.encode(orderNo + amount + secretKey);

    }

    

    private static String secretKey = "default_key";

}

问题：当修改支付签名逻辑（如替换加密方式）时，可能误改 secretKey，导致日期格式化、字符串处理等无关功能异常，排查难度极大。

正确做法：按职责拆分封装：

// 日期工具类

public class DateUtil {

    public static String formatDate(Date date) { ... }

}



// 字符串工具类

public class StringUtil {

    public static String trim(String str) { ... }

}



// 支付工具类

public class PaymentUtil {

    private static String secretKey = "default_key";

    public static String signPayment(String orderNo, BigDecimal amount) { ... }

}

二、乱封装的核心危害：从开发效率到系统稳定性的双重冲击

乱封装的危害具有 “隐蔽性” 和 “累积性”，初期可能仅表现为局部开发不便，随业务迭代会逐渐放大，对系统造成多重影响。

1. 降低开发效率，增加需求落地成本

乱封装会导致接口设计与业务需求脱节，当需要调用核心功能或获取关键数据时，需额外编写适配代码，甚至重构原有封装。例如某报表功能需获取订单原始字段用于统计，但前期封装的订单查询接口仅返回加工后的简化数据，无法满足需求，开发团队只能协调原封装者新增接口，沟通与开发周期延长，直接影响项目进度。

2. 破坏系统可扩展性，引发连锁故障

未预留扩展点的乱封装，会让后续功能迭代陷入 “牵一发而动全身” 的困境。某项目的缓存工具类未设计 “缓存过期清除” 开关，当业务需临时禁用缓存时，只能修改工具类源码，却因未考虑其他依赖模块，导致多个功能因缓存逻辑变更而异常，引发线上故障。这种因封装缺陷导致的扩展问题，会随系统复杂度提升而愈发严重。

3. 提升调试难度，延长问题定位周期

内部细节的无序隐藏，会让问题排查失去清晰路径。例如某支付接口返回 “参数错误”，但封装时未在接口中返回具体错误字段，且内部日志缺失关键信息，开发人员需逐层断点调试，才能定位到 “订单号长度超限” 的问题，原本十分钟可解决的故障，耗时延长数倍。

三、避免乱封装的实践原则：回归封装本质，平衡安全与灵活

避免乱封装无需复杂的设计模式，核心是围绕 “职责清晰、接口合理” 展开，结合前文总结的经验，可落地为两大原则。

1. 按 “单一职责” 划分封装边界

一个类或组件仅负责一类核心功能，不堆砌无关逻辑。例如用户模块中，将 “用户注册登录”“信息修改”“地址管理” 拆分为三个独立封装单元，通过明确的接口交互（如用户 ID 关联），避免功能耦合。这种拆分方式既能降低修改风险，也让代码结构更清晰，便于后续维护。

2. 接口设计遵循 “最小必要 + 适度灵活”

• 最小必要：仅暴露外部必须的接口，隐藏内部实现细节（如工具类无需暴露临时变量、辅助函数）；

• 适度灵活：针对潜在变化预留扩展点，避免接口僵化。例如短信发送工具类，核心接口sendSms(String phone, String content)满足基础需求，同时提供setTimeout(int timeout)方法允许调整超时时间，既隐藏签名验证、服务商调用等细节，又能应对不同场景的参数调整需求。

某商品管理项目的封装实践可作参考：商品查询功能同时提供两个接口 —— 面向前端的 “分页筛选简化接口” 和面向后端统计的 “完整字段接口”，既满足不同场景需求，又未暴露数据库查询逻辑，后续数据库表结构调整时，仅需维护内部实现，外部调用无需改动，充分体现了合理封装的价值。

结语

封装的本质是 “用合理的边界保障代码安全，用清晰的接口提升开发效率”，而非 “为封装而封装”。开发过程中，需避免过度追求形式化封装，也需警惕功能堆砌的混乱封装，多从后续维护、业务扩展的角度权衡接口设计。毕竟，好的封装是开发的 “助力”，而非 “阻力”—— 下次封装前，不妨先思考：“这样的设计，会不会给后续埋下隐患？”

员工分页查询功能开发

1. 需求分析

2. 代码开发

1. 根据分页查询接口设计对应的DTO

2. 设计controller层

    @GetMapping("/page")

    @ApiOperation(value = "员工分页查询")

    public Result page(EmployeePageQueryDTO employeePageQueryDTO){

        //输出日志

        log.info("员工分页查询,查询参数: {}",employeePageQueryDTO);

        //调用service层返回分页结果

        PageResult pageResult = employeeService.pageQuery(employeePageQueryDTO);

        //返回result

        return Result.success(pageResult);

    }

3. 设计service层,使用Page Helper进行分页,并返回total和record

 @Override

    public PageResult pageQuery(EmployeePageQueryDTO employeePageQueryDTO) {

        //开始分页

        PageHelper.startPage(employeePageQueryDTO.getPage(), employeePageQueryDTO.getPageSize());



        //调用mapper方法返回page对象,泛型为内容的类型,(page实际是一个List)

        Page page = employeeMapper.pageQuery(employeePageQueryDTO);



        //获取总的数据量

        long total = page.getTotal();



        //获取所有员工对象

        List record = page.getResult();



        //返回结果

        return new PageResult(total,record);

    }

4. 设计Mapper层

    Page pageQuery(EmployeePageQueryDTO employeePageQueryDTO);

4. 使用动态SQL进行查询

<select id="pageQuery" resultType="com.sky.entity.Employee">

        select * from employee

        <where>

            <if test="name != null and name != ''">

                name like concat('%',#{name},'#')

            if>

        where>

        order by create_time desc

    select>

3. 功能测试

Swagger测试:

问题

createTime这种是数组形式传递的

前后端联调:

问题:

操作时间渲染格式问题

4. 代码完善

方式一:

代码:

    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")

    private LocalDateTime createTime;



    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")

    private LocalDateTime updateTime;

数据返回:

方式二:

代码:

需要在配置类中重写父类的方法,并配置添加消息转换器

 @Override

    protected void extendMessageConverters(List> converters) {

        log.info("扩展消息转换器");

        //创建一个消息转换器

        MappingJackson2HttpMessageConverter converter  = new MappingJackson2HttpMessageConverter();

        //为消息转换器设置一个对象转换器,对象转换器可以将对象数据转换为json数据

        converter.setObjectMapper(new JacksonObjectMapper());

        //将消息转换器添加到容器中,由于converters内部有很多消息转换器,我们假如的默认排在最后一位

        //所以将顺序设置为最靠前

        converters.add(0,converter);

    }

其中JacksonObjectMapper为自己实现的实体类,写法较为固定

数据返回:

作者：用户4007842211260
来源：juejin.cn/post/7531791862521151528

一、灰度和红蓝区

灰度发布

• 定义：


• 
  
  
  
  • 灰度发布又称灰度测试、金丝雀发布，是指在软件产品正式全面上线之前，选择部分用户或部分服务器来进行新版本的发布和测试。
  
  
  • 例如，在一个拥有大量用户的社交应用的更新过程中，只让其中 10% 的用户使用新版本，而其余 90% 的用户仍然使用旧版本。
  
  
  
  


• 目的：


• 
  
  
  
  • 风险控制：将新版本的风险降至最低。由于只对部分用户或服务器进行更新，即使出现问题，影响范围也相对较小。例如，在更新一个金融应用的支付功能时，通过灰度发布，可以先在少量用户中测试，避免大面积的支付功能故障影响大量用户的资金交易。
  
  
  • 收集反馈：在小范围用户使用的过程中，可以收集用户反馈，包括功能的可用性、性能问题、用户体验等方面的反馈。比如，一款游戏进行版本更新，通过灰度发布可以观察这部分用户的游戏体验和对新功能的接受程度，根据反馈及时调整和优化。
  
  
  • 性能测试：观察新版本在真实环境下的性能表现，如服务器负载、响应时间等。例如，一个电商平台在上线新的商品推荐算法时，通过灰度测试可以观察在部分用户使用情况下，服务器是否能承受新算法带来的额外计算量和数据请求。
  
  
  
  


• 实现方式：


• 
  
  
  
  • 基于用户的灰度：根据用户的某些特征（如用户 ID、地区、注册时间等）来划分使用新版本的用户。例如，选取新注册用户进行灰度测试，让他们使用新的注册流程版本，而老用户仍然使用旧的注册流程。
  
  
  • 基于服务器的灰度：将服务器分为不同的集群，一部分集群部署新版本，一部分集群部署旧版本。例如，一个网站将其服务器集群分为 A、B、C 三组，让 A 组服务器先部署并运行新版本，B、C 组仍然运行旧版本，根据不同的负载均衡策略将用户请求引导到不同的服务器组。
  
  
  
  

红蓝区（我们现在的蓝区是灰度，部分用户，红区是放量）

• 定义：


• 
  
  
  
  • 红蓝区通常是将生产环境分成两个相对独立的区域，分别部署不同版本的系统，通常是旧版本（蓝区）和新版本（红区），类似于 AB 测试。
  
  
  • 例如，在一个内容分发平台中，蓝区使用原有的内容推荐系统，红区使用经过优化的新推荐系统。
  
  
  
  


• 目的：


• 
  
  
  
  • 对比测试：通过将新旧版本分别部署在不同的区域，能够在相同的环境和时间下对新旧系统进行直接对比。可以对比两个版本的性能指标（如吞吐量、响应时间）、业务指标（如用户留存率、点击率）等。例如，在一个新闻网站上，红区使用新的页面布局，蓝区使用旧的布局，对比不同区域用户的点击率和停留时间，以评估新布局的效果。
  
  
  • 快速回滚：当发现红区的新版本出现严重问题时，可以迅速将流量切换回蓝区的旧版本，降低对业务的影响。例如，在一个在线教育平台的系统更新中，如果红区的新系统出现严重的性能下降，导致用户无法正常上课，可以将用户请求切换回蓝区，保证服务的正常进行。
  
  
  
  


• 实现方式：


• 
  
  
  
  • 负载均衡切换：通过负载均衡器来控制流量分配到红区和蓝区。在正常情况下，根据一定的比例分配流量，如红区和蓝区分别分配 70% 和 30% 的流量。当发现红区出现问题时，将流量全部切换到蓝区。
  
  
  • 功能切换：可以对不同的功能进行红蓝区划分。例如，在一个企业办公软件中，将文件存储功能部署在红区，将即时通讯功能部署在蓝区，分别测试不同功能的新老版本，最后根据测试结果决定是否进行整体切换。
  
  
  
  

总之，无论是灰度发布还是红蓝区，都是为了在保证服务稳定性和业务连续性的前提下，更安全、高效地将新系统或新版本推向市场，降低因软件更新带来的风险，并在更新过程中不断收集反馈和数据，以优化系统和提升用户体验。

在 Web 应用中，验证码（CAPTCHA）常用于防止机器人批量提交请求，比如注册、登录、评论等功能。
本篇我们将使用 Go 语言和 Gin 框架，结合第三方库 github.com/mojocn/base64Captcha，快速实现一个简易图像验证码生成接口。

一、功能目标

二、安装依赖

首先安装 Gin 和 Base64Captcha：

go get github.com/gin-gonic/gin

go get github.com/mojocn/base64Captcha

三、代码实现

package main



import (

	"github.com/gin-gonic/gin"

	"github.com/mojocn/base64Captcha"

	"net/http"

)



// 验证码存储在内存中（也可以换成 Redis）

var store = base64Captcha.DefaultMemStore



// 生成验证码

func generateCaptcha(c *gin.Context) {

	driver := base64Captcha.NewDriverDigit(80, 240, 5, 0.7, 80) // 高度80, 宽度240, 5位数字

	captcha := base64Captcha.NewCaptcha(driver, store)

	id, b64s, err := captcha.Generate()

	if err != nil {

		c.JSON(http.StatusInternalServerError, gin.H{"error": "验证码生成失败"})

		return

	}



	c.JSON(http.StatusOK, gin.H{

		"captcha_id":   id,

		"captcha_image": b64s, // Base64 编码的图片

	})

}



// 校验验证码

func verifyCaptcha(c *gin.Context) {

	var req struct {

		ID    string `json:"id"`

		Value string `json:"value"`

	}

	if err := c.ShouldBindJSON(&req); err != nil {

		c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})

		return

	}



	if store.Verify(req.ID, req.Value, true) { // true 表示验证成功后清除

		c.JSON(http.StatusOK, gin.H{"message": "验证成功"})

	} else {

		c.JSON(http.StatusBadRequest, gin.H{"message": "验证码错误"})

	}

}



func main() {

	r := gin.Default()

	r.GET("/captcha", generateCaptcha)

	r.POST("/verify", verifyCaptcha)

	r.Run(":8080")

}

四、运行与测试

运行服务：

go run main.go

1. 获取验证码

curl http://localhost:8080/captcha

返回：

{

  "captcha_id": "ZffX7Xr7EccGdS4b",

  "captcha_image": "data:image/png;base64,iVBORw0KGgoAAAANSUhE..."

}

前端可直接用 <img src="captcha_image" /> 渲染验证码。

2. 校验验证码

curl -X POST http://localhost:8080/verify \

  -H "Content-Type: application/json" \

  -d '{"id":"ZffX7Xr7EccGdS4b","value":"12345"}'

五、注意事项

六、总结

使用 base64Captcha 结合 Gin，可以非常方便地生成和校验验证码。
本篇示例已经可以直接应用到注册、登录等防刷场景中。

这篇文章源于开发中发现的一个服务之间调用问题，在当前服务中调用了其他团队的一个服务，看日志一直报错没有找到下游的服务实例，然后就拉上运维来一块排查，运维让我先 telnet 一下网络，我一下没反应过来是要干啥！

telnet

telnet是电信(telecommunications)和网络(networks)的联合缩写，它是一种基于 TCP 的网络协议，用于远程登录服务器（数据均以明文形式传输，存在安全隐患，所以现在基本不会用了）或测试主机上的端口开放情况。

# 命令格式

telnet IP或域名 端口



# telnet ip地址

telnet 192.168.1.1 3306



# telnet 域名

telnet cafe123.cn 443

ping

ping 是一种基于 ICMP（Internet Control Message Protocol）的网络工具，用于测试主机之间的网络连通性，它不能指定端口。

# 命令格式

ping IP或域名



# ping ip地址

ping 192.168.1.1



# ping 域名

ping cafe123.cn

日常开发中测试某台服务器上的web后端、数据库、redis等服务的端口是否开放可用，就可以用 telnet 命令；若只需确认服务器主机是否在线，就可以用 ping 命令。

像一般服务之间调用出现问题，我就需要先从服务器网络开始测试，一步步来缩小范围，如果当前服务器上都没法 telnet 通目标服务器的某个端口，那就是网络问题，那就可以从网络入手来排查是网络不让访问还是目标服务压根不存在。

curl

curl（Client URL）是一个强大的网络请求命令工具，可以理解为命令行中的 postman。

比如如果我们要在服务器上去请求某个接口，看能不能请求通，总不能在 Linux 上去装个 postman 来请求吧。这种情况 curl 命令就派上用场了。

1、请求某个网页

# 命令格式

curl 网址



# 示例

curl https://cafe123.cn

2、发送 get 请求

参数 -X 指定 HTTP 方法，不指定默认就是 get

# 示例

curl -X GET https://cafe123.cn?name=zhou&age=18

3、发送 post 请求

请求头用 -H 指定，多个直接分开多次指定就行，-d 指定 post 请求参数

curl -X POST -H "Content-Type: application/json" -H "token: 1345102704" -d '{"name":"ZHOU","age":18}'  https://api.cafe123.cn/users

实际上面的这些也不用记，浏览器的 network 前端接口请求查看面板里右键实际是可以直接复制出来对应接口的 curl 命令的，然后直接复制出来去服务器上执行就行了，postman 中也支持直接导入 curl 命令给自动转成 postman 对应的参数。

一、前言

平常开发中有可能需要实现在项目启动后执行的功能，Springboot中的ApplicationRunner和CommandLineRunner接口都能够帮我们很好地完成这种事情。它们的主要作用是在应用启动后执行一段初始化或任务逻辑，常见于一些启动任务，例如加载数据、验证配置等等。今天我们就来聊聊这两个接口在实际开发中是怎么使用的。

二、使用方式

我们直接看示例代码：

@Component

public class CommandLineRunnerDemo implements CommandLineRunner {

    @Override

    public void run(String... args) throws Exception {

        //执行特定的代码

        System.out.println("执行特定的代码");

    }

}

@Component

public class ApplicationRunnerDemo implements ApplicationRunner {

    @Override

    public void run(ApplicationArguments args) throws Exception {

        System.out.println("ApplicationRunnerDemo.run");

    }

}

从源码上分析，CommandLineRunner与ApplicationRunner两者之间只有run()方法的参数不一样而已。CommandLineRunner#run()方法的参数是启动SpringBoot应用程序main方法的参数列表，而ApplicationRunner#run()方法的参数则是ApplicationArguments对象。

如果我们有多个类实现CommandLineRunner或ApplicationRunner接口，可以通过Ordered接口控制执行顺序。下面以ApplicationRunner接口为例子：

直接启动看效果：

可以看到order值越小，越先被执行。

传递参数

Spring Boot应用启动时是可以接受参数的，这些参数通过命令行 java -jar app.jar 来传递。CommandLineRunner会原封不动照单全收这些参数，这些参数也可以封装到ApplicationArguments对象中供ApplicationRunner调用。下面我们来看一下ApplicationArguments的相关方法：

• getSourceArgs() 被传递给应用程序的原始参数，返回这些参数的字符串数组。


• getOptionNames() 获取选项名称的Set字符串集合。如 --spring.profiles.active=dev --debug 将返回["spring.profiles.active","debug"] 。


• getOptionValues(String name) 通过名称来获取该名称对应的选项值。如--config=dev --config=test 将返回["dev","eat"]。


• containsOption(String name) 用来判断是否包含某个选项的名称。


• getNonOptionArgs() 用来获取所有的无选项参数。

三、总结

CommandLineRunner 和 ApplicationRunner 常用于应用启动后的初始化任务或一次性任务执行。它们允许你在 Spring 应用启动完成后立即执行一些逻辑。ApplicationRunner 更适合需要处理命令行参数的场景，而 CommandLineRunner 更简单直接。

上周，我们组里来了个新同事，看我噼里啪啦地在黑窗口里敲git命令，他很好奇地问我：

“哥，现在VS Code自带的Git工具那么好用，还有Sourcetree、GitKraken这些，你为什么还坚持用命令行啊？不觉得麻烦吗？”

这个问题问得很好。

我完全承认，现代的Git GUI工具做得非常出色，它们直观、易上手，尤其是在处理简单的提交和查看分支时，确实很方便。我甚至会推荐刚接触Git的新人，先从GUI开始，至少能对Git的工作流程有个直观的感受。

但用了8年Git，我最终还是回到了纯命令行。

这不是因为我守旧，也不是为了显得自己多“牛皮”。而是因为我发现，命令行在三个方面，给了我GUI无法替代的价值：速度、能力和理解。

这篇文章，就想聊聊我的一些观点。

速度

对于我们每天要用上百次的工具来说，零点几秒的效率提升，累加起来也是巨大的。在执行高频的、重复性的操作时，键盘的速度，永远比“移动鼠标 -> 寻找目标 -> 点击”这个流程要快。

• 一个最简单的commit & push流程：
  
  
  
  
  • 我的命令行操作：git add . -> git commit -m "..." -> git push。配合zsh/oh-my-zsh的自动补全和历史记录，我敲这几个命令可能只需要3-5秒，眼睛甚至不用离开代码。
  
  
  • GUI操作：我需要在VS Code里切换到Git面板 -> 鼠标移动到“更改”列表 -> 点击“+”号暂存全部 -> 鼠标移动到输入框 -> 输入信息 -> 点击“提交”按钮 -> 再点击“同步更改”按钮。
  
  
  
  

这个过程，再快也快不过我的肌肉记忆。

• 更高效的别名（Alias）：
  
  

  ~/.gitconfig文件是我的宝库。我在里面配置了大量的别名，把那些长长的命令，都缩短成了两三个字母。

  
  

  [alias]
  
      st = status
  
      co = checkout
  
      br = branch
  
      ci = commit
  
      lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
  
  

  
  

  现在，我只需要敲git st就能看状态，git lg就能看到一个非常清晰的分支图。这种个性化定制带来的效率提升，是GUI工具无法给予的。

深入Git

GUI工具做得再好，它本质上也是对Git核心功能的一层“封装”。它会优先把最常用的80%功能，做得非常漂亮。但Git那剩下20%的、极其强大的、但在特定场景下才能发挥作用的高级工具，很多GUI工具并没有提供，或者藏得很深。

而命令行，能让你100%地释放Git的全部能力。

• git rebase -i (交互式变基)：
  
  

  这是我认为命令行最具杀手级的应用之一。当我想清理一个分支的提交记录时，比如合并几个commit、修改commit信息、调整顺序，git rebase -i提供的那个类似Vim编辑器的界面，清晰、高效，能让我像做手术一样精确地操作提交历史。



• git reflog (你的后悔药)：
  
  

  reflog记录了你本地仓库HEAD的所有变化。有一次，我错误地执行了git reset --hard，把一个重要的commit给搞丢了。当时有点慌，但一句git reflog，立刻就找到了那个丢失的commit的哈希值，然后用git cherry-pick把它找了回来。这个救命的工具，很多GUI里甚至都没有入口。



• git bisect (二分法查Bug)：
  
  

  当你想找出是哪个commit引入了一个Bug时，git bisect是你的神器。它会自动用二分法，不断地切换commit让你去验证，能极大地缩小排查范围。这种高级的调试功能，几乎是命令行用户的专属。

会用到理解

这一点，是我认为最核心的。

GUI工具，把Git包装成了一系列按钮，它在帮你隐藏细节。

你点击“拉取（Pull）”，它可能在背后执行了git fetch + git merge，也可能是git fetch + git rebase。你不清楚，也不需要清楚，点就完事了。

这在一切顺利时没问题。但一旦出现复杂的合并冲突，或者你需要回滚一个错误的操作，按钮就不够用了。因为你不理解按钮背后的原理，你不知道Git的HEAD、工作区、暂存区到底处于一个什么状态，你就会感到恐慌，甚至会因为误操作，把仓库搞得一团糟。

而命令行，强迫你去学习和理解Git的每一个动作和它背后的模型。

你输入的每一个命令，git reset --hard和git reset --soft的区别是什么？git merge和git rebase的数据流向有什么不同？每一次的输入，都在加深你对Git三区（工作区、暂存区、版本库）模型的理解。

这种对底层模型的深刻理解，才是一个资深工程师真正需要具备的。它能让我在遇到任何复杂情况时，都心里有底，知道该用哪个命令去精确地解决问题。

我从不要求我们组里的新人都用命令行，但我会鼓励他们，在熟悉了GUI之后，一定要花时间去学习一下命令行。

这不仅仅是一个工具选择的问题，更是一个思维方式的选择。

对我来说，用命令行，让我感觉我是在和Git这个工具直接对话。这种掌控感和确定性，是任何漂亮的UI都无法带给我的。

也许，这就是一个程序员的执念吧😀。

实现一个简化版的状态机框架

我将为你设计一个简化版的状态机框架，包含状态、事件、转换机制，并支持插件扩展功能。这个实现会参考Spring StateMachine的设计理念。

核心组件设计

// 状态枚举接口

public interface State {

    String getId();

}



// 事件枚举接口

public interface Event {

    String getId();

}



// 状态上下文

public class StateContext<S extends State, E extends Event> {

    private S currentState;

    private E event;

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

    

    // 获取当前状态

    public S getCurrentState() {

        return currentState;

    }

    

    // 设置当前状态

    public void setCurrentState(S currentState) {

        this.currentState = currentState;

    }

    

    // 获取触发事件

    public E getEvent() {

        return event;

    }

    

    // 设置触发事件

    public void setEvent(E event) {

        this.event = event;

    }

    

    // 获取扩展状态数据

    public Map<String, Object> getExtendedState() {

        return extendedState;

    }

    

    // 添加扩展状态数据

    public void addExtendedState(String key, Object value) {

        extendedState.put(key, value);

    }

    

    // 获取特定扩展状态数据

    public Object getExtendedState(String key) {

        return extendedState.get(key);

    }

}



// 状态转换接口

public interface Transition<S extends State, E extends Event, C extends StateContext<S, E>> {

    boolean isTriggered(C context);

    S getSource();

    S getTarget();

    void executeActions(C context);

}



// 状态机接口

public interface StateMachine<S extends State, E extends Event, C extends StateContext<S, E>> {

    S getCurrentState();

    void sendEvent(E event, Map<String, Object> extendedState);

    void addListener(StateMachineListener<S, E, C> listener);

    void addTransition(Transition<S, E, C> transition);

}



// 状态机监听器

public interface StateMachineListener<S extends State, E extends Event, C extends StateContext<S, E>> {

    void stateChanged(S from, S to);

    void eventAccepted(E event);

    void transitionStarted(Transition<S, E, C> transition);

    void transitionCompleted(Transition<S, E, C> transition);

}

基础实现

// 枚举状态实现

public enum SimpleState implements State {

    INITIAL("INIT"),

    PROCESSING("PROCESS"),

    COMPLETED("COMPLETE"),

    ERROR("ERR");

    

    private String id;

    

    SimpleState(String id) {

        this.id = id;

    }

    

    @Override

    public String getId() {

        return id;

    }

}



// 枚举事件实现

public enum SimpleEvent implements Event {

    START_PROCESS("START"),

    FINISH_PROCESS("FINISH"),

    ERROR_OCCURRED("ERROR");

    

    private String id;

    

    SimpleEvent(String id) {

        this.id = id;

    }

    

    @Override

    public String getId() {

        return id;

    }

}



// 基础状态机实现

public class BasicStateMachine<S extends State, E extends Event, C extends StateContext<S, E>>

        implements StateMachine<S, E, C> {

    

    private S currentState;

    private List<Transition<S, E, C>> transitions = new ArrayList<>();

    private List<StateMachineListener<S, E, C>> listeners = new ArrayList<>();

    private StateMachineLogger logger = new StateMachineLogger();

    

    public BasicStateMachine(S initialState) {

        this.currentState = initialState;

    }

    

    @Override

    public S getCurrentState() {

        return currentState;

    }

    

    @Override

    public void sendEvent(E event, Map<String, Object> extendedState) {

        logger.log("Processing event: " + event.getId());

        

        // 创建状态上下文

        StateContext<S, E> context = createContext(event, extendedState);

        

        // 通知监听器事件已接受

        notifyEventAccepted(event);

        

        // 查找并执行适用的转换

        for (Transition<S, E, C> transition : transitions) {

            if (transition.getSource().getId().equals(currentState.getId()) && transition.isTriggered((C) context)) {

                logger.log("Executing transition from " + currentState.getId() + " on " + event.getId());

                

                // 通知监听器转换开始

                notifyTransitionStarted(transition);

                

                // 执行转换动作

                transition.executeActions((C) context);

                

                // 更新当前状态

                currentState = transition.getTarget();

                

                // 通知监听器状态改变

                notifyStateChanged(transition.getSource(), transition.getTarget());

                

                // 通知监听器转换完成

                notifyTransitionCompleted(transition);

                

                break;

            }

        }

    }

    

    private StateContext<S, E> createContext(E event, Map<String, Object> extendedState) {

        StateContext<S, E> context = new StateContext<>();

        context.setCurrentState(currentState);

        context.setEvent(event);

        

        if (extendedState != null) {

            extendedState.forEach((key, value) -> context.addExtendedState(key, value));

        }

        

        return context;

    }

    

    @Override

    public void addListener(StateMachineListener<S, E, C> listener) {

        listeners.add(listener);

    }

    

    @Override

    public void addTransition(Transition<S, E, C> transition) {

        transitions.add(transition);

    }

    

    // 通知状态改变

    private void notifyStateChanged(S from, S to) {

        listeners.forEach(listener -> listener.stateChanged(from, to));

    }

    

    // 通知事件接受

    private void notifyEventAccepted(E event) {

        listeners.forEach(listener -> listener.eventAccepted(event));

    }

    

    // 通知转换开始

    private void notifyTransitionStarted(Transition<S, E, C> transition) {

        listeners.forEach(listener -> listener.transitionStarted(transition));

    }

    

    // 通知转换完成

    private void notifyTransitionCompleted(Transition<S, E, C> transition) {

        listeners.forEach(listener -> listener.transitionCompleted(transition));

    }

    

    // 日志工具类

    private static class StateMachineLogger {

        public void log(String message) {

            System.out.println("[StateMachine] " + message);

        }

    }

}