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。

开心一刻

今天心情不好，给哥们发语音

我：哥们，晚上出来喝酒聊天吧

哥们：咋啦，心情不好？

我：嗯，刚刚在公交车上看见前女友了

哥们：然后呢？

我：给她让座时，发现她怀孕了...

哥们：所以难受了？

我：不是她怀孕让我难受，是她怀孕还坐公交车让我难受

哥们：不是，她跟着你就不用坐公交车了？不还是也要坐，有区别吗？

我默默的挂断了语音，心情更难受了

Java开发手册

作为一个 javaer，我们肯定看过 Alibaba 的 Java开发手册，作为国内Java开发领域的标杆性编码规范，我们或多或少借鉴了其中的一些规范，其中有一点

我印象特别深，也一直在奉行，自己还从未试过用 is 作为布尔类型变量的前缀，不知道会有什么坑；正好前段时间同事这么用了，很不幸，他挖坑，我踩坑，阿西吧！

is前缀的布尔变量有坑

为了复现问题，我先简单搞个 demo；调用很简单，服务 workflow 通过 openfeign 调用 offline-sync，代码结构如下

qsl-data-govern-common：整个项目的公共模块

qsl-offline-sync：离线同步

• qsl-offline-sync-api：向外提供 openfeign 接口


• qsl-offline-sync-common：离线同步公共模块


• qsl-offline-sync-server：离线同步服务

qsl-workflow：工作流

• qsl-workflow-api：向外提供 openfeign 接口，暂时空实现


• qsl-workflow-common：工作流公共模块


• qsl-workflow-server：工作流服务

完整代码：qsl-data-govern

qsl-offline-sync-server 提供删除接口

/**

 * @author 青石路

 */

@RestController

@RequestMapping("/task")

public class SyncTaskController {



    private static final Logger LOG = LoggerFactory.getLogger(SyncTaskController.class);



    @PostMapping("/delete")

    public ResultEntity<String> delete(@RequestBody SyncTaskDTO syncTask) {

        // TODO 删除处理

        LOG.info("删除任务[taskId={}]", syncTask.getTaskId());

        return ResultEntity.success("删除成功");

    }

}

qsl-offline-sync-api 对外提供 openfeign 接口

/**

 * @author 青石路

 */

@FeignClient(name = "data-govern-offline-sync", contextId = "dataGovernOfflineSync", url = "${offline.sync.server.url}")

public interface OfflineSyncApi {



    @PostMapping(value = "/task/delete")

    ResultEntity<String> deleteTask(@RequestBody SyncTaskDTO syncTaskDTO);

}

qsl-workflow-server 调用 openfeign 接口

/**

 * @author 青石路

 */

@RestController

@RequestMapping("/definition")

public class WorkflowController {



    private static final Logger LOG = LoggerFactory.getLogger(WorkflowController.class);



    @Resource

    private OfflineSyncApi offlineSyncApi;



    @PostMapping("/delete")

    public ResultEntity<String> delete(@RequestBody WorkflowDTO workflow) {

        LOG.info("删除工作流[workflowId={}]", workflow.getWorkflowId());

        // 1.查询工作流节点，查到离线同步节点（taskId = 1）

        // 2.删除工作流节点，删除离线同步节点

        ResultEntity<String> syncDeleteResult = offlineSyncApi.deleteTask(new SyncTaskDTO(1L));

        if (syncDeleteResult.getCode() != 200) {

            LOG.error("删除离线同步任务[taskId={}]失败：{}", 1, syncDeleteResult.getMessage());

            ResultEntity.fail(syncDeleteResult.getMessage());

        }

        return ResultEntity.success("删除成功");

    }

}

逻辑是不是很简单？我们启动两个服务，然后发起 http 请求

POST http://localhost:8081/data-govern/workflow/definition/delete
Content-Type: application/json

{
"workflowId": 99
}

此时 qsl-offline-sync-server 日志输出如下

2025-06-30 14:53:06.165|INFO|http-nio-8080-exec-4|25|c.q.s.s.controller.SyncTaskController :删除任务[taskId=1]

至此，一切都很正常，第一版也是这么对接的；后面 offline-sync 进行调整，删除接口增加了一个参数：isClearData

public class SyncTaskDTO {



    public SyncTaskDTO(){}



    public SyncTaskDTO(Long taskId, Boolean isClearData) {

        this.taskId = taskId;

        this.isClearData = isClearData;

    }



    private Long taskId;

    private Boolean isClearData = false;



    public Long getTaskId() {

        return taskId;

    }



    public void setTaskId(Long taskId) {

        this.taskId = taskId;

    }



    public Boolean getClearData() {

        return isClearData;

    }



    public void setClearData(Boolean clearData) {

        isClearData = clearData;

    }

}

然后实现对应的逻辑

/**

 * @author 青石路

 */

@RestController

@RequestMapping("/task")

public class SyncTaskController {



    private static final Logger LOG = LoggerFactory.getLogger(SyncTaskController.class);



    @PostMapping("/delete")

    public ResultEntity<String> delete(@RequestBody SyncTaskDTO syncTask) {

        // TODO 删除处理

        LOG.info("删除任务[taskId={}]", syncTask.getTaskId());

        if (syncTask.getClearData()) {

            LOG.info("清空任务[taskId={}]历史数据", syncTask.getTaskId());

            // TODO 清空历史数据

        }

        return ResultEntity.success("删除成功");

    }

}

调整完之后，同事通知我，让我做对 qsl-workflow 做对应的调整。调整很简单，qsl-workflow 删除时直接传 true 即可

/**

 * @author 青石路

 */

@RestController

@RequestMapping("/definition")

public class WorkflowController {



    private static final Logger LOG = LoggerFactory.getLogger(WorkflowController.class);



    @Resource

    private OfflineSyncApi offlineSyncApi;



    @PostMapping("/delete")

    public ResultEntity<String> delete(@RequestBody WorkflowDTO workflow) {

        LOG.info("删除工作流[workflowId={}]", workflow.getWorkflowId());

        // 1.查询工作流节点，查到离线同步节点（taskId = 1）

        // 2.删除工作流节点，删除离线同步节点

        // 删除离线同步任务，isClearData直接传true

        ResultEntity<String> syncDeleteResult = offlineSyncApi.deleteTask(new SyncTaskDTO(1L, true));

        if (syncDeleteResult.getCode() != 200) {

            LOG.error("删除离线同步任务[taskId={}]失败：{}", 1, syncDeleteResult.getMessage());

            ResultEntity.fail(syncDeleteResult.getMessage());

        }

        return ResultEntity.success("删除成功");

    }

}

调整完成之后，发起 http 请求，发现历史数据没有被清除，看日志发现

LOG.info("清空任务[taskId={}]历史数据", syncTask.getTaskId());

没有打印，参数明明传的是 true 吖！！！

offlineSyncApi.deleteTask(new SyncTaskDTO(1L, true));

这是哪里出了问题？

问题排查

因为 qsl-offline-sync-api 是直接引入的，并非我实现的，所以我第一时间找到了其实现者，反馈了问题后让其自测下；一开始他还很自信，说这么简单怎么会有问题

当他启动 qsl-offline-sync-server 后，发起 http 请求

POST http://localhost:8080/data-govern/sync/task/delete
Content-Type: application/json

{
"taskId": 123,
"isClearData": true
}

发现 isClearData 的值是 false

此刻，疑问从我的额头转移到了他的额头上，他懵逼了，我轻松了。为了功能能够正常交付，我还是决定看下这个问题，没有了心理压力，也许更容易发现问题所在。第一眼看到 isClearData，我就隐约觉得有问题，所以我决定仔细看下 SyncTaskDTO 这个类，发现 isClearData 的 setter 和 getter 方法有点不一样

private Boolean isClearData = false;



public Boolean getClearData() {

    return isClearData;

}



public void setClearData(Boolean clearData) {

    isClearData = clearData;

}

方法名是不是少了 Is？带着这个疑问我找到了同事，问他 setter 、getter 为什么要这么命名？他说是 idea 工具自动生成的（也就是我们平时用到的idea自动生成setter、getter方法的功能）

我让他把 Is 补上试试

private Boolean isClearData = false;



public Boolean getIsClearData() {

    return isClearData;

}



public void setIsClearData(Boolean isClearData) {

    this.isClearData = isClearData;

}

发现传值正常了，他回过头看着我，我看着他，两人同时提问

他：为什么加了 Is 就可以了？

我：布尔类型的变量，你为什么要加 is 前缀？

问题延申

作为一个严谨的开发，不只是要知其然，更要知其所以然；关于

为什么加了 Is 就可以了

这个问题，我们肯定是要会上一会的；会这个问题之前，我们先来捋一下参数的流转，因为是基于 Spring MVC 实现的 Web 应用，所以我们可以这么问 deepseek

Spring MVC 是如何将前端参数转换成POJO的

能够查到如下重点信息

RequestResponseBodyMethodProcessor 的 resolveArgument

/**

 * Throws MethodArgumentNotValidException if validation fails.

 * @throws HttpMessageNotReadableException if {@link RequestBody#required()}

 * is {@code true} and there is no body content or if there is no suitable

 * converter to read the content with.

 */

@Override

public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,

        NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {



    parameter = parameter.nestedIfOptional();

    Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());

    String name = Conventions.getVariableNameForParameter(parameter);



    if (binderFactory != null) {

        WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);

        if (arg != null) {

            validateIfApplicable(binder, parameter);

            if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {

                throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());

            }

        }

        if (mavContainer != null) {

            mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());

        }

    }



    return adaptArgumentIfNecessary(arg, parameter);

}

正是解析参数的地方，我们打个断点，再发起一次 http 请求

很明显，readWithMessageConverters 是处理并转换参数的地方，继续跟进去会来到 MappingJackson2HttpMessageConverter 的 readJavaType 方法

此刻我们可以得到，是通过 jackson 完成数据绑定与数据转换的。继续跟进，会看到 isClearData 的赋值过程

通过前端传过来的参数 isClearData 找对应的 setter方法是 setIsClearData，而非 setClearData，所以问题

为什么加了 Is 就可以了

是不是就清楚了？

问题解决

总结

前言

核心痛点：业务规则高频变更与系统稳定性之间的矛盾

想象一个电商促销场景：

// 传统硬编码方式（噩梦开始...）

public BigDecimal calculateDiscount(Order order) {

    BigDecimal discount = BigDecimal.ZERO;

    

    if (order.getTotalAmount().compareTo(new BigDecimal("100")) >= 0) {

        discount = discount.add(new BigDecimal("10"));

    }

    

    if (order.getUser().isVip()) {

        discount = discount.add(new BigDecimal("5"));

    }

    

    // 更多if-else嵌套...

    return discount;

}

当规则变成："非VIP用户满200减30，VIP用户满150减40，且周二全场额外95折"时，代码将陷入维护地狱！

规则引擎通过分离规则逻辑解决这个问题：

1. 规则外置存储（数据库/文件）
2. 支持动态加载
3. 声明式规则语法
4. 独立执行环境

下面给大家分享5种常用的规则引擎，希望对你会有所帮助。

最近准备面试的小伙伴，可以看一下这个宝藏网站（Java突击队）：www.susan.net.cn，里面：面试八股文、场景题、面试真题、项目实战、工作内推什么都有。

1.五大常用规则引擎

1.1 Drools：企业级规则引擎扛把子

官网：http://www.drools.org/

适用场景：

• 金融风控规则（上百条复杂规则）
• 保险理赔计算
• 电商促销体系

实战：折扣规则配置

// 规则文件 discount.drl

rule "VIP用户满100减20"

    when

        $user: User(level == "VIP")

        $order: Order(amount > 100)

    then

        $order.addDiscount(20);

end

Java调用代码：

KieServices kieServices = KieServices.Factory.get();

KieContainer kContainer = kieServices.getKieClasspathContainer();

KieSession kSession = kContainer.newKieSession("discountSession");



kSession.insert(user);

kSession.insert(order);

kSession.fireAllRules();

优点：

• 完整的RETE算法实现
• 支持复杂的规则网络
• 完善的监控管理控制台

缺点：

• 学习曲线陡峭
• 内存消耗较大
• 需要依赖Kie容器

适合：不差钱的大厂，规则复杂度高的场景

1.2 Easy Rules：轻量级规则引擎之王

官网：github.com/j-easy/easy…

适用场景：

• 参数校验
• 简单风控规则
• 审批流引擎

注解式开发：

@Rule(name = "雨天打折规则", description = "下雨天全场9折")

public class RainDiscountRule {



    @Condition

    public boolean when(@Fact("weather") String weather) {

        return "rainy".equals(weather);

    }

    

    @Action

    public void then(@Fact("order") Order order) {

        order.setDiscount(0.9);

    }

}

引擎执行：

RulesEngineParameters params = new RulesEngineParameters()

    .skipOnFirstAppliedRule(true); // 匹配即停止



RulesEngine engine = new DefaultRulesEngine(params);

engine.fire(rules, facts);

优点：

• 五分钟上手
• 零第三方依赖
• 支持规则组合

缺点：

• 不支持复杂规则链
• 缺少可视化界面

适合：中小项目快速落地，开发人员不足时

1.3 QLExpress：阿里系脚本引擎之光

官网：github.com/alibaba/QLE…

适用场景：

• 动态配置计算逻辑
• 财务公式计算
• 营销规则灵活变更

执行动态脚本：

ExpressRunner runner = new ExpressRunner();

DefaultContext context = new DefaultContext<>();

context.put("user", user);

context.put("order", order);



String express = "if (user.level == 'VIP') { order.discount = 0.85; }";

runner.execute(express, context, null, true, false);

高级特性：

// 1. 函数扩展

runner.addFunction("计算税费", new Operator() {

    @Override

    public Object execute(Object[] list) {

        return (Double)list[0] * 0.06;

    }

});



// 2. 宏定义

runner.addMacro("是否新用户", "user.regDays < 30");

优点：

• 脚本热更新
• 语法接近Java
• 完善的沙箱安全

缺点：

• 调试困难
• 复杂规则可读性差

适合：需要频繁修改规则的业务（如运营活动）

1.4 Aviator：高性能表达式专家

官网：github.com/killme2008/…

适用场景：

• 实时定价引擎
• 风控指标计算
• 大数据字段加工

性能对比（执行10万次）：

// Aviator 表达式

Expression exp = AviatorEvaluator.compile("user.age > 18 && order.amount > 100");

exp.execute(map);



// Groovy 脚本

new GroovyShell().evaluate("user.age > 18 && order.amount > 100"); 

引擎	耗时
Aviator	220ms
Groovy	1850ms

编译优化：

// 开启编译缓存（默认开启）

AviatorEvaluator.getInstance().useLRUExpressionCache(1000);



// 字节码生成模式（JDK8+）

AviatorEvaluator.setOption(Options.ASM, true);

优点：

• 性能碾压同类引擎
• 支持字节码生成
• 轻量无依赖

缺点：

• 只支持表达式
• 不支持流程控制

适合：对性能有极致要求的计算场景

这里有复杂的商城项目实战，使用技术：SpringBoot、Spring Security、MySQL、Mybatis、shardingsphere、Nacos、JWT、ElasticSearch、Redis、RocketMQ、MongoDB、Caffeine、FreeMaker、Redisson、Minio、WebSocket、hanlp、mahout、jsoup、Docker等等，非常值得一看

1.5 LiteFlow：规则编排新物种

官网：liteflow.com/

适用场景：

• 复杂业务流程
• 订单状态机
• 审核工作流

编排示例：

<chain name="orderProcess">

    <then value="checkStock,checkCredit"/> 

    <when value="isVipUser"> 

        <then value="vipDiscount"/> 

    when>

    <otherwise>

        <then value="normalDiscount"/>

    otherwise>

    <then value="saveOrder"/>

chain>

Java调用：

LiteflowResponse response = FlowExecutor.execute2Resp("orderProcess", order, User.class);

if (response.isSuccess()) {

    System.out.println("流程执行成功");

} else {

    System.out.println("失败原因：" + response.getCause());

}

优点：

• 可视化流程编排
• 支持异步、并行、条件分支
• 热更新规则

缺点：

• 新框架文档较少
• 社区生态待完善

适合：需要灵活编排的复杂业务流

2 五大规则引擎横向评测

性能压测数据（单机1万次执行）：

引擎	耗时	内存占用	特点
Drools	420ms	高	功能全面
Easy Rules	38ms	低	轻量易用
QLExpress	65ms	中	阿里系脚本引擎
Aviator	28ms	极低	高性能表达式
LiteFlow	120ms	中	流程编排专家

3 如何技术选型？

黄金法则：

1. 简单场景：EasyRules + Aviator 组合拳
2. 金融风控：Drools 稳如老狗
3. 电商运营：QLExpress 灵活应变
4. 工作流驱动：LiteFlow 未来可期

4 避坑指南

1. Drools内存溢出

// 设置无状态会话（避免内存积累）

KieSession session = kContainer.newStatelessKieSession();

2. QLExpress安全漏洞

// 禁用危险方法

runner.addFunctionOfServiceMethod("exit", System.class, "exit", null, null);

3. 规则冲突检测

// Drools冲突处理策略

KieSessionConfiguration config = KieServices.Factory.get().newKieSessionConfiguration();

config.setProperty("drools.sequential", "true"); // 按顺序执行

总结

1. 能用：替换if/else（新手村）
2. 用好：规则热更新+可视化（进阶）
3. 用精：规则编排+性能优化（大师级）

曾有人问我：“规则引擎会不会让程序员失业？” 我的回答是：“工具永远淘汰不了思考者，只会淘汰手工作坊”。

真正的高手，不是写更多代码，而是用更优雅的方式解决问题。

最后送句话：技术选型没有最好的，只有最合适的。

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

作者：苏三说技术
来源：juejin.cn/post/7517854096175988762

需求详细描述：用户登录成功后，默认带入10min的初始值，可针对该用户进行单独设置，单位：分钟，设置范围：1-15，用户在系统没有操作后满足该时长自动退出登录；

疑问：怎么判断用户在10分钟内有没有操作？

实现步骤

✅ 一、功能点描述:
默认超时时间,登录后默认为 10 分钟，
支持自定义设置 用户可修改自己的超时时间（1~15 分钟）
自动登出逻辑 用户在设定时间内没有“操作”，就触发登出.

✅ 二、关键问题：如何判断用户是否操作了？

🔍 操作的定义：
这里的“操作”可以理解为任何与页面交互的行为，
例如：
点击按钮、
鼠标移动、
键盘输入、
页面滚动、路由变化等。

✅ 三、解决方案：
使用全局事件监听器来检测用户的活跃状态，并重置计时器。

✅ 四、实现思路（Vue3 + Composition API）
我们可以通过以下步骤实现：

1. 定义一个响应式的 inactivityTime 变量（单位：分钟）

const inactivityTime = ref(10); // 默认10分钟

2. 创建一个定时器变量

let logoutTimer = null;

3. 重置定时器函数

function resetTimer() {

  if (logoutTimer) {

    clearTimeout(logoutTimer);

  }



  logoutTimer = setTimeout(() => {

    console.log('用户已超时，执行登出');

    // 这里执行登出操作，如清除 token、跳转到登录页等

    store.dispatch('logout'); // 假设你用了 Vuex/Pinia

  }, inactivityTime.value * 60 * 1000); // 转换为毫秒

}

4. 监听用户活动并重置定时器

function setupActivityListeners() {

  const events = ['click', 'mousemove', 'keydown', 'scroll', 'touchstart'];



  events.forEach(event => {

    window.addEventListener(event, resetTimer, true);

  });

}



function removeActivityListeners() {

  const events = ['click', 'mousemove', 'keydown', 'scroll', 'touchstart'];



  events.forEach(event => {

    window.removeEventListener(event, resetTimer, true);

  });

}

5. 在组件挂载时初始化定时器和监听器

<script setup>

import { ref, onMounted, onUnmounted } from 'vue';

import { useRouter } from 'vue-router';



const router = useRouter();

const inactivityTime = ref(10); // 默认10分钟

let logoutTimer = null;



function resetTimer() {

  if (logoutTimer) {

    clearTimeout(logoutTimer);

  }



  logoutTimer = setTimeout(() => {

    alert('由于长时间未操作，您已被自动登出');

    localStorage.removeItem('token'); // 清除 token

    router.push('/login'); // 跳转到登录页

  }, inactivityTime.value * 60 * 1000);

}



function setupActivityListeners() {

  const events = ['click', 'mousemove', 'keydown', 'scroll', 'touchstart'];

  events.forEach(event => {

    window.addEventListener(event, resetTimer, true);

  });

}



function removeActivityListeners() {

  const events = ['click', 'mousemove', 'keydown', 'scroll', 'touchstart'];

  events.forEach(event => {

    window.removeEventListener(event, resetTimer, true);

  });

}



onMounted(() => {

  setupActivityListeners();

  resetTimer(); // 初始化定时器

});



onUnmounted(() => {

  removeActivityListeners();

  if (logoutTimer) clearTimeout(logoutTimer);

});

</script>

✅ 四、支持用户自定义设置（进阶）
你可以通过接口获取用户的个性化超时时间：

// 假设你从接口获取到了用户的设置

api.getUserSettings().then(res => {

  const userTimeout = res.autoLogoutTime; // 单位：分钟，假设值为 5-15

  if (userTimeout >= 1 && userTimeout <= 15) {

    inactivityTime.value = userTimeout;

    resetTimer(); // 更新定时器

  }

});

✅ 五、完整逻辑流程图（文字版）

✅ 六、注意事项
不要监听太少的事件,比如只监听 click，可能会漏掉键盘操作，
使用 true 参数添加事件监听器，表示捕获阶段监听，更可靠
多标签页场景,如果用户开了多个标签页，需考虑同步机制（比如使用 LocalStorage）
移动端适配,加入 touchstart 等移动端事件监听，
登出前最好加个提示，比如弹窗让用户选择是否继续会话。

✅ 七、推荐封装方式
你可以把这个逻辑封装成一个 Vue 自定义 Hook，例如 useAutoLogout.js，然后在需要的页面调用它即可。

// useAutoLogout.js

export function useAutoLogout(timeoutMinutes = 10) {

  let timer = null;



  function resetTimer() {

    if (timer) clearTimeout(timer);

    timer = setTimeout(() => {

      alert('由于长时间未操作，您已被自动登出');

      localStorage.removeItem('token');

      window.location.href = '/login';

    }, timeoutMinutes * 60 * 1000);

  }



  function setupListeners() {

    const events = ['click', 'mousemove', 'keydown', 'scroll', 'touchstart'];

    events.forEach(event => {

      window.addEventListener(event, resetTimer, true);

    });

  }



  function removeListeners() {

    const events = ['click', 'mousemove', 'keydown', 'scroll', 'touchstart'];

    events.forEach(event => {

      window.removeEventListener(event, resetTimer, true);

    });

  }



  onMounted(() => {

    setupListeners();

    resetTimer();

  });



  onUnmounted(() => {

    removeListeners();

    if (timer) clearTimeout(timer);

  });

}

然后在组件中：

import { useAutoLogout } from '@/hooks/useAutoLogout'



export default {

  setup() {

    useAutoLogout(10); // 设置默认10分钟

  }

}

✅ 八、总结：

实现方式：
判断用户是否有操作，监听 click、 mousemove、 keydown 等事件，
自动登出设置定时器，在无操作后触发，
用户自定义超时时间，接口获取后动态设置定时器时间，
页面间复用，封装为 Vue 自定义 Hook 更好维护。

使用优化

如果把它封装成一个自定义 Hook（如 useAutoLogout），这种写法确实需要在每个需要用到自动登出功能的页面里手动引入并调用它，麻烦且不优雅，不适合大型项目。

✅ 一、进阶方案：通过路由守卫自动注入
你可以利用 Vue Router 的 beforeEach 钩子，在用户进入页面时自动触发 useAutoLogout。
步骤如下：

// src/utils/autoLogout.js

import { useAutoLogout } from '@/hooks/useAutoLogout'



export function enableAutoLogout(timeout = 10) {

  useAutoLogout(timeout)

}

2. 在路由配置中使用 meta 标记是否启用自动登出

// src/router/index.js

import { createRouter, createWebHistory } from 'vue-router';

import { useAutoLogout } from '@/hooks/useAutoLogout';

import store from './store'; // 假设你有一个 Vuex 或 Pinia 状态管理库用于保存用户设置



const routes = [

  {

    path: '/dashboard',

    name: 'Dashboard',

    component: () => import('@/views/Dashboard.vue'),

    meta: { autoLogout: true } // 表示这个页面需要自动登出功能

  },

  {

    path: '/login',

    name: 'Login',

    component: () => import('@/views/Login.vue')

    // 不加 meta.autoLogout 表示不启用

  }

];



const router = createRouter({

  history: createWebHistory(),

  routes,

});



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

  if (to.meta.autoLogout) {

    // 获取用户的自定义超时时间

    let timeout = 10; // 默认值

    try {

      // 这里假设从后端获取用户的自定义超时时间

      const userSettings = await store.dispatch('fetchUserSettings'); // 根据实际情况调整

      timeout = userSettings.autoLogoutTime || timeout;

    } catch (error) {

      console.error("Failed to fetch user settings:", error);

    }



    // 使用自定义超时时间初始化或重置计时器

    const resetTimer = useAutoLogout(timeout);

    resetTimer(); // 初始设置计时器

  }

  next();

});



export default router;

⚠️ 注意事项：

• 组件实例：
  Vue 3 Composition API 中，不能直接在 beforeEach 中访问组件实例，需要把 enableAutoLogout 改为在组件内部调用，或者结合 Vuex/Pinia 做状态管理。


• 状态管理： 如果用户可以在应用运行期间更改其自动登出时间设置，你需要一种机制来实时更新这些设置。这通常涉及到状态管理库（如Vuex/Pinia）以及与后端同步用户偏好设置。


• 避免重复监听事件： 在每次导航时都添加新的事件监听器会导致内存泄漏。上述代码通过在组件卸载时移除监听器解决了这个问题，但如果你选择其他方式实现，请确保也处理了这一点。


• 用户体验: 在实际应用中，最好在即将登出前给用户提示，让用户有机会延长会话。

✅ 三、终极方案：创建一个全局插件（最优雅）
你可以把这个逻辑封装成一个 Vue 插件，这样只需要一次引入，就能全局生效。

示例：创建一个插件文件 autoLogoutPlugin.js

// src/plugins/autoLogoutPlugin.js

import { useAutoLogout } from '@/hooks/useAutoLogout'



export default {

  install: (app, options = {}) => {

    const timeout = options.timeout || 10



    app.mixin({

      setup() {

        useAutoLogout(timeout)

      }

    })

  }

}

使用插件：

// main.js

import AutoLogoutPlugin from './plugins/autoLogoutPlugin'



const app = createApp(App)



app.use(AutoLogoutPlugin, { timeout: 10 }) // 设置默认超时时间



app.mount('#app')

✅ 这样做之后，所有页面都会自动应用 useAutoLogout，无需手动导入。

插件使用解释

• ✅ export default 是一个 Vue 插件对象，必须包含 install 方法
  Vue 插件是一个对象，它提供了一个 install(app, options) 方法。这个方法会在你调用 app.use(Plugin) 的时候执行。


• ✅ install: (app, options = {}) => { ... }
  app: 是你的 Vue 应用实例（也就是通过 createApp(App) 创建的那个）
  options: 是你在调用 app.use(AutoLogoutPlugin, { timeout: 10 }) 时传入的配置项
  所以你可以在这里拿到你设置的超时时间 { timeout: 10 }。


• ✅ const timeout = options.timeout || 10
  这是一个默认值逻辑：如果用户传了 timeout，就使用用户的；
  否则使用默认值 10 分钟。


• ✅ app.mixin({ ... })
  这是关键部分！
  
  
  
  
  • 💡 什么是 mixin？
    mixin 是 Vue 中的“混入”，可以理解为：向所有组件中注入一些公共的逻辑或配置。
  
  
  • 举个例子：如果你有一个功能要在每个页面都启用，比如日志记录、权限检查、自动登出等，就可以用 mixin 实现一次写好，到处生效。
  
  
  • ✅ setup() 中调用 useAutoLogout(timeout)
    每个组件在创建时都会执行一次 setup() 函数。
    在这里调用 useAutoLogout(timeout)，相当于：
    在每一个页面组件中都自动调用了 useAutoLogout(10)
    也就是说，自动注册了监听器 + 自动设置了计时器
  
  
  
  


• 为什么这样就能全局监听用户操作？因为你在每个组件中都执行了 useAutoLogout(timeout)，而这个函数内部做了以下几件事：

function useAutoLogout(timeout) {

  // 设置定时器

  // 添加事件监听器（点击、移动鼠标、键盘输入等）

  // 组件卸载时清除监听器和定时器

}

因此，只要某个组件被加载，就会自动启动自动登出机制；组件卸载后，又会自动清理资源，避免内存泄漏。

总结一下整个流程

1️⃣ 在 main.js 中调用 app.use(AutoLogoutPlugin, { timeout: 10 })

2️⃣ 插件的 install() 被执行，获取到 timeout 值

3️⃣ 使用 app.mixin() 向所有组件中注入一段逻辑

4️⃣ 每个组件在 setup() 阶段自动调用 useAutoLogout(timeout)

5️⃣ 每个组件都注册了全局事件监听器，并设置了登出定时器
✅ 这样一来，所有组件页面都拥有了自动登出功能，不需要你手动去每个页面加代码。

注意事项

❗ 不是所有页面都需要自动登出 比如登录页、错误页可能不需要。可以在 mixin 中加判断，例如：根据路由或 meta 字段过滤
⚠️ 性能问题？ 不会有明显影响，因为只添加了一次监听器，且组件卸载时会清理
🔄 登录后如何动态更新超时时间？ 可以结合 Vuex/Pinia，在 store 改变时重新调用 useAutoLogout(newTimeout)
🧪 测试建议 手动测试几种情况：
• 页面切换是否重置计时
• 用户操作是否刷新倒计时
• 超时后是否跳转登录页

进阶建议：支持按需开启（可选）
如果你想只在某些页面启用自动登出功能，而不是全局启用，也可以这样改写：

app.mixin({

  setup() {

    // 判断当前组件是否启用了 autoLogout

    const route = useRoute()

    if (route.meta.autoLogout !== false) {

      useAutoLogout(timeout)

    }

  }

})

然后在路由配置中：

{

  path: '/dashboard',

  name: 'Dashboard',

  component: () => import('@/views/Dashboard.vue'),

  meta: { autoLogout: true }

}

最终效果你只需要在 main.js 中引入插件并配置一次：
app.use(AutoLogoutPlugin, { timeout: 10 })
就能让整个项目中的所有页面都拥有自动登出功能，无需在每个页面单独导入和调用。

✅ 四、总结对比

🟢 大型项目、统一行为控制，所有页面都启用自动登出 ➜ 推荐使用 插件方式

🟡 中型项目、统一管理页面行为，只在某些页面启用 ➜ 推荐使用 路由守卫 + meta

🔴 小型项目、部分页面控制，只在个别页面启用 ➜ 继续使用 手动调用

新闻中一直倡导的“不可信的Wi-Fi不要随便连接”，一直不知道里面的风险，即使是相关专业的从业人员，惭愧。探索后发现这里面的安全知识不少，记录下：

简单来说：

当用户连接上攻击者创建的伪造热点或者不可信的wifi后，实际上就进入了一个高度不可信的网络环境，攻击者可以进行各种信息窃取、欺骗和控制操作。

主要风险有：

🚨 1.中间人攻击（MITM）

攻击者拦截并转发你与网站服务器之间的数据，做到“你以为你连的是官网，其实中间有人”。

• 可窃取账号密码、聊天记录、信用卡信息


• 可篡改网页内容，引导你下载恶意应用

如果你和“正确”的网站之间是https，那么信息不会泄露，TLS能保证通信过程的安全，前提是你连接的这个https网站是“正确”的。正确的含义是：不是某些人恶意伪造的，不是一些不法份子通过DNS欺骗来重定向到的。

🪤 2.DNS欺骗 / 重定向

攻击者控制DNS，将合法网址解析到伪造网站。

• 你访问的“http://www.bank.com” 其实是假的银行网站，DNS域名解析到恶意服务上，返回和银行一样的登录的界面，这样用户输入账号密码就被窃取到了。


• 输入的账号密码被记录，后端没收到任何请求

这里多说一句：目前的登录方式中，采用短信验证码的方式，能避免真实的密码被窃取的风险，尽量用这种登录方式。

📥 3.强制HTTP连接，篡改内容

即使你访问的是HTTPS网站，攻击者可以强制降级为HTTP或注入恶意代码：

• 注入广告、木马脚本


• 启动钓鱼表单页面骗你输入账号密码

攻击者操作流程：

• 用户访问 http://example.com（明文）


• 攻击者拦截请求，阻止它跳转到 HTTPS


• 返回伪造页面（比如仿登录页面），引导用户输入账号密码


• 用户完全不知道自己并未进入 HTTPS 页面

这里“降级”的意思是，虽然你访问的是http网站，网站正常会转为https的访问方式，但是被阻止了，一直使用的是http协议访问，能实现这种降级的前提有两个：

• 用户没有直接输入 https://baidu.com， 而是输入的http://baidu.com, 依赖浏览器自动跳转


• 访问的网站没有开启 HSTS（HTTP Strict Transport Security）

搭建安全的网站的启示：

• 网站访问用https，并且如果用户访问HTTP网站时被自动转到 HTTPS 网站


• 网站要启用HSTS

HSTS 是一种告诉浏览器“以后永远都不要使用 HTTP 访问我”的机制。

如何开启HSTS？
添加响应头（核心方式）
。在你的网站服务端（如 Nginx、Apache、Spring Boot、Express 等）添加以下 HTTP 响应头：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

各参数含义如下：

网站实现http访问转为了https访问：

1 网站服务器配置了自动重定向（HTTP to HTTPS）

• 这是最常见的做法。网站后台（如 Nginx、Apache、Tomcat 等）配置了规则，凡是 HTTP 请求都会返回 301/302 重定向到 HTTPS 地址。


• 目的是强制用户用加密的 HTTPS 访问，保障数据安全。

2 请求的http response中加入HSTS机制

• 网站通过 HTTPS 响应头发送了 HSTS 指令。


• 浏览器收到后会记住该网站在一定时间内只能用 HTTPS 访问。


• 即使你输入 http://，浏览器也会自动用 https:// 访问，且不会发送 HTTP 请求。

📁 4.会话劫持（Session Hijacking）

如果你已登录某个网站（如微博/邮箱），攻击者可以窃取你与服务端之间的 Session Cookie，无需密码即可“冒充你”。

搭建web服务对于cookie泄密的安全启示：

1、开启 Cookie 的 Secure 和 HttpOnly

当一个 Cookie 设置了 Secure 标志后，它只会在 HTTPS 加密连接中发送，不会通过 HTTP 明文连接发送。

设置 HttpOnly 后，JavaScript 无法通过 document.cookie 访问该 Cookie，它只能被浏览器在请求时自动带上。如果站点存在跨站脚本漏洞（XSS），攻击者注入的 JS 可以读取用户的 Cookie。设置了 HttpOnly 后，即便 JS 被执行，也无法读取该 Cookie。

2、配合设置 SameSite=Strict 或 Lax 可进一步防止 CSRF 攻击。

Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnly

CSRF(Cross-Site Request Forgery) 攻击的原理示意

重点是：你在浏览器中访问A网站，浏览器中存储A的cookie，此时你访问恶意的B网站，B网站向A网站发送请求，浏览器一般默认带上A网站的cookie，因此，相当于B网站恶意使用了你在A网站的身份，完成了攻击，比如获取信息，比如添加东西。设置SameSite=Strict能防止跨站伪造攻击，对A网站的请求只能在A网站下发送，在B网站发起对A网站请求的无法使用A的cookie

同源策略和Cookie的关系：
同源策略限制的是脚本访问另一个域的内容（比如 JS 不能读取别的网站 Cookie 或响应数据），但浏览器发送请求时，会自动携带目标域对应的 Cookie（只要该 Cookie 未被 SameSite 限制）。 也就是说，请求可以跨域发送，Cookie 也会随请求自动发送，但脚本无法读取响应。在没有设置SameSite时，B网站是可以直接往A网站发送请求并附带上A网站的cookie的。

关于SameSite三种取值详解：

🛡 SameSite使用建议（最佳实践）

🧬 5.恶意软件传播

伪造热点可提供假的软件下载链接、更新提示等方式传播病毒或木马程序。

📡 6.网络钓鱼 + 社会工程攻击

攻击者可能弹出“需登录使用Wi-Fi”的界面，其实是钓鱼网站：

• 模拟常见的Wi-Fi登录界面（如酒店/机场门户）


• 用户一旦输入账号、手机号、验证码等敏感信息就被窃取

🔎 7.MAC地址、设备指纹收集

哪怕你没主动上网，连接伪热点后，攻击者也可能收集：

• 你的设备MAC地址、品牌型号


• 操作系统、语言、浏览器等指纹信息


• 用于后续追踪、精准广告投放，甚至诈骗定位

✅ 如何防范被伪热点攻击？

什么语言最适合用来游戏开发？

游戏开发，是一项结合了图形渲染、性能优化、系统架构与玩家体验的综合艺术，而“选用什么编程语言”这个问题，往往是新手开发者迈入这片领域时面临的第一个技术岔路口。

一、从需求出发：游戏开发对语言的核心要求

在选择语言之前，我们先明确一点：游戏类型不同，对语言的要求也大不一样。开发 3D AAA 大作和做一个像素风的休闲小游戏，使用的语言和引擎可能完全不同。

一般来说，语言选择需要考虑：