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

01 引言

长连接是业务项目中经常遇到的技术，往往用于数据向前端推送，如各种大屏、驾驶舱等实时数据的展示。单向推送可能会选择SSE，SSE因为AI时代的到来，逐步被大家熟知，而WebSocket作为经典的双向通讯，也经常被用来做数据推送。

今天聊一下，我发现的一种特殊的设计，可以单独将基于Netty的WebSocket单独部署，接入时，只需要引入API，初始化客户端即可完成对接。直接隔离了WebSocket服务端的编码。

02 普通应用

WebSocket的普通接入，需要编写WebSocket服务端。通过浏览器原生 API即可实现。

2.1 前端代码

浏览器原生的代码：

if ('WebSocket' in window) {

  const websocket = new WebSocket("ws://localhost:9090/testWs");

} else {

  alert('当前浏览器不支持 WebSocket');

}



websocket.onopen = function(event) {

  console.log('WebSocket 连接成功');

};



websocket.onmessage = function(event) {

  console.log('收到消息:', event.data);

};



websocket.onerror = function(error) {

  console.error('WebSocket 错误:', error);

};



websocket.onclose = function(event) {

  console.log('WebSocket 连接关闭');

};



// 发送消息

function sendMessage() {

  const message = document.getElementById('text').value;

  websocket.send(message);

}



// 关闭连接

function closeConnection() {

  websocket.close();

}

2.2 服务端代码

@Slf4j

@Component

public class WebSocketServer {



    @Getter

    private ChannelGr0up channelGr0up = new DefaultChannelGr0up(GlobalEventExecutor.INSTANCE);



    public void start() throws InterruptedException {

        EventLoopGr0up bossGr0up = new NioEventLoopGr0up();

        EventLoopGr0up workGr0up = new NioEventLoopGr0up();



        ServerBootstrap serverBootstrap = new ServerBootstrap();

        serverBootstrap.group(bossGr0up, workGr0up);

        serverBootstrap.channel(NioServerSocketChannel.class);

        serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>(){



            @Override

            protected void initChannel(SocketChannel socketChannel) throws Exception {

                ChannelPipeline pipeline = socketChannel.pipeline();

                pipeline.addLast(new HttpServerCodec());

                pipeline.addLast(new HttpObjectAggregator(65535));

                pipeline.addLast(new WebSocketServerProtocolHandler("/testWs"));

                // 自定义的handler，处理业务逻辑

                pipeline.addLast(new SimpleChannelInboundHandler<TextWebSocketFrame>() {



                    @Override

                    public void handlerAdded(ChannelHandlerContext ctx) throws Exception {

                        // 建立客户端

                        Channel channel = ctx.channel();

                        log.info("客户端建立连接：channelId={}", channel.id());

                        channelGr0up.add(channel);

                    }



                    @Override

                    public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {

                        // 断开链接

                        Channel channel = ctx.channel();

                        log.info("客户端断开连接：channelId={}", channel.id());

                        channelGr0up.remove(channel);

                    }



                    @Override

                    protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame msg) throws Exception {

                        // 接受消息

                        Channel channel = ctx.channel();

                        log.info("收到来自通道channelId[{}]发送的消息：{}", channel.id(), msg.text());



                        // 广播通知所有的客户端

                        channelGr0up.writeAndFlush(new TextWebSocketFrame("收到来自channelId[" + channel.id() + "]发送的消息：" + msg.text() + "123_"));

                    }

                });

            }

        });



        // 配置完成，开始绑定server，通过调用sync同步方法阻塞直到绑定成功

        ChannelFuture channelFuture = serverBootstrap.bind(9090).sync();

        log.info("Server started and listen on:{}",channelFuture.channel().localAddress());

        // 对关闭通道进行监听

        channelFuture.channel().closeFuture().sync();

    }

}

2.3 效果演示

为了方便演示，我直接使用在线测试工具：

webfem.com/tools/ws/in…

2.4 设计思想

设计如图：

这就是一个简单的点对点的一个设计。这样的设计本身没有什么问题，但是面对不同的业务系统都要接入WebSocket，我们就需要将服务端的代码复制一份，然后修改成适合自己业务项目的逻辑。

如果业务项目比较多，就会出现大量重复的代码，如我们公司就有20多个业务系统。从《代码重构》这本书中，就得知这是一种坏的味道，需要我们想办法优化。

如何来优化呢？按照阿里程序员的说话，没有什么是加一个中间层不能解决的，如果不能那就再加一层。

03 独特的设计

3.1 总览

如何通过中间层去解耦呢？

为了将WebSocket能够复用，就需要通过一个中间层能够作为一个传递者。既可以让用户直接连接WebSocket，也可以通过中间层直接推送消息。

我们来看看最终的设计流程：

3.2 流程分析

在流程分析执之前，我们需要说明引入的中间层。

• Socket中间客户端


• Socket服务

Socket中间客户端

Socket中间客户端作为一个jar传递于业务项目中，用来代替WebSocket直接推送消息给Socket客户端。同时也会将WebSocket服务的IP和端口暴露给客户端。

Socket中间客户端是基于Netty的Socket客户端，通过Bootstrap bootstrap = new Bootstrap()实例化，遵循TCP协议。详见代码。

Socket服务

为什么需要引入Socket服务呢？这也是小编之前非常疑惑的地方，直到自己搭建才知道为什么这么设计。

由于Socket中间客户端无法直接连接WebSocket，那么那就要一个完全基于TCP协议的Socket服务，就可以和Socket中间客户端建立连接。

而Socket服务和WebSocket位于同一个服务，就可以获取到WebSocket的所有通道（channel），就可以将消息推送给客户端了。

运行流程

• ① 客户端通过业务项目暴露的WebSOcket的IP和端口给前端，前端用来建立WebSocket连接。当着这个主要针对H5。类似安卓或者IOS有支持TCP的SDK，就可以直接连接Socket服务了。


• ② 随着业务项目启动建立与Socket服务的连接，等待随时给Socket服务发送消息。


• ③ Socket服务接收到消息后，直接获取WebSocket的通道。然后通过通道可以推送消息。


• ④ 获取到通道之后，就可以直接推送消息给前端了。

所以每次使用，只需要引入Jar，需要推送消息给客户端，只需要直接调用方法推送即可。

04 设计实现

4.1 WebSocket服务端

代码同2.2的代码

WebSocket服务的端口是9090

4.2 Socket服务端

@Slf4j

@Component

public class SockerServer {



    @Autowired

    private WebSocketServer webSocketServer;



    public void start() throws InterruptedException {

        EventLoopGr0up bossGr0up = new NioEventLoopGr0up();

        EventLoopGr0up workGr0up = new NioEventLoopGr0up();



        ServerBootstrap serverBootstrap = new ServerBootstrap();

        serverBootstrap.group(bossGr0up, workGr0up);

        serverBootstrap.channel(NioServerSocketChannel.class);

        serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>(){



            @Override

            protected void initChannel(SocketChannel socketChannel) throws Exception {

                ChannelPipeline pipeline = socketChannel.pipeline();

                pipeline.addLast(new DelimiterBasedFrameDecoder(2048, Unpooled.copiedBuffer("_".getBytes())));

                pipeline.addLast(new StringDecoder(StandardCharsets.UTF_8));

                pipeline.addLast(new StringEncoder(StandardCharsets.UTF_8));

                // 自定义的handler，处理业务逻辑

                pipeline.addLast(new SimpleChannelInboundHandler<>() {



                    @Override

                    public void handlerAdded(ChannelHandlerContext ctx) throws Exception {

                        // 建立客户端

                        Channel channel = ctx.channel();

                        log.info("Socket客户端建立连接：channelId={}", channel.id());

                    }



                    @Override

                    public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {

                        // 断开链接

                        Channel channel = ctx.channel();

                        log.info("Socket客户端断开连接：channelId={}", channel.id());

                    }



                    @Override

                    protected void channelRead0(ChannelHandlerContext ctx, Object msg) throws Exception {

                        // 接受消息

                        Channel channel = ctx.channel();

                        log.info("Socket收到来自通道channelId[{}]发送的消息：{}", channel.id(), msg);

                        // 通过WebSocket将方法发送给客户端

                        webSocketServer.getChannelGr0up().writeAndFlush(new TextWebSocketFrame("收到来自channelId[" + channel.id() + "]发送的消息：" + msg + "123_"));

                    }

                });

            }

        });



        // 配置完成，开始绑定server，通过调用sync同步方法阻塞直到绑定成功

        ChannelFuture channelFuture = serverBootstrap.bind(9091).sync();

        log.info("Server started and listen on:{}",channelFuture.channel().localAddress());

        // 对关闭通道进行监听

        channelFuture.channel().closeFuture().sync();

    }

}

Socket服务的端口是9091

4.3 Socket中间客户端

@Slf4j

public class MockClient {



    @Getter

    private SocketChannel socketChannel;



    public void connect() throws InterruptedException {

        EventLoopGr0up eventLoopGr0up = new NioEventLoopGr0up();

        Bootstrap bootstrap = new Bootstrap();

        bootstrap.channel(NioSocketChannel.class);

        bootstrap.option(ChannelOption.SO_KEEPALIVE, true);

        bootstrap.option(ChannelOption.SO_BACKLOG, 500);

        bootstrap.group(eventLoopGr0up);



        bootstrap.handler(new ChannelInitializer() {

            @Override

            protected void initChannel(Channel channel) throws Exception {

                ChannelPipeline pipeline = channel.pipeline();

                pipeline.addLast(new DelimiterBasedFrameDecoder(2048, Unpooled.copiedBuffer("_".getBytes())));

                pipeline.addLast(new StringDecoder(StandardCharsets.UTF_8));

                pipeline.addLast(new StringEncoder(StandardCharsets.UTF_8));

                pipeline.addLast(new SimpleChannelInboundHandler<String>(){

                    @Override

                    protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {

                        log.info("client receive: {}", msg);

                    }

                });

            }

        });



        ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 9091).sync();

        this.socketChannel = (SocketChannel) channelFuture.channel();

    }

}

Socket只是用来发送消息的，所以不同处理接受的消息。注意这里的中间客户端连接的是Socket服务，端口是9091

4.4 配置启动

@Slf4j

@Component

public class StartConfig {



    @Autowired

    private WebSocketServer webSocketServer;

    @Autowired

    private SockerServer socketServer;





    @PostConstruct

    public void init() {

        ExecutorService executorService = Executors.newFixedThreadPool(2);

        executorService.execute(() -> {

            log.info("websocket init ....");

            try {

                webSocketServer.start();

            } catch (InterruptedException e) {

                throw new RuntimeException(e);

            }

        });



        executorService.execute(() -> {

            log.info("socket init ....");

            try {

                socketServer.start();

            } catch (InterruptedException e) {

                throw new RuntimeException(e);

            }

        });

    }

}

这个就是独立部署的Socket服务配置，两个服务分别使用多线程启动。

4.5 模拟数据推送

@Test

void contextLoads() throws Exception {

    MockClient mockClient = new MockClient();

    mockClient.connect();

    SocketChannel socketChannel = mockClient.getSocketChannel();



    new Timer().schedule(new TimerTask() {

        @Override

        public void run() {

            System.out.println("send msg...");

            socketChannel.writeAndFlush("foo test..._");

        }

    }, 0, 2000);



    System.in.read();

}

每个2s发送一次消息。

4.6 客户端

客户端同样用在线测试工具代替。

4.7 演示

05 小结

这就完成了WebSocket的解耦。关于Socket消息的编解码，有很多注意点，在搭建过程中，总会不成功， 需要根据连接的协议选择不同的编解码，才能正确的接受和发送信息。这些留到后面的文章继续介绍。

昨天我看新年第一波简历 看破防了

最近团队缺人，我连着看了一周的简历。

说实话，看得我挺难受的。😖

我发现一个特别普遍的现象：很多工作了四五年的兄弟，期望薪资填个 25k 甚至 30k，但你仔细翻他的项目经历，全是后台管理系统，全是 H5 拼图页面，全是表单增删改查。

你问他：这几年你遇到的最大技术难点是啥？🤔

他回你：表单字段太多了，校验逻辑太复杂。或者说，产品经理改需求太频繁。😖

听到这种回答，我心里大概就有了底：这兄弟的薪资上限，大概率锁死在 20W 以内了。

这就是咱们常说的 CRUD 困局。

别沉迷 CRUD，高薪的关键是工程化视野与底层兜底能力。想在快节奏中兼顾标准与效率？试试 RollCode 低代码平台，利用 私有化部署 和 自定义组件 沉淀资产，轻松搞定 静态页面发布（SSG + SEO）。

你会 Vue，你会 React，你会用 Antd 画页面，你会调接口。兄弟，这些在 2018 年也许能让你拿高薪，但现在是 2026 年了，这些东西是基建，是培训班出来的应届生两个月就能上手的。🤣

那么问题来了，那个坐在你隔壁工位、平时话不多、但年薪能拿 50W 的大佬，他到底比你强在哪？

是他敲键盘比你快？还是他发量比你少？

都不是。

我觉得最核心的差距，就只有三点。听我细说。

你在做填空，他在设计整张试卷

这事儿特别明显。就拿新开一个项目来说。

15W 的兄弟是怎么干的？

找个脚手架，create-react-app 一把梭。然后开始堆页面，写组件。遇到要用的工具函数？去百度搜一个粘贴进来。遇到样式冲突？加个 !important 搞定。代码格式乱了？不管了，先跑通再说。

他的脑子里只有一个字：做。

50W 的兄弟是怎么干的？

他在写第一行业务代码之前，会先在脑子里过一遍这几件事：

大家代码风格不一样怎么办？先把 ESLint + Prettier + Husky 这一套流水线配好，谁提交的代码格式不对，连 git push 都推不上去。

这个项目以后会不会变大？要不要直接上 Monorepo 管理？

公共组件怎么抽离？是不是该搭个私有 npm 库？

打包速度怎么优化？Vite 的配置能不能再调调？

这就是差距。🤔

老板愿意给他 50W，不是因为他页面画得快，而是因为他制定了标准。他一个人，能让团队剩下 10 个人的产出质量变高。这叫工程化视野，这才是值钱的玩意儿。

出了事，你只会甩锅，他能兜底

场景再具体点：用户投诉页面卡顿，加载慢。

15W 的兄弟通常反应是这样的：

打开控制台 Network 看一眼。

哎呀，接口这就 800ms 了，这后端不行啊，锅在服务端。

嗨🙂‍↔️，这图片 UI 给得太大了，切图没切好。

这数据量几万条，浏览器渲染本来就慢，我也没办法！

总之，只要不是 JS 报错，这事儿就跟我没关系。

50W 的兄弟会干嘛？

他不会废话，他直接打开 Chrome 的 Performance 面板，像做外科手术一样分析。

这一段掉帧，是不是触发了强制重排？

内存这一路飙升，是不是哪个闭包没释放，或者 DOM 节点没销毁？

主线程卡死，是不是长任务阻塞了渲染？能不能开个 Web Worker 把计算挪出去？

网络慢，是不是 HTTP/2 的多路复用没吃满？关键资源的加载优先级设对了吗？

这就叫底层能力。🤔

平时写业务看不出来，一旦遇到高并发、大数据量、若网环境这种极端场景，只会调 API 的人两手一摊，而懂底层原理的人能从浏览器内核里抠出性能。

这种 兜底能力，就是你的溢价。

他是业务合伙人!

这点最扎心。

产品经理提了个不靠谱的需求，比如要在手机端展示一个几百列的超级大表格。

15W 的兄弟：

心里骂娘：这傻X产品，脑子有坑。😡🤬

嘴上老实：行吧，我尽量试试。

结果做出来卡得要死，体验极差，上线被用户骂，回来接着改，陷入无尽加班。

这种思维模式下，你就是个执行资源，也就是个 打工人。

50W 的兄弟：

他听完需求直接就怼回去了：

哥们，在手机上看几百列表格，用户眼睛不要了？你这个需求的业务目标是啥？是为了让用户核对数据？

如果是核对数据，那我们要不要换个方案，只展示关键指标，点击再下钻看详情？这样开发成本低了 80%，用户体验还好。

这就叫技术变现。

高端的前端，不仅仅是写代码的，他是懂技术的业务专家。他能用技术方案去纠正产品逻辑，帮公司省钱，帮业务赚钱。

在老板眼里，你是成本，他是投资。🤷‍♂️

哪怕现在是 15W，咱也能翻盘

如果你看上面这些话觉得膝盖中了一箭，别慌。谁还不是从切图仔过来的？

想打破这个 CRUD 的怪圈，从明天上班开始，试着变一下：

别再只盯着那几个 API 了

Vue 文档背得再熟也就是个熟练工。去看看源码，看看人家是怎么设计响应式的，看看 React 为什么要搞 Fiber。懂了原理，你就不怕框架变。

别做重复工作

下次想复制粘贴工具函数的时候，停一下。试着自己封装一个通用的，甚至试着把你们项目里重复的逻辑抽成一个库。工程化就是这么一点点做起来的。

钻进去一个细分领域

别啥都学，啥都学不精。

可视化、低代码、Node.js 中间件、音视频，随便挑一个，把它钻透。在任何一个细分领域做到前 5%，你都有议价权。

还是那句话！前端并没有死，死的是那些 只会切图和调接口 的工具人。

50W 的年薪，买的不是你的时间，而是你 解决复杂问题 的能力，和你 避免团队踩坑 的经验。

别再满足于重复做一个 CRUD 了。下次打开编辑器的时候，多问自己一句：

除了把这个功能做出来，我还能为这段代码多做点什么？

共勉🙌

背景

嘿，兄弟！你是不是也感觉 AI 越来越香，但 Token 账单也越来越“烫”？ 💸

GPT-4o、Kimi 这些模型的上下文窗口动不动就几十万、上百万 Token，我们恨不得把整个项目都扔进去。但冷静下来看看账单... ... 哇哦

LLM 的 Token 每一分都是真金白银啊！

当大家都在想办法优化模型、优化算法时，有没有想过，我们每天都在用的 JSON，可能就是那个“背刺”我们 Token 费用的“内鬼”？

JSON 虽好，但它实在是... ... 太！啰！嗦！了！

“内鬼”现形：JSON 到底有多浪费

在 LLM 的世界里，Token 就是钱。表达同样的信息，谁用的 Token 少，谁就是赢家。

不信？我们直接上例子，用事实说话。

假设我们有这样一个简单的用户列表：

1. 冗长的“老大哥”：JSON

标准的 JSON 格式，充满了大括号、双引号和逗号，简直是 Token 杀手。

[

  {

    "id": 1,

    "name": "Alice",

    "age": 30

  },

  {

    "id": 2,

    "name": "Bob",

    "age": 25

  },

  {

    "id": 3,

    "name": "Charlie",

    "age": 35

  }

]

（数数看，光是 name 这个词就重复了 3 遍！）

2. “小清新”但还不够：YAML

YAML 确实清爽了不少，用缩进代替了括号，也去掉了双引号。

- id: 1

  name: Alice

  age: 30

- id: 2

  name: Bob

  age: 25

- id: 3

  name: Charlie

  age: 35

嗯，进步了，但不多。id, name, age 这些键名还是在无情地重复。

3. “抠门”的王者：TOON 登场！

TOON （Token-Oriented Object Notation）闪亮登场，它用了一种近乎“变态”的方式来压缩信息：

[3]{id,name,age}:

  1,Alice,30

  2,Bob,25

  3,Charlie,35

看明白了吗？[3] 表示有3个对象，{id,name,age} 只定义了一次“表头”，后面的数据就像 CSV 一样紧凑排列。

没有对比就没有伤害！ 同样的数据，TOON 的 Token 占用量简直是“骨折价”！

啥是 TOON？为 LLM 而生的“省钱利器”

TOON（面向 Token 的对象表示法）就是这么一个专为 LLM 提示词而生的、紧凑且人类可读的数据格式。

它能表示和 JSON 一模一样的对象、数组和数据类型，但它的语法就是为了最小化 Token 使用而设计的。

你可以把它理解为 YAML 的嵌套结构 + CSV 的表格布局 = TOON

TOON 最擅长处理的场景，就是我们最常见的**“结构一致的对象数组”**。在实现 CSV 般紧凑的同时，它又提供了清晰的结构信息（{key1, key2}:），帮助 LLM 更可靠地解析和验证数据。

注意： TOON 并非银弹。如果你的数据是深度嵌套或结构极其不统一的，那 JSON 可能还是老老实实的选择。但在“对象数组”这个 LLM 最常见的场景下，TOON 简直无敌。

数据为证：TOON 到底有多能打？

光说不练假把式。Chase Adams 大佬做了一组非常直观的基准测试，对比了 JSON、YAML、TOON 和 CSV 的 Token 效率。

基准测试链接：http://www.curiouslychase.com/playground/…

结论一目了然：

CSV 是 Token 效率的“天花板”，但它无法表示嵌套结构，而且没有元数据，LLM 很容易“读歪”。

TOON 稳坐第二把交椅，效率直逼 CSV，但它保留了完整的结构信息。

JSON 和 YAML... ... 两位老大哥，在 Token 效率上被 TOON 吊打。

如何在 LLM 中“无痛”用上 TOON？

你可能会想：“哇，这么牛？那我岂不是要重构整个系统？”

完全不用

官方推荐的架构是这样的：

看懂了吗？TOON 只是一个**“转换层”**。

你的系统内部，该用 JSON 还是用 JSON，啥也不用改。

在调用 LLM 之前，你只需加一个编码步骤，把 JSON 编码（Encode） 成 TOON 格式再发送。

LLM 返回 TOON 格式的数据后，你再解码（Decode） 成 JSON 给系统用。

你就把它当成一个“中间件”，在和 LLM 交互的“最后一公里”上帮你省钱

别再浪费 Token 了！

在 LLM 时代，Token 效率就是核心竞争力。

JSON 是一个伟大的格式，但在 LLM 交互这个新场景下，它显得既臃肿又昂贵。

TOON 提供了一个完美的替代方案：它在保留 JSON 完整表达能力的同时，实现了接近 CSV 的 Token 效率。

如果你还在为高昂的 LLM Token 费用而头疼，如果你还在忍受 JSON 带来的冗余，那么，是时候给你的系统“升个舱”了

参考

• github.com/toon-format…


• http://www.curiouslychase.com/playground/…

大家好，我是孟健。

昨天 24 小时内，三家公司同时说了同一句话：我们的代码，基本不是人写的了。

不是媒体炒作。不是 PR 包装。是 Nvidia、OpenAI、Cognition、Anthropic——四家站在 AI 最前沿的公司，几乎同一时间亮出了底牌。

这件事值得每个写代码的人停下来想一想。

发生了什么

先摆事实。

Nvidia：黄仁勋几个月前在内部喊出"stop coding"，让 3 万名工程师全面换用 AI 编程工具。最新数据——代码产出量翻了 3 倍。不是 10%、20%的提升，是 3 倍。

OpenAI：内部团队交付了一个完整产品，每一行代码都是 AI Agent 生成的。工程师全程没写一行代码，只负责 Review 和监督。开发效率提升了 10 倍。

Cognition（做 Devin 的那家）：联合创始人 Scott Wu 发了条推，说公司超过 90%的代码是 AI 写的。他的原话是："你现在实际需要亲手敲的代码有多少？对我们来说，大概不到 10%。"

Anthropic：首席产品官 Mike Krieger 说得更直接——"Claude 在写 Claude。Claude 的产品和 Claude Code，完全由 Claude 自己写。"

四家公司，同一个结论：程序员的核心工作，正在从"写代码"变成"不写代码"。

这不是第一次有人喊"狼来了"

我知道你在想什么。

"AI 替代程序员"这话喊了三年了。2023 年 GitHub Copilot 发布的时候喊过一次。2024 年 Devin 出来的时候又喊了一次。2025 年 Claude Code 和 Codex 上线的时候再喊一次。

每次喊完，程序员还是该上班上班，该加班加班。

但这次不一样。

之前是模型公司说"我们能做到"——那是销售话术。

这次是用 AI 写代码的公司自己说"我们已经做到了"——这是生产实践。

Nvidia 不是 AI 编程工具公司，它是芯片公司。它给 3 万工程师换工具，不是为了 PR，是因为代码产出真的翻了 3 倍。当你的竞争对手用同样的人力做出 3 倍的产出，你不跟进就是在等死。

这个信号的含金量，跟"某 AI 公司发了个 Demo"完全不是一个量级。

为什么是现在

你可能好奇：AI 编程工具 2024 年就有了，为什么突然到了这个临界点？

答案是速度。

就在昨天，OpenAI 发布了 GPT-5.3-Codex-Spark——一个跑在 Cerebras 晶圆级芯片上的编码模型。这是 OpenAI 第一次用非 Nvidia 的芯片部署生产级模型。

关键数字：每秒 1000+ token 的代码生成速度，比之前快 15 倍。

Cerebras 的芯片有多大？一整块硅晶圆，餐盘那么大，就是一个处理器。不是把几百个 GPU 堆在一起，是把一整个芯片做到极致。

15 倍速度意味着什么？

以前用 AI 写代码，你提交一个任务，泡杯咖啡等几分钟。现在是你话音刚落，代码就出来了。从"异步等结果"变成了"实时对话"。

这个体感差异是质变。

我自己每天用 Claude Code 做产品。之前等 AI 生成的时候我会切到别的窗口干别的事。现在？根本没时间切——它比我打字还快。

当 AI 写代码的速度快到人类来不及思考的时候，"人写代码"这件事本身就变成了瓶颈。

这就是为什么四家公司同时跨过了这个临界点。不是巧合，是速度到了。

我自己的体感

说说我的真实经历。

我在腾讯带过几十人的团队，在字节也做过前端技术 Leader。那时候团队产出的计算方式是：人头 × 工时 × 人效。想提高产出？加人、加班、优化流程。

2025 年 10 月辞职创业后，我开始全面用 AI 编程。

一个人，一个月，做了近 30 个出海小产品。

不是简单的静态页面。是有前端、有后端、有支付、有 SEO、有数据统计的完整产品。放在以前，这是一个 5-8 人的小团队干一个季度的量。

我不觉得 AI 替代了我。更准确地说，是 AI 把我从"写代码的人"变成了"做决策的人"。

以前 80%的时间在写代码，20%在想产品。

现在反过来了——80%的时间在想产品方向、用户需求、商业模式，20%在 Review AI 写的代码。

这个转变，跟 Nvidia 那 3 万工程师的转变是一模一样的。

程序员要失业了吗？

这是每次 AI 编程话题下必然出现的问题。

我的判断是：不会失业，但工作内容会彻底改变。

上海交大最近发了一篇论文（ProjDevBench），测试 AI 从零构建完整软件项目的能力。结果通过率只有 27%——基础功能还行，但系统设计、性能优化、资源管理全崩。

这说明什么？

AI 已经能干 80%的活了。但剩下那 20%——架构决策、边界处理、性能调优、产品判断——恰恰是最值钱的 20%。

Scott Wu 说得好："瓶颈不再是写代码本身，而是两件事——1）让人类更容易理解、规划和提问；2）让 AI 更容易获取任务的真实上下文。"

翻译成人话就是：未来的程序员不是代码机器，是 AI 的 项目经理 。

你的价值不再是一天能写多少行代码，而是你能不能把一个模糊的需求拆解成 AI 能理解的指令，能不能在 AI 写完之后判断"这个架构扛不扛得住"，能不能在 AI 犯错的时候快速定位问题。

这些能力，恰恰是在大厂带过团队、做过大项目的人最擅长的。

如果你只做一件事

说了这么多，落到行动上，我建议你今天就做一件事：

把你最常做的一类开发任务，完整地交给 AI 做一次。

不是让它补两行代码。是给它一份需求描述，让它从零开始搞。前端、后端、数据库、部署，全交出去。

你会发现两件事：

Nvidia 的 3 万工程师已经这么干了。OpenAI 的团队已经这么干了。你还在等什么？

如果这篇对你有帮助，欢迎点赞、收藏、关注，你的支持是我持续输出的动力 ✨

我的其他平台账号和开源项目在个人主页中，欢迎交流 🤝

作为程序员，你竟然还在手撸代码 ？？？

如果没有公司给你提供科学上网，提供AI 编程工具的账号，你真能玩转AI ？？？

除了平时搜搜查查，AI 对你还有其他用处 ？？？

震惊！

某博主竟然开头就贩卖焦虑？难道程序员真的要被 AI 取代了？

别急，这篇文章就一步步带你玩转 AI 编程！

如果只是想了解如何使用 AI 编程，可以直接跳到章节： 「所以，我们需要什么！？」

理解概念

要深入使用 AI，我们要先理解一些概念

1. AI 基础

• AI大模型：拥有超大规模参数、超级聪明的机器学习模型，所有的 AI 应用都是调用大模型的计算处理能力。如：问答、图片生成、视频生成。

国内主流大模型对比：

国外主流大模型对比

一般我们编程使用的都是国外的大模型，毕竟开发工具、系统、编程语言都是外国的。编码方面的能力，国外模型还是碾压的存在。

• MCP：一套提供给 AI 大模型调用的标准协议。一些厂商会把自己的能力包装成MCP，让大模型在理解完用户的复杂任务时，可以调用厂商的能力。比如：你让豆包给你用 “高德” 生成一份超准的导航，豆包就会去调用高德的 MCP，为你出导航～


• IDE：程序员专属概念。AI IDE是集成了 AI 能力的软件开发平台，开发者可以通过自然语言，让 IDE 调用 AI 模型和 MCP 给你写代码，速度和质量牛的飞起，真有手就能写代码！

主流的 AI IDE 对比

2. RAG ➡️ Agent ➡️ Planning：AI 应用方式的演进之路

AI 的应用方式正从 “被动响应” 向 “主动规划” 快速迭代。

从 RAG 进行检索增强生成，到 AI Agent 实现自主调用工具完成任务，再到 Planning 能 “拆解复杂任务与全局决策” 的高阶形态。让 AI 从 “内容生成器” 蜕变到 “智能协作体”。

• RAG —— 检索增强生成
  
  核心逻辑是：先检索，再生成。用户提出问题，先从外部数据库、文档库中检索与问题最相关的信息，再将这些信息作为 “参考资料” 喂给大模型，让模型基于真实数据生成回答。


• AI Agent —— “自主工具操作员”
  
  AI Agent（智能体） ,让 AI 像人一样调用工具、执行步骤、验证结果。能理解用户的模糊需求，自主规划任务步骤，选择并调用合适的工具（如计算器、浏览器、代码解释器、RAG 系统），完成任务。


• Planning（规划）—— “全局任务指挥官”
  
  AI 系统的高阶能力，核心逻辑是 “先拆解，再执行，再调整”。基于全局目标，将复杂、长期、多约束的任务拆解为有序的子任务序列，并根据执行过程中的反馈动态调整策略。
  
  不仅关注单个任务的完成，更关注子任务之间的关联和整体目标的达成。

演进逻辑与核心差异总结

所以，我们需要什么！？

你作为一名优秀的程序员，你需要通过科学上网、精准付费，在 AI IDE中，基于AI大模型的能力，熟练使用 Agent/Planning，配合 MCP 等工具，让 AI 帮你写出又快又好的代码，更好的服务你的业务！

1. 使用 Cursor、Antigravity、Trae 开发工具

下载地址：Cursor、Antigravity、TREA

账号注册：Cursor 和 Trae 登录方式都超简单，会员的话直接去官网购买即可


至于 Antigravity，因为 Google 是禁止国内用户访问的，因此一定要能正常上网，邮箱账号必须纯正🇺🇸，但是我们有 闲鱼 之光，是可以尝试下的～

2. 装好主流 MCP

对于前端程序员，UI 这类低级工作，完全可以交给 Agent 去编写。比如：公司的设计师用的是figma，我们只需要在 cursor 中装上figma mcp，然后 figma 账号申请开发者权限，就能自由的让 AI 帮我们写好代码。亲测还原度 85%+

3. 沉淀 Rules 和 Workflows

我们现在已经可以通过开发工具让 AI 干活了，但如何更符合我们的编码习惯和设计思想？那就得给 AI 规范，也就是通过提示词让 AI 更乖的，干更对的活。

比如，Antigravity就有明确的让我们添加规则和工作流的入口，并且会引导我们如何写提示词，然后在提问的时候，引用对应的文件即可。

Rules(规则)和Workflows(工作流)，沉淀 沉淀 再 沉淀！！！

4. ！！！文档先行！！！

AI 时代的编码，一定要做好设计，写好文档。

AI 虽然帮你干活，但是任务是你来安排的，你给出的任务要足够精准。

同时，你的编码思维才是代码能写好的核心，你必须把你的思维和想法，落成文档给到 AI 大模型。

• markdown 格式：注意 AI 需要理解 md 文档


• 图文并茂：在编写文档的时候，时常需要画图，此时可以使用 md 语法来画图。这里我推荐mermaidchart，可以基于 md 语法进行可视化编辑。
  

写在最后

当你有正常可以使用模型的账号后，其实这个账号不仅仅是在 IDE 可以使用，比如 Antigravity 的账号，跟 Gemini 是一致的，你也可以在大模型的官网登录进行图片、视频生成。

在了解了大模型、MCP、工作流、AI 编程工具后，相信你对 AI 的应用又有了新的理解。我们一定要积极去尝试，国内国外的 AI 工具能用的多用，尽情的去拥抱 AI！

AI 是生产力，毋庸置疑！

第一章：JDK 25 都发了，为什么大家还在 Java 8

JDK 25 发布那天，我特意去看了一眼发布说明。内容不复杂，新特性不少，语气一如既往地克制，像是在告诉你： “你可以升级了，但我们不催。”

这种感觉我在 Java 世界里已经很熟了。

同一天，Python 社区的画风完全不一样。Python 3.13 的兼容性讨论、弃用警告、生态适配进度，被反复拿出来说。很多库会直接写在 README 里：“Python 3.8 即将停止支持，请尽快升级。”Java 这边没有这种集体施压。JDK 25 发布了，但 JDK 8 依然能跑、能用、能上线。

我翻了下手头几个线上系统的运行环境，结果并不意外：

• 老核心系统：Java 8


• 偏边缘的新服务：Java 11


• 真正用到 17 的，只有少数新项目


• 至于 21、25，基本只存在于 PPT 和技术分享里

这不是个别现象。招聘网站、云厂商镜像、监控 SDK 默认支持版本，几乎都在默默告诉你一件事：Java 8 依然是“安全版本”（你发任你发，我用java8）。这和 Python 的升级节奏形成了非常明显的反差。

Python 2 → 3，是一次不升级就活不下去的断代。Java 8 → 25，更像是一次你可以一直不动的演进。

从技术角度看，Java 明明一直在进化：

• 语言层面：var、record、sealed class


• JVM 层面：GC、JIT、内存模型


• 工程层面：模块化、工具链

但这些变化，没有哪一项是“非升不可”。

我见过不少 Java 服务，代码风格停在 2016 年，但稳定运行到今天。也见过 Python 项目，因为一个依赖不再支持旧版本，被迫整体升级。

这两种生态的差异，很早就写在设计选择里了。

Java 的向后兼容是它的优势。但到了 JDK 25 这个时间点，这个优势开始变得有点微妙。

因为问题已经不是：

JDK 8 能不能用？

而变成了：

如果一直停在 JDK 8，到底是在保守，还是在逃避某些成本？

这个问题，在技术会议上很少被正面讨论。更多时候，它会被一句话带过：

“先别动，风险太大。”

可风险到底在哪？为什么 Python 升级时大家骂归骂，还是会跟着走；而 Java 这边，哪怕官方已经跑到 25，企业却依然集体停在 8？

我后来发现，真正卡住升级的，从来不是新特性本身。而是升级这件事，一旦开始，就很难只停在“换个 JDK”上。但这件事，只有在你真的尝试过一次升级之后，才会意识到。你也就会抱怨为何JDK会把普及新特性的成本强加在每个java开发者身上

第二章：升级 JDK，看起来向下兼容，实际上并不“平滑”

很多人对 Java 升级的第一判断，来自一个几乎写进 DNA 的认知：

Java 是强向下兼容的语言。

这句话本身没错，也是大多数人从jdk7到jdk8无缝升级的真实感受。但问题在于，大多数人只把它理解成了语法层面。

你用 Java 8 写的代码，放到 JDK 17、21、25 上，大概率还能编译。for、try-catch、Stream、lambda，一个都不会少。这也是为什么很多升级评估一开始都显得非常乐观。真正的问题是 Java 的“向下兼容”，从来不等于 JVM 的平滑迁移。

第一次认真推进 JDK 升级时，我们的目标设得非常保守：不引入新语法、不改业务逻辑、不升级框架，只把运行时从 Java 8 换成 17。理论依据也很充分：代码是向下兼容的，JVM 只要能跑就行。

结果第一个暴露问题的，不是业务代码，而是 JVM 本身。

从 JDK 9 开始，Java 做了一次非常激进、但长期看又必须要做的事情：模块化（JPMS） 。这一步，本质上是在重塑 JVM 的边界。在 Java 8 之前，JDK 更像是一个“开放的整体”。JDK 自己的内部实现，和应用代码之间，并没有严格的隔离。于是很多框架、工具、甚至业务代码，都默认了一件事：

JVM 内部的类，我是可以摸得到的。

比如反射。

Field field = String.class.getDeclaredField("value");

field.setAccessible(true);

在 Java 8，这是一个非常常见、甚至被大量框架依赖的操作。但在模块化之后，这种行为被明确标记为：非法访问（Illegal Reflective Access） 。升级后，日志里开始出现大量这样的提示：

Illegal reflective access by xxx

这类 warning 很容易被误判成“噪音”。因为程序还能跑，接口也没挂。但实际上，这不是 JVM 在提醒你“写得不优雅”，而是在明确告诉你：

你现在还能用，是 JVM 在帮你兜底。

于是有人会加启动参数：

--add-opens java.base/java.lang=ALL-UNNAMED

问题是，从这一刻开始，所谓的“向下兼容”已经被你亲手打破了。你不再是被 JVM 兼容，而是用参数强行绕过 JVM 的设计边界。这也是 Java 升级过程中一个非常隐蔽的转折点：

• 代码层面看起来没变


• 启动参数开始越来越复杂


• JVM 行为开始依赖“约定俗成的补丁”

而这一步，一旦走出去，基本就退不回去了。更麻烦的是，这种不平滑迁移，并不是“偶发问题”，而是 Java 设计演进的必然结果。模块化不是可选项，它是为了：

• 限制 JVM 内部 API 滥用


• 提升安全性


• 为长期演进留空间

但代价是：大量在 Java 8 时代“合理存在”的用法，在新 JVM 下被系统性否定了。这也是为什么很多团队会有一种强烈的错觉：

代码明明没变，怎么升级 JDK 反而问题一堆？

因为你真正升级的，不只是一个版本号，而是 JVM 对“什么是合法行为”的判断标准。而这类问题，偏偏又很难在测试环境一次性暴露完。有的库只在特定路径触发反射；有的异常只在高并发下出现；有的 warning 今天是 warning，下一版就变成 error......

这也是 Java 升级和 Python 最大的不同。

Python 的升级是显式断代：你升级，就必须改代码。

Java 的升级是隐式收紧：你不改代码，但 JVM 会慢慢不再纵容你。

这种“看起来兼容，实际上在变”的特性，让 Java 在企业环境里变得越来越尾大不掉。不是升不了，而是你永远无法确定：

下一步，是不是会踩到一个你完全没预期过的 JVM 行为变化？

也正因为这样，很多公司最终选择了一个看似稳妥、但风险被推迟的方案：停在 Java 8。

第三章：真正让升级失败的，不是编译错误，而是线上行为变了

如果只是编译报错，JDK 升级反而简单。

编不过，改代码；启动不了，补参数；问题是可定位的，也是可回滚的。

真正让团队对升级产生恐惧的，往往发生在上线之后。升级前，所有检查都过了：

• 单元测试全绿


• 接口回归没问题


• 压测 QPS、RT 都在预期范围内

代码一行没改，JDK 从 8 换成 17。

上线当天没有事故。第二天开始，监控里出现了一些非常微妙的变化。不是报错，也不是性能雪崩。而是一些 “看起来不该变的行为，变了” 。

最早被发现的是 GC 行为。Java 8 默认用的是 Parallel GC，而 JDK 17 的默认已经变成了 G1。当时的判断很简单：G1 是“更先进的 GC”，不应该比旧的差。

但线上数据并不这么配合。

• Full GC 次数少了


• Minor GC 次数变多


• 单次停顿更短，但更频繁

这对 JVM 来说是“健康变化”，但对业务来说，结果是：

某些接口的 P99 响应时间开始抖动。

不是慢，而是不稳定。问题在于，这类变化不会在压测里明显暴露。压测关注的是吞吐和平均值，而不是长尾。你只能在真实流量下，才会看到这些边缘效应。

紧接着出现的是更难定位的问题：类加载行为的变化。JDK 9 之后，类加载和模块边界被重新梳理过。很多“以前恰好能工作”的加载顺序，在新 JVM 下变了。

最典型的是 SPI 机制。

ServiceLoader.load(SomeService.class)

在 Java 8 下，这段代码的加载顺序是稳定的。在新 JDK 下，如果存在多个实现，顺序可能发生变化。大多数时候，这没什么影响。但如果你的代码里隐式依赖了加载顺序，问题就来了：比如默认实现被换了；没有异常，没有日志，只是业务行为“和以前不太一样”。这类问题，几乎不可能靠自动化测试完全覆盖。因为测试本身，也是在“旧认知”下设计的。

还有一类更隐蔽的变化，来自于 JIT。JVM 在新版本里持续优化编译策略。某些代码路径，在 Java 8 下是“冷路径”，在新 JDK 下被识别成“热点”。结果是：

• 以前不明显的锁竞争，被放大


• 原本可以忽略的对象创建，开始影响 GC

代码没变，但 JVM 对代码的“理解方式”变了。

这也是为什么很多线上问题，在排查时会陷入一种诡异的状态：

SQL 没变，代码没变，配置没变，只有 JDK 变了

而你又很难证明：问题真的就是 JDK 引起的。

到这一步，升级已经不再是技术选型问题了。它变成了一个心理问题。

团队开始本能地回避这种“不可解释风险”。即便你知道：

• 这些问题不是 JDK 的 bug


• 而是历史代码对 JVM 行为的过度依赖

但现实是，线上系统不接受“技术上合理”的解释。这也是很多公司在第一次升级尝试之后，迅速得出结论的原因：

不是升不了， 而是不值得再为这种不确定性买单。

于是升级计划被无限期搁置。Java 8 继续稳定运行，问题被推迟，而不是被解决。

第四章：真正的风险，不在 JDK，而在你不敢动的那一部分代码

当升级卡在第三章那些“行为变化”上时，团队往往会得出一个结论：

问题太散了，风险不可控。

但后来复盘发现，真正不可控的，从来不是 JDK，而是我们不敢去验证的那一块代码。几乎每个中大型 Java 项目里，都有这样一层东西：

• 没人愿意动


• 但所有人都在用


• 出问题只能回滚

它可能是十年前写的公共组件，也可能是一次紧急需求里硬塞进去的工具类。

在 Java 8 时代，这类代码有一个共同特征：它们和 JVM 的关系非常近。比如自定义 ClassLoader。

public class CustomClassLoader extends ClassLoader {

    @Override

    protected Class<?> findClass(String name) {

        // 从非标准路径加载字节码

    }

}

在 Java 8 下，这种实现非常常见。升级之后，问题不一定立刻出现。但一旦涉及模块、服务加载或反射，行为就开始变得不可预测。

再比如字节码增强。无论是早期的 cglib，还是基于 ASM 的工具，很多实现都默认了：

• 某些 JDK 内部类是存在的


• 某些方法签名是稳定的

这些假设，在新 JDK 下不再成立。更现实的问题是：这些代码往往没有完整测试。因为它们本来就不是“业务逻辑”。它们被视为基础设施， 被默认是“不会出问题的”。升级 JDK 时，测试覆盖率看起来还不错。但真正和 JVM 行为强相关的部分，几乎没有被验证过。

于是升级就进入了一个死循环：

• 不敢上线，是因为没验证


• 不验证，是因为不敢动


• 不动，就永远无法升级

这也是 Java 升级和其他语言很不一样的地方。Python 项目里，底层行为大多由解释器和库兜住。Java 项目里，很多“工程能力”是直接构建在 JVM 之上的。而这些能力，恰恰是最难平滑迁移的。

还有一个被严重低估的因素，是运维和排障成本。Java 8 的排障手段，大家已经非常熟悉：

• jmap


• jstack


• 老一套 GC 日志

新 JDK 不是不能用这些工具，而是行为、参数、输出都在变化。同一条 GC 日志，在不同版本下，含义已经不完全一致。这会直接导致一个现实问题：

出问题时，团队是否有信心“看懂”新 JDK 的行为？

如果答案是否定的，那升级本身就是一种冒险。

于是你会看到一种很典型的现象：

• 开发知道 Java 17 更好


• 架构知道 Java 21 是趋势


• 但一到生产，所有人都默认：还是 Java 8 吧

不是因为它完美，而是因为它足够“熟”。

升级 JDK，本质上不是技术债的清理，而是一次对未知的正面接触。而大多数系统，并没有为这种接触做好准备。也正因为这样，很多公司并不是“卡在 Java 8”，而是被 Java 8 保护了很多年。

第五章：真正逼你升级的，从来不是技术本身

在很多公司里，JDK 升级从来不是一个“主动议题”。它通常出现在某个非常具体、而且很现实的场景里。比如云厂商的一封邮件。内容往往写得很克制，大概意思是：

某某 JDK 版本即将停止安全更新 请尽快规划升级方案

这类邮件第一次看到时，大多数人并不会紧张。因为“即将”往往意味着还有一段缓冲期。真正产生压力的，是第二封、第三封。

当你发现云厂商的默认镜像开始发生变化，新建实例已经不再提供 Java 8，升级这件事，就从“技术选择”变成了外部约束。还有安全审计。Java 8 的漏洞，并不比新版本多。但问题在于：很多漏洞，在 Java 8 上不再修了。这意味着同样一个问题：

• 在新 JDK 上，是一个补丁


• 在 Java 8 上，是一个长期风险

安全团队不会和你讨论 JVM 设计演进。他们只看结果： 有没有官方支持，有没有风险背书。

接着是第三方生态。越来越多的中间件、SDK、监控工具，开始把“最低支持 JDK”往上抬。不是突然抛弃 Java 8，而是新功能不再考虑它。

你会慢慢发现：

• 想用新版本框架 → 需要新 JDK


• 想接入新工具 → 官方不再测试 Java 8


• 想拿到性能优化 → 只在新 JVM 生效

这时候，继续停在 Java 8 的成本开始显性化。不是系统跑不动，而是你被锁在一个越来越狭窄的选择空间里。

更现实的是人员问题。新来的工程师，默认使用的已经是 Java 17 甚至更高版本。他们熟悉的是新工具链、新调试方式。当他们面对一套 Java 8 的系统时，不是学不会，而是：

很多问题的解决路径，已经不在他们的经验范围内了。

这会让“稳定”变成另一种风险。因为稳定的前提，是有人能长期维护它。到这一步，升级已经不再是“要不要”的问题。 而是变成了：

现在升级，还是被动升级？

很多团队选择继续拖延，希望把升级成本压到最低。

但现实往往是：拖得越久，升级的边界越难控制。

当升级真的不可避免时，你已经不再有“慢慢试”的空间。而这，才是 Java 8 最危险的地方。它让你误以为，时间是站在你这边的。

第六章：一次相对靠谱的 JDK 升级，应该从哪里开始

真正开始升级之前，有一件事必须先想清楚：你这次升级，是为了“到达某个版本”，还是为了“验证系统能否继续演进”。

这两个目标，看起来很像，路径完全不同。很多失败的升级，问题就出在一开始选错了目标。

如果你只是想“把 Java 8 换成 17”，那你会天然倾向于：

• 尽量不改代码


• 尽量不动依赖


• 尽量让系统看起来“没变”

但这种升级方式，本质上是在赌：赌 JVM 的变化不会触发你没覆盖到的路径。

相对靠谱的升级，第一步反而是承认一件事：

有些问题不是升级带来的， 而是升级帮你提前暴露出来的。

所以真正的起点，往往不是生产环境，而是一个可以被随时推翻的验证环境。不是单元测试，也不是本地跑一下。而是把完整应用，用新 JDK 跑起来。不接真实流量，但一定要接真实配置、真实依赖、真实启动参数。

很多团队在这里就已经踩到了第一个坑：启动参数。Java 8 下积累了大量 JVM 参数，其中不少早已被废弃，甚至在新版本里直接失效。你会看到类似这样的警告：

Ignoring option PermSize; support was removed in 8.0

在 Java 8 你还能“假装没看到”，在新 JDK 下，它会直接提醒你：这些参数已经没有意义了。清理这些参数，本身就是一次风险排查。不是“能不能启动”， 而是启动之后，哪些地方开始行为变化。这里有一个非常实际的做法：在同一套代码下，同时跑两个版本的 JVM。

• 一套用 Java 8


• 一套用目标 JDK

对外提供同样的接口，跑同样的请求。不需要全量对比结果，但要盯几个关键指标：

• P99 延迟


• GC 行为


• 异常日志类型是否变化

很多问题，不是“新版本一定有 bug”，而是你第一次看到了原来就存在的极端情况。还有一个经常被忽略的点：日志和监控工具本身是否适配新 JDK。有些 agent 在 Java 8 下工作得很好，但在模块化之后，注入行为发生变化。结果不是监控失效，而是监控数据“看起来正常，其实已经不完整”。

如果你在升级过程中，突然发现某些指标消失了，那不是系统变健康了，而是你少看了一部分。这也是为什么，靠谱的升级节奏通常很慢。不是因为技术上推进不了，而是你需要时间去重新建立：

“我对这个系统行为的信心。”

到这里，升级才算真正开始。不是宣布成功，而是你终于知道：

• 哪些问题是 JDK 带来的


• 哪些问题是历史债务


• 哪些地方，必须在升级过程中一起解决

而这一步，几乎不可能一蹴而就。也正因为这样，很多公司在真正启动升级后，才意识到一件事：升级 JDK，其实是在逼自己重新理解系统。 而这件事，本身就是一次不小的工程。

第七章：如果一直不升，会发生什么？

在很多团队内部，其实都默认了一种状态：

不升级，不代表现在就有问题。

这句话在相当长的一段时间里，都是成立的。Java 8 足够稳定，线上系统运行多年，没有明显的性能瓶颈，也没有无法解决的故障。于是“暂时不升”逐渐变成了“长期不升”。真正的问题，是这种状态并不是静止的。最先发生变化的，往往不是系统本身，而是它所处的环境。云厂商开始调整基础镜像；CI/CD 环境里的默认 JDK 版本往前走；安全扫描工具对旧版本的容忍度越来越低

你会发现，原来“理所当然”的前提，一个一个消失了。接着是依赖生态。一开始只是新功能不支持 Java 8，后来变成新版本直接不再测试，再后来是明确标注：不兼容。这时候你还能苟住，靠锁版本、靠私服、靠内部维护。

但代价在慢慢累积。每一次新需求评估，都会多一个隐含条件：

这个东西，能不能在 Java 8 上跑？

这个问题一旦出现得足够频繁，系统就已经被版本反向塑形了。更危险的是，问题开始延迟出现。

很多在新 JDK 下会被立刻暴露的行为问题，在 Java 8 下被默默吞掉。你看不到 warning；也感受不到约束。

直到某一天，你必须升级。那时候你面对的，已经不是一次版本迁移，而是一堆被时间放大的设计问题。而升级窗口，反而更小了。

因为这次升级，不是你主动选的。可能是：

• 安全合规要求


• 外部依赖强制


• 云平台策略调整

你已经没有“慢慢试”的空间。于是很多团队会在这个阶段做出一个看似合理的选择：

那就继续顶着吧，能跑一天是一天。

问题在于，这条路并不是线性的。系统越老，理解成本越高，可控范围越小。

最终你会发现，你并不是在“稳定运行一个老系统”，而是在维护一个越来越没人敢动的黑盒。

这时候，Java 8 不再是你的缓冲垫，而是你的时间锁。

而你已经很难判断：

现在不升级，到底是在规避风险， 还是在把风险推给未来一个更糟糕的时刻？

这一点，很多团队只有在真正被逼到墙角时，才会意识到。

结语：也许问题不只在我们

写到这里，再回头看“为什么还卡在 Java 8”，很多原因已经很清楚了：

• 生态复杂


• 历史债重


• 升级风险真实存在

但如果只停在这里，其实有点不公平。因为有一个问题，很少被正面拿出来讨论：

Java 真的做到“向下兼容”了吗？

从语法层面看，是的。Java 8 写的代码，放到 JDK 25，大多数还能编译。但从工程和运行时层面看，答案并没有这么确定。JDK 9 之后，JVM 的内部结构、边界、约束，被系统性地重构过。模块化不是补丁，是一次方向性的调整。这个调整本身没有错。甚至可以说，是 Java 走向长期可维护性的必经之路。

问题在于：JDK8之后演进的成本，几乎全部落在了使用者身上。

旧代码还能跑，但开始被警告；旧用法还能用，但需要加参数；旧依赖还能凑合，但不再被官方支持

从结果上看，JDK 并没有为“平滑迁移”提供一条真正低成本的路径。它选择的是：

保证不立刻崩， 但也不保证你能轻松往前走。

这是一种非常 Java 的工程取舍。向后兼容，被理解成“不破坏既有运行”；而不是“帮助你完成迁移”。

于是一个微妙的局面就出现了：

• JDK 在持续演进


• 企业系统被留在原地


• 升级的代价，被默认为“业务方应该承担的成本”

当升级困难时，我们习惯反思自己的架构、代码、历史债。

但很少有人问一句：

如果一个平台的演进，让大多数成熟用户都不敢升级， 那这个演进路径，是否真的对“工程用户”友好？

也许这并没有标准答案。Java 选择了稳定、选择了克制、选择了长期演进。而代价，是把升级这件事，变成了一次高认知门槛的工程决策。

所以今天还停在 Java 8 的团队，未必是保守，也未必是技术债失控。有时候，只是因为他们不想为一次并不完全由自己造成的不连续演进， 付出过高的试错成本。

当然，这并不意味着一直停留就是对的。

只是到了 JDK 25 这个节点，也许我们该承认一件事：

Java 的升级之所以难， 并不只是因为系统老， 也因为这条升级路，本身就不够平坦。

而要不要踏上这条路，现在，依然没有一个放之四海而皆准的答案。

同步至个人站点：如何零成本搭建个人站点

站点地址：stack.mcell.top，包含完整的：写作、评论、部署、MCP支持...

我经常写作，最开始是在一些平台上，比如稀土掘金。后面慢慢写多了，就想有个自己的博客平台。

最初搭建的博客很简单：一个纯静态的 HTML 文件，内容也不复杂，写点自我介绍，当作个人站点。直接托管到 GitHub Pages，域名用的也是它默认那串。

但很快就发现：功能太少了。
比如发布文章？评论？甚至想加点扩展能力都很难——纯 HTML 又没框架，后面越改越痛苦。

接着就走上了“大家都走过的弯路”：
买了轻量服务器，又买了域名……然后写服务端、接数据库、写前端，把整套都搭起来。

直到后面参与了一个开源项目才意识到：
这种内容站点/文档站点，压根没必要搞这么重。成熟框架太多了，比如 VitePress 这种（比如Vue官网就是VitePress），基本开箱即用。

然后我就重构了一次：直接上 VitePress。部署？还是 GitHub Pages。那时候至少配上了自定义域名，看起来舒服多了：stack.mcell.top

又过了一段时间，我开始觉得个人站点还是有点单调。VitePress 能改，但做深度定制的时候会有点别扭（有些地方甚至会翻车）。
索性就 vibe coding 一把：把原先 VitePress 那套，重构到了 Next.js。

路线也很清晰：

• Next.js


• SSG / 静态导出（要部署到 GitHub Pages，关键是要把站点导出成纯静态）


• GitHub Actions 自动构建


• 部署到 GitHub Pages


• 配上自定义域名

后面我又陆续补了评论和文档搜索功能。用到服务器了吗？没有。

• 评论用的是 giscus：本质是把评论托管在 GitHub Discussions 里，前端加载组件就行，也不用数据库。
  


• 搜索用的是 pagefind：还是静态站那套玩法，构建阶段生成索引，运行时纯前端查询。
  

再后面，我还给博客加了 MCP 功能。同样，还是没有服务器：
SSG 阶段生成一份 JSON docs，只要把路径映射到 MCP server 就行；然后我做了个本地的 MCP server，用户安装大概这样：

memo mcp add stack-mcepp npx -y @mcell/stack-mcell

memo code 是我最近自己写的一个轻量级编程Agent，类似Claude code那种，感兴趣可以参与进来。

本质上就是：agent 请求本地 MCP server，MCP server 再去拉取我提前生成好的 JSON 内容。

文档站上 MCP 的整体方案的记录我放在这里：从一个想法到可发布：我把博客接进 MCP 的完整实践

这一套折腾下来，依然是 0 成本。分享给大家，或许是个不错的“0 成本建站思路”。

提示词

如果你对这套方案比较感兴趣，想要多了解了解，你可以clone我的博客仓库：mcell satck，或者是直接把这段提示词发给AI，他会给你方案：

我想搭建一个个人博客，大致如下：



- 框架：nextjs ssg

- 部署：Github Action 自动化部署 + Github Page（自定义域名）

- 图片存储：对象存储（七牛云或者火山引擎）

- 搜索服务：pagefind

- 文章评论服务：giscus

- 开发方式：Vibe coding

- mcp 集成：参考 https://stack.mcell.top/blog/2026/mcp-from-idea-to-delivery-for-content-site



请你给我一个具体可落地的方案（分阶段）

（完）

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

01 引言

你是否找过免费可用的数据库连接工具，又寻找SSH的连接工具。我们自从收到Navicat律师函警告后，从一度卸载了所有破解的软件，花了很多时间寻找替代品。

这两天发现了一个All in one的集成软件，可以连接数据库、SSH、Docker的神仙工具：HexHub

02 简介

HexHub 是一款专为开发者和运维人员设计、集成了数据库、SSH、SFTP和Docker管理功能的桌面图形界面工具。其核心理念是“All in one”，旨在提供一个统一的工作平台。

官方提供了免费版和商业版，然而免费版已经足够我们日常使用了。

官网地址：http://www.hexhub.cn/

03 使用

官方提供了三种平台的安装包，满足不同的平台的需要。

3.1 数据库连接

目前满足的数据有：Redis、Mysql、MariaDB、PostgreSQL、SqlServer、ClickHouse、SQLite、Oracle

我们以Mysql为例:

我们填入数据库信息即可：

控制台库表提示，关键词高亮的辅助信息。

还有常用的执行计划、格式化、导出、保存等

对于表的操作涵盖了常用的操作，完全满足日常需要。

3.2 SSH

直接右键建立SSH连接即可。

界面主要分了三屏：控制台、UI以及监控。其中UI和监控可以手动收起来或者展开。

控制台的配色，感觉下来还是比较舒服的。

3.3 Docker

Docker的配置类似

其中Docker的配置可能会出现不成功的问题，官方也给除了解决方案：

04 小结

如果你目前在同时使用多个不同的工具来完成日常工作，那么尝试 HexHub 来简化工作流可能会是一个不错的选择。

本人快 40 岁了。第一份工作是做网站编辑，那时候开始接触 jQuery，后来转做前端，一直做到现在。说实话，我对写程序谈不上特别热爱，所以技术水平一般。

年轻的时候如果做得不开心，就会直接 裸辞。不过每次裸辞的那段时间，我都会拼命学习，这对我的成长帮助其实很大。

下面给年轻人几点个人建议：

• 不要被网上“35 岁就失业”的说法吓到。很多人是在贩卖焦虑。我都快 40 了还能拿到 offer，只是这些 offer 薪资不到 30K。


• 基础真的很重要。我靠着基础吃香了十几年，在公司里也解决过不少疑难问题，深得领导器重。就算现在有 AI，你也要有能力判断它写得对不对，还要知道如何向 AI 提问。


• 适不适合做程序员，其实几年之后就能看出来：你能不能当上 Leader，或者至少能不能独当一面。如果你觉得自己确实不太适合，可以趁早考虑转行，或者下班后发展一些副业。大千世界，行行出状元，能赚钱的行业很多，不必只盯着程序员这一条路。


• 如果你觉得自己资质一般，但又真的喜欢写程序，那也没关系。《刻意练习》这本书里提到，一个人能不能成为行业顶尖，关键在于后天练习的方式，而不是天赋本身。


• 程序员做到后面，最大的挑战其实是身体机能，而不是技术。一定要多锻炼身体。在还没有小孩之前，尽量把自己的技术水平拉到一个相对高的位置。结婚有家庭之后，学习时间会明显减少，而且年龄增长、抗压能力下降，而程序员本身又是高度用脑的职业。如果你的技术储备够高，就能在一定程度上缓冲项目压力，让自己工作更从容。


• React、Vue、Angular 等框架都可以尝试做做项目。不同框架背后的设计思路，对思维成长很有帮助。前端很多理念本身就借鉴了后端的逻辑，多接触不同体系，会让你看问题更立体。


• 可以在 GitHub 上做一些开源小项目。素材从哪里来？其实就来自你在公司做过的项目。把其中一块通用能力抽出来，沉淀成一个独立组件或工具库，再整理发布到 GitHub。与此同时，多写一些技术文章进行总结和输出。等到找工作时，简历里可以写上类似 "全网阅读量几万+" 这样的成果展示，这些都会成为你的加分项，让你在竞争中更有优势。


• 35 岁以上，竞争力通常体现在两个方向：要么技术水平足够强，能够解决复杂问题；要么具备一定的管理能力，能够带团队。有人说那我以前就带过一两个徒弟，怎么办，那你得学会包装，你懂得，哈哈。


• 35 岁以上，面试对技术广度要求更高，所以不要太深入挖掘某一项技术了。我以前认识一个领导，虽然写代码能力一般，在公司已经不写代码了，但是他的技术广度比较好，业务能力还行，虽然 40岁了 还能跳槽到比较好的广告公司，而不是靠人脉，不得不佩服。


• 打工人比较麻烦的事就是 简历太"花"。频繁跳槽，在一个公司没干几个月就走，或者长期待业太久。如果岗位需要背调，简历造假会很麻烦，虽然有些小公司或外包公司不做背调。所以这方面简历自己要想想办法，你懂得。


• 另外要认清一个现实：单纯打工，很难发财。 这件事越早想明白越好。多读一些关于认知、资产配置的书，弄清楚什么是资产，什么是消费。哪怕这些认知在你有生之年未必能带来巨大财富，也可以传递给下一代，让他们少走弯路。

以上只是个人经历和感受，不一定适用于所有人，但希望能给年轻的你一些参考。

今天是大年初一，江湖十年给读者朋友们拜年了，祝大家新年快乐！

又是新的一年，想必大家都没看春晚吧 😄，今天继续一年一度的用 Go 语言实现春晚魔术。

废话不多说，咱们直接看原理。

魔术原理揭秘

这个魔术的数学原理其实很简单，基于一个简单的恒等式：

设目标时间为 T

设观众说的两个数为 A 和 B

魔术师计算的第三个数为 C = T - (A + B)



那么：A + B + C = A + B + [T - (A + B)] = T

这里的 T 就是最终结果：2162227

• 观众 A 说：1106


• 观众 B 说：88396


• 观众“乱按”的计算器显示：2072725


• 相加结果：1106 + 88396 + 2072725 = 2162227

这个数字代表：2 月 16 日 22 时 27 分

理解了吗？

这里其实有个障眼法，就是魔术师现场找了三个观众“乱按”了几下，但其实谁也不确定他们按的什么，对不对，其实他们按的数字根本就没用上，而是计算器里已经预先计算出了目标时间 T 与 A + B 总和的差值。

没错，魔术这种东西就是这么朴实无华。

Go 语言实现魔术

那么接下来，就用 Go 语言来实现一个简单的计算器程序，来还原这个魔术。

首先定义一个魔术计算器：

// MagicCalculator 魔术计算器

type MagicCalculator struct {

	targetTime int    // 目标时间转换的数字

	timestamp  string // 实际时间字符串

}

接下来实现一个魔术计算器的构造方法：

// NewMagicCalculator 创建一个魔术计算器实例

func NewMagicCalculator() *MagicCalculator {

	// 获取当前时间

	now := time.Now()



	// 生成类似 "2162227" 的时间数字

	// 格式: 月(1-2 位) + 日(2 位) + 小时(2 位) + 分钟(2 位)

	month := int(now.Month())

	day := now.Day()

	hour := now.Hour()

	minute := now.Minute()



	// 构建时间字符串和数字

	timestamp := fmt.Sprintf("%dddd", month, day, hour, minute)



	// 转换为整数

	target, _ := strconv.ParseInt(timestamp, 10, 64)



	return &MagicCalculator{

		targetTime: int(target),

		timestamp:  timestamp,

	}

}

当前时间 now 就是用来计算目标时间的，可以根据需要设定，这里直接使用当前时间。

target 是格式为 2162227 的时间数字，也就是咱们原理解析中的目标时间 T。

定义一个 计算魔术数字 T -（A + B）的方法：

// GetMagicNumber 计算魔术数字

func (mc *MagicCalculator) GetMagicNumber(num1, num2 int) int {

	// 魔术公式: target - (num1 + num2)

	return mc.targetTime - (num1 + num2)

}

最后就是定义一个交互式函数，它实现了：

• 计算目标时间 T


• 接收用户输入的 A、B


• 计算观众“乱按”的第三个数字

源码如下：

func InteractiveMagic() {

	fmt.Println("=== 交互式魔术体验 ===")

	fmt.Println("请按照提示输入数字，我会展示魔术的原理")



	mc := NewMagicCalculator()



	var num1, num2 int

	fmt.Print("请输入第一个数: ")

	fmt.Scan(&num1)

	fmt.Print("请输入第二个数: ")

	fmt.Scan(&num2)



	fmt.Printf("\n你输入的是: %d 和 %d\n", num1, num2)



	magicNum := mc.GetMagicNumber(num1, num2)

	fmt.Printf("魔术数字（第三个数）是: %d\n", magicNum)



	fmt.Printf("\n验证: %d + %d + %d = %d\n", num1, num2, magicNum, mc.targetTime)

	fmt.Printf("这个数字代表的时间是: %s\n", mc.timestamp)

}

程序 main 入口：

func main() {

	InteractiveMagic()

}

验证魔术：

# 运行程序

$ go run main.go

=== 交互式魔术体验 ===

请按照提示输入数字，我会展示魔术的原理

请输入第一个数: 1106

请输入第二个数: 88396



你输入的是: 1106 和 88396

魔术数字（第三个数）是: 2081398



验证: 1106 + 88396 + 2081398 = 2170900

这个数字代表的时间是: 2170900

通过 go run main.go 运行程序，接下来根据提示分别输入两个数字，这里以春晚观众说的两个数字（1106、88396）为例，然后计算观众“乱按”的第三个数字（2081398），最终得到的目标时间是 2170900。

没错，我在 2 月 17 日 09 时 00 分运行的程序。

总结

今天依旧使用 Go 语言简单实现了魔术小程序，看个乐子，开心最重要。

如果你有兴趣，完全可以通过聊天的方式让大模型生成一个带有前端界面的魔术计算器程序，体验 vibe coding 的乐趣。

本文完整代码示例我放在了 GitHub 上，欢迎点击查看。

25 年我的文章里吐槽了春晚魔术“降本增效”，在此给刘谦老师道个歉，是我冒犯了🤣之前对魔术一无所知。

25 年看了老罗采访刘谦的视频，对刘谦大佬肃然起敬 respect 🫡。

延伸阅读

• 用 Go 语言还原 2025 刘谦春晚魔术！：jianghushinian.cn/2025/01/30/…


• 用 Go 语言实现刘谦 2024 春晚魔术，还原尼格买提汗流浃背的尴尬瞬间!：jianghushinian.cn/2024/02/10/…


• 本文 GitHub 示例代码：github.com/jianghushin…

联系我

• 公众号：Go编程世界


• 微信：jianghushinian


• 邮箱：jianghushinian007@outlook.com


• 博客：jianghushinian.cn


• GitHub：github.com/jianghushin…

前言

昨天在Code Review时，我发现阿城在Service层直接返回了Result对象。

指出这个问题后，阿城有些不解，反问我为什么不能这样写。

于是我们展开了一场技术讨论（battle 🤣）。

讨论过程中，我发现这个看似简单的设计问题，背后其实涉及分层架构、职责划分、代码复用等多个重要概念。

与其让这次讨论的内容随风而去，不如整理成文，帮助更多遇到同样困惑的朋友理解原因。

知其然，更知其所以然。

耐心看完，你一定有所收获。

正文

职责分离原则

在传统的MVC架构中，Service层和Controller层各自承担着不同的职责。

Service层负责业务逻辑的处理，而Controller层负责HTTP请求的处理和响应格式的封装。

当我们将数据包装成 Result 对象的任务交给 Service 层时，意味着 Service 层不再单纯地处理业务逻辑，而是牵涉到了数据处理和响应的部分。

这样会导致业务逻辑与表现逻辑的耦合，降低了代码的清晰度和可维护性。

看一个不推荐的写法:

@Service

public class UserService {

    public Result<User> getUserById(Long id) {

        User user = userMapper.selectById(id);

        if (user == null) {

            return Result.error(404, 用户不存在);

        }

        return Result.success(user);

    }

}



@RestController

public class UserController {

    @Autowired

    private UserService userService;

    

    @GetMapping("/user/{id}")

    public Result<User> getUser(@PathVariable Long id) {

        return userService.getUserById(id);

    }

}

上面代码中，Service 层不仅负责从数据库获取用户信息，还直接处理了返回的结果。

如果我们需要改变返回的格式，或者进行错误信息的标准化，所有 Service 层的方法都需要修改。这样会导致代码的高耦合。

相比之下，以下做法将展示逻辑留给 Controller 层，保证了业务逻辑的纯粹性：

@Service

public class UserService {

    public User getUserById(Long id) {

        User user = userMapper.selectById(id);

        if (user == null) {

            throw new BusinessException(用户不存在);

        }

        return user;

    }

}



@RestController

public class UserController {

    @Autowired

    private UserService userService;

    

    @GetMapping("/user/{id}")

    public Result<User> getUser(@PathVariable Long id) {

        User user = userService.getUserById(id);

        return Result.success(user);

    }

}

让每一层都专注于自己的职责。

可复用性问题

当Service层返回Result时，会严重影响方法的可复用性。

假设我们有一个订单服务需要调用用户服务:

@Service

public class OrderService {

    @Autowired

    private UserService userService;

    

    public void createOrder(Long userId, OrderDTO orderDTO) {

        // 不推荐的方式:需要解包Result

        Result<User> userResult = userService.getUserById(userId);

        if (!userResult.isSuccess()) {

            throw new BusinessException(userResult.getMessage());

        }

        User user = userResult.getData();

        

        // 后续业务逻辑

        validateUserStatus(user);

        // ...

    }

}

这种写法有个很明显的问题。

OrderService 作为另一个业务服务，业务之间的调用本来应该简单直接，但使用 Result 带来了两个问题：

如果是调用第三方外部服务，需要这种包装还能理解，但在自己业务之间互相调用时，完全没必要这样做。

如果Service返回纯业务对象:

@Service

public class OrderService {

    @Autowired

    private UserService userService;

    

    public void createOrder(Long userId, OrderDTO orderDTO) {

        // 推荐的方式:直接获取业务对象

        User user = userService.getUserById(userId);

        

        // 后续业务逻辑

        validateUserStatus(user);

        // ...

    }

}

代码变得简洁且符合直觉。

业务层之间直接传递业务对象，保持简单和清晰。

异常处理机制

有些 Service 层在业务判断失败后，会直接返回 Result.fail(xxx) 这样的代码，例如：

public Result<Void> createOrder(Long userId, OrderDTO orderDTO) {

    if (userId == null) {

        return Result.fail("用户ID不能为空");

    }

    // 后续业务逻辑

    return Result.success();

}

这种做法有几个问题：

而如果我们通过抛出异常并结合全局异常处理来统一处理错误，例如：

public void createOrder(Long userId, OrderDTO orderDTO) {

    if (userId == null) {

        throw new BusinessException("用户ID不能为空");

    }

    // 后续业务逻辑

}

再通过全局异常捕获来转换为 Result：

@RestControllerAdvice

public class GlobalExceptionHandler {

    @ExceptionHandler(BusinessException.class)

    public Result<Void> handleBusinessException(BusinessException e) {

        return Result.error(400, e.getMessage());

    }



    @ExceptionHandler(Exception.class)

    public Result<Void> handleException(Exception e) {

        log.error("系统异常", e);  // 这里可以查看堆栈信息

        return Result.error(500, "系统繁忙");

    }

}

这样做的好处是：

• 减少重复代码：业务方法不再需要写重复的错误判断，代码更简洁。


• 集中错误处理：错误处理集中在一个地方，修改时只需修改全局异常处理器，不用改动每个 Service 层方法。


• 业务与错误分离：业务逻辑专注处理核心功能，错误处理交给统一的机制，代码更加清晰易懂。

而且异常可以携带更丰富的上下文信息，如果业务侧需要时，可以带上堆栈信息，便于一些问题的定位。

测试便利性

Service层返回业务对象而不是Result时，能够大大提升单元测试的便利性:

@SpringBootTest

public class UserServiceTest {

    

    @Autowired

    private UserService userService;

    

    @Test

    public void testGetUserById() {

        // 推荐的方式:直接断言业务对象

        User user = userService.getUserById(1L);

        assertNotNull(user);

        assertEquals(张三, user.getName());

    }

    

    @Test

    public void testGetUserById_NotFound() {

        // 推荐的方式:断言抛出异常

        assertThrows(BusinessException.class, () -> {

            userService.getUserById(999L);

        });

    }

}

如果Service返回Result，测试代码则需要写得更复杂:

@Test

public void testGetUserById() {

    // 不推荐的方式:需要解包Result

    Result<User> result = userService.getUserById(1L);

    assertTrue(result.isSuccess());

    assertNotNull(result.getData());

    assertEquals(张三, result.getData().getName());

}

测试代码变得莫名冗长，还得去关注响应结构，这并不是Service层测试的关注点。

Service 层本应专注于业务逻辑，测试也应该直接验证业务数据。

领域驱动设计角度

再换个角度。

从领域驱动设计（DDD）的角度来看，Service 层属于应用层或领域层，应该使用领域语言来表达业务逻辑。

而 Result 是基础设施层的概念，代表 HTTP 响应格式，不应该污染领域层。

例如，考虑转账业务：

@Service

public class TransferService {

    

    public TransferResult transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) {

        Account fromAccount = accountRepository.findById(fromAccountId);

        Account toAccount = accountRepository.findById(toAccountId);

        

        fromAccount.deduct(amount);

        toAccount.deposit(amount);

        

        accountRepository.save(fromAccount);

        accountRepository.save(toAccount);

        

        return new TransferResult(fromAccount, toAccount, amount);

    }

}

在这个例子中，TransferResult 是一个领域对象，代表了转账的结果，包含了与业务相关的意义，而不是一个通用的 HTTP 响应封装 Result。

这种做法更符合领域模型的表达，体现了领域层的职责——处理业务逻辑，而不是涉及 HTTP 响应格式的细节。

接口适配的灵活性

当 Service 层返回纯粹的业务对象时，Controller 层可以根据不同的接口需求灵活封装响应：

@RestController

@RequestMapping("/api")

public class UserController {

    

    @Autowired

    private UserService userService;

    

    // REST接口返回Result

    @GetMapping("/user/{id}")

    public Result<User> getUser(@PathVariable Long id) {

        User user = userService.getUserById(id);

        return Result.success(user);

    }

    

    // GraphQL接口直接返回对象

    @QueryMapping

    public User user(@Argument Long id) {

        return userService.getUserById(id);

    }

    

    // RPC接口返回自定义格式

    @DubboService

    public class UserRpcServiceImpl implements UserRpcService {

        public UserDTO getUserById(Long id) {

            User user = userService.getUserById(id);

            return convertToDTO(user);

        }

    }

}

同一个Service方法可以被不同类型的接口复用，每个接口根据自己的协议要求封装响应。

强行使用 Result 会导致接口的适配性变差，无法根据不同协议的需求灵活定制响应格式。

灵活性反而丢失了。

事务边界清晰

Service 层通常是事务边界所在，当 Service 返回业务对象时，事务的语义更加清晰：

@Service

public class OrderService {

    

    @Transactional

    public Order createOrder(OrderDTO orderDTO) {

        Order order = new Order();

        // 设置订单属性

        orderMapper.insert(order);

        

        // 扣减库存

        inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());

        

        return order;

    }

}

在这个例子中，事务是围绕 Service 层的方法展开的，@Transactional 注解确保在业务逻辑执行失败时，事务会回滚。因为方法正常返回时，事务会提交；如果抛出异常，事务会回滚，事务的边界非常明确。

如果 Service 返回的是 Result，很难界定事务是否应该回滚。比如：

public Result<Order> createOrder(OrderDTO orderDTO) {

    Order order = new Order();

    // 设置订单属性

    orderMapper.insert(order);

    

    // 扣减库存

    Result<Void> inventoryResult = inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());

    if (!inventoryResult.isSuccess()) {

        return Result.fail("库存不足");

    }

    

    return Result.success(order);

}

在这种情况下，如果库存不足，虽然 Result 返回失败信息，但事务并不会回滚，可能会导致数据不一致，反而还得额外去抛出异常。

而通过抛出异常的方式，事务的回滚语义非常清晰：异常抛出则回滚，方法正常返回则提交，这种设计确保了事务的边界更加明确，避免了潜在的数据一致性问题。

写在最后

看来阿城要走的路还很长，码路漫漫，踏浪前行。

2026年，祝大家加班少，薪水多，bug少，头发多，多写点注释，少走点弯路。

人生就像一个大项目，需求多，时间紧，但没关系——bug 和头发总有一个会先来。

🤣

生产环境出bug了但没及时发现？支付接口异常导致资损？这个语音通知方案专为开发者打造，重要异常直接打电话，让你第一时间响应处理！

作为开发者，我们最怕的就是生产环境出现异常却没有及时发现。飞书群、钉钉群报警很容易错过，尤其是深夜或周末。今天分享一个专门针对开发者的语音电话通知解决方案，让重要异常第一时间电话通知到你。

🎯 典型使用场景

需要立即电话通知的开发场景：

• 🚨 API接口异常或超时


• 💰 支付流程异常（防止资损）


• 📊 数据处理任务失败


• 🔐 用户登录异常激增


• ⚡ 核心业务逻辑报错

🚀 3步快速集成

💻 代码集成示例

🐍 Python（异常处理）

import requests

import logging



def send_voice_alert(message, phone):

    """发送语音告警"""

    url = "https://push.spug.cc/send/A27L****bgEY"

    data = {'key1': message, 'targets': phone}

    

    try:

        response = requests.post(url, json=data, timeout=5)

        return response.json()

    except Exception as e:

        logging.error(f"语音告警发送失败: {e}")



# 在异常处理中使用

try:

    # 你的业务代码

    process_payment(order_id)

except PaymentException as e:

    # 支付异常立即电话通知

    send_voice_alert(f"支付异常: {str(e)}", "186xxxx9898")

    raise

☕ Java（Spring Boot异常处理）

@Component

public class VoiceAlertService {

    

    private final RestTemplate restTemplate = new RestTemplate();

    private static final String VOICE_URL = "https://push.spug.cc/send/A27L****bgEY";

    

    public void sendVoiceAlert(String message, String phone) {

        try {

            Map<String, String> data = new HashMap<>();

            data.put("key1", message);

            data.put("targets", phone);

            

            HttpHeaders headers = new HttpHeaders();

            headers.setContentType(MediaType.APPLICATION_JSON);

            HttpEntity<Map<String, String>> entity = new HttpEntity<>(data, headers);

            

            restTemplate.postForEntity(VOICE_URL, entity, String.class);

        } catch (Exception e) {

            log.error("语音告警发送失败: {}", e.getMessage());

        }

    }

}



// 全局异常处理器

@ControllerAdvice

public class GlobalExceptionHandler {

    

    @Autowired

    private VoiceAlertService voiceAlertService;

    

    @ExceptionHandler(CriticalException.class)

    public ResponseEntity<String> handleCriticalException(CriticalException e) {

        // 关键异常立即电话通知

        voiceAlertService.sendVoiceAlert("API异常: " + e.getMessage(), "186xxxx9898");

        return ResponseEntity.status(500).body("Internal Server Error");

    }

}

🔧 实际开发场景

场景1: 支付接口监控

def create_order_payment():

    try:

        result = payment_service.create_order()

        if result.status != 'success':

            send_voice_alert("支付订单创建失败", "186xxxx9898")

    except Exception as e:

        send_voice_alert(f"支付系统异常: {str(e)}", "186xxxx9898")

场景2: 定时任务监控

def daily_data_sync():

    try:

        sync_user_data()

    except Exception as e:

        send_voice_alert("每日数据同步失败", "186xxxx9898")

        raise

场景3: API响应时间监控

@Component

public class ApiPerformanceInterceptor implements HandlerInterceptor {

    

    @Autowired

    private VoiceAlertService voiceAlertService;

    

    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, 

                           Object handler) throws Exception {

        request.setAttribute("startTime", System.currentTimeMillis());

        return true;

    }

    

    @Override

    public void afterCompletion(HttpServletRequest request, HttpServletResponse response,

                              Object handler, Exception ex) throws Exception {

        long startTime = (Long) request.getAttribute("startTime");

        long duration = System.currentTimeMillis() - startTime;

        

        if (duration > 5000) {  // 超过5秒

            String message = String.format("API响应慢: %s 耗时%dms", 

                                         request.getRequestURI(), duration);

            voiceAlertService.sendVoiceAlert(message, "186xxxx9898");

        }

    }

}

📋 参数说明

❓ 开发者常见问题

🤔 如何避免告警风暴？
建议设置异常频率限制，同类异常5分钟内只发送一次。

💰 语音通话收费吗？

语音通话按次计费，建议只对关键异常使用，普通日志用短信或微信。

🛡️ 如何保护API安全？

🎉 为什么开发者需要语音通知？

✅ 及时响应：生产故障分秒必争，电话比微信更直接

✅ 降低损失：支付、订单等关键业务异常能立即处理

✅ 简单集成：几行代码搞定，无需复杂配置

✅ 多语言支持：Python、Node.js、Java等任何语言都能用

✅ 个人友好：无需企业资质，个人开发者也能用

记住：好的开发者不是不写bug，而是能第一时间发现并修复bug！

网站链接：push.spug.cc

自研第一个SKILL-openclaw入门

openclaw不是搭建好了就结束了，用起来才能发挥作用，而SKILL，就是openclaw的灵魂，是openclaw的内功。

所以准备慢慢记录学习openclaw的skill之路。

所谓读万卷书不如行万里路，实践对知识的理解非常重要，今天就准备自己开发一个简单的SKILL，来加深对SKILL的理解。

如果还不知道SKILL是什么，建议先看第一篇：

抄一个还是改一个

学字先描红，开发先抄，cv程序员的称号不是白得的。

先看看这个：

openclaw毕竟是外国人开发的，默认的skill都是国外的，比如这个天气查询，先找到这个系统自带的skill看看：

这个skill位于系统内置skill的目录：

/app/skills/weather/SKILL.md

这个SKILL的内容：

一个查询天气的skill，还挺复杂，有主要的服务，还有备份的，可惜都是国外的服务，国人用就有点水土不服了，就以他为例，改成简单的国内的：

完整的代码如下：

需要重启gateway生效，然后问一下：

万事大吉了！

小结

这是第一个自研的SKILL，功能不大，却也实用，再找一个免费的天气接口，作为备份，完善一下，就可以替代系统自带的天气SKILL了。

从简单开始，从复制开始，慢慢学习复杂一点的SKILL，开发openclaw的功能！

Apache Kafka 4.0 正式发布了，这是一次里程碑式的版本更新。这次更新带来的改进优化非常多，不仅简化了 Kafka 的运维，还显著提升了性能，扩展了应用场景。

我这里简单聊聊我觉得最重要的 3 个改动：

详细更新介绍可以参考官方文档：http://www.confluent.io/blog/introd… 。

KRaft 模式成为默认模式

在 Kafka 2.8 之前，Kafka 最被大家诟病的就是其重度依赖于 Zookeeper 做元数据管理和集群的高可用（ZK 模式）。在 Kafka 2.8 之后，引入了基于 Raft 协议的 KRaft 模式（Kafka Raft），不再依赖 Zookeeper，大大简化了 Kafka 的架构，让你可以以一种轻量级的、单进程的方式来使用 Kafka。

KRaft 模式在后续的版本中不断完善，直到 Kafka 3.3.1，被正式标记为生产环境可用（Production Ready）。

Kafka 4.0 则迈出了更大的一步——彻底移除了对 Zookeeper 的支持，并默认采用 KRaft 模式。

需要注意的是，Kafka 4.0 不再支持以 ZK 模式运行或从 ZK 模式迁移。如果你的 Kafka 仍然使用 ZK 模式，官方建议先升级到过渡版本（如 Kafka 3.9），执行 ZK 迁移后再升级到目标版本。

详细介绍：developer.confluent.io/learn/kraft…

消费者重平衡协议升级

全新的消费者重平衡协议正式 GA 了，可以告别“stop-the-world”重新平衡了！这个协议的核心思想最早在 Kafka 2.4 版本 通过KIP-429: Kafka Consumer Incremental Rebalance Protocol 实现。

新协议的核心在于增量式重平衡，不再依赖全局同步屏障，而是由组协调器（Gr0upCoordinator）驱动，各个消费者独立地与协调器交互，只调整自身相关的分区分配，从而将全局的“停顿”分解成多个局部的、微小的调整。只有需要调整的消费者和分区才会发生变更，未受影响的消费者可以继续正常工作（旧有的再均衡协议依赖于组范围内的同步屏障，所有消费者都需要参与，这会导致明显的“停顿”）。

详细介绍：cwiki.apache.org/confluence/…

队列功能（早期访问版本）

Kafka 4.0 通过引入共享组 (Share Gr0up) 机制提供了类似队列的功能。不过，它并非真正意义上的队列，而是利用 Kafka 已有的主题（Topic）和分区（Partition）机制，结合新的消费模式和记录确认机制来实现类似队列的行为。

Kafka 发布订阅模型

共享组解决了传统 Kafka 消费者组（Consumer Gr0ups）在某些场景下的局限性，主要体现在：

• 支持多消费者协同消费：多个消费者可以协同消费同一主题的消息，并可以同时处理同一分区的数据。每个消息在被确认之前，都会被一个时间限制的锁机制保护，确保同一时刻只有一个消费者可以尝试处理。


• 突破消费者组与分区数量的限制：共享组的消费者数量可以超过主题的分区数量，从而更好地支持高并发消费场景。而消费者组的并行消费能力受限于分区数量，这往往导致用户为了满足峰值负载下的并行消费需求而创建过多的分区，造成资源浪费。


• 消息的独立确认：支持对每条消息进行独立确认、释放或拒绝，提供更精细的消息处理能力。


• 消息投递次数记录：系统会记录每条消息的投递次数，方便处理无法处理的消息。

共享组还支持无队列深度限制和基于时间点的恢复能力，极大地扩展了 Kafka 的应用场景。

详细介绍：cwiki.apache.org/confluence/…

Kafka 常见面试题

关于 Kafka 以及其他常见消息队列的知识点/面试题总结，大家可以参考这两篇文章：

• 消息队列基础知识总结


• Kafka 常常见知识点&面试题总结

摘要：MyBatis源码展现了优秀的设计模式和架构思想。其运用建造者模式创建复杂对象，动态代理实现Mapper接口，装饰器动态扩展功能等。架构上采用清晰分层设计，插件化扩展机制实现开闭原则，多级缓存提升性能，面向接口编程降低耦合。这些设计理念对日常业务开发也有很大借鉴价值。

通过以下系列博文，我们熟悉了Mybatis源码实现的诸多细节，如Executor接口及其实现、缓存体系、自定义插件等。

这次，让我们跳出局部，看看Mybatis在设计和架构上，有哪些值得我们学习的地方。

注：本文中源码来自mybatis 3.4.x版本，地址github.com/mybatis/myb…

一 设计模式

1.1 建造者模式

MyBatis 大量使用建造者模式解决「复杂对象初始化」问题，比如 SqlSessionFactoryBuilder、XMLConfigBuilder、MapperBuilderAssistant 等。

以SqlSessionFactoryBuilder为例，在创建SqlSessionFactory前需要先解析主配置文件，这个过程非常繁琐。使用建造者模式：

• 分离「对象构建逻辑」和「对象使用逻辑」，让复杂对象创建流程清晰；


• 建造者可以分步骤校验配置正确性，避免无效对象产生；


• 多重载的 build 方法， 适配不同入参场景 。

public class SqlSessionFactoryBuilder {



  public SqlSessionFactory build(Reader reader) {

    return build(reader, null, null);

  }



  // 简化代码：reader就是配置文件的读取流

  public SqlSessionFactory build(Reader reader, String environment, Properties properties) {

      XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);

      return build(parser.parse());

    }

  }

1.2 工厂模式

工厂模式隐藏对象创建细节，上层无需关心「具体实现类」，只依赖接口。例如

• SqlSessionFactory 负责创建 SqlSession，提供了多个重载实现。


• Executor、StatementHandler、ResultSetHandler、ParameterHandler只能由 Configuration 中的 newExecutor 等方法创建，根据配置选择不同实现类；同时应用自定义插件。

1.3 动态代理

MyBatis 核心的特性之一是「Mapper 接口无需实现类」，底层通过 JDK 动态代理，实现接口方法调用触发SQL执行。详见 MapperProxyFactory，缓存方法元数据，避免重复解析。

// 缓存mapper方法元数据，避免重复解析

private final Map<Method, MapperMethod> methodCache = new ConcurrentHashMap<Method, MapperMethod>();

此外，插件原理也是动态代理，定义Interceptor接口声明代理逻辑、代理对象创建等。使用户可以自定义插件实现。

1.4 模板方法

• 模板方法将「不变的通用逻辑」抽离到父类，「可变的差异化逻辑」交给子类实现；


• 避免子类重复编写通用代码（如缓存检查、参数校验），降低代码冗余；


• 父类控制流程，子类只关注核心逻辑，符合「开闭原则」。

BaseExecutor 实现了模板方法模式，将 Executor 的通用流程（如参数处理、SQL 执行、结果集处理）抽象为模板方法，具体子类（SimpleExecutor/BatchExecutor/ReuseExecutor）只需实现差异化逻辑。

// 模板方法，一级缓存使用逻辑

@Override

public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {

// ...，会调用doQuer()

    

}



// 由子类实现

protected abstract <E> List<E> doQuery(...)

1.5 装饰模式

用装饰模式替代继承，无需定义子类，就能给对象动态增加职责。

如通过CachingExecutor装饰，给BaseExecutor增加二级缓存能力。

public Executor newExecutor(Transaction transaction, ExecutorType executorType) {

    // 对BaseExecutor子类进行装饰

    if (cacheEnabled) {

        executor = new CachingExecutor(executor);

    }

    // 省略...

}

如Cache接口体系，定义了很多装饰器，根据用户配置，实现功能特性自由组合。

1.6 策略模式

Executor接口可根据用户配置，运行时可切换SimpleExecutor、ReuseExecutor或BatchExecutor，实现不同的SQL执行策略。

RoutingStatementHandler 根据配置路由到不同的 StatementHandler实现。

1.7 注册中心

源码中大量使用 Registry 模式来管理可扩展组件， 可以统一初始化、统一查找、统一生命周期；例如：

• TypeHandlerRegistry


• MapperRegistry


• LanguageDriverRegistry


• CacheRegistry

二 架构思维

2.1 分层设计

MyBatis的核心分层非常清晰，每层只做一件事，符合「单一职责原则」：

• 各层职责：
  
  
  
  • Mapper 层：用户接口，定义 SQL 操作；
  
  
  • SqlSession 层：会话入口，封装 Executor 调用；
  
  
  • Executor 层：执行器，处理缓存、事务、SQL 执行流程；
  
  
  • StatementHandler 层：处理 SQL 拼接、Statement 创建；
  
  
  • Parameter/ResultSetHandler 层：参数绑定、结果集映射；
  
  
  
  


• 架构思维：
  
  
  
  • 分层降低耦合：修改结果集映射逻辑，不会影响 Executor 层；
  
  
  • 每层依赖「接口」而非「实现」：比如 Executor 是接口，具体实现可替换；
  
  
  • 分层便于测试：可单独测试 ParameterHandler 的参数绑定逻辑。
  
  
  
  

2.2 插件化设计

MyBatis 提供了插件扩展机制（Interceptor），允许开发者通过拦截器增强核心组件（Executor、StatementHandler、ParameterHandler、ResultSetHandler）的功能，实现如分页、日志、加密等。

• 核心设计：
  
  
  
  • 定义 Interceptor 接口，开发者实现 intercept 方法即可拦截目标方法；
  
  
  • 通过 @Intercepts 注解指定拦截的类和方法，无需修改源码；
  
  
  • 拦截器链（InterceptorChain）通过动态代理层层包装目标对象，保证插件的有序执行；
  
  
  
  


• 架构思维：
  
  
  
  • 「开闭原则」的良好体现：框架核心功能固定，扩展功能通过插件实现，无需修改源码；
  
  
  • 「责任链模式」：多个插件按顺序执行，每个插件只处理自己的逻辑，互不干扰；
  
  
  • 扩展点设计要「最小化」：只开放核心组件的关键方法，避免过度暴露内部逻辑。
  
  
  
  

2.3 多级缓存

MyBatis 实现了「一级缓存（SqlSession 级别）+ 二级缓存（Mapper 级别）」的多级缓存：

• 一级缓存：BaseExecutor 中的 localCache（PerpetualCache），默认开启，SqlSession 关闭后失效；


• 二级缓存：CachingExecutor 包装普通 Executor，缓存数据存入 Mapper 对应的 Cache 对象，跨 SqlSession 共享；

同时支持集成 Redis/Ehcache 等第三方缓存 。

2.4 面向接口编程

MyBatis 全程贯彻「依赖倒置原则」，完全面向接口编程：接口定义「做什么」，实现类定义「怎么做」，替换实现类不影响上层逻辑；

• 核心组件都是接口：Executor、StatementHandler、ParameterHandler、ResultSetHandler、SqlSession 等；


• 上层代码只依赖接口：比如 SqlSession 的 selectList 方法，底层调用的是 Executor 接口的 query 方法，无需关心具体是 SimpleExecutor 还是 BatchExecutor。

2.5 约定优于配置

MyBatis 大量使用约定来减少配置，通过约定可以显著降低配置量，提升开发体验。例如：

• Mapper 接口与 XML 文件同名同包；


• 方法名与 SQL ID 一致；


• 结果集字段与 JavaBean 属性自动映射；


• StatementHandler接口默认使用PreparedStatementHandler

2.6 架构思维总结

MyBatis源码体现了简单而不简陋的设计哲学：

上述技巧和思维不仅适用于框架开发，在日常业务开发中也能直接落地。

除夕夜，老金我刚咬了一口韭菜鸡蛋饺子。
手机"叮"的一声，弹出个通知。
老金我瞄了一眼——Qwen3.5，上线了。饺子差点没喷出来。

赶紧打开 chat.qwen.ai，两个模型直接挂在上面，可以用了。
阿里这帮人，大年三十放大招，连个发布会都没开，就这么安安静静地把东西甩出来了。

老金我放下筷子，扒了一晚上代码和文档，确认了一件事：
这不是小版本迭代，这是架构级别的重构。

先说结论：Qwen3.5到底升级了什么

根据老金我除夕夜扒的HuggingFace代码库、阿里云官网和chat.qwen.ai的实际体验，帮你梳理了3个核心变化。

第一个：原生多模态。
注意，是"原生"，不是"拼接"。
Qwen3之前的多模态方案是语言模型+视觉模块的两段式架构。
Qwen3.5直接把视觉感知和语言推理塞进了同一个训练框架。

阿里云官网对Qwen3.5-Plus的描述是："原生多模态合一训练，混合架构双创新突破。"
简单说，以前是两个人配合干活，现在是一个人同时搞定。

第二个：Gated Delta Networks——线性注意力机制。
官方确认，Qwen3.5采用了一种叫 Gated Delta Networks 的线性注意力，跟传统的Gated Attention做了混合架构。
传统Transformer的注意力计算量跟序列长度的平方成正比，Gated Delta Networks把这个关系拉成线性。

翻译成人话：处理长文本的速度快了，显存占用也降了。
而且不是快了一点半点——官方实测数据：

• 在32k上下文长度下，Qwen3.5-397B-A17B的解码吞吐量是Qwen3-Max的 8.6倍


• 在256k上下文长度下，这个数字是 19.0倍


• 跟Qwen3-235B-A22B比，分别是3.5倍和7.2倍

老金我看到这个数据的时候饺子真喷出来了。

第三个：更大的模型家族。
目前在chat.qwen.ai上已经可以直接使用的有两个版本：

• Qwen3.5-Plus（闭源API模型，通过阿里云百炼提供服务，支持 1M token上下文窗口）


• Qwen3.5-397B-A17B（开源旗舰模型，3970亿参数只激活170亿）

跟之前HuggingFace代码里泄露的9B和35B-A3B相比，正式发布的模型规模大得多。
3970亿总参数，比Qwen3的旗舰235B-A22B直接翻了快一倍。

总参数量达3970亿，每次前向传播仅激活170亿参数，在保持能力的同时优化速度与成本。

语言与方言支持从119种扩展至201种，词表从15万扩大到25万，在多数语言上带来约10-60%的编码/解码效率提升。
简单说，同样的一段话，Qwen3.5能用更少的token表示，推理更快，API费用也更省。

线性注意力到底意味着什么

这块稍微展开说一下，因为这可能是Qwen3.5最关键的技术突破。
不懂技术的朋友别跳过，老金我用人话给你翻译。

传统Transformer用的是标准自注意力机制。
简单理解：AI在读一篇文章的时候，每读到一个字，都要回头看一遍前面所有的字。

如果文章有1万个字，每个字要跟其他9999个字各看一次。
字数越多，AI就越吃力——计算量是"字数的平方"级别的。

Qwen3.5用的Gated Delta Networks，核心思路是：用一个巧妙的数学方法，让AI不用每次都回头看所有内容。
结果就是：计算量从"字数的平方"降到"字数的倍数"。

听起来差别不大？我给你举个具体例子：

处理一个10分钟的视频：

• 传统方式：可能需要64G显存的显卡才能跑


• Gated Delta Networks：16G显存就够了

这不是快了几个百分点的问题，是能不能跑起来的问题。
很多任务以前根本跑不动，现在可以了。

Qwen3.5更聪明的地方在于：它把Gated Delta Networks（线性注意力）和Gated Attention（标准注意力）做成了 混合架构。
简单任务用线性注意力省资源，复杂任务自动切换到标准注意力保精度。
不是非此即彼，而是动态选择——什么场景用什么方案。

这也是为什么官方说的"Qwen3-Next架构"——更高稀疏度的MoE + 混合注意力 + 多token预测。

多token预测是什么意思？
传统模型一次只能"想"出一个字，Qwen3.5一次能预测多个字，生成速度又快了一截。

原生多模态为什么重要

之前的多模态模型大多是"拼接式"的。
打个比方：就像找了一个英语翻译和一个法语翻译，中间再安排一个协调员把两人的翻译对接起来。

先训一个语言模型（处理文字），再训一个视觉编码器（处理图片），最后用对齐层把两者连起来。
这种方式有个天然缺陷：视觉和语言的理解是割裂的。

Qwen3.5走的是另一条路——从预训练阶段就把文本、图像、视频放在一起训。
模型从一开始就"看"和"读"同时进行。
就像培养一个从小就双语环境长大的孩子，不需要翻译，直接理解。

阿里官方说法是"统一架构整合语言推理与视觉感知"。

这对普通用户来说意味着什么？
1、你发一张图给AI，它能真正"看懂"图里的内容，不容易出现"看到了但理解错了"的情况
2、一次对话就能同时处理图片+文字，不用分两步操作
3、成本更低——一个模型干两个模型的活，API费用直接砍半

阿里官网已经写了"效果、成本与多模态理解深度上同时超越Qwen3-Max与Qwen3-VL"。
如果这个说法成立，那Qwen3.5-Plus可能是目前性价比最高的多模态模型之一。

比如这样提问，它都能准确且快速的回答：

跑分亮了：Qwen3.5到底有多强

说技术架构大家可能没直觉，直接看跑分数据。
官方放了一大堆benchmark对比，老金我帮你提炼最关键的几个：

自然语言能力（对比GPT5.2、Claude 4.5 Opus、Gemini-3 Pro）：

几个重点：

1、指令遵循（IFBench 76.5）和多语言挑战（MultiChallenge 67.6）两项全场第一。
这意味着你给它的指令它听得更准，不容易跑偏。

2、搜索Agent能力（BrowseComp 78.6）也是第一。
联网搜索信息的能力很强。

3、多语言能力（NOVA-63 59.1）第一。
201种语言不是白支持的。

4、编程和数学还是GPT5.2和Claude强一些，但差距不大。

视觉语言能力（这才是Qwen3.5的杀手锏）：

乖乖，视觉能力这块Qwen3.5真的杀疯了：

• MathVision 88.6——看图做数学题，全场最高


• OCRBench 93.1——文字识别能力，直接碾压，比GPT5.2高出12个点


• OmniDocBench 90.8——文档理解能力第一，对搞办公的朋友来说太实用了


• HallusionBench 71.4——幻觉最少，看到什么说什么，不瞎编


• AndroidWorld 66.8——能操作安卓手机，这个后面单独说

注意，这是一个3970亿参数只激活170亿的模型跑出来的成绩。
跟GPT5.2这种完整版闭源大模型对打还能在多个维度赢，开源模型能做到这个水平，老金我服了。

Visual Agent：AI能操作你的手机和电脑了

这是老金我觉得最炸裂的功能，但很多报道都没重点说。
Qwen3.5可以作为 视觉智能体，自主操作手机和电脑完成日常任务。

什么意思？你告诉它"帮我把这个Excel表格的缺失行补全"，它真的能：
1、打开Excel文件
2、识别出哪些行和列需要补全
3、自动填写数据
4、保存文件

全程不需要你动手，AI自己操作界面完成。
官方展示了好几个演示：

• 手机端：适配主流App，你说"帮我发条朋友圈"，它能自己操作完成


• 电脑端：处理跨应用的数据整理、多步骤流程自动化

AndroidWorld跑分66.8，目前公开数据里最高的。
这不是ChatGPT那种"帮你写个脚本自己跑"。
Qwen3.5是真的在操作GUI界面，像人一样点击、输入、滑动。

对于不会编程的普通用户来说，这个能力可能比会写代码更有用。

空间智能和视觉编程

除了操作手机电脑，Qwen3.5在"看"这件事上还有两个特别的能力。

空间智能：
借助对图像像素级位置信息的建模，Qwen3.5能做到：

• 物体计数——图里有几个苹果，它能数准


• 相对位置判断——电话亭在黄色货车的左边还是右边


• 驾驶场景理解——看行车记录仪画面，分析为什么没在路口停车

官方展示了一个驾驶场景的例子：给它一段行车记录仪视频截帧，它能分析出"信号灯在我接近停车线时变黄，此时距离太近无法安全停车，所以选择通过路口"。
这个能力在自动驾驶和机器人导航场景里非常关键。

视觉编程：
更酷的是，Qwen3.5能把看到的东西变成代码：

• 手绘界面草图 → 结构清晰的前端代码


• 游戏视频 → 逻辑还原代码


• 长视频 → 自动提炼为结构化网页

你甚至可以让他看视频手搓游戏。

如果对你有帮助，记得关注一波~

春节档：AI圈的神仙打架

Qwen3.5选在除夕夜发布，这个时间点太狠了。
这个春节档，至少还有3个重磅选手要登场。

1、DeepSeek V4——最受期待的选手，V3已经证明了DeepSeek的实力
2、GLM-5——智谱的新旗舰，之前Pony Alpha的表现已经让人刮目相看
3、MiniMax 2.2——M2.5编程能力追平Claude，2.2值得关注

老金我觉得今年春节档的竞争格局跟去年完全不同。
去年是DeepSeek V3一家独大。
今年是四五个玩家同时出牌。

对普通用户来说，这其实是好事。
竞争越激烈，开源模型的能力提升越快，API价格越便宜。

MoE架构：小身材大能量

Qwen3.5-397B-A17B这个版本号值得单独说一下。
397B是总参数量，A17B是激活参数量——3970亿参数里每次只用170亿。

什么意思？打个比方：
这就像一个公司有3970个员工，但每次处理一个任务只需要170个人同时干活。
其他人"待命"，等需要的时候再上。

这就是MoE（Mixture of Experts，混合专家）架构的核心思路。
模型里有很多"专家"模块，每个token只激活其中几个。
好处是：模型容量大（知识多），但推理成本低（算得快）。

回顾一下Qwen3的数据：

Qwen3-235B-A22B（2350亿参数，激活220亿）在编程、数学、推理上已经能跟DeepSeek-R1、GPT-5正面对决。
Qwen3-30B-A3B在SWE-Bench上拿到69.6分，价格性能比吊打一众付费模型。

Qwen3.5-397B-A17B直接把总参数量拉到3970亿，是Qwen3旗舰的1.7倍。
但激活参数只有170亿，比Qwen3旗舰的220亿还少。

翻译成人话：知识储备更多了，但跑起来反而更省资源。
再加上原生多模态和线性注意力的加持，老金我认为这是2026年上半年最值得关注的开源模型之一。

现在就能用：3步上手Qwen3.5

说了这么多技术细节，老金我讲讲实际怎么用。
好消息是：你现在就可以直接体验Qwen3.5，不用等。

第1步：打开 chat.qwen.ai
浏览器直接输入 chat.qwen.ai，这是阿里官方的对话平台。
注册一个账号就能用，支持手机号和邮箱注册。
不需要科学上网，国内直接访问。

第2步：选模型和模式
页面顶部有个模型选择器，点开会看到两个选项：

• Qwen3.5-Plus：推荐日常使用，速度快，响应快


• Qwen3.5-397B-A17B：旗舰模型，适合复杂任务（推理、写代码、分析长文档）

不知道选哪个？选Qwen3.5-Plus就行，够用了。
需要更强的推理能力再切397B。

选好模型后，还能选三种思考模式：

• 自动（auto）：自适应思考，该深入就深入，该快就快，推荐大多数场景使用


• 思考（thinking）：遇到难题用这个，模型会进行深度推理，一步步想清楚再回答


• 快速（fast）：简单问题用这个，不消耗思考token，回答又快又省

第3步：直接对话
跟ChatGPT的用法一模一样——输入框打字，回车发送。
支持的功能包括：

• 纯文字对话（问答、写作、翻译、编程）


• 上传图片让它分析（产品截图、文档照片、手写笔记）


• 上传文件让它总结（PDF、Word、代码文件）


• 联网搜索（点击搜索按钮，它会帮你查最新信息）

完全免费，目前没有次数限制。

对，你没看错，免费的。
这也是阿里开源生态的一贯打法。

开发者进阶用法

如果你是开发者，除了网页版还有更多玩法。

场景1：API调用（1M上下文窗口）
阿里云百炼已经上线Qwen3.5-Plus的API，支持100万token的上下文窗口。
100万token是什么概念？大概相当于一次性读完一本750页的英文小说还绰绰有余。

而且API完全兼容OpenAI格式，切换成本几乎为零：

from openai import OpenAI



client = OpenAI(

    api_key="your-api-key",

    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",

)



completion = client.chat.completions.create(

    model="qwen3.5-plus",

    messages=[{"role": "user", "content": "介绍一下Qwen3.5"}],

    extra_body={

        "enable_thinking": True,

        "enable_search": False

    },

    stream=True

)

两个关键参数：

• enable_thinking：开启推理模式，让模型先想再答，适合复杂问题


• enable_search：开启联网搜索和Code Interpreter

场景2：Vibe Coding（跟编程工具集成）
官方明确说了，百炼API可以跟这些编程工具无缝集成：

• Qwen Code——阿里自己的编程助手


• Claude Code——Anthropic的CLI工具


• Cline——VS Code插件


• OpenClaw——开源Agent框架


• OpenCode——开源编程工具

也就是说，你在Claude Code里把模型切成Qwen3.5-Plus，一样能用。
价格比GPT-5便宜10倍以上，对于日常编程来说性价比拉满。

场景3：多模态应用
原生多模态意味着你可以用一个模型搞定：

• 图片内容识别+文案生成


• 视频内容理解+摘要提取


• 图文混排文档的解析和问答


• GUI自动化——让AI帮你操作软件界面

以前这些任务要调3-4个不同的API，现在一个就够了。

场景4：本地部署
Qwen3.5-397B-A17B虽然总参数3970亿，但激活参数只有170亿。
等开源权重发布后，用Ollama或vLLM部署，消费级显卡也有可能跑起来。
后续如果有更小的版本（比如9B），16G显存的显卡就能流畅运行。

老金的判断

Qwen3.5除夕夜在chat.qwen.ai正式上线了。
老金我说说自己的看法。

看好的点：

• 原生多模态是正确的方向，拼接式迟早要被淘汰


• Gated Delta Networks解决了长序列的核心瓶颈，8.6倍/19倍的吞吐量提升不是闹着玩的


• MoE架构在成本和性能之间找到了平衡点——3970亿参数只激活170亿，这个比例很激进


• 视觉能力真的强——OCR、文档理解、数学视觉多项第一


• Visual Agent能操作手机电脑，这是AI从"回答问题"到"替你干活"的关键一步


• 阿里在开源这条路上一直很坚定，Qwen3的开源质量有目共睹


• 完全免费使用，对普通用户来说门槛为零

值得关注的未来方向：
官方博客最后提了三个方向，老金我觉得每个都很重要：
1、跨会话持久记忆——现在的AI每次对话都是"失忆"状态，未来能记住你之前聊过什么
2、具身接口——不只是操作手机电脑屏幕，未来可能控制机器人在真实世界干活
3、自我改进机制——AI能自己变得更好，不需要人类手动更新

阿里原话是："将当前以任务为边界的助手升级为可持续、可信任的伙伴。"

老金我的态度是谨慎乐观。
架构升级的方向是对的，除夕夜放这个大招，阿里是真的有底气。

跑分数据已经出来了，视觉能力多项碾压GPT5.2和Claude 4.5 Opus，你现在就可以去chat.qwen.ai亲自试试。

有一点可以确定：2026年的开源大模型，竞争只会越来越激烈。
对于开发者和普通用户来说，这是最好的时代。

往期推荐：

AI编程教程列表
提示词工工程（Prompt Engineering）
LLMOPS(大语言模运维平台)
AI绘画教程列表
WX机器人教程列表

每次我都想提醒一下，这不是凡尔赛，是希望有想法的人勇敢冲。
我不会代码，我英语也不好，但是我做出来了很多东西，在文末的开源知识库可见。
我真心希望能影响更多的人来尝试新的技巧，迎接新的时代。

谢谢你读我的文章。
如果觉得不错，随手点个赞、在看、转发三连吧🙂
如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章。

开源知识库地址：
tffyvtlai4.feishu.cn/wiki/OhQ8wq…

JDK 25 重磅发布了！这是一个非常重要的版本，里程碑式。

JDK 25 是 LTS（长期支持版），至此为止，有 JDK8、JDK11、JDK17、JDK21 和 JDK 25 这五个长期支持版了。

JDK 21 共有 18 个新特性，这篇文章会挑选其中较为重要的一些新特性进行详细介绍：

• JEP 506: Scoped Values (作用域值)


• JEP 512: Compact Source Files and Instance Main Methods (紧凑源文件与实例主方法)


• JEP 519: Compact Object Headers (紧凑对象头)


• JEP 521: Generational Shenandoah (分代 Shenandoah GC)


• JEP 507: Primitive Types in Patterns, instanceof, and switch (模式匹配支持基本类型, 第三次预览)


• JEP 511: Module Import Declarations (模块导入声明)


• JEP 513: Flexible Constructor Bodies (灵活的构造函数体)


• JEP 508: Vector API (向量 API, 第十次孵化)

其实里面的很多新特性在之前的版本中就多次提到了，这里只是转正或者再次预览。

下图是从 JDK 8 到 JDK 24 每个版本的更新带来的新特性数量和更新时间：

JEP 506: 作用域值

作用域值（Scoped Values）可以在线程内和线程间共享不可变的数据，优于线程局部变量 ThreadLocal ，尤其是在使用大量虚拟线程时。

final static ScopedValue<...> V = new ScopedValue<>();



// In some method

ScopedValue.where(V, <value>)

           .run(() -> { ... V.get() ... call methods ... });



// In a method called directly or indirectly from the lambda expression

... V.get() ...

作用域值通过其“写入时复制”(copy-on-write)的特性，保证了数据在线程间的隔离与安全，同时性能极高，占用内存也极低。这个特性将成为未来 Java 并发编程的标准实践。

JEP 512: 紧凑源文件与实例主方法

该特性第一次预览是由 JEP 445 （JDK 21 ）提出，随后经过了 JDK 22 、JDK 23 和 JDK 24 的改进和完善，最终在 JDK 25 顺利转正。

这个改进极大地简化了编写简单 Java 程序的步骤，允许将类和主方法写在同一个没有顶级 public class的文件中，并允许 main 方法成为一个非静态的实例方法。

class HelloWorld {

    void main() {

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

    }

}

进一步简化：

void main() {

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

}

这是为了降低 Java 的学习门槛和提升编写小型程序、脚本的效率而迈出的一大步。初学者不再需要理解 public static void main(String[] args) 这一长串复杂的声明。对于快速原型验证和脚本编写，这也使得 Java 成为一个更有吸引力的选择。

JEP 519: 紧凑对象头

该特性第一次预览是由 JEP 450 （JDK 24 ）提出，JDK 25 就顺利转正了。

通过优化对象头的内部结构，在 64 位架构的 HotSpot 虚拟机中，将对象头大小从原本的 96-128 位（12-16 字节）缩减至 64 位（8 字节），最终实现减少堆内存占用、提升部署密度、增强数据局部性的效果。

紧凑对象头并没有成为 JVM 默认的对象头布局方式，需通过显式配置启用：

• JDK 24 需通过命令行参数组合启用：
  $ java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders ... ；


• JDK 25 之后仅需 -XX:+UseCompactObjectHeaders 即可启用。

JEP 521: 分代 Shenandoah GC

Shenandoah GC 在 JDK12 中成为正式可生产使用的 GC，默认关闭，通过 -XX:+UseShenandoahGC 启用。

Redhat 主导开发的 Pauseless GC 实现，主要目标是 99.9% 的暂停小于 10ms，暂停与堆大小无关等

传统的 Shenandoah 对整个堆进行并发标记和整理，虽然暂停时间极短，但在处理年轻代对象时效率不如分代 GC。引入分代后，Shenandoah 可以更频繁、更高效地回收年轻代中的大量“朝生夕死”的对象，使其在保持极低暂停时间的同时，拥有了更高的吞吐量和更低的 CPU 开销。

Shenandoah GC 需要通过命令启用：

• JDK 24 需通过命令行参数组合启用：-XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational


• JDK 25 之后仅需 -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational 即可启用。

JEP 507: 模式匹配支持基本类型 (第三次预览)

该特性第一次预览是由 JEP 455 （JDK 23 ）提出。

模式匹配可以在 switch 和 instanceof 语句中处理所有的基本数据类型（int, double, boolean 等）

static void test(Object obj) {

    if (obj instanceof int i) {

        System.out.println("这是一个int类型: " + i);

    }

}

这样就可以像处理对象类型一样，对基本类型进行更安全、更简洁的类型匹配和转换，进一步消除了 Java 中的模板代码。

JEP 505: 结构化并发(第五次预览)

JDK 19 引入了结构化并发，一种多线程编程方法，目的是为了通过结构化并发 API 来简化多线程编程，并不是为了取代java.util.concurrent，目前处于孵化器阶段。

结构化并发将不同线程中运行的多个任务视为单个工作单元，从而简化错误处理、提高可靠性并增强可观察性。也就是说，结构化并发保留了单线程代码的可读性、可维护性和可观察性。

结构化并发的基本 API 是StructuredTaskScope，它支持将任务拆分为多个并发子任务，在它们自己的线程中执行，并且子任务必须在主任务继续之前完成。

StructuredTaskScope 的基本用法如下：

    try (var scope = new StructuredTaskScope<Object>()) {

        // 使用fork方法派生线程来执行子任务

        Future<Integer> future1 = scope.fork(task1);

        Future<String> future2 = scope.fork(task2);

        // 等待线程完成

        scope.join();

        // 结果的处理可能包括处理或重新抛出异常

        ... process results/exceptions ...

    } // close

结构化并发非常适合虚拟线程，虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程，从而允许非常多的虚拟线程。

JEP 511: 模块导入声明

该特性第一次预览是由 JEP 476 （JDK 23 ）提出，随后在 JEP 494 （JDK 24）中进行了完善，JDK 25 顺利转正。

模块导入声明允许在 Java 代码中简洁地导入整个模块的所有导出包，而无需逐个声明包的导入。这一特性简化了模块化库的重用，特别是在使用多个模块时，避免了大量的包导入声明，使得开发者可以更方便地访问第三方库和 Java 基本类。

此特性对初学者和原型开发尤为有用，因为它无需开发者将自己的代码模块化，同时保留了对传统导入方式的兼容性，提升了开发效率和代码可读性。

// 导入整个 java.base 模块，开发者可以直接访问 List、Map、Stream 等类，而无需每次手动导入相关包

import module java.base;



public class Example {

    public static void main(String[] args) {

        String[] fruits = { "apple", "berry", "citrus" };

        Map<String, String> fruitMap = Stream.of(fruits)

            .collect(Collectors.toMap(

                s -> s.toUpperCase().substring(0, 1),

                Function.identity()));



        System.out.println(fruitMap);

    }

}

JEP 513: 灵活的构造函数体

该特性第一次预览是由 JEP 447 （JDK 22）提出，随后在 JEP 482 （JDK 23）和 JEP 492 （JDK 24）经历了预览，JDK 25 顺利转正。

Java 要求在构造函数中，super(...) 或 this(...) 调用必须作为第一条语句出现。这意味着我们无法在调用父类构造函数之前在子类构造函数中直接初始化字段。

灵活的构造函数体解决了这一问题，它允许在构造函数体内，在调用 super(..) 或 this(..) 之前编写语句，这些语句可以初始化字段，但不能引用正在构造的实例。这样可以防止在父类构造函数中调用子类方法时，子类的字段未被正确初始化，增强了类构造的可靠性。

这一特性解决了之前 Java 语法限制了构造函数代码组织的问题，让开发者能够更自由、更自然地表达构造函数的行为，例如在构造函数中直接进行参数验证、准备和共享，而无需依赖辅助方法或构造函数，提高了代码的可读性和可维护性。

class Person {

    private final String name;

    private int age;



    public Person(String name, int age) {

        if (age < 0) {

            throw new IllegalArgumentException("Age cannot be negative.");

        }

        this.name = name; // 在调用父类构造函数之前初始化字段

        this.age = age;

        // ... 其他初始化代码

    }

}



class Employee extends Person {

    private final int employeeId;



    public Employee(String name, int age, int employeeId) {

        this.employeeId = employeeId; // 在调用父类构造函数之前初始化字段

        super(name, age); // 调用父类构造函数

        // ... 其他初始化代码

    }

}

JEP 508: 向量 API(第十次孵化)

向量计算由对向量的一系列操作组成。向量 API 用来表达向量计算，该计算可以在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令，从而实现优于等效标量计算的性能。

向量 API 的目标是为用户提供简洁易用且与平台无关的表达范围广泛的向量计算。

这是对数组元素的简单标量计算：

void scalarComputation(float[] a, float[] b, float[] c) {

   for (int i = 0; i < a.length; i++) {

        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;

   }

}

这是使用 Vector API 进行的等效向量计算：

static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;



void vectorComputation(float[] a, float[] b, float[] c) {

    int i = 0;

    int upperBound = SPECIES.loopBound(a.length);

    for (; i < upperBound; i += SPECIES.length()) {

        // FloatVector va, vb, vc;

        var va = FloatVector.fromArray(SPECIES, a, i);

        var vb = FloatVector.fromArray(SPECIES, b, i);

        var vc = va.mul(va)

                   .add(vb.mul(vb))

                   .neg();

        vc.int0Array(c, i);

    }

    for (; i < a.length; i++) {

        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;

    }

}

尽管仍在孵化中，但其第十次迭代足以证明其重要性。它使得 Java 在科学计算、机器学习、大数据处理等性能敏感领域，能够编写出接近甚至媲美 C++等本地语言性能的代码。这是 Java 在高性能计算领域保持竞争力的关键。

从 JDK8 到 JDK24 每一版版本的新特性详细介绍，可以在 JavaGuide 官方网站（ javaguide.cn ）上找到。

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

01 引言

FastExcel仅存在江湖上出现了两年，可能很多开发者还不知道这个项目。但是说到阿里的EasyExcel，大家肯定耳熟能详。

没错，FastExcel就是EasyExcel的作者离开阿里之后，重新维护的加强版EasyExcel，而此后，阿里的EasyExcel宣布不再更新进入维护期。

这两天，无意间看到一篇文章介绍的Apache新项目，怎么看怎么眼熟，和FastExcel如出一撤。了解下来，才发现原来是同一个项目，只是背景更加强大了。

02 Fesod

2.1 简介

Apache Fesod (Incubating)是一个高性能、内存高效的 Java 库，用于读写电子表格文件，旨在简化开发并确保可靠性。

Apache Fesod (Incubating) 可以为开发者和企业提供极大的自由度和灵活性。我们计划在未来引入更多新功能，以持续提升用户体验和工具可用性。Apache Fesod (Incubating) 致力于成为您处理电子表格文件的最佳选择。

名称 fesod（发音为 /ˈfɛsɒd/），是 fast easy spreadsheet and other documents（快速简单的电子表格和其他文档）的首字母缩写，表达了项目的起源、背景和愿景。

Apache Fesod目前处于孵化器，还没有正式毕业。最低的Java版本也必须是1.8。

GitHub地址：github.com/apache/feso…

官网地址：fesod.apache.org/

2.2 Maven依赖

以后要使用的依赖：

<dependency>

    <groupId>org.apache.fesod</groupId>

    <artifactId>fesod</artifactId>

    <version>version</version>

</dependency>