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

站点地址：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>

由于目前正处于Apache的孵化期，暂时没有稳定版本。要使用的话，目前最新的fastexcel 1.3.0的版本。

<dependency>

    <groupId>cn.idev.excel</groupId>

    <artifactId>fastexcel</artifactId>

    <version>1.3.0</version>

</dependency>

2.3 大致时间线

• 2024.09.11 easyexcel发布最后一个稳定版本，easyexcel 4.0.3


• 2024.11.06 easyexcel阿里官方宣布停更。只修复BUG


• 2024.12.05 easyexcel作者新开仓库，取名FastExcel,并发布第一个版本，fastexcel 1.0.0


• 2025.01.14 fastExcel 发布第二个版本稳定版，fastexcel 1.1.0


• 2025.04.14 fastExcel 发布第三个版本稳定版，fastexcel 1.2.0


• 2025.08.23 fastExcel发布最后一个稳定版本，fastexcel 1.3.0


• 2025.09.04 easyexcelGitHub仓库归档，仅可读


• 2025.09.17 fastExcel正式进入Apache服化器，更名Fesod

从此，正式成为Apache的产物，所谓Apache出品必是精品，这么强大的维护团队，期待更多的功能以及更好的性能。

其实在FastExcel作者创建仓库时，第一次的名字并不是FastExcel，好像是EasyExcel plus，具体什么不记得了。但确实存在过。

2.4 怀疑

网上搜了一下fastExcel捐给Apache的消息有限，并没有官方说明。还特意看了下Apache Fesod团队的人员有没有Fastexcel的作者。看了之后确实有。

2.5 熟悉的味道

案例这里就不在赘述，我们看看官方即可：

新的项目使用FesodSheet调起读写方法，其他和原来的一致。

03 小结

不追求新功能的可以继续使用原来的fastexcel或者easyexcel,大部分场景，简单的导入导出功能已经足够使用。渴望新功能的，可以期待一下fesod的正式版。

这个问题本身有个误解：把三个东西都叫「web server」，会让人以为它们是同一种东西的三种实现。其实不是。Nginx 和 Apache 是 HTTP 服务器，Tomcat 是 Servlet 容器，它们干的活不在一个层次上。

Nginx 和 Apache（一般说的 Apache 指的是 Apache HTTP Server，也就是 httpd）是 HTTP 服务器：收 HTTP 请求、按配置干活、回 HTTP 响应。它们擅长扛静态文件、做反向代理、做负载均衡，但它们不执行 Java 代码。你打一个 .war 包丢给 Nginx，Nginx 不知道怎么处理——它只会返回 404 或者把请求转给别人。

Tomcat 是 Servlet 容器，不是完整的 Java EE 应用服务器（那是 WildFly、WebLogic、WebSphere 干的事，它们支持 EJB、JMS、JTA 等完整规范）。Tomcat 只实现 Servlet 和 JSP 规范，核心能力是：把 HTTP 请求交给你的 Java 代码去处理，再把结果变成 HTTP 响应发回去。

所以「Java 后台程序能不能用 Apache 和 Nginx」——能，而且生产环境里经常是「Nginx/Apache 在前，Tomcat 在后」：前面负责扛流量、静态资源、HTTPS 终结、负载均衡，后面专门跑 Java。

Nginx 和 Apache：都是 HTTP 服务器，架构不一样

两者都能做静态文件服务、反向代理、负载均衡，但内部设计完全不同。

Apache 有三种工作模式（MPM）：prefork 是一个连接一个进程，worker 是多进程+多线程，event 是在 worker 基础上优化了 keep-alive 连接的处理。现代 Apache（2.4+）默认用 event MPM，处理 keep-alive 的方式已经接近事件驱动了，不完全是老式的「一个连接占一个线程」。但不管哪种模式，Apache 的并发上限都受限于进程/线程数——每个线程有自己的栈空间（Linux 默认 8MB），1000 个线程光栈就要 8GB 内存，还没算堆上的数据。所以 Apache 的并发连接数一般在几百到几千这个量级。

Nginx 是另一种思路：少量 worker 进程 + 事件循环。每个 worker 用 epoll（Linux）/ kqueue（macOS）做 I/O 多路复用，一个 worker 可以同时挂着几万条连接。大部分连接在等 I/O，不需要单独的线程，也就不需要那 8MB 的栈空间。所以同样一台机器，Nginx 能撑的并发连接数比 Apache 高一个数量级。

这也是很多人说「Nginx 比 Apache 性能好」的原因——不是 Nginx 处理单个请求更快，而是它用更少的资源就能维持大量连接。 如果你的场景是几十个并发、主要跑 PHP，Apache + mod_php 用着挺好，没必要换。但如果要扛几万并发、做反向代理或者负载均衡，Nginx 的模型更合适。

Tomcat：能直接对外，但不擅长

这里要纠正一个常见的说法：「Tomcat 必须放在 Nginx 后面」。

Tomcat 自带 HTTP 连接器（Coyote），可以直接监听 80 或 443 端口对外服务。开发的时候大家天天直接访问 localhost:8080，没什么问题。Spring Boot 更进一步——内嵌 Tomcat 打成一个 jar 包，java -jar 直接跑，连单独部署 Tomcat 都省了。

很多微服务架构里，每个服务就是一个内嵌 Tomcat 的 Spring Boot 应用，前面挂一个 API 网关（Spring Cloud Gateway、Kong 之类的）做路由和鉴权，根本没有单独部署 Nginx 的环节。

但 Tomcat 直接对外有几个短板：

静态文件性能。 Nginx 处理静态文件用的是 sendfile 系统调用（之前零拷贝那篇讲过），数据不经过用户空间，直接从磁盘到网卡。Tomcat 处理静态文件要经过 Java 的 IO 层，多了一次拷贝和 JVM 的开销。量小的时候感知不到，量大了差距就出来了。

SSL 终结。 Nginx 的 SSL 实现基于 OpenSSL，经过大量优化，支持 session 复用、OCSP stapling 这些。Tomcat 也能做 SSL，但性能和配置灵活性都不如 Nginx。把 SSL 卸载到 Nginx，Tomcat 和 Nginx 之间走 HTTP 明文，Tomcat 的负担更轻。

限流、缓存、负载均衡。 这些 Nginx 用几行配置就能搞定，Tomcat 要么不支持，要么需要写 Java 代码或者引入额外组件。

所以典型的生产部署是这样的：

upstream tomcat_backend {

    server 127.0.0.1:8080;

    server 127.0.0.1:8081;  # 多实例负载均衡

}



server {

    listen 443 ssl;

    ssl_certificate     /etc/nginx/cert.pem;

    ssl_certificate_key /etc/nginx/key.pem;



    location /static/ {

        alias /var/www/static/;

    }



    location / {

        proxy_pass http://tomcat_backend;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-Proto $scheme;

    }

}

Nginx 扛 SSL、吐静态文件、做负载均衡，动态请求转给后面的 Tomcat。但这不是唯一的架构——小项目、内部系统、微服务里 Tomcat 直接对外也很常见，取决于你的流量规模和运维需求。

为啥早年都是 Apache + Tomcat

早期 Nginx 还没普及的时候，Apache 是 Linux 上默认的 HTTP 服务器。Java 项目的标准搭配是 Apache + mod_jk（或 mod_proxy）+ Tomcat：Apache 在前面接请求，通过 AJP 协议或 HTTP 代理转给 Tomcat。

mod_jk 用的是 AJP 协议（Apache JServ Protocol），比 HTTP 更紧凑，省了 HTTP 头的解析开销。但 AJP 协议在 2020 年爆出过 Ghostcat 漏洞（CVE-2020-1938），之后很多团队开始关闭 AJP 端口，改用 HTTP 代理。

现在新项目基本都用 Nginx 替代 Apache 当入口了。Apache 在需要 .htaccess（目录级配置覆盖）或者跑 mod_php 的场景还有优势，但纯做反向代理和负载均衡，Nginx 的资源占用和并发能力都更好。

怎么判断你的项目该用哪种组合

Spring Boot 微服务、内部系统、流量不大： 内嵌 Tomcat 直接对外，前面挂个网关或者云厂商的负载均衡器就行，不需要单独部署 Nginx。

对外的 Web 应用、有静态资源、需要 HTTPS： Nginx 在前做 SSL 终结和静态资源，动态请求 proxy_pass 到 Tomcat。

PHP + Java 混合部署（老项目）： Apache 跑 mod_php 处理 PHP，同时 mod_proxy 把 Java 请求转给 Tomcat。不过这种架构越来越少了。

纯静态站点、CDN 回源、API 网关： 只需要 Nginx，不需要 Tomcat。

Nginx 和 Tomcat 不是竞争关系，Apache 和 Nginx 才是。而即便是 Apache 和 Nginx，在大部分场景下也不是「谁好谁差」的问题——Nginx 在高并发反向代理上更强，Apache 在需要 .htaccess 和动态模块加载的场景更方便。

PWA 到底是什么？

Progressive Web App（渐进式 Web 应用，简称 PWA）是一种使用标准 Web 技术（HTML、CSS、JavaScript）构建的网页应用，但通过浏览器提供的增强能力，让它具备接近原生 App 的体验。

它不是一个全新的东西，而是一种“渐进增强”（Progressive Enhancement）的理念：从普通的网页开始，逐步添加高级特性，让用户感觉像在使用安装的原生应用。

PWA 的三大核心支柱（至今仍是）：

• 可靠（Reliable）：即使在弱网/断网情况下也能加载并基本可用（靠 Service Worker + 缓存）。


• 快速（Fast）：瞬间加载、流畅交互（优化的缓存 + 性能最佳实践）。


• 可安装（Installable）：可以“添加到主屏幕”，以独立窗口（standalone）模式运行，有图标、启动画面，像 App 一样。

在 2026 年，PWA 已经从 2015 年的“概念”变成了许多企业实际落地的主流移动解决方案之一。浏览器支持大幅成熟，Chrome/Edge/Firefox 几乎完整，Safari（iOS）也追赶了很多年（虽仍有差距）。

它在 2026 年真正解决了哪些真实痛点？

以下是 2026 年开发者/产品/业务最常遇到的痛点，以及 PWA 如何针对性解决（基于当前浏览器现实支持情况）：

2026 年 PWA 的真实平台支持对比（简表）

总结一句话（2026 年视角）

PWA 不是要完全取代原生 App，而是解决了**“我想给用户 App 般的体验，但不想付出双平台原生开发的代价”** 这个最真实、最普遍的痛点。

特别适合：

• 电商、新闻、社交工具、SaaS、生产力工具、内容平台


• 预算有限、需要快速验证、重视 SEO 和链接分享的场景


• 想覆盖桌面 + 移动 + 弱网用户的企业

不适合：

• 重度游戏、AR/VR、深度硬件调用（如银行指纹/人脸支付完整链路）


• 对 iOS 推送/后台要求极高的场景（仍需原生补位）

很多开发者还在用十年前的习惯写现在的 Spring Boot 应用。这种技术代差不仅让代码显得臃肿，更是在浪费服务器的真金白银。本文整理了一些进阶技巧，帮助优化 Spring Boot 应用的运行效率与代码质量。

准备工作：快速搭建 Java 环境

编写代码前需要安装 JDK。但对新手来说，手动配置环境变量和切换版本其实挺浪费时间的。

而 ServBay 提供了集成化的解决方案，支持一键部署 Java 环境，这样开发者可以快速切换不同的 JDK 版本，无需手动调整系统配置，让开发环境的搭建变得高效且规范。

精细化配置 JVM 内存降低云端成本

很多 Spring Boot 应用在云服务器上裸奔。默认的 JVM 配置往往会申请过多的内存，导致账单金额飙升。

如果我们运行的是微服务，其实根本不需要动辄 4GB 的堆空间。我通常会把初始内存和最大内存压到一个合理的范围。

# 限制内存并指定垃圾回收线程数

export JAVA_OPTS="-Xms512m -Xmx1024m -XX:+UseContainerSupport -XX:ParallelGCThreads=2 -XX:MaxMetaspaceSize=256m"

java $JAVA_OPTS -jar app-service.jar

加上 -XX:+UseContainerSupport 后，JVM 能准确识别容器的边界。同时，我会手动限制 Tomcat 的线程池大小，因为默认的 200 个线程对大多数中小型业务来说完全是浪费。

# application.yaml 里的精简配置

server:

  tomcat:

    threads:

      max: 60

通过这些设置，单个容器的内存占用通常能降低 20% 以上，从而减少云服务器的节点数量。

采用现代 Java 语法精简业务逻辑

如果代码库里到处是冗长的 Getter 和 Setter，或者还在用复杂的 if-else 处理枚举，那就赶紧升级新版 Java。

使用 Record 定义数据模型

Record 适合用于 DTO 或 API 返回对象。我现在的 API 数据传输对象全部改用 Record。

// 这一行代码就搞定了构造、Getter 和 toString

public record UserResponse(Long id, String nickname, String email) {}

文本块与 Switch 表达式

文本块解决了多行字符串拼接时的转义符困扰，而 Switch 表达式则提供了更安全的返回值方式。

// 使用文本块编写 SQL

String sql = """

    SELECT * FROM product_info 

    WHERE category = 'ELECTRONICS' 

    AND stock > 0

    """;



// Switch 表达式直接返回结果

String categoryName = switch (typeCode) {

    case 1 -> "电子产品";

    case 2 -> "家居生活";

    default -> "其他类型";

};

Switch 的模式匹配

Java 17 引入的模式匹配让类型判断更加直观，减少了显式的强制类型转换。所以，处理复杂的业务分支时，我会用增强型的 Switch 配合模式匹配。

// 处理不同类型的事件消息

static String handleEvent(Object event) {

    return switch (event) {

        case OrderEvent o -> "订单编号：" + o.id();

        case UserEvent u -> "用户名称：" + u.name();

        case null -> "空消息";

        default -> "未知事件";

    };

}

善用 Stream API 的增强功能

Stream API 在数据处理方面持续进化。新版增加了更丰富的收集器与过滤逻辑，使得内存中的数据聚合与转换更加高效。合理使用并行流处理大规模数据集，可以充分利用多核 CPU 的性能，缩短复杂逻辑的执行时间。

启用现代垃圾回收器减少停顿

在高并发场景下，我更倾向于使用 ZGC 这种低延迟垃圾回收器。它能把停顿时间压减到 1 毫秒以内，用户几乎感知不到卡顿。

如果对启动速度有极端要求，比如在函数计算场景下，我会利用 GraalVM 将 Spring Boot 编译为原生镜像（Native Image）。

# 构建原生执行文件

./mvnw native:compile -Pnative

这样编译出来的程序启动时间从几秒缩短到几十毫秒，内存占用甚至能砍掉 80%。虽然编译过程变久了，但运行时换来的性能增益它值得。

耗时任务必须异步化

在 Controller 里同步生成 PDF 或者发送复杂的邮件的都叉出去，这会直接堵死 Web 线程。

现在的做法是把这些重活直接扔进消息队列，让主流程瞬间返回。

// 投递到 RabbitMQ 或 Kafka@PostMapping("/submit-report")

public ResponseEntity<String> handleReport(@RequestBody ReportConfig config) {

    taskQueue.send("report_gen_topic", config);

    return ResponseEntity.accepted().body("报告生成任务已启动，请稍后查看");

}

把计算压力转移到后端的 Worker 节点上，这样主 API 就能保持极高的响应速度，即便在高并发流量下也不会崩溃。

总结

优化 Spring Boot 应用是一个系统性的工程。如果你还在忍受冗长的编译等待、高昂的云端开支和莫名其妙的停顿，现在就应该改变做法了。快来试试这些技巧吧。

// 糟糕的做法：阻塞主线程

void onClick() {

    Data data = network.fetchSync();  // 界面卡住 3 秒

    updateUI(data);

}



// 更好的做法：用单独线程处理阻塞操作

void onClick() {

    new Thread(() -> {

        Data data = network.fetchSync();

        runOnUIThread(() -> updateUI(data));

    }).start();

}

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

│                   共享线程池                      │

│  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐       │

│  │ T1  │ │ T2  │ │ T3  │ │ T4  │ │ T5  │       │

│  │阻塞 │ │阻塞 │ │阻塞 │ │阻塞 │ │阻塞 │       │

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

│     │       │       │       │       │          │

│     └───────┴───────┼───────┴───────┘          │

│                     ▼                           │

│         下游服务 A（响应变慢）                    │

│                                                 │

│  结果：所有线程被 A 占满，B 和 C 的请求无法处理    │

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

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

│                                                  │

│   ┌──────────┐  ┌──────────┐  ┌──────────┐      │

│   │ 线程池 A  │  │ 线程池 B  │  │ 线程池 C  │      │

│   │ (3线程)  │  │ (3线程)  │  │ (3线程)  │      │

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

│        │             │             │            │

│        ▼             ▼             ▼            │

│    下游服务A      下游服务B      下游服务C        │

│    (变慢)        (正常)        (正常)           │

│                                                  │

│   结果：A 的线程池耗尽，但 B 和 C 不受影响        │

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

while True:

    if has_network_event():

        handle_network()

    if time_for_game_tick():

        game_tick()

    if has_scheduled_task():

        run_task()

    if log_buffer_not_empty():

        flush_logs()

    # ... 代码很快变成一团乱麻

Thread("network",   network_loop)

Thread("game-tick", game_loop)

Thread("scheduler", scheduler_loop)

Thread("logger",    log_writer_loop)

// 简单测试：创建 10000 个线程

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

    pthread_create(&threads[i], NULL, empty_func, NULL);

}

// 在普通机器上可能需要 100-300ms

pthread_attr_t attr;

pthread_attr_init(&attr);

pthread_attr_setstacksize(&attr, 256 * 1024);  // 256 KB

pthread_create(&thread, &attr, func, NULL);

Thread thread = new Thread(null, runnable, "name", 256 * 1024);

// 或者 JVM 参数 -Xss256k

纯粹的上下文切换本身只需要 1-5 微秒。但切换后，新线程访问的数据很可能不在 CPU 缓存中，需要从内存重新加载。这种缓存污染导致的性能损失可能比切换本身高出一个数量级。

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

│                  上下文切换的真实开销                 │

├─────────────────────────────────────────────────────┤

│  直接开销（保存/恢复状态）         ~1-5 μs          │

│  间接开销（缓存失效）              ~10-100 μs       │

│  总体影响                          视工作负载而定   │

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

4. 调度开销

操作系统需要维护运行队列、就绪队列，执行调度算法来决定下一个运行的线程。线程数越多，调度器的负担越重。

在极端情况下（数万线程），光是遍历调度队列都会成为性能瓶颈。

量化视角

让我们把这些数字放在一起：

对于大多数应用来说，几十到几百个线程是完全可以接受的。现代 Linux 内核可以轻松处理上万个线程，只要它们不都在同时争抢 CPU。

四、决策框架：按用途确定线程数

理解了线程的多重作用和真实开销后，我们可以建立一个决策框架：

1. CPU 密集型计算：等于核数

如果线程的主要工作是计算（数学运算、数据处理、加密解密等），坚守经典法则：

int threadCount = Runtime.getRuntime().availableProcessors();

// 或者 核数 + 1，留一个处理偶发的 I/O

这里的逻辑很简单：更多的线程只会增加切换开销，不会提升吞吐量。

实际案例：

• 图像处理库
• 科学计算框架
• 视频编解码器

2. I/O 密集型：优先考虑非阻塞

如果线程大部分时间在等待 I/O（网络、磁盘、数据库），你有两个选择：

选项 A：非阻塞 I/O + 事件循环（推荐）

# Python asyncio

async def fetch_all(urls):

    async with aiohttp.ClientSession() as session:

        tasks = [fetch(session, url) for url in urls]

        return await asyncio.gather(*tasks)

        

# 用少量线程处理大量并发连接

Node.js、Nginx、Redis 都采用这种模型，用极少的线程处理海量并发。

选项 B：线程池 + 阻塞 I/O

如果你必须使用阻塞 I/O（比如 JDBC 不支持异步），可以用经典公式：

线程数 = CPU 核数 × (1 + I/O 等待时间 / CPU 计算时间)

如果平均每个请求花 100ms 等待 I/O、1ms 做计算，在 8 核机器上：

线程数 = 8 × (1 + 100/1) = 808

这只是理论上限。实际中还要考虑：

• 下游系统能否承受这么多并发
• 内存是否足够
• 连接池大小限制

3. 故障隔离：按风险域划分

为每个可能独立失败的依赖分配独立的线程池：

// Hystrix/Resilience4j 风格

ThreadPoolBulkhead paymentPool = ThreadPoolBulkhead.of("payment", 

    ThreadPoolBulkheadConfig.custom()

        .maxThreadPoolSize(10)

        .coreThreadPoolSize(5)

        .queueCapacity(20)

        .build());



ThreadPoolBulkhead inventoryPool = ThreadPoolBulkhead.of("inventory", 

    ThreadPoolBulkheadConfig.custom()

        .maxThreadPoolSize(8)

        .coreThreadPoolSize(4)

        .queueCapacity(15)

        .build());



ThreadPoolBulkhead shippingPool = ThreadPoolBulkhead.of("shipping", 

    ThreadPoolBulkheadConfig.custom()

        .maxThreadPoolSize(6)

        .coreThreadPoolSize(3)

        .queueCapacity(10)

        .build());

每个池的大小取决于：

• 下游服务的正常响应时间：响应越慢，需要越多线程来维持吞吐量
• 可接受的最大并发数：下游服务能承受多少并发请求
• 降级策略：线程池满时是快速失败、排队等待，还是返回降级结果

计算舱壁大小的方法

假设某个下游服务：

• 正常响应时间：50ms
• 期望吞吐量：每秒 100 个请求
• 可接受的排队延迟：100ms

最小线程数 = 吞吐量 × 响应时间

          = 100 × 0.05

          = 5 个线程



队列容量 = 吞吐量 × 可接受排队延迟

        = 100 × 0.1

        = 10 个请求

但还要考虑异常情况。如果下游服务变慢（响应时间从 50ms 变成 500ms）：

此时需要的线程数 = 100 × 0.5 = 50 个线程

这就是舱壁要保护的场景。我们不应该给它 50 个线程，而是：

ThreadPoolBulkhead.of("payment",

    ThreadPoolBulkheadConfig.custom()

        .maxThreadPoolSize(10)      // 硬上限：最多 10 个线程

        .coreThreadPoolSize(5)      // 正常情况够用

        .queueCapacity(20)          // 允许短暂排队

        .build());



// 当下游变慢时：

// - 10 个线程被占满

// - 20 个请求在队列等待

// - 第 31 个请求立即被拒绝（快速失败）

// - 系统其他部分不受影响

舱壁 vs 断路器

舱壁模式常与断路器（Circuit Breaker）配合使用：

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

│                        请求流程                          │

│                                                         │

│   请求 ──→ 断路器 ──→ 舱壁（线程池） ──→ 下游服务        │

│              │              │                           │

│              │              │                           │

│         检查是否熔断    检查是否有空闲线程                │

│              │              │                           │

│              ▼              ▼                           │

│         熔断则快速失败  无空闲则拒绝或排队                │

│                                                         │

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

// Resilience4j 组合使用示例

CircuitBreaker circuitBreaker = CircuitBreaker.of("payment", 

    CircuitBreakerConfig.custom()

        .failureRateThreshold(50)           // 失败率超过 50% 则熔断

        .waitDurationInOpenState(Duration.ofSeconds(30))

        .build());



ThreadPoolBulkhead bulkhead = ThreadPoolBulkhead.of("payment", ...);



Supplier decoratedSupplier = Decorators

    .ofSupplier(() -> paymentService.call())

    .withCircuitBreaker(circuitBreaker)     // 先检查断路器

    .withThreadPoolBulkhead(bulkhead)       // 再进入线程池

    .withFallback(ex -> fallbackResponse()) // 降级响应

    .decorate();

舱壁的代价

舱壁模式会显著增加系统的总线程数：

传统模式：

  1 个共享线程池 × 50 线程 = 50 线程



舱壁模式：

  支付服务池    10 线程

  库存服务池     8 线程

  物流服务池     6 线程

  用户服务池     8 线程

  通知服务池     4 线程

  ─────────────────────

  总计          36 线程（但每个池都有冗余）

  

  实际配置时考虑峰值：

  每个池 ×1.5 = 54 线程

这看起来线程更多了，但关键区别在于：

在微服务架构中，隔离性通常比资源利用率更重要。舱壁带来的额外线程开销，换来的是系统在部分故障时仍能提供服务的能力。

4. 简化抽象：按职责最小化

当线程用于代码组织时，遵循够用就好原则：

// 典型的服务端应用线程分配

Thread acceptor    = new Thread(this::acceptLoop);     // 1个：接受连接

Thread[] workers   = new Thread[cpuCores];             // N个：处理业务

Thread timer       = new Thread(this::timerLoop);      // 1个：定时任务

Thread logger      = new Thread(this::logWriter);      // 1个：异步日志

Thread monitor     = new Thread(this::metricsReport);  // 1个：监控上报



// 总计：cpuCores + 4 个线程

这些辅助线程大部分时间在休眠，不会与 worker 线程竞争 CPU。关键是确保它们：

• 不会执行耗时的计算
• 不会频繁唤醒
• 有明确的单一职责

五、警惕"线程风暴"

即使每个决策单独看都合理，累积起来也可能造成问题。

叠加效应

假设你的 Java 服务：

• Tomcat 线程池：200 个
• 数据库连接池：每个连接有后台线程，50 个
• Redis 客户端池：20 个
• Kafka 消费者：10 个分区 × 3 个消费者组 = 30 个
• 定时任务调度器：核心线程 10 个
• JVM GC 线程：8 个
• 其他框架的后台线程：若干

加起来可能有 300-500 个线程，而你的机器可能只有 8 个 CPU 核心。

抖动风险

在某些时刻，大量线程可能同时被唤醒：

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

│              t0: 某个事件触发                        │

│                      │                              │

│     ┌────────────────┼───────────────┐              │

│     ▼                ▼               ▼              │

│  ┌─────┐         ┌─────┐         ┌─────┐           │

│  │100个│         │50个 │         │30个 │           │

│  │HTTP │         │定时 │         │Kafka│           │

│  │请求 │         │任务 │         │消息 │           │

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

│     │               │               │               │

│     └───────────────┼───────────────┘               │

│                     ▼                               │

│           8 个 CPU 核心开始疯狂切换                  │

│                     │                               │

│                     ▼                               │

│        延迟飙升，GC 停顿，服务抖动                   │

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

这种"线程风暴"会导致：

• 所有请求的延迟同时上升
• P99 延迟剧烈波动
• 可能触发超时和级联故障

缓解策略

策略一：错峰调度

让定时任务随机分散，而不是整点触发：

// 不好：所有实例同时执行

@Scheduled(cron = "0 0 * * * *")  // 每小时整点



// 更好：启动时计算随机偏移

int jitter = random.nextInt(60);

@Scheduled(cron = "0 " + jitter + " * * * *")

策略二：为关键线程提升优先级

确保 CPU 密集型的核心工作线程能优先获得调度：

// 关键业务线程

thread.setPriority(Thread.MAX_PRIORITY);  // Java: 1-10，默认 5



// 或者在 Linux 上使用 nice 值

// nice -n -5 java -jar app.jar

// C/C++：使用实时调度策略

struct sched_param param;

param.sched_priority = 50;  // 实时优先级

pthread_setschedparam(thread, SCHED_FIFO, ¶m);

策略三：CPU 绑定（CPU Affinity）

将关键线程绑定到特定 CPU，避免缓存失效：

// 使用 JNA 或 JNI 调用系统 API

// Linux: sched_setaffinity()

// 或使用 Disruptor 等框架内置的支持

// C: 将线程绑定到 CPU 0 和 1

cpu_set_t cpuset;

CPU_ZERO(&cpuset);

CPU_SET(0, &cpuset);

CPU_SET(1, &cpuset);

pthread_setaffinity_np(thread, sizeof(cpuset), &cpuset);

策略四：限制并发

使用信号量或令牌桶限制同时运行的线程数：

Semaphore semaphore = new Semaphore(cpuCores * 2);



void process(Request request) {

    semaphore.acquire();

    try {

        doWork(request);

    } finally {

        semaphore.release();

    }

}

六、协程时代：换汤不换药？

Go 语言的 goroutine、Kotlin 的协程、Java 的虚拟线程（Project Loom）……协程似乎成了并发的银弹。

"创建一百万个协程"的 demo 随处可见，这是否意味着我们不用再关心"数量"问题了？

协程的本质

协程（或用户态线程、绿色线程）本质是把调度权从操作系统收回到用户态：

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

│                    传统线程                        │

│                                                   │

│   线程1  线程2  线程3  线程4  ... 线程1000        │

│     │      │      │      │           │           │

│     └──────┴──────┴──────┴───────────┘           │

│                    │                              │

│            操作系统调度器                          │

│                    │                              │

│     ┌──────┬──────┬──────┬──────────┐            │

│     ▼      ▼      ▼      ▼          ▼            │

│   CPU0   CPU1   CPU2   CPU3  ...  CPU7           │

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



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

│                    协程模型                        │

│                                                   │

│   协程1  协程2  协程3  ... 协程1000000            │

│     │      │      │            │                 │

│     └──────┴──────┴────────────┘                 │

│                    │                              │

│           语言运行时调度器                         │

│                    │                              │

│     ┌──────────────┼──────────────┐              │

│     ▼              ▼              ▼              │

│   线程1          线程2    ...   线程N            │

│     │              │              │              │

│     └──────────────┼──────────────┘              │

│                    │                              │

│            操作系统调度器                          │

│                    │                              │

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

│            ▼               ▼                     │

│          CPU0    ...    CPU7                     │

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

协程的优势在于：

• 创建开销极小：Go 的 goroutine 初始栈只有 2KB
• 切换开销极小：用户态切换，不需要进入内核
• 调度更智能：运行时了解协程在做什么（如等待 channel）

但物理规则依然适用

协程改变的是切换效率，不是 CPU 核心数。

// 100 万个协程同时做 CPU 密集计算？

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

    go func() {

        for {

            // 纯计算，没有 I/O

            heavyComputation()

        }

    }()

}

// 结果：并不会比 GOMAXPROCS 个协程更快

核心洞察：如果协程在执行时不主动让出（通过 I/O、channel、sleep 等），它就和操作系统线程没有本质区别。

协程的正确心智模型

Go 运行时会自动调整实际的操作系统线程数，但 GOMAXPROCS（默认等于 CPU 核数）限制了同时执行的线程数。

// 正确用法：百万协程处理 I/O

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

    go handleConnection(conn[i])  // 每个协程大部分时间在等待网络

}



// 需要注意：CPU 密集型任务

pool := make(chan struct{}, runtime.NumCPU())  // 信号量

for task := range tasks {

    pool <- struct{}{}  // 获取令牌

    go func(t Task) {

        defer func() { <-pool }()  // 释放令牌

        cpuIntensiveWork(t)        // 同时只有 NumCPU 个在计算

    }(task)

}

Java 虚拟线程的启示

Java 21 引入的虚拟线程（Virtual Threads）同样遵循这个逻辑：

// 可以创建大量虚拟线程处理阻塞 I/O

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {

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

        executor.submit(() -> {

            // 阻塞 I/O 会自动让出载体线程

            String result = httpClient.send(request);

            process(result);

        });

    }

}



// 但如果是 CPU 密集型...

executor.submit(() -> {

    // 这个虚拟线程会持续占用载体线程

    while (true) {

        computePi();  // 其他虚拟线程饿死

    }

});

七、实践清单

让我们把讨论转化为可操作的检查清单：

启动前问自己

□ 这个线程/协程的主要工作是什么？

  - [ ] CPU 计算

  - [ ] I/O 等待

  - [ ] 故障隔离

  - [ ] 代码组织



□ 它会阻塞吗？阻塞多久？



□ 它需要和其他线程竞争资源吗？



□ 它的生命周期是什么？

  - [ ] 与应用相同（后台线程）

  - [ ] 与请求相同（per-request）

  - [ ] 执行完任务就结束（fire-and-forget）

配置建议速查

监控指标

上线后，持续关注：

线程状态分布

├── RUNNABLE（运行中）   → 应该 ≈ CPU 核数

├── BLOCKED（锁等待）    → 过高说明有锁竞争

├── WAITING（条件等待）  → I/O 线程正常状态

└── TIMED_WAITING（超时等待）→ sleep 或 poll



上下文切换率

└── vmstat, pidstat -w  → 每秒切换数



线程创建率

└── 高频创建说明需要用池



CPU 使用率

└── 高于预期 → 检查是否在自旋

└── 低于预期 → 检查是否在等锁

八、总结

回到最初的问题：你的程序应该启动多少线程？

答案是：取决于这些线程要做什么。

• 如果是为了并行计算，线程数应该接近 CPU 核心数
• 如果是为了处理阻塞 I/O，优先考虑非阻塞方案；如果必须阻塞，根据 I/O 时间比例估算
• 如果是为了故障隔离，为每个风险域分配独立的资源边界
• 如果是为了简化代码，确保这些线程不会争抢关键资源

"线程数 = CPU 核心数"是一个好的起点，但不是终点。理解你的工作负载，理解线程的真实开销，理解你想通过多线程解决的问题——这比任何公式都重要。

最后，无论你做出什么选择，记得压测验证。真实世界的表现总是比理论分析更复杂，而性能问题往往藏在那些"理论上应该没问题"的地方。

附录：常见框架的默认配置参考

了解你正在使用的框架的默认行为，有助于做出更好的决策。

Web 服务器

数据库连接池

HikariCP 作者给出的经验公式：

连接数 = ((核心数 × 2) + 有效磁盘数)

对于大多数场景，10-20 个连接足以支撑相当高的吞吐量。更多的连接往往意味着更多的锁竞争和上下文切换，反而降低性能。

消息队列客户端

线程池最佳实践

// 推荐：根据任务类型创建不同的线程池

// 而不是所有任务共享一个



// CPU 密集型任务

ExecutorService cpuPool = Executors.newFixedThreadPool(

    Runtime.getRuntime().availableProcessors(),

    new ThreadFactoryBuilder().setNameFormat("cpu-worker-%d").build()

);



// I/O 密集型任务

ExecutorService ioPool = new ThreadPoolExecutor(

    corePoolSize,     // 核心线程数

    maxPoolSize,      // 最大线程数

    60, TimeUnit.SECONDS,  // 空闲线程存活时间

    new LinkedBlockingQueue<>(queueCapacity),  // 有界队列！

    new ThreadFactoryBuilder().setNameFormat("io-worker-%d").build(),

    new CallerRunsPolicy()  // 拒绝策略：让调用者自己执行

);



// 定时任务

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(

    2,  // 通常不需要很多

    new ThreadFactoryBuilder().setNameFormat("scheduler-%d").build()

);

关键提醒：永远使用有界队列和合理的拒绝策略。无界队列在高负载下会导致内存溢出。

TIOBE 的编程社区指数指出，这门全球最受欢迎的编程语言正逐渐失去市场份额，被 R、Perl 这类更专精的语言赶超。

目前 Python 在 TIOBE 月度编程语言人气指数中仍位居榜首，领先第二名 C 语言超过 10 个百分点。但在过去六个月里，Python 的人气其实一直在下滑，从去年 7 月 26.98% 的市场份额高点，降到了本月 TIOBE 指数中的 21.81%。

TIOBE 的 CEO 保罗・扬森表示，这一变化说明，有好几门更专精、更面向特定领域的语言正在慢慢蚕食 Python 的市场，其中最显眼的就是 R 和 Perl。

我大概学习过一年的 perl 语言，这门语言给我留下的比较深的印象就是文本处理，尤其是正则表达式的部分，非常厉害。

扬森提到，R 是一门用于统计计算的编程语言，长期以来在数据科学领域都是 Python 的直接竞争对手。本月 R 以 2.19% 的占比排在第八位，而一年前它还排在第 15 位。虽然近几年 Python 超越了 R，但如今 R 似乎正重新找回势头，已经连续好几个月回到 TIOBE 指数的前十行列。

与此同时，Perl 也在脚本领域重新崛起。扬森说，Perl 曾经是脚本领域毫无争议的霸主，但后来因为多年的内部分裂，再加上新兴语言的竞争，逐渐走向衰落。不过最近这门语言迎来了转机，2025 年 9 月它在 TIOBE 指数中从一年前的第 27 位冲到了第 10 位。本月它以 1.67% 的占比排在第 11 位，而去年同期它还在第 30 位。

TIOBE 编程社区月度指数是衡量编程语言人气的指标，其评分基于一个计算公式，会评估全球范围内掌握该语言的工程师数量、相关课程以及第三方供应商的情况。评分数据会通过分析谷歌、亚马逊、维基百科、必应等超过 20 个网站得出。

2026 年 2 月 TIOBE 指数前十排名：

与之相对应的的 PYPL（PopularitY of Programming Language） 编程语言人气指数则是通过分析谷歌上语言教程的搜索频率来评估语言人气。

2026 年 2 月 PYPL 指数前十排名：

原文

http://www.infoworld.com/article/412…

前言

Flutter 是 Google 推出的跨平台 UI 框架，最初只支持 iOS 和 Android。随着 HarmonyOS 的崛起，Flutter 也能在鸿蒙系统上运行了。这背后到底是怎么实现的呢？本文将从源码层面进行解析。

一、核心原理：Flutter 分层架构

要理解 Flutter 如何在 HarmonyOS 上运行，首先需要了解 Flutter 的架构。Flutter 采用分层设计，从上到下分为三层：

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

│   Framework 层（Dart）           │  ← Flutter 代码

├─────────────────────────────────┤

│   Engine 层（C++）               │  ← 渲染引擎（Impeller）

├─────────────────────────────────┤

│   Embedder 层（平台相关）         │  ← 与操作系统交互(调用 HarmonyOS 原生 API)

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

前面两层完全复用现有Dart和C++代码，而 Embedder 层则是为 HarmonyOS 定制的。

关键点：Embedder 层

Embedder 层是 Flutter 能够跨平台运行的关键。它负责：

• 创建和管理窗口


• 处理输入事件


• 调用系统 API


• 管理渲染 Surface

**不同平台有不同的 Embedder 实现： **

• Android：platform_view_android.cc


• iOS：platform_view_ios.mm


• HarmonyOS：platform_view_ohos.cpp

cc和cpp是标准的C++语言代码后缀

鸿蒙的系统API是C++ 实现的,所以鸿蒙platform_view 使用C++实现进行调用最方便**

二、HarmonyOS Embedder 的核心实现

让我们看看 HarmonyOS Embedder 的核心代码结构：

2.1 平台视图（PlatformViewOHOS）

这是 HarmonyOS Embedder 的核心类，位于：
engine/src/flutter/shell/platform/ohos/platform_view_ohos.cpp

class PlatformViewOHOS final : public PlatformView {

 public:

  PlatformViewOHOS(PlatformView::Delegate& delegate,

                   const flutter::TaskRunners& task_runners,

                   const std::shared_ptr<PlatformViewOHOSNapi>& napi_facade,

                   const std::shared_ptr<flutter::OHOSContext>& ohos_context);



  // 通知窗口创建

  void NotifyCreate(fml::RefPtr<OHOSNativeWindow> native_window); 



  // 更新显示尺寸

  void UpdateDisplaySize(int width, int height);



  // 分发平台消息

  void DispatchPlatformMessage(std::string name, void* message, ...);

 private:

  std::shared_ptr<OHOSContext> ohos_context_;  // HarmonyOS 图形上下文

  std::shared_ptr<PlatformViewOHOSNapi> napi_facade_;  // NAPI装饰器（NAPI 是 HarmonyOS 提供的 JavaScript 接口, 用于调用 HarmonyOS 系统 API

  std::unique_ptr<OHOSSurface> ohos_surface_;  // HarmonyOS 渲染 Surface, surface 是渲染的目标画布, 可以是窗口, 也可以是离屏缓冲区

};

**这个类做了什么？ **

2.2 Shell 持有者（OHOSShellHolder）

Shell 是 Flutter 引擎的核心，负责管理 Flutter 应用的生命周期、渲染循环、事件处理等, OHOSShellHolder 负责创建和管理 Shell：

class OHOSShellHolder {

 public:

  // 构造函数

  // settings: Flutter 引擎启动参数（如是否启用 Impeller、日志级别等）



  // napi_facade: 与 HarmonyOS 原生层交互的 NAPI 装饰器



  // platform_loop: HarmonyOS 平台线程的 looper，用于投递平台任务

  OHOSShellHolder(const flutter::Settings& settings,

                  std::shared_ptr<PlatformViewOHOSNapi> napi_facade,

                  void* platform_loop);



  // 析构函数：确保 Shell 安全退出并释放所有资源

  ~OHOSShellHolder();

 

  // 启动 Flutter 引擎，加载 Dart 代码并开始渲染

  // hap_asset_provider: HarmonyOS HAP 包资源提供器，用于读取 assets、fonts、kernel_blob 等

  // entrypoint: Dart 入口函数名（默认为 main）



  // libraryUrl: Dart 库 URI（如 package:my_app/main.dart）



  // entrypoint_args: 传给 Dart main 的命令行参数列表



  void Launch(std::unique_ptr<OHOSAssetProvider> hap_asset_provider,

              const std::string& entrypoint,

              const std::string& libraryUrl,

              const std::vector<std::string>& entrypoint_args);

  // 优雅地停止 Flutter Shell，等待所有任务完成后退出

  void Shutdown();

  // 获取 PlatformViewOHOS 的弱引用，用于在平台线程安全地访问平台视图

  fml::WeakPtr<PlatformViewOHOS> GetPlatformView();

  // 设置应用生命周期回调，供 HarmonyOS 通知 Flutter 前后台切换

  void SetLifecycleHandler(std::function<void(AppLifecycleState)> handler);

  // 设置平台消息回调，供 HarmonyOS 主动发消息到 Dart 侧

  void SetPlatformMessageHandler(

      std::function<void(const std::string& channel,

                         const std::vector<uint8_t>& message,

                         std::function<void(std::vector<uint8_t>)> reply)> handler);

  // 向 Dart 侧发送平台消息，支持异步回调

  void SendPlatformMessage(const std::string& channel,

                           const std::vector<uint8_t>& message,

                           std::function<void(std::vector<uint8_t>)> reply = nullptr);

  // 通知 Flutter 引擎窗口尺寸变化，触发重新布局

  void NotifyViewportMetricsChanged(const ViewportMetrics& metrics);

  // 通知 Flutter 引擎内存压力，触发 Dart 侧 GC 或资源释放

  void NotifyLowMemoryWarning();

  // 获取当前 Shell 的运行状态

  enum class ShellState { kNotStarted, kRunning, kShuttingDown, kStopped };

  ShellState GetShellState() const;

  // 返回当前线程安全的 Shell 指针，仅用于调试或测试

  Shell* GetShellUnsafe() const { return shell_.get(); }

 private:

  // 创建并配置 Flutter Shell，内部调用 Shell::Create

  void CreateShell(const flutter::Settings& settings,

                   std::unique_ptr<OHOSAssetProvider> asset_provider);

  // 初始化平台任务执行器，将 HarmonyOS 平台任务映射到 Flutter 的任务队列

  void SetupTaskRunners(void* platform_loop);

  // 注册 HarmonyOS 平台视图到 Shell，完成平台桥接

  void RegisterPlatformView();

  // 加载 Dart AOT 或 Kernel，决定运行模式（Release/Profile 使用 AOT，Debug 使用 Kernel）

  void LoadDartCode(const std::string& entrypoint,

                    const std::string& libraryUrl,

                    const std::vector<std::string>& entrypoint_args);

  // 释放所有资源，顺序：PlatformView → Shell → TaskRunners

  void Teardown();

 private:

  std::unique_ptr<Shell> shell_;                         // Flutter 引擎核心

  std::shared_ptr<PlatformViewOHOSNapi> napi_facade_;  // NAPI 装饰器

  fml::WeakPtrFactory<OHOSShellHolder> weak_factory_;    // 弱引用工厂，防止悬空指针

  ShellState state_ = ShellState::kNotStarted;           // 当前 Shell 状态

  flutter::TaskRunners task_runners_;                    // 跨平台任务队列（UI/GPU/IO/Platform）

  std::mutex state_mutex_;                               // 保护 state_ 的线程安全

};

三、图形渲染适配

Flutter 在 HarmonyOS 上支持三种渲染方式：

3.1 鸿蒙三种渲染方式

enum class OHOSRenderingAPI {

  kSoftware,          // 软件渲染, 基于 CPU 进行渲染, 性能较低, 不依赖于 GPU，适用于简单场景。

  kOpenGLES,          // OpenGL ES 渲染（Skia）, 基于 OpenGL ES 进行渲染, 性能较高, 依赖于 GPU, 适用于复杂场景。

  kImpellerVulkan,    // Vulkan 渲染（Impeller）, 基于 Vulkan 进行渲染, 性能最高, 依赖于 GPU, 适用于需要高性能渲染的场景。

};

在 platform_view_ohos.cpp 中，根据渲染方式创建不同的Surface：

std::unique_ptr<OHOSSurface> OhosSurfaceFactoryImpl::CreateSurface() {

  switch (ohos_context_->RenderingApi()) {

    case OHOSRenderingAPI::kSoftware:

      return std::make_unique<OHOSSurfaceSoftware>(ohos_context_); // 软件渲染, 基于 CPU 进行渲染, 性能较低, 不依赖于 GPU，适用于简单场景。

    case OHOSRenderingAPI::kOpenGLES:

      return std::make_unique<OhosSurfaceGLSkia>(ohos_context_); // OpenGL ES 渲染（Skia）, 基于 OpenGL ES 进行渲染, 性能较高, 依赖于 GPU, 适用于复杂场景。

    case flutter::OHOSRenderingAPI::kImpellerVulkan:

      return std::make_unique<OHOSSurfaceVulkanImpeller>(ohos_context_); // Vulkan 渲染（Impeller）, 基于 Vulkan 进行渲染, 性能最高, 依赖于 GPU, 适用于需要高性能渲染的场景。

    default:

      return nullptr;

  }

}

3.2 原生窗口（OHOSNativeWindow）

HarmonyOS 的窗口系统通过 OHNativeWindow 暴露给 Flutter：

class OHOSNativeWindow : public fml::RefCountedThreadSafe<OHOSNativeWindow> {

 public:

  Handle Gethandle() const;  // 获取 HarmonyOS 原生窗口句柄

  bool IsValid() const;      // 检查窗口是否有效

  SkISize GetSize() const;   // 获取窗口尺寸

 private:

  Handle window_;  // OHNativeWindow*

};

**渲染流程： **

Flutter Engine

    ↓

PlatformViewOHOS

    ↓

OHOSSurface（根据渲染方式创建不同的Surface）

    ↓

OHOSNativeWindow（HarmonyOS 原生窗口）

    ↓

HarmonyOS 图形系统

四、输入事件处理

因为事件处理需要在渲染完成后(VSync同步流程)才能触发, 否则会导致事件处理与渲染不一致的问题。

4.1 VSync 同步

VSync（垂直同步）信号是渲染的关键，它是每次屏幕刷新周期开始时发送的信号，用于同步渲染和显示。

Flutter 需要等待系统的 VSync 信号，才能触发下一帧渲染。

class VsyncWaiterOHOS final : public VsyncWaiter {

 public:

  explicit VsyncWaiterOHOS(const flutter::TaskRunners& task_runners,

                           std::shared_ptr<bool>& enable_frame_cache);



 private:

  OH_NativeVSync* vsync_handle_;  // HarmonyOS VSync 句柄

  void AwaitVSync() override;  // 等待 VSync 信号

  static void OnVsyncFromOHOS(long long timestamp, void* data); // 接收 HarmonyOS VSync 信号, 通知 Flutter Engine 触发下一帧渲染

};

**工作流程： **

HarmonyOS VSync 信号

    ↓

VsyncWaiterOHOS::OnVsyncFromOHOS

    ↓

通知 Flutter Engine

    ↓

触发下一帧渲染

    ↓

渲染完成

    ↓

触发事件处理

4.2 触摸事件处理

HarmonyOS 的输入事件需要转换为 Flutter 的事件格式：

触摸事件通过 OhosTouchProcessor 处理：

class OhosTouchProcessor {

 public:

  // 处理 HarmonyOS 触摸事件

  void ProcessTouchEvent(const OH_NativeXComponent_TouchEvent* event);

 private:

  // 转换为 Flutter 触摸事件格式

  std::vector<PointerData> ConvertToFlutterTouchEvents(

      const OH_NativeXComponent_TouchEvent* event);

};

五、平台消息通信

Flutter 与 HarmonyOS 的通信通过 Platform Channel 实现：

5.1 NAPI 装饰器（PlatformViewOHOSNapi）

NAPI（Native API）是 HarmonyOS 提供的原生 API 接口：

class PlatformViewOHOSNapi {

 public:

  // 发送平台消息到 HarmonyOS

  void SendPlatformMessage(const std::string& channel,

                           const std::vector<uint8_t>& message);

  // 接收来自 HarmonyOS 的平台消息

  void SetPlatformMessageHandler(

      std::function<void(const std::string&, const std::vector<uint8_t>&)> handler);

 private:

  napi_env env_;  // NAPI 环境

};

5.2 消息处理流程

Flutter 代码（Dart）

    ↓

MethodChannel.invokeMethod

    ↓

PlatformViewOHOS::DispatchPlatformMessage

    ↓

PlatformViewOHOSNapi::SendPlatformMessage

    ↓

HarmonyOS 原生代码（ArkTS/C++）

    ↓

返回结果

    ↓

Flutter 接收响应

六、完整的工作流程

让我们把所有部分串联起来，看看 Flutter 应用在 HarmonyOS 上是如何运行的：

6.1 初始化流程

1. HarmonyOS 应用启动

    ↓

2. 调用 OhosMain::NativeInit（NAPI 入口）

    ↓

3. 创建 OHOSShellHolder

    ↓

4. 创建 PlatformViewOHOS

    ↓

5. 创建 OHOSContext（图形上下文）

    ↓

6. 创建 OHOSSurface（渲染表面）

    ↓

7. 创建 Flutter Shell（引擎）

    ↓

8. 加载 Dart 代码

    ↓

9. 开始渲染

6.2 渲染流程

1. Dart 代码构建 Widget 树

    ↓

2. Framework 层生成 Layer 树

    ↓

3. Engine 层生成 Scene

    ↓

4. Impeller 渲染引擎绘制

    ↓

5. 通过 OHOSSurface 提交绘制指令

    ↓

6. OHOSNativeWindow 接收绘制结果

    ↓

7. HarmonyOS 图形系统显示到屏幕

6.3 事件处理流程

1. 用户触摸屏幕

    ↓

2. HarmonyOS 接收触摸事件

    ↓

3. OhosTouchProcessor 处理

    ↓

4. 转换为 Flutter 触摸事件格式

    ↓

5. PlatformViewOHOS 分发事件

    ↓

6. Framework 层处理事件

    ↓

7. Widget 响应用户操作

七、关键代码示例

7.1 创建 HarmonyOS Embedder

// 创建图形上下文

std::unique_ptr<OHOSContext> CreateOHOSContext(

    const flutter::TaskRunners& task_runners,

    OHOSRenderingAPI rendering_api,

    bool enable_vulkan_validation,

    bool enable_opengl_gpu_tracing,

    bool enable_vulkan_gpu_tracing) {

  switch (rendering_api) {

    case OHOSRenderingAPI::kSoftware:

      return std::make_unique<OHOSContext>(OHOSRenderingAPI::kSoftware);

    case OHOSRenderingAPI::kOpenGLES:

      return std::make_unique<OhosContextGLSkia>(OHOSRenderingAPI::kOpenGLES,

                                                 task_runners);

    case OHOSRenderingAPI::kImpellerVulkan:

      return std::make_unique<OHOSContextVulkanImpeller>(

          enable_vulkan_validation, enable_vulkan_gpu_tracing);

    default:

      return nullptr;

  }

}

// 创建平台视图

PlatformViewOHOS::PlatformViewOHOS(

    PlatformView::Delegate& delegate,

    const flutter::TaskRunners& task_runners,

    const std::shared_ptr<PlatformViewOHOSNapi>& napi_facade,

    const std::shared_ptr<flutter::OHOSContext>& ohos_context)

    : PlatformView(delegate, task_runners),

      napi_facade_(napi_facade),

      ohos_context_(ohos_context) {

  // 创建 Surface 工厂

  surface_factory_ = std::make_shared<OhosSurfaceFactoryImpl>(ohos_context_);

  // 创建渲染 Surface

  ohos_surface_ = surface_factory_->CreateSurface();

  // 预加载 GPU Surface（加速首帧渲染）

  task_runners_.GetRasterTaskRunner()->PostDelayedTask(

      [surface = ohos_surface_]() { surface->PrepareGpuSurface(); },

      fml::TimeDelta::FromMicroseconds(1000));

}

7.2 通知窗口创建

void PlatformViewOHOS::NotifyCreate(

    fml::RefPtr<OHOSNativeWindow> native_window) {

  FML_LOG(INFO) << "NotifyCreate start";

  // 缓存原生窗口

  native_window_ = native_window;

  // 通知 Surface 窗口已创建

  ohos_surface_->SetNativeWindow(native_window);

  // 获取窗口尺寸

  SkISize size = native_window->GetSize();

  // 更新视口尺寸

  UpdateDisplaySize(size.width(), size.height());



  // 通知 Flutter 引擎窗口已创建

  NotifyCreated();

}

7.3 处理平台消息

void PlatformViewOHOS::DispatchPlatformMessage(

    std::string name,

    void* message,

    int messageLength,

    int responseId) {

  // 创建平台消息

  fml::MallocMapping buffer = fml::MallocMapping(

      static_cast<const uint8_t*>(message), messageLength);

  auto platform_message = std::make_unique<PlatformMessage>(

      name,

      std::move(buffer),

      responseId,

      fml::TimePoint::Now());

  // 分发到 Flutter 引擎

  DispatchPlatformMessage(std::move(platform_message));

}

八、为什么 Flutter 能在 HarmonyOS 上运行？

通过上面的代码分析，我们可以总结出以下几个关键原因：

8.1 架构设计优势

Flutter 的分层架构设计使得 Embedder 层可以独立适配不同平台：

• Framework 层和 Engine 层是平台无关的


• 只有 Embedder 层需要针对不同平台实现

8.2 HarmonyOS 提供的开放接口

HarmonyOS 提供了丰富的原生 API，使得 Flutter 可以：

• 通过 OHNativeWindow 获取窗口句柄


• 通过 OH_NativeVSync 获取 VSync 信号


• 通过 NAPI 调用系统能力


• 通过 XComponent 组件集成 Flutter 视图

8.3 图形接口兼容

HarmonyOS 支持标准的图形接口：

• OpenGL ES：Skia 渲染引擎可以直接使用


• Vulkan：Impeller 渲染引擎可以直接使用


• NativeWindow：提供了跨平台的窗口抽象

8.4 社区共同努力

• 华为官方和 Flutter 社区共同维护 flutter_flutter 项目


• 基于 Flutter Engine 源码进行适配


• 提供完整的开发工具链

从代码层面看，核心就是实现了 PlatformViewOHOS、OHOSShellHolder、OHOSContext 等类，将 Flutter Engine 与 HarmonyOS 系统连接起来。

**一句话总结：Flutter 通过实现 HarmonyOS 专属的 Embedder 层，将 Flutter Engine 与 HarmonyOS 的窗口系统、图形系统、输入系统对接，从而实现了跨平台运行。 **

九、参考资料

• flutter_flutter 源码


• Flutter Engine 架构


• HarmonyOS NAPI 开发指南

引言

近一年来，代码生成类工具逐渐从“写几行示例代码”走向“完整功能交付”，但真正落到工程实践时，很多工具仍停留在 Demo 阶段：要么跑不起来，要么改动成本过高。 本次评测的核心目标并不是追求“炫技”，而是站在开发者真实使用场景出发，验证一套组合方案是否具备以下能力：

• 是否能在本地环境中快速跑通


• 是否能端到端生成可演示、可交付的前端成果


• 是否减少重复劳动，而不是制造新的维护负担

因此，本文选择了 Claude Code + 蓝耘 MaaS 平台 这一组合，从命令行工具****接入开始，结合多个真实前端需求案例，对模型在网页应用、小游戏以及 3D 可视化等场景下的表现进行实测分析。 评测重点不在“模型参数”或“理论能力”，而在于：它到底能不能帮开发者省时间、少踩坑。

最大输出和最大输入一比一，编码能力放在下面了，个人觉得是挑不出毛病的好吧。不信你试试

一、命令行使用 Claude Code（安装与配置）

步骤一：安装 Claude Code（命令行）

前提

• Node.js ≥ 18（建议使用 nvm 管理版本以避免权限问题）。


• macOS：推荐用 nvm 或 Homebrew 安装 Node.js，不建议直接双击 pkg 安装（可能有权限问题）。


• Windows：请先安装 Git for Windows。

安装

npm install -g @anthropic-ai/claude-code

安装完成后验证：

claude --version

步骤二：配置蓝耘MaaS平台

1、注册 / 登录：访问**蓝耘MaaS平台**，完成账号注册并登录。

2、在「API KEY 管理」中创建 API Key，并复制备用。

在本机设置环境变量（推荐方式：编辑配置文件）

• macOS / Linux：~/.claude/settings.json


• Windows：%USERPROFILE%/.claude/settings.json

示例 settings.json（请替换your_lanyun_maas_api_key）：

{

  "env": {

    "ANTHROPIC_AUTH_TOKEN": "your_lanyun_maas_api_key",

    "ANTHROPIC_BASE_URL": "https://maas-api.lanyun.net/anthropic",

    "API_TIMEOUT_MS": "3000000",

    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1,

    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "/maas/deepseek-ai/DeepSeek-V3.2",

    "ANTHROPIC_DEFAULT_SONNET_MODEL": "/maas/deepseek-ai/DeepSeek-V3.2",

    "ANTHROPIC_DEFAULT_OPUS_MODEL": "/maas/deepseek-ai/DeepSeek-V3.2"

  }

}

• 同时创建（或确认）~/.claude.json：
  
  

  {
  "hasCompletedOnboarding": true
  }

生效提示

• 配置完成后请打开一个新的终端窗口以载入新的环境变量。


• 启动 claude，首次会询问是否使用该 API key（选择 Yes），并请在第一次访问时同意信任工作目录（允许读取文件以便代码功能）。

步骤三：常见排查

• 若手动修改 ~/.claude/settings.json 后不生效：
  
  
  
  
  • 关闭所有 Claude Code 窗口，重新打开新的终端。
  
  
  • 若仍不生效，尝试删除该文件并重新生成配置（注意备份原文件）。
  
  
  • 检查 JSON 格式是否正确（可用在线 JSON 校验工具）。
  
  
  
  


• 检查版本与更新：
  
  

  claude --version
  claude update

二、编码工具中使用 claude-code：三个端到端案例（含提示与实测评价）

每个案例先给出“需求 + 提示词”示例，然后给出对模型产出（代码/效果）的实测评价，评价尽量贴近工程实践：是否能直接运行、需要手工修改的点、功能完整性、性能与安全注意项。

案例 1：交互式个人血压记录网页 — 前端端到端生成

需求：希望 GLM-4.7 能够生成一个简单的个人血压记录网页应用，包括录入血压数据的前端界面和一个数据可视化大屏展示页面，要求界面美观，且支持单人登录功能。

提示词：我们向 GLM-4.7 输入了如下的自然语言提示：

请用 HTML、CSS 和 JavaScript 创建一个完整的个人血压记录网页应用。要求包括：1) 用户登录界面；2) 血压数据录入表单（收缩压、舒张压、测量日期）；3) 数据可视化大屏界面，以图表展示历史血压记录；4) 整体界面风格现代简洁，配色协调美观。5) 将前端代码与样式、脚本整合在一个 HTML 文件中，方便直接运行。

实测评价（工程视角）

• 可运行性：生成的单文件 HTML 通常能在本地直接打开并运行，图表（如用 Chart.js）能正常渲染——基本可直接跑通。


• 需要人工补充/注意点：持久化通常仅用 localStorage，真实生产需后端与加密；登录为前端模拟（不安全），若要求真登录需接入后端 API 与认证方案。


• 代码质量：结构清晰但注释与边界检查（表单验证、异常处理）需补充；样式可直接用但对响应式与无障碍要进一步优化。


• 总结：非常适合原型与内部演示；若要上线需补后端、认证与输入校验、数据导出等工程工作。

案例 2：Web 双人对战小游戏（Joy-Con 风格）

需求：开发一个基于 Web 的双人对战小游戏，界面风格模仿 Nintendo Switch 主机的 Joy-Con 手柄，包括左右两个虚拟手柄和中间的游戏屏幕。要求实现基本的游戏逻辑和简单的控制功能。

提示词：我们向 GLM-4.7 输入了如下提示：

请用 HTML5 Canvas 和 JavaScript 编写一个双人对战小游戏。界面要求模仿 Nintendo Switch 的 Joy-Con 手柄：左侧蓝色手柄，右侧红色手柄，中间为游戏屏幕。玩家 1 使用键盘 A/D 移动，J 攻击，K 跳跃；玩家 2 使用键盘 U/I/O 分别释放技能。游戏要求有基本的角色移动和攻击判定逻辑，界面风格统一美观。请将所有代码整合在一个 HTML 文件中，确保在浏览器中打开即可运行。

实测评价（工程视角）

• 可运行性：模型生成的 Canvas 游戏通常包含主循环、碰撞/判定的基本实现，能够进行本地试玩；帧率在普通浏览器和单页面逻辑下表现正常。


• 需要人工补充/注意点：物理判定、碰撞响应和输入去抖（debounce）常是“粗糙实现”，需手动修正以避免卡顿或误判；网络对战未实现（仅本地双人）。


• 代码质量：逻辑上可读，但没有模块化（全部放在全局），不利于维护；建议拆分为模块或使用简易引擎封装。


• 总结：适合快速原型与教学演示；若做成产品需重构输入处理、物理/判定逻辑、以及添加资源管理与关卡数据。

案例 3：前端可视化组件生成

需求：创建一个基于 Three.js 的 3D 场景，包含一个华丽的宝塔和周围盛开的樱花树，场景要求视觉精美、结构清晰，且支持用户通过鼠标或手势进行交互控制（如旋转场景、缩放视图）。

提示词：我们向 GLM-4.7 输入了如下提示：

请用 Three.js 编写一个包含宝塔和樱花树的 3D 场景。要求：1) 宝塔位于场景中央，装饰华丽；2) 周围环绕盛开的樱花树，营造花园氛围；3) 场景使用等轴测或俯视视角，光影柔和，有适当的环境光和定向光以产生投影；4) 支持鼠标拖动旋转场景和滚轮缩放查看；5) 所有代码整合在一个 HTML 文件中，使用 CDN 引入 Three.js 及其依赖，确保直接打开即可运行。

实测评价（工程视角）

• 可运行性：多数生成结果能在现代浏览器中打开并展示场景（依赖 CDN 的 Three.js），基础交互（OrbitControls）通常可用。


• 需要人工补充/注意点：模型与细节（如樱花树的粒子/贴图）可能是简单几何或贴图替代，若追求视觉精细需要自行替换高质量模型/贴图与烘焙光照或使用 PBR 材质；阴影与性能在低端设备上需做 LOD/简化处理。


• 代码质量：示例代码多为教学风格，未必包含资源加载进度管理与错误处理；建议加上纹理压缩、异步加载与内存释放逻辑。


• 总结：适合演示级视觉效果与交互交付；商业级视觉需投入美术资源并改造渲染管线与性能优化。

三、补充建议（快速 checklist）

• 环境：Node.js 用 nvm 管理、macOS 权限使用 sudo 谨慎；Windows 使用 PowerShell / Git Bash 测试命令。


• 配置：编辑 ~/.claude/settings.json 时注意 JSON 语法（逗号、引号、转义）；每次修改后重启终端。


• 模型选择：通过 ~/.claude/settings.json 修改 ANTHROPIC_DEFAULT_*_MODEL 字段来切换模型；切换后启动 claude 并在交互中用 /status 确认。


• 安全/上线：所有“示例仅前端”场景上线前必须接入安全认证、后端存储与输入验证（避免注入与隐私泄露）。

总结

从本次实际使用和多个案例的结果来看，Claude Code 在接入蓝耘 MaaS 后，已经具备“工程可用级”的生成能力，尤其在以下几个方面表现比较稳定：

• 端到端能力明确：在单文件 HTML、前端 Demo、Canvas 游戏、Three.js 场景等任务中，生成结果大多可直接运行，减少了大量“拼代码”的前期工作。


• 适合作为原型与验证工具：非常适合用在需求验证、内部演示、方案评审和教学场景中，而不是一开始就手写全部代码。


• 开发者心智成本低：命令行方式接入，不改变现有工作流，比网页对话式工具更符合日常编码习惯。

当然，也需要客观看待它的边界：

• 生成代码在安全性、模块化、性能优化方面仍需要人工介入；


• 登录、数据存储、多人协作等生产级能力仍需配合后端体系完善；


• 更复杂的项目仍然离不开开发者的架构设计与工程判断。

整体来看，这套方案的价值并不在于“替代程序员”，而在于把开发者从重复、低价值的样板工作中解放出来，让时间更多地投入到业务逻辑、架构设计和体验打磨上。

如果你的目标是： 更快做出可运行的东西，而不是从零写样板代码，那么 Claude Code + 蓝耘 MaaS，已经是一个值得放进工具箱里的选项。

前言

从 JDK 14 开始，Java 官方引入了 JPackage** 工具（在 JDK 16 正式成为标准功能），它能够将 Java 应用打包成特定平台的原生安装包，自带定制化的 JRE 运行环境。这意味着用户无需提前安装 Java 环境，双击安装包即可完成应用部署，极大地简化了交付流程。

本文将介绍如何使用 JPackage 工具将 Spring Boot 项目打包成 Windows、macOS 或 Linux 平台的原生安装包。

一、JPackage 简介

1.1 什么是 JPackage

JPackage 是 JDK 自带的打包工具，位于 $JAVA_HOME/bin 目录下。它的核心功能是：

生成平台原生安装包：Windows 的 .exe/.msi、macOS 的 .dmg/.pkg、Linux 的 .deb/.rpm

自定义 JRE：使用 jlink 工具裁剪 JDK，仅打包应用所需的模块，大幅减小安装包体积

简化部署：用户无需预装 Java 环境，安装包自带运行时

1.2 JPackage 的优势

二、环境准备

2.1 JDK 版本要求

推荐使用 JDK 17 或更高版本（JPackage 在 JDK 16 才成为标准功能，JDK 17 是 LTS 版本）

确认 JPackage 可用：

jpackage --version