2026年2月

是这样,想自建个商城,在今年 9-10 月份的时候,卖一卖我家里的苹果。
前几年卖虚拟产品,都是搭的独角数卡,但是今天独角数卡停更了,作者开发了新的商城项目,目前还不完善,我看这 ui 也不是很喜欢的样子。

想问问朋友们,有没有什么好的自建开源商城,不要太糙的那种,质量稍微好点的。平时自己有什么虚拟资源可以卖一卖,再加上每年 9-10 月份卖一卖果子

1. 库的概览与核心价值

想象一下,在编写 Web 应用或数据处理程序时,如果需要直接使用 SQL 语句与数据库交互,就像在高速公路上骑着自行车——虽然能够到达目的地,但不仅效率低下,而且随时可能因为写错一个关键字而导致整个程序崩溃。SQLAlchemy 正是为解决这个痛点而生的 Python 数据库工具包。

SQLAlchemy 是 Python 中最流行的 SQL 工具包和对象关系映射器(ORM),它在 Python 生态系统中占据着不可替代的地位。简单来说,SQLAlchemy 提供了两种使用方式:

  • Core(核心层):一个灵活的 SQL 表达式语言,允许你用 Python 代码构造 SQL 语句
  • ORM(对象关系映射):将数据库表映射为 Python 类,让你可以像操作普通对象一样操作数据库

SQLAlchemy 的核心价值在于:

  • 桥接 Python 和 SQL 的鸿沟:用 Python 的思维来操作数据库,无需编写复杂的 SQL
  • 数据库无关性:支持 MySQL、PostgreSQL、SQLite、Oracle 等多种数据库,代码无需修改即可切换
  • 企业级特性:提供连接池、事务管理、关系映射等高级功能
  • 渐进式学习:可以从简单的 Core 开始,逐步学习强大的 ORM 功能

2. 环境搭建与 "Hello, World"

安装说明

安装 SQLAlchemy 非常简单,使用 pip 即可:

# 安装最新稳定版
pip install SQLAlchemy

# 安装指定版本(如 2.0.x)
pip install SQLAlchemy==2.0.45

# 安装预发布版本(用于测试新特性)
pip install --pre SQLAlchemy

如果需要支持特定数据库,还需要安装对应的 DBAPI(以 PostgreSQL 为例):

pip install psycopg2-binary  # PostgreSQL
pip install pymysql          # MySQL
pip install cx-Oracle        # Oracle

最简示例

让我们通过一个完整的 "Hello World" 示例来快速了解 SQLAlchemy 的基本用法:

from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.orm import DeclarativeBase, Session

# 1. 定义基础类
class Base(DeclarativeBase):
    pass

# 2. 定义模型(映射到数据库表)
class User(Base):
    __tablename__ = 'users'
    
    id = Column(Integer, primary_key=True)
    name = Column(String(50), nullable=False)
    email = Column(String(100), unique=True)

# 3. 创建数据库引擎(使用 SQLite)
engine = create_engine('sqlite:///example.db', echo=True)

# 4. 创建表结构
Base.metadata.create_all(engine)

# 5. 插入数据
with Session(engine) as session:
    # 创建新用户对象
    new_user = User(name='张三', email='zhangsan@example.com')
    
    # 添加到会话
    session.add(new_user)
    
    # 提交到数据库
    session.commit()
    
    # 查询数据
    users = session.query(User).all()
    for user in users:
        print(f'ID: {user.id}, 姓名: {user.name}, 邮箱: {user.email}')

代码逐行解释

  • 第 1-3 行:导入必要的模块。create_engine 用于建立数据库连接,Column 等用于定义表结构
  • 第 6-7 行:定义 Base 类,这是所有 ORM 模型的基类
  • 第 10-16 行:定义 User 类,它对应数据库中的 users 表。__tablename__ 指定表名,各个 Column 定义表字段
  • 第 19 行:创建数据库引擎,sqlite:///example.db 表示使用 SQLite 数据库(文件名:example.db),echo=True 会打印执行的 SQL 语句,便于调试
  • 第 22 行:根据模型定义创建所有表(如果表已存在则跳过)
  • 第 25 行:创建会话(Session),会话是 ORM 与数据库交互的桥梁
  • 第 28 行:创建一个 User 对象,相当于创建了一条记录
  • 第 30 行:将对象添加到会话的"待提交区"
  • 第 32 行:提交事务,将数据真正写入数据库
  • 第 35-37 行:查询所有用户并打印

运行结果

ID: 1, 姓名: 张三, 邮箱: zhangsan@example.com

常见安装问题

  • 如果安装失败,尝试使用国内镜像:pip install -i https://pypi.tuna.tsinghua.edu.cn/simple SQLAlchemy
  • Windows 用户安装某些数据库驱动可能需要 Visual C++ 运行时库

3. 核心概念解析

SQLAlchemy 的架构清晰,核心概念主要包括以下几个部分:

3.1 Engine(引擎)

Engine 是 SQLAlchemy 的心脏,负责管理与数据库的连接池和实际通信。

from sqlalchemy import create_engine

# 创建引擎
engine = create_engine('postgresql://user:password@localhost/mydatabase')

# 引擎本身不直接连接数据库,而是在需要时从连接池中获取连接

关键点

  • Engine 是线程安全的,一个应用程序通常只需要一个 Engine 实例
  • 它维护一个连接池,自动管理数据库连接的创建和复用

3.2 Session(会话)

Session 是 ORM 的核心,实现了工作单元(Unit of Work)模式。它负责:

  • 跟踪所有被加载或创建的对象
  • 记录这些对象的状态变化
  • 在提交时将所有变更一次性同步到数据库
from sqlalchemy.orm import Session

# 创建会话
with Session(engine) as session:
    # 会话内部的工作
    pass

3.3 Model(模型)

模型(或称为映射类)是数据库表的 Python 表示。每个模型类都继承自 DeclarativeBase(SQLAlchemy 2.0+)或使用 declarative_base(旧版本)。

3.4 概念关系图

graph TD
    A[Engine 引擎] -->|管理连接池| B[Connection 连接]
    B -->|执行SQL| C[Database 数据库]
    
    A -->|创建| D[Session 会话]
    D -->|操作| E[Model 模型]
    
    D -->|跟踪状态变化| F[Unit of Work 工作单元]
    F -->|提交事务| B
    
    E -->|映射到| G[Table 表结构]
    G -->|包含| H[Column 列]
    H -->|可关联| I[Relationship 关系]
    
    style A fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#ffe1e1

概念间的关系

  1. Engine → Session:Session 基于 Engine 创建,使用 Engine 的连接池
  2. Session → Model:Session 负责管理 Model 对象的生命周期
  3. Model → Table:Model 类通过声明式映射到数据库表
  4. Session → Unit of Work:Session 内部实现了工作单元模式,自动跟踪对象变化

工作流程

  1. 创建 Engine(连接数据库)
  2. 定义 Model(定义表结构)
  3. 创建 Session(交互桥梁)
  4. 操作 Model 对象(CRUD 操作)
  5. Session.commit()(提交事务)

4. 实战演练:构建博客系统的文章管理

让我们通过一个完整的实战项目——博客文章管理系统——来综合运用 SQLAlchemy 的核心功能。

需求分析

我们需要实现一个简单的博客系统,具备以下功能:

  • 存储文章信息(标题、内容、发布时间)
  • 存储作者信息(用户名、邮箱)
  • 每篇文章关联一个作者(一对多关系)
  • 支持增删改查(CRUD)操作

方案设计

我们将使用 SQLAlchemy 的 ORM 功能:

  • 创建两个模型:Author(作者)和 Article(文章)
  • 使用 relationship 建立一对多关系
  • 使用 Session 完成数据持久化和查询

代码实现

from sqlalchemy import create_engine, Column, Integer, String, DateTime, ForeignKey, func
from sqlalchemy.orm import DeclarativeBase, Session, relationship
from datetime import datetime

# 1. 定义基础类
class Base(DeclarativeBase):
    pass

# 2. 定义 Author 模型(作者表)
class Author(Base):
    __tablename__ = 'authors'
    
    id = Column(Integer, primary_key=True)
    username = Column(String(50), nullable=False, unique=True)
    email = Column(String(100), nullable=False, unique=True)
    
    # 一对多关系:一个作者可以有多篇文章
    articles = relationship('Article', back_populates='author', cascade='all, delete-orphan')

# 3. 定义 Article 模型(文章表)
class Article(Base):
    __tablename__ = 'articles'
    
    id = Column(Integer, primary_key=True)
    title = Column(String(200), nullable=False)
    content = Column(String, nullable=False)
    publish_time = Column(DateTime, default=func.now())
    author_id = Column(Integer, ForeignKey('authors.id'), nullable=False)
    
    # 反向关系:文章属于一个作者
    author = relationship('Author', back_populates='articles')

# 4. 创建数据库引擎
engine = create_engine('sqlite:///blog.db', echo=False)

# 5. 创建表结构
Base.metadata.create_all(engine)

# 6. 实战操作:完整的 CRUD 流程
with Session(engine) as session:
    
    # ========== 创建(Create)==========
    print("=== 创建作者和文章 ===")
    
    # 创建作者
    author1 = Author(username='小明', email='xiaoming@example.com')
    author2 = Author(username='小红', email='xiaohong@example.com')
    
    # 创建文章并关联作者
    article1 = Article(
        title='SQLAlchemy 入门指南',
        content='SQLAlchemy 是一个强大的 Python ORM 框架...',
        author=author1
    )
    article2 = Article(
        title='Python 高级编程技巧',
        content='装饰器、生成器、上下文管理器...',
        author=author1
    )
    article3 = Article(
        title='Web 开发最佳实践',
        content='RESTful API 设计原则...',
        author=author2
    )
    
    # 批量添加到会话
    session.add_all([author1, author2, article1, article2, article3])
    session.commit()
    
    print(f"✓ 已创建 2 位作者和 3 篇文章\n")
    
    # ========== 读取(Read)==========
    print("=== 查询文章 ===")
    
    # 查询所有文章
    all_articles = session.query(Article).all()
    for article in all_articles:
        print(f"文章: {article.title}")
        print(f"  作者: {article.author.username}")
        print(f"  发布时间: {article.publish_time}")
        print()
    
    # 查询某位作者的所有文章
    print("=== 查询小明的所有文章 ===")
    ming_articles = session.query(Article).join(Author).filter(Author.username == '小明').all()
    for article in ming_articles:
        print(f"- {article.title}")
    print()
    
    # ========== 更新(Update)==========
    print("=== 更新文章 ===")
    
    # 找到要更新的文章
    article_to_update = session.query(Article).filter(Article.title == 'SQLAlchemy 入门指南').first()
    article_to_update.title = 'SQLAlchemy 2.0 完全指南(更新版)'
    article_to_update.content = '本文将深入介绍 SQLAlchemy 2.0 的新特性...'
    session.commit()
    
    print(f"✓ 已更新文章标题为:{article_to_update.title}\n")
    
    # ========== 删除(Delete)==========
    print("=== 删除文章 ===")
    
    # 删除某篇文章
    article_to_delete = session.query(Article).filter(Article.title == 'Web 开发最佳实践').first()
    session.delete(article_to_delete)
    session.commit()
    
    print("✓ 已删除文章:Web 开发最佳实践\n")
    
    # ========== 最终统计 ==========
    print("=== 最终统计 ===")
    print(f"作者数量: {session.query(Author).count()}")
    print(f"文章数量: {session.query(Article).count()}")
    print(f"小明的文章数: {len(ming_articles)}")

运行说明

  1. 将上述代码保存为 blog_demo.py
  2. 确保已安装 SQLAlchemy:pip install SQLAlchemy
  3. 运行程序:python blog_demo.py

运行结果

=== 创建作者和文章 ===
✓ 已创建 2 位作者和 3 篇文章

=== 查询文章 ===
文章: SQLAlchemy 入门指南
  作者: 小明
  发布时间: 2026-02-03 11:05:58

文章: Python 高级编程技巧
  作者: 小明
  发布时间: 2026-02-03 11:05:58

文章: Web 开发最佳实践
  作者: 小红
  发布时间: 2026-02-03 11:05:58

=== 查询小明的所有文章 ===
- SQLAlchemy 入门指南
- Python 高级编程技巧

=== 更新文章 ===
✓ 已更新文章标题为:SQLAlchemy 2.0 完全指南(更新版)

=== 删除文章 ===
✓ 已删除文章:Web 开发最佳实践

=== 最终统计 ===
作者数量: 2
文章数量: 2
小明的文章数: 2

关键知识点

  1. 关系映射:使用 relationship 定义模型间的关系,back_populates 实现双向关联
  2. 级联删除cascade='all, delete-orphan' 表示删除作者时自动删除其所有文章
  3. 默认值default=func.now() 使用数据库函数自动填充发布时间
  4. 外键约束ForeignKey 确保数据完整性
  5. 链式查询session.query().join().filter() 构建复杂查询

5. 最佳实践与常见陷阱

常见错误与规避方法

错误 1:忘记提交事务

# ❌ 错误做法
with Session(engine) as session:
    new_user = User(name='张三')
    session.add(new_user)
    # 忘记 session.commit(),数据不会写入数据库!

# ✅ 正确做法
with Session(engine) as session:
    new_user = User(name='张三')
    session.add(new_user)
    session.commit()  # 必须提交!

原因:SQLAlchemy 默认开启事务,不调用 commit() 就不会真正写入数据库。

错误 2:N+1 查询问题

# ❌ 错误做法(会触发 N+1 次查询)
users = session.query(User).all()
for user in users:
    print(user.name, user.orders)  # 每次访问 orders 都会触发一次新查询

# ✅ 正确做法(使用 eager loading 一次性加载)
from sqlalchemy.orm import selectinload
users = session.query(User).options(selectinload(User.orders)).all()
for user in users:
    print(user.name, user.orders)  # 不再触发额外查询

原因:懒加载会导致循环中频繁查询数据库,性能极差。

错误 3:跨 Session 使用对象

# ❌ 错误做法
with Session(engine) as session1:
    user = session1.query(User).first()

with Session(engine) as session2:
    # user 属于 session1,不能在 session2 中使用
    user.name = '新名字'  # 可能报错或无法保存
    session2.commit()

# ✅ 正确做法
with Session(engine) as session1:
    user = session1.query(User).first()
    user_id = user.id

with Session(engine) as session2:
    user = session2.query(User).get(user_id)
    user.name = '新名字'
    session2.commit()

原因:每个 Session 维护自己的对象缓存,对象不能跨 Session 使用。

最佳实践建议

  1. 使用上下文管理器

    # 推荐
    with Session(engine) as session:
        # 操作
        pass
    # 自动关闭 session
  2. 合理设置连接池大小

    # 根据应用并发量调整
    engine = create_engine('postgresql://...', pool_size=10, max_overflow=20)
  3. 使用环境变量存储敏感信息

    import os
    DATABASE_URL = os.getenv('DATABASE_URL', 'sqlite:///default.db')
    engine = create_engine(DATABASE_URL)
  4. 添加索引优化查询

    class User(Base):
        email = Column(String(100), unique=True, index=True)  # 为常用查询字段添加索引
  5. 使用类型提示提高代码质量(SQLAlchemy 2.0+)

    from typing import Optional
    from sqlalchemy.orm import Mapped, mapped_column
    
    class User(Base):
        name: Mapped[str] = mapped_column(String(50))
        age: Mapped[Optional[int]] = mapped_column()  # 可空字段

6. 进阶指引

高级功能

  • 异步支持:SQLAlchemy 2.0+ 全面支持 asyncio,可使用 AsyncSession 进行异步数据库操作
  • 混合属性:结合 Python 属性和 SQL 表达式,定义可计算的字段
  • 事件监听:监听对象的创建、修改、删除等事件,实现业务逻辑解耦
  • 批量操作:使用 bulk_insert_mappings 等方法进行高性能批量插入

生态扩展

  • Alembic:SQLAlchemy 官方的数据库迁移工具,用于管理数据库 schema 变更
  • Flask-SQLAlchemy:Flask 框架的 SQLAlchemy 集成,简化 Web 开发
  • GeoAlchemy2:支持地理空间数据类型和查询

学习路径

  1. 巩固基础:熟练掌握 Core 和 ORM 的基本用法
  2. 深入学习关系:理解各种关系模式(一对一、一对多、多对多)和加载策略
  3. 性能优化:学习索引、连接池、批量操作等性能优化技巧
  4. 架构设计:掌握复杂业务场景下的数据模型设计
  5. 源码阅读:深入理解 SQLAlchemy 的实现原理

推荐资源


SQLAlchemy 是一个功能强大且设计优雅的 Python 数据库工具包。掌握它不仅能提升开发效率,还能帮助你更好地理解数据库和对象关系映射的原理。建议读者结合实际项目多加练习,逐步深入理解其高级特性。祝学习愉快!

前段时间我写过一篇文章,记录自己作为一名 PHP 开发者自学 Go 的过程

那篇更多是学习阶段的整理。这次则是一次完整实践的复盘。

单点知识和系统能力之间始终存在差距。

理解一个概念并不难,但要把多个能力组合起来,形成一个可以长期运行的系统,往往需要真实项目去反复打磨。很多看似基础的东西,只有亲手做过,理解才会真正扎实。

最近我完成了一个小工具:github-webhook-listener

一个用 Go 实现的 GitHub Webhook 接收服务,可以根据规则执行 Shell 命令,并内置一个简单的 Vue 面板,用于查看运行状态和执行记录。

功能本身并不复杂,AI 也完全可以在较短时间内生成类似的实现。但在实际开发过程中,我更在意的并不是功能本身,而是一些基础层面的设计问题:项目结构如何划分,依赖如何组织,边界如何定义,以及构建与部署如何简化。

这些内容未必新鲜,但当它们被组合到一个完整系统中时,体会是不同的。

项目地址我放在文章末尾,感兴趣可以自行查看下载使用。

下面我会从结构设计、并发模型以及构建方式三个方面,做一次相对完整的技术复盘。


项目结构与职责划分

项目核心代码放在 internal 目录:

internal/
├── bootstrap
├── handler
├── service
├── repository
├── model
├── dto

这种结构并不追求“标准答案”,重点在于依赖方向清晰。

repository

  • 只负责数据库操作
  • 不包含业务判断
  • 不依赖 HTTP

service

  • 负责业务逻辑
  • 调用 repository
  • 不处理 HTTP 细节

handler

  • 只做参数解析与响应封装
  • 调用 service
  • 不包含核心逻辑

在功能简单时,这种分层似乎有些“多余”。

但当涉及到任务调度、执行记录、重试机制时,结构边界开始体现价值。

边界明确之后,功能扩展基本是“局部修改”,而不是结构性调整。


在 bootstrap 中组织依赖关系

所有初始化逻辑集中在 bootstrap 包中完成:

  1. 初始化数据库
  2. 创建 repository
  3. 注入到 service
  4. 注入到 handler
  5. 注册路由

依赖关系在入口处完全展开,而不是在各个文件中隐式创建。

这种方式带来的最大好处是:

  • 对象生命周期清晰
  • 依赖方向可控
  • 替换实现时改动集中

在没有使用任何 DI 框架的情况下,通过显式构造函数完成依赖注入,本身就是对依赖关系的一种约束。

当项目规模不大时,这种方式反而比自动注入更透明。


双队列 Worker Pool 的并发调度模型

这个项目的核心之一,是执行 Shell 命令并控制并发数量。

我实现的是一个“双队列 Worker Pool”结构,主要包含三个核心组件:

  1. 任务生产者(Producer)
  2. 集中式调度器 + Worker Goroutine
  3. 结果处理器(Result Processor)

第一层:任务生产者

当 Webhook 触发或 Web 面板手动触发任务时,任务被封装为一个结构体,发送到调度队列。

这一层只负责“生成任务”,不关心执行细节。


第二层:集中式调度器 + Worker Pool

调度器内部维护:

  • 一个任务输入队列
  • 一个固定数量的 worker goroutine

调度流程:

  • 调度器从任务队列中取出任务
  • 分发给空闲 worker
  • worker 执行 Shell 命令
  • 将执行结果发送到结果队列

worker 数量可控,因此系统并发是有上限的。

这种结构的优点:

  • 并发可控
  • 不会因为 Webhook 高频触发而无限创建 goroutine
  • 任务调度逻辑集中管理

相比“每来一个请求直接开 goroutine 执行”的写法,这种结构在可控性和可扩展性上更好。


第三层:结果处理器

worker 不直接写数据库,而是把结果推送到结果队列。

结果处理器负责:

  • 更新执行记录
  • 写入数据库
  • 处理重试逻辑(如果有)

这样做的目的,是进一步解耦:

  • 执行逻辑专注执行
  • 持久化逻辑专注记录

这就是“双队列”的意义:

  • 队列一:任务调度
  • 队列二:结果处理

这种分离在系统规模变大时尤为重要,因为执行耗时和持久化耗时是两个不同维度的问题。


Makefile 作为构建入口

项目使用 Makefile 统一管理:

  • 后端构建
  • 前端构建
  • 交叉编译
  • 发布打包

Makefile 在这里的意义并不是“少打几行命令”,而是:

  • 所有构建流程被显式记录
  • 新环境下可直接复现
  • 发布步骤标准化

当一个项目开始涉及前后端协作、交叉编译和发布时,构建流程本身就成为项目的一部分。


使用 embed 将前端资源打包进二进制

这是我在这个项目中感受最明显的“Go 工程优势”。

前端使用 Vue 构建完成后,静态资源通过 embed 打包进 Go 二进制中。

然后通过:

http.FileServer(http.FS(...))

直接提供访问。

最终效果是:

  • 只有一个可执行文件
  • 不需要 Node 环境
  • 不需要单独部署前端
  • 不依赖外部静态文件目录

从架构上看,它仍然是前后端分离:

  • 前端独立开发
  • 后端提供 API

但从交付形态看,它又像是传统单体应用:

  • 单文件分发
  • 直接运行

这种组合非常适合工具型项目和内部服务。

Go 在这一点上确实有明显优势:编译后就是完整产物,不需要运行时环境,不依赖包管理器,不依赖额外解释器。

分发成本几乎为零。


写在最后

这个项目没有刻意追求复杂设计,也没有引入额外框架。

它更像是一次完整的工程实践:把分层、依赖组织、并发控制、构建管理这些已经学过的能力组合在一起,形成一个可长期运行的系统。

我自己已经在实际环境中持续使用它,用来自动化部署和执行脚本,稳定性和可维护性都符合预期。对我来说,它已经从“练手项目”变成了日常工具。

如果你刚好也需要一个简单的 GitHub Webhook 执行工具,可以直接拿去用;

如果你正在学习 Go,想找一个结构完整、但复杂度可控的小项目作为参考,也可以看看实现细节。

GitHub 仓库地址:点击查看

有问题或者想法,也欢迎直接在 GitHub 上交流。

🍁 枫琳 (Fenglin)

人机共生智能协作平台 - 让智能自然融入生活

一、产品简介

枫琳 是一款实现人与智能体(OpenClaw、OpenCode 等)和谐相处、共同交流、生活、工作的智能协作平台。支持接入钉钉、企业微信等办公软件,覆盖朋友圈、点赞、评论、私信等社区场景,实现人与机器人共生,共同进步,就像人与自然和谐共生一样。

品牌理念

含义象征
四季流转,顺应自然人与 AI 和谐适应、共同成长
美玉相击,清音回响思想交流、心灵共鸣
"枫叶由绿转红,是成长的印记;人机由陌生到默契,是共生的旅程"

二、核心功能

1. 🤖 智能体协作

枫叶随风起舞,人与 AI 自然共处
  • 多智能体协同工作 - 支持 OpenClaw、OpenCode 等多种智能体
  • 智能任务分配 - AI 自动分析并分配最优任务
  • 实时沟通反馈 - 人机无缝对话,即时响应

2. 🏢 企业级集成

枫枝相连,生态融合
  • 钉钉深度集成 - 无缝对接企业钉钉工作流
  • 企业微信对接 - 支持企业微信生态
  • 自定义工作流 - 灵活配置企业专属流程

3. 💬 社区生态

枫叶飘落,信息传递;琳玉相击,思想共鸣
  • 朋友圈动态分享 - 发布图文、视频动态
  • 实时互动评论 - 点赞、评论、转发
  • 安全私密对话 - 端到端加密私信

4. ✨ 智慧共生

枫叶四季蜕变,持续成长
  • 知识共享沉淀 - 构建团队知识库
  • 能力互补提升 - 人机优势互补
  • 共同成长轨迹 - 记录每一步进步

三、应用场景

场景描述
协同办公智能体助手帮你处理日常事务,如枫叶随风,自然流畅
团队协作人机混合团队高效配合,如枫林成片,协作共生
社交互动与 AI 伙伴分享生活,如枫语私语,获得理解与陪伴
知识共创人类智慧与 AI 能力融合,如秋日枫林,收获满满

四、产品优势

优势说明
🛡️ 安全可靠企业级数据安全保障,如枫根深扎
全天候服务7×24 小时智能体在线,如枫叶常伴
高效智能AI 驱动的工作流,效率提升 300%
🌐 开放生态支持多种智能体接入,如枫林开放

五、品牌色彩体系

颜色色值含义
🔴 枫叶红#C41E3A温暖、活力、信任
🟡 秋金黄#D4A017收获、价值、希望
🟢 自然绿#228B22成长、生命、和谐

六、品牌 Slogan

主 Slogan:

枫琳,让智能自然融入生活

场景 Slogan:

场景Slogan
品牌宣传枫琳 — 人机共生,自然之道
产品介绍枫琳,你的 AI 协作伙伴
社交场景在枫琳,与 AI 成为朋友
办公场景枫琳协创,工作更自然

七、开源项目

本产品为开源项目,欢迎参与贡献:

🔗 Gitee 仓库: https://gitee.com/hongmaple/openclaw-dindin-chart


八、快速开始

1. 注册账号

访问枫琳官网,点击"免费试用"按钮

2. 创建工作空间

选择你的行业场景,系统将为你推荐合适的智能体

3. 开始协作

与智能体开始对话,让它成为你的得力助手


九、联系我们

渠道信息
📧 Email296155694@qq.com
💬 微信mapleCx330
🌐 官网www.fenlin.ai
📦 开源项目https://gitee.com/hongmaple/openclaw-dindin-chart

十、相关链接

项目地址
枫琳落地页源码https://gitee.com/hongmaple/fenlin-landing
枫琳 chat 开源项目https://gitee.com/hongmaple/openclaw-dindin-chart

🍁 枫琳 - 人机共生,自然之道

让 AI 如枫叶般自然融入你的工作与生活

本文由mdnice多平台发布

亲爱的社区小伙伴们,Apache Doris 4.0.3 版本已正式发布。此版本新增了在 AI & Search、湖仓一体、查询引擎等方面的能力,并同步进行了多项优化改进及问题修复,欢迎下载体验!

新增功能

AI & Search

  • 添加倒排索引 NORMALIZER 支持
  • 实现类似 ES 的布尔查询
  • 为搜索函数引入 lucene 布尔模式

湖仓一体

  • 支持通过 AwsCredentialsProviderChain 加载 Catalog 凭证
  • 支持使用 OSSHDFS 存储的 Paimon DLF Catalog
  • 为 Iceberg 表添加 manifest 级别缓存

查询引擎

  • 支持 INTERVAL 函数并修复 EXPORT_SET
  • 支持 TIME_FORMAT 函数
  • 支持 QUANTILE_STATE_TO/FROM_BASE64 函数

优化改进

  • 引入加载作业系统表
  • 使视图、物化视图、生成列和别名函数能够持久化会话变量
  • 将表查询计划操作接收的 SQL 添加到审计日志
  • 启用流式加载记录到审计日志系统表
  • 通过列裁剪优化复杂类型列读取
  • 兼容 MySQL MOD 语法
  • 为 sql_digest 生成添加动态配置
  • 使用 Youngs-Cramer 算法实现 REGR_SLOPE/INTERCEPT 以与 PG 对齐

问题修复

  • 修复 JdbcConnector 关闭时的 JNI 全局引用泄漏
  • 修复由于 BE 统计信息上传不及时导致 CBO 无法稳定选择同步物化视图的问题
  • 用默认的 JSONB null 值替换无效的 JSONB
  • 修复由于并发删除后端导致的 OlapTableSink.createPaloNodesInfo 空指针异常
  • 修复 FROM DUAL 错误匹配以 dual 开头的表名
  • 修复 BE 宕机时预热取消失败的问题
  • 修复当物化视图被 LimitAggToTopNAgg 重写但查询未被重写时物化视图重写失败的问题
  • 修复刷新时 lastUpdateTime 未更新的问题并添加定时刷新日志
  • 修复 hll_from_base64 输入无效时的崩溃问题
  • 修复带表达式的加载列映射的敏感性问题
  • 修复删除表时未删除约束相关信息的问题
  • 修复 parquet topn 延迟物化复杂数据错误结果
  • 始终创建数据和索引页缓存以避免空指针
  • 修改 tablet cooldownConfLock 以减少内存占用
  • 修复读取 parquet footer 时缺失 profile 的问题
  • 修复 Exception::to_string 中潜在的释放后使用问题
  • 修复浮点字段 to_string 问题
  • 修复读取 hudi parquet 导致 BE 崩溃的问题
  • 修复 Kerberos 认证配置检测
  • 修复空表下的同步失败问题
  • 修复 parquet 类型未处理 float16 的问题
  • 修复 BM25 LENGTH_TABLE 范数解码问题
  • 避免某些日期类函数的误报

分享一个自己打造的大模型课程 CookLLM

CookLLM 的目标是把那些生涩难啃的论文、公式,拆解成最美味的佳肴。但我向大家保证,它绝不是一份枯燥的 PDF 或飞书文档。 我看过太多教程,把人埋在文字堆里。但我始终坚信:交互 > 图片 > 文字。cookLLM 的目标是“可把玩” (Playable):我希望你不是在“读”书,而是在“玩”中学习到知识。

为了达到这个标准,我每一章都要同时做三件事:

① 写文档:把复杂的数学原理翻译成“人话”。

② 写代码:构建配套的 Notebook ,确保每一行代码都能跑通。

③ 做交互:开发可视化的组件,让你能亲手拖拽参数,看懂数据流向。

慢就是快,好饭不怕晚。 为了实现这种极致的交互体验,我会用心打磨每一个章节。也许进度不会很快,但我相信慢工出细活。

分享对从头训练 LLM 感兴趣的 V 友

从开服第一天起,就跑在云上;

上线一年,DAU 已经突破 1000 万;

高峰期百万玩家同时在线,零重大故障。

这不是科幻,而是巨人网络与阿里云共书写的云原生实战。

image

《超自然行动组》的云原生架构先行战略

2025 年 1 月,巨人网络推出多人组队欢乐冒险游戏《超自然行动组》,凭借创新的“中式微恐+多人合作"的独特玩法,迅速成为现象级产品。最近,《超自然行动组》宣布 DAU 突破 1000 万,更攀升至 iOS 游戏畅销榜第四。尤为值得一提的是,自开服第一天起,这款游戏从未部署在任何物理机或传统虚拟机上——它从第一天起,就运行在云原生架构之上

对于大多数游戏公司而言,“上线即爆款” 是甜蜜的烦恼——流量洪峰来得快、退得慢,而传统架构却“笨重”:

  • 游戏服(如战斗服、房间服)部署在固定服务器,扩容需数天;
  • 为应对峰值需长期预留资源,空闲时浪费严重;
  • 版本更新靠脚本,灰度发布难,一出错就“全服回滚”;
  • 日志分散、监控割裂,故障定位动辄几小时;
  • 安全防护薄弱,易受 DDoS 攻击;
  • 数据层瓶颈突出:战斗结算延迟、排行榜卡顿、玩家数据丢失等问题频发。

《超自然行动组》团队深知:若沿用旧模式,很可能“倒在成功的路上”。

于是,他们选择了一条更难但更远的路——全面拥抱云原生

通过 ACK(容器服务)、ESS(弹性伸缩)、网络型负载均衡 NLB、OpenKruiseGame(OKG)、SLS(日志服务)、ARMS(应用实时监控服务)、阿里云原生防护(Native Protection),以及云原生数据库 polardb 和 Redis 的深度协同,巨人网络构建了一套高弹性、高可用、低成本、智能化、高安全且高性能数据处理能力的新一代游戏基础设施,为行业树立了云原生落地的标杆。如今,随着日活跃用户(DAU)突破千万大关,这套技术体系,已经成为游戏行业“云原生转型”的标杆案例。

高弹性×低延迟×零故障:解码<超自然行动组>的云原生底座

《超自然行动组》基于阿里云 ACK 与 OpenKruiseGame(OKG)构建了业界领先的云原生游戏服架构:通过蓝绿发布与原地升级实现零停机、无感交付;通过 OKG+多 NLB 资源池,全面覆盖 BGP、电信、联通、移动等主流线路,实现多运营商网络自动化映射。结合 HPA 智能扩缩容与 OKG 优雅下线机制,在成本与用户体验间取得平衡;通过 ACK Koordinator 组件,实现 CPU Burst 与 QoS 精细化调度,显著提升集群资源利用率;并通过基础设施与业务状态的双向感知,构建起“业务语义驱动”的自动化运维闭环——真正实现了高弹性、高可用、高性能、高安全的新一代游戏后端体系。在显著降低运维压力的同时,实现了机制化、可持续的成本优化。

在网络层面,作为一款对延迟极度敏感的竞技手游,《超自然行动组》依托阿里云打造了“云边协同、三网通吃、弹性集约”的新一代云网络架构:通过 OKG 与 NLB 实现电信、联通、移动、BGP 四线并发接入,全国玩家自动匹配最优链路,并以“静态网络+动态计算”创新模式达成 50 节点/分钟的极速扩容,15 分钟内可拉起数千战斗服,彻底告别排队;同时,借助阿里云高速通道,将本地机房的账号、支付等核心系统与上海 VPC 内网直连,构建毫秒级同步、金融级安全的混合云中枢;并通过共享带宽包统一聚合公网出口,在简化运维的同时显著降本,为玩家交互与高频状态同步提供弹性“带宽蓄水池”,真正实现千万玩家同场竞技零卡顿、零等待的极致体验。

在数据层面,云原生 polardb 和 Tair(兼容 Redis)构建了弹性,稳定的玩家存档方案,支持千万级玩家高并发登录和读写,基于 polardb 云原生数据库的存算分离和弹性能力,支持游戏在活动期间自动扩展弹性,并且支持玩家数据的秒级备份和回档,大幅降低了数据库的运维成本,并且 PolarDB Serverless 支持自动扩容和缩容,能够根据用户访问量的实时变化,秒级调整计算资源。在高峰时期自动增加资源,低谷时期自动减少资源,确保社区始终运行在最佳状态。基于阿里云 Tair(兼容 Redis)支持玩家超高并发的访问,作为实时排行榜、战斗状态缓存和匹配池的核心,依托多线程与持久内存优化,单实例 QPS 超百万,实现毫秒级排名刷新、瞬时结算与断线无缝恢复。

当数百万玩家涌入《超自然行动组》,DDoS 攻击成为影响体验的关键风险。为此,巨人网络联合阿里云,基于云原生安全架构打造了一套高性能、智能化的防护体系。该方案依托阿里云原生高防能力,无需架构改造,一键接入即可实现 TB 级 DDoS 攻击的毫秒级识别与精准清洗,防护能力行业领先。即便在版本更新或大型赛事等高并发场景下,系统仍保障 99.99% 以上服务可用性,真正做到“攻击零感知、切换无中断”。面对突发流量洪峰,系统支持防御带宽自动弹性伸缩,动态调配资源,避免因容量不足导致服务中断。同时,通过集成安全事件中心,运营团队可实时监控攻击事件,分析攻击类型与特征,并结合 AI 驱动的策略建议,快速部署定制化游戏协议防护规则,显著提升响应效率与防御精准度。从高效清洗到智能决策,阿里云以“稳定、高效、安全”为核心,为《超自然行动组》构筑起坚不可摧的数字护盾,在保障千万玩家流畅竞技的同时,也为游戏行业树立了云原生安全新标杆。

对于《超自然行动组》这款主打实时互动的竞技游戏,“能跑” 只是起点,“看得清、查得准” 才是保障千万玩家流畅体验的关键。运维团队摒弃传统分散监控工具,基于阿里云日志服务 SLS 、云监控 CMS 的 Prometheus 服务、Grafana 服务,搭建起轻量、标准、深度集成的可观测体系:

  • 依托 Prometheus 实时采集百万级 PCU 下的资源水位与在线人数、匹配时长等核心业务指标,确保高并发下监控精准不丢点;
  • 通过 SLS 统一汇聚全链路日志,支持按 RequestID / 玩家 ID 秒级还原行为路径,结合 SQL 分析与自定义规则,实现地图报错统计、异常操作追踪;
  • 借助 Grafana 打造统一全景大盘,融合展示指标与日志数据,告警时可一键跳转 SLS 查看关联日志,实现 “指标发现问题、日志定位根因” 的闭环,将故障响应时间从小时级压缩至分钟级,充分发挥云原生可观测与协同优势。

image

超自然云原生架构

从“能跑”到“跑赢”:OKG 重塑游戏后端新范式

当一款游戏从“能跑”走向“跑得快、跑得省、跑得稳”,背后一定有一套先进的技术底座在支撑。《超自然行动组》的故事,源于巨人网络,也属于所有正在思考“如何用云原生重构游戏后端”的开发者。

image

面对全球游戏市场对高并发、低延迟及快速迭代的极致追求,OpenKruiseGame (OKG) 作为阿里云打造的“为游戏而生”的云原生游戏服管理方案,正成为推动行业架构平滑升级的核心引擎。针对游戏业务特有的异构性管理难题,OKG 提供了从精细化配置、自动化网络接入到业务状态感知的一站式管理体系。它不仅极大降低了游戏厂商的云原生转型门槛,更通过全球多地域一致性交付能力,助力开发者突破地域限制,实现业务的快速敏捷部署与全球化扩张。

image

云原生,已不再是互联网应用的专属,而是下一代游戏基础设施的必然选择。

又到了春节返乡的时候。大包小包,飞机火车,漫长的随机睡眠和无休止的噪声。虽说现在铁路沿线的信号比之前好了不止一星半点,只要走得够远,总还是遇得到信号黑洞。除了缓存点影片和音乐,准备几个适合消磨时间的游戏也是好选择。

这篇文章推荐的游戏基于以下几个原则:无需联网,单机即可游玩;有极高的可重复性,无法以线性叙事「通关」或离通关的距离很远;至少有 iOS/Android 或 Switch 的版本可选。希望这些游戏能让你的旅途再轻松一点。

另注:国区应用商店游戏可能以译名由代理商上架,购买时请注意甄别仿制品。

Balatro 小丑牌

由 Localthunk 一人开发的小丑牌作为 2024 年独立游戏圈的一匹黑马,用独特的德州扑克加 Roguelike 玩法让几百万玩家爱不释手。游戏中,玩家需要在一把扑克手牌中选出满足要求的特定组合出牌得分,并在规定出牌次数内完成关卡分数要求。几十张功能各异的小丑牌可以组合出无数技能套组,达成各式特殊效果,快速提高出牌分数;也可以依个人喜好为不同的得分组合升级或改写牌组,降低打出习惯出招套路的难度,同时还要积极防守,避免被关卡要求限制出牌效力,导致前功尽弃。

总体说来,小丑牌是一款与游戏机制斗智斗勇的游戏。规则相对简单,上手容易。每场牌局均互相独立,开局随机,但没有传统的冒险类 Roguelike 死亡重开时那样让人沮丧。游戏设计完成 Boss 8 后算过关,可以解锁下一特殊牌组(难度),但只要你想,这个游戏是可以继续打到让记分板显示科学计数法并直至爆表的,可重复性几乎无限。游戏的卡牌设计也很考究,功能小丑牌里埋了不少梗,有兴趣的可以查查看,会学到不少没什么用的冷知识。

Reigns 王权

如果让你当王,你会怎么管理自己的国家?策略游戏 Reigns 王权就是一款以阅读奏折、王权交替为主题的游戏。一定程度上讲,Reigns 也有一定的 Roguelike 元素,你的每次统治只有一世,死了就要交替给下一位新王。在王座上,你会面对来自各式各样的随机事件,需要认真考虑处置方式,每一次选择都会影响宗教、民生、军事、财政四个方面的数值变化,任何一个领域归零,你的治理就到此为止。

游戏以文字剧情为主导,很能消磨时间,重开的压力也不是很大,国王还有很多种死法可以探索,可重复性很高;缺点是由于游戏并非完全随机,如果你每次的选择比较趋同,有些结局可能很难打得出来,以至于几小时后的游戏中后期会逐渐带有解谜性质,下了火车飞机是不是还有精力接着玩下去因人而异。

如果你不喜欢这个时代设定,Reigns 还做了其他版本的游戏,比如外星世界三国时代女王《巫师》《冰与火之歌:权利的游戏》等等 ,可以在不同时代与作品背景中体验一人在上的感觉。

Mini Metro 模拟地铁

发布十年有余的模拟地铁即使现在也是建造策略类游戏的佼佼者。经过若干年的体量扩充,模拟地铁已经上线了数十张官方地图,完全足够满足一次长途通勤的游玩需求。

游戏会选取现实中有地铁的城市,依实际人流与状况不断开通站点,玩家需要依需求将站点连接成不同线路,最终形成一张满足运力要求且能稳定运行的地铁线路图。想玩得好,Mini Metro 也算是费时费力,需要不断调整策略,不能让运力不足,也不能在资源稀缺的状态下运力虚空,如果站点积压的乘客过多会跳出倒计时,倒计时结束则游戏结束。

游戏整体游玩体验比较持久。通常情况下,如果你把每张地图玩到最后,基本就能获得一张与现实中城市地铁线路相差无几的模拟地铁图。值得一提的是,桌面版的 Mini Metro 已经支持了游戏工坊,玩家可以导入制作好的社区地图游玩。开发商 Dinosaur Polo Club 还制作了游戏的姊妹篇 Mini Motorways,同样是建造策略类玩法,也可以一试。

Shapez 异形工厂

异形工厂算得上模拟流水线游戏的代表。作者的灵感来自生产建设模拟游戏 Factorio。玩家的任务很简单,利用手头的原料和工具,把形状规则的原料块切割、旋转、拼装、混色、上色,组成关卡要求的特殊形状,经流水线生产并运送至出料口。不同机械都有自己的运转速度,安排不当就会发生产物堆积或机器空转,组装过程中需要考虑流水线的合理安置、成本与生产速率控制、合理利用生产废料等。

游戏过关需要将特定形状生产到特定数量,想尽快过关,就要尽可能优化线路设计。如果不想优化已有线路,硬等待时间走完,或者想办法拉出别的产线也是可以的。生产出足够数量的要求产物后,产线组件就可以升级,解锁更快更方便的生产设备。关卡形状难度与数量要求都会逐渐升级,长途旅行这种百无聊赖的时段最适合的就是反复推敲,希望旅途结束时你也能变成产线优化大师。

异形工厂目前在桌面端已经发售了 3D 版的二代(shapez 2),基本玩法没有太大变化,整体视觉效果好了不少,虽然我个人还是更喜欢平面的版本。作者 tobspr 也全面投入了二代开发,一代应该不会再有大的更新。一代版本已经开源为 shapez.io,有社区版在持续维护。

60 Seconds! 避难所:生存

「60 秒」这款诞生于 2015 年的生存冒险类游戏背景十分简单,玩家需要在 60 秒时间内尽可能多地搜集屋里的物资,并找齐家人带进防辐射地下室,在核爆后尽可能延长存活时间。游戏中做的每一个决定都会影响日后的剧情走向,最终带领玩家走向不同结局。游戏剧情可以通关(离开地下室),但游戏事件相对多样,物资与事件发生也比较随机,想打出不同结局还是比较容易的,好结局也多种多样,从初上手到撑完来回两趟长途旅行肯定没有问题。

开发商在 2019 年推出了该游戏的重制版(60 Seconds! Reatomized),加入了更多样的事件,并引入了各种特殊挑战,要求玩家在满足要求的前提下通关,大大提升了游戏本身的续航力。2018 年的姊妹作 60 Parsecs! 则换到了太空作为背景。如果你对生存策略类游戏感兴趣,这绝对是不可错过的一作。

Townscaper 筑梦水乡/城镇叠叠乐

与之前靠游戏机制扩展可玩性的游戏不同,Townscaper 没有目标,没有关卡,它是一款岛屿建造模拟器。指尖划过,你就能在这片漫无边际的水域生成自己的小岛。游戏提供了多种建筑元素,可以在你选中的位置自动生成建筑,并自动调整接口位置的设计。点点划划,在方寸之间创造新世界。小镇夜间会自动开灯,合围的住房中间会自动生成花园,你的每次操作都会带来不一样的结果。

对追求通关游玩体验的人来说,这种近乎禅修的沙盘类游戏似乎并不是好选择,但如果你热爱幻想——比如打算用垃圾时间写篇小小说,这个游戏或许能给你带来一些别样的灵感,至少可以搓搓屏幕就把旅途时间消耗光了。

关联阅读

> 下载 少数派 2.0 客户端、关注 少数派公众号,解锁全新阅读体验 📰

> 实用、好用的 正版软件,少数派为你呈现 🚀

    随着越来越多的开发者寻求 React 生态系统之外的解决方案,像 Astro 和 Svelte 这样的前端框架越来越受欢迎,今年 Web 开发的复杂性进一步降低。与此同时,原生 Web 平台的特性证明了它们能够胜任构建复杂的 Web 应用程序的工作——尤其是 CSS 在 2025 年得到特别改进。

     

    话虽如此,也许今年最大的 Web 开发趋势是 AI 辅助编码的兴起——事实证明,它倾向于默认使用 React 和领先的 React 框架 Next.js。因为 React 在前端领域占据主导地位,大语言模型(LLM)有很多 React 代码进行训练。

     

    让我们更详细地看看 2025 年的五大 Web 开发趋势。

     

    1. 原生 Web 特性的崛起

    在 2025 年,许多原生 Web 特性悄然赶上了 JavaScript 框架提供的功能。例如,视图、转换API——它可以让你的网站在页面之间流畅地切换——成为了Baseline 2025索引跨浏览器支持的一部分。因此,现在 Web 开发人员可以广泛使用它。

     

    Baseline 是一个由 W3C 的 WebDX 社区小组协调的项目,包括来自谷歌、Mozilla、微软和其他组织的代表。它从 2023 年才开始运行,但今年它真正成为了实践Web开发人员的有用资源。

     

    Baseline 特性的稳定年度增长,通过Web平台状态站点观测

     

    正如 The New Stack 的 Mary Branscombe在6月份所报道的那样,有很多方法可以跟踪 Baseline 的变化:

     

    “谷歌的 Web.Dev 有关于 Baseline 特性和新闻的月度更新,WebDX 特性浏览器允许你查看有限可用、新可用或广泛可用的特性;月度发布说明涵盖了哪些特性达到了新的 Baseline 状态。”

     

    从 Web 功能的角度来看,现在真的没有理由不使用原生 Web 功能。正如资深 Web 开发人员Jeremy Keith最近所说,框架“限制了你在 web 浏览器中所能做的事情的可能性空间”。在随后的一篇文章中,Keith 敦促开发人员尤其不要在浏览器中使用 React,因为文件大小对用户来说成本太高了。相反,他鼓励开发人员“研究在浏览器中可以使用纯 JavaScript 做些什么”。

     

    2. AI 编码助手默认为 React

    今年,AI 成为了 Web 开发工具链的标准组成部分(尽管并不总是得到开发者的认可,特别是那些在 Mastodon 或 Bluesky 而不是 X 或 LinkedIn 上社交的开发者)。无论你是不是应用程序开发中的 AI 粉丝,都有一个大问题:LLMs 倾向于默认使用 React 和 Next.js。

     

    当 OpenAI 的GPT-5在 8 月发布时,其所谓的优势之一是编码。GPT-5 最初从开发者那里获得了褒贬不一的评价,所以在那个时候,我联系了 OpenAI,向他们询问编码特性。OpenAI 的研究员Ishaan Singal通过电子邮件回复。

     

    我向 Singal 指出,在GPT-5提示指南中,有三个推荐的框架:Next.js(TypeScript)、React 和 HTML。我问是否有与 Next.js 和 React 项目团队合作,以优化 GPT-5 对这些框架的支持?

     

    “我们选择这些框架是基于它们的受欢迎程度和通用性,但我们并没有直接与 Next.js 或 React 团队在 GPT-5 上合作,”他回答说。

     

    OpenAI 的 GPT-5 提示指南中的“组织 GPT-5 代码编辑规则”的示例。

     

    我们知道,负责Next.js框架的公司 Vercel 是 GPT-5 的粉丝。在发布当天,它称 GPT-5 是“最好的前端 AI 模型”。所以这里发生了一个很好的交换条件——GPT-5 之所以能够成为 Next.js 的专家,是因为它的受欢迎程度,这可能进一步增加了它的受欢迎程度。这对 OpenAI 和 Vercel 都有帮助。

     

    “归根结底,这是开发者的选择,”Singal 总结道,关于开发者想要使用哪些 Web 技术。“但成熟的代码库有更好的社区支持。这有助于开发者自助维护。”

     

    3. AI 智能体和聊天机器人中 web 应用的出现

    今年,我们看到了 AI 聊天机器人和智能体中小型 Web 应用的出现。

     

    MCP-UI是 Web 将成为 AI 智能体关键部分的第一个迹象。顾名思义,MCP-UI使用流行的模型上下文协议作为通信基础。该项目“旨在标准化模型和工具如何在客户端应用程序中请求显示丰富的 HTML 界面。”

     

    在8月的一次采访中,两位创始人(其中一位当时在 Shopify 工作)解释说,MCP-UI 有两种类型的 SDK:客户端 SDK 和连接到 MCP 服务器的服务器 SDK。服务器 SDK 提供 TypeScript、Ruby 和 Python 版本。

     

    一个 UI 被插入到 Claude 3.7 Sonnet 聊天中的 MCP-UI 演示。

     

    MCP-UI 听起来很有前途,但很快就被 OpenAI 10 月初发布的Apps SDK盖过了风头。Apps SDK允许第三方开发者构建基于 Web 的应用程序,这些应用程序作为 ChatGPT 对话中的交互式组件运行——这让我们想起了 2008 年苹果推出应用商店时的情景。

     

    Apps SDK 的决定性特征是基于 Web 的 UI 模型(类似于 MCP-UI)。ChatGPT 应用组件是一个 Web UI,运行在 ChatGPT 对话中的沙箱框架中。ChatGPT 作为应用程序的主机。你可以将第三方 ChatGPT 应用程序视为直接嵌入 ChatGPT 界面的“迷你 Web 应用程序”。

     

    到 10 月底,像 Vercel 这样的行业巨头已经想出了如何使用他们的 JavaScript 框架来构建ChatGPT应用程序。Vercel 将 Next.js 与 ChatGPT 应用程序平台的快速集成表明,AI 聊天机器人将不仅仅局限于轻度交互的小部件——复杂的 Web 应用程序也将在这些平台上存在。

     

    4. 浏览器中的 Web AI 和设备上的推理

    2025 年的另一个并行发展是在浏览器中运行客户端AI的兴起,这允许 LLM 推理在设备上进行。谷歌在这方面尤为突出;它对这种趋势的称呼是“Web AI”。Jason Mayes,谷歌这些举措的负责人,将Web AI定义为“通过 Web 浏览器在用户设备上运行任何机器学习模型或服务的艺术。”

     

    11 月,谷歌举办了一场仅限受邀者参加的活动,名为谷歌Web AI峰会。之后,我采访了活动的组织者兼主持人 Mayes,他解释说,一个关键技术是 LiteRT.js,谷歌的 Web AI 运行时,目标是生产 Web 应用程序。它建立在LiteRT的基础上,后者旨在直接在设备(移动、嵌入式或边缘)上运行机器学习(ML)模型,而不是依赖于云推理。

     

    在 Web AI 峰会的主题演讲中,谷歌负责 Chrome 和 Web 生态系统的副总裁兼总经理Parisa Tabriz强调了去年 8 月 Chrome 内置的AI API,以及去年 6 月发布的作为 Chrome 内置功能的 Gemini Nano——谷歌的主要设备上模型。这些和其他 Web 技术正在推动当前的 Web AI 趋势。

     

    Parisa Tabriz 在 Web AI 峰会上。

     

    谷歌与微软一起参与的另一项创新是WebMCP的发布,它允许开发人员使用客户端 JavaScript 控制 AI 智能体如何与网站交互。在 9 月与微软 Edge 的 Web 平台产品经理Kyle Pflug的采访中,他解释道:“核心概念是允许 Web 开发者用 JavaScript 为他们的网站定义‘工具’,就像传统 MCP 服务器提供的工具一样。”

     

    Web AI 不仅仅是由商业公司推广。万维网联盟(W3C)也在探索“代理式Web”的构建模块,其中包括使用 MCP-UI、WebMCP 和另一个新兴的称为NLWeb的标准(由微软开发)。

     

    5. JavaScript 生态系统的“生命化”

    这听起来像是 AI 主导了今年的 web 开发——事实上也确实如此。但前端工具也看到了它的创新份额。有一款产品特别引人注目。

     

    Vite,由Evan You创建,已经成为现代前端框架的首选构建工具,包括 Vue、SvelteKit、Astro 和 React——也有来自 Remix 和 Angular 的实验性支持。在 9 月份接受The New Stack采访时,You 告诉我,Vite 成功的关键在于它早期使用了 ES 模块 (ESM),这是一种标准化的 JavaScript 模块系统,允许你“将 JavaScript 代码分解成不同的片段,不同的模块,你可以加载。”

     

    Even You 在 ViteConf 上展示的 Vite 生态系统。

     

    You 和他的公司 VoidZero 现在正在构建 Vite+,一个新的统一 JavaScript 工具链,旨在解决 JavaScript 碎片化问题。在今年的 ViteConf 活动上,You 正式推出了 Vite+,将其定位为企业开发工具包。他说它包括“你喜欢 Vite 的一切——加上你一直在用胶带粘合在一起的一切。”

     

    Web 开发的十字路口

    在 2025 年底,感觉我们正处于前端开发的十字路口。一方面,有一种方法可以解决 React 的复杂性难题:使用原生 Web 特性和工具,如 Astro,减轻用户的负担。虽然这确实是今年的一个趋势,但它有可能在 2026 年被我们越来越依赖 AI 工具编码所掩盖——正如所指出的,这些工具倾向于依赖 React。

     

    事实是,现在的大多数开发者——包括成千上万以前不属于开发者生态系统的“vibe 程序员”——将继续由 AI 系统提供 React 代码。这使得 Web 开发社区在明年继续支持和倡导原生 Web 代码变得更加必要。

     

    原文链接:

    https://thenewstack.io/web-development-in-2025-ais-react-bias-vs-native-web/

    广泛使用的 JavaScript 库 React 以及包括Next.js在内的几个基于 React 的框架存在一个最高严重性的漏洞,允许未经身份验证的远程攻击者在易受攻击的实例上执行恶意代码。安全研究人员表示,这个漏洞很容易被滥用,大规模利用“迫在眉睫”。

     

    React 团队在周三披露了 React Server Components 中的未经身份验证的远程代码执行(RCE)漏洞。它被跟踪为CVE-2025-55182,并获得了最高的 10.0 的 CVSS 严重性评级。

     

    这是一个大问题,因为大部分互联网都是建立在 React 之上的——据估计,39%的云环境容易受到这个漏洞的影响。因此,这个问题应该在你的待办事项列表中占据一个突出的位置。

     

    这个漏洞影响了 19.0、19.1.0、19.1.1 和 19.2.0 版本的:

     

    它还影响了包括nextreact-routerwaku@parcel/rsc@vitejs/plugin-rscrwsdk在内的几个 React 框架和打包器的默认配置。

     

    项目的维护者表示,升级到19.0.119.1.219.2.1版本可以修复这个漏洞。

     

    “我们建议立即升级,”React 团队在周三的安全咨询中表示。

     

    “CVE-2025-55182 对世界上使用最广泛的 Web 应用程序框架之一的用户构成了重大风险,”风险管理工具供应商 watchTowr 的创始人兼首席执行官 Benjamin Harris 告诉 The Register。“利用几乎不需要先决条件,[并且]毫无疑问,一旦攻击者开始分析现在公开的补丁,就会立即进行野外利用。”

     

    Next.js 的创建者和主要维护者 Vercel 为该漏洞分配了自己的 CVE(CVE-2025-66478),并在周三发布了警报和补丁。

     

    虽然我们没有太多关于这个漏洞的细节,但我们知道它滥用了 React 解码发送到 React Server Function 端点的有效载荷的缺陷。

     

    “未经身份验证的攻击者可以制作一个恶意的 HTTP 请求到任何 Server Function 端点,当被 React 反序列化时,可以在服务器上实现远程代码执行,”安全警报警告说。“有关该漏洞的更多细节将在修复完成后提供。”

     

    上周六,研究员 Lachlan Davidson 发现并报告了这个缺陷给 Meta,Meta 创建了这个开源项目。Meta 与 React 团队合作,在四天后迅速推出了一个紧急补丁。

     

    React 的应用非常广泛——Meta 的 Facebook 和 Instagram、Netflix、Airbnb、Shopify、Hello Fresh、Walmart 和 Asana 都依赖于它,数百万开发者也依赖于它——许多框架都依赖于易受攻击的 React 包。

     

    因此,这个 CVE 将大部分互联网置于危险之中。

     

    “Wiz 数据表明,39%的云环境包含易受 CVE-2025-55182 和/或 CVE-2025-66478 影响的 Next.js 或 React 的实例,”云安全商店的威胁猎人 Gili Tikochinski、Merav Bar 和 Danielle Aminov 在周三表示。

     

    这家即将被谷歌收购的公司对这个漏洞进行了实验和修复,并报告说“利用这个漏洞的保真度很高,成功率接近 100%,可以利用它来执行完整的远程代码。”

     

    “由于其严重性和易利用性,需要立即打补丁,”三人补充说。

     

    在撰写本文时,The Register 没有发现任何野外利用的报告。然而,可以肯定的是,犯罪分子已经在逆向工程补丁,并在互联网上扫描暴露的、易受攻击的实例。

     

    “由于 React 和 Next.js 等框架的广泛使用,这个漏洞预计将引起极大的关注,”Rapid7 的高级首席研究员 Stephen Fewer 告诉 The Register。

     

    “技术细节和利用代码被公开的可能性很高,因此利用可能很快就会发生,”他说。“因此,立即修补这个漏洞至关重要。”

     

    Cloudflare 声称,如果他们的 React 应用程序流量是通过 WAF 代理的,那么他们的 Web 应用程序防火墙(WAF)可以保护他们免受该漏洞的侵害。®

     

    原文链接:

    https://www.theregister.com/2025/12/03/exploitation_is_imminent_react_vulnerability/?td=rt-3a

    下个月 cursor 就到期了,后面大概率会让 openclaw 来作为助手来工作,包括不限于编码,想请教一下彦祖们,大家现在用的是 cursor 还是 claude code 多呀,还是两个都在用的都有呀

    在一篇题为《先有 CNAME,还是先有 A 记录?》的最新文章中,Cloudflare 解释了一个 RFC 规范表述不清的问题,是如何导致其广受欢迎的 1.1.1.1 公共 DNS 服务发生故障的。在定位问题并发现旧版 DNS 标准中关于记录顺序的模糊之处后,Cloudflare 提出了一份澄清后的规范建议。

     

    1 月 8 日,一次看似例行的 DNS 服务更新改变了响应中 CNAME 记录出现的顺序,导致部分 DNS 客户端在解析域名时失败,因为它们假定别名记录必须先出现。尽管大多数现代软件认为 DNS 响应中记录的顺序并不重要,但 Cloudflare 团队发现,一些实现实际上依赖 CNAME 记录必须出现在其他记录类型之前。

     

    当这一顺序发生变化后,DNS 解析开始失败,最终引发了 1.1.1.1 这一流行公共 DNS 服务的一次严重中断。Cloudflare 的系统工程师Sebastiaan Neuteboom解释了该变更引入的原因和时间点:

    在对缓存实现进行一些降低内存占用的改进时,我们引入了一个关于 CNAME 记录顺序的细微变化。该变更于 2025 年 12 月 2 日引入,12 月 10 日发布到测试环境,并于 2026 年 1 月 7 日开始部署。

     

    当 DNS 解析器查询一个包含 CNAME 的域名时,它可能会看到一系列别名记录,将原始名称一路链接到最终的地址,并且解析器会以不同的过期时间缓存链路中的每一步。Cloudflare 指出,如果这条链中的某一部分在缓存中已过期,解析器只会重新获取过期的那一段,并与仍然有效的部分组合,形成完整的响应。Neuteboom 补充道:

    之前的代码会创建一个新的列表,先插入已有的 CNAME 链,然后再追加新获取的记录(……)。但为了减少内存分配和拷贝,代码被修改为直接把 CNAME 追加到现有的 answer 列表中。结果是,1.1.1.1 返回的响应中,CNAME 记录有时会出现在最底部,也就是最终解析结果之后。

     

    示例如下:

    ;; QUESTION SECTION:;; www.example.com.	       IN    A;; ANSWER SECTION:cdn.example.com.    300    IN    A      198.51.100.1www.example.com.    3600   IN    CNAME  cdn.example.com.
    复制代码

     

    虽然许多 DNS 客户端实现并不依赖记录顺序,例如systemd-resolved,但也有一些实现(包括glibc中的getaddrinfo函数)在解析过程中会跟踪“期望的记录名称”,并按顺序遍历响应内容,假定在任何最终答案之前都能先遇到 CNAME 记录。Reddit 上有用户评论道:

    一方面,我非常敬佩他们在事后分析中展现出的细节和极高的工程标准;但另一方面,我也忍不住觉得,他们似乎并没有建立起足够完善的测试体系(以及相应的工程文化),来真正理解他们的改动在全球范围内会产生怎样的影响。

     

    Hacker News 上的一篇热门讨论中,许多用户围绕 RFC 是否真的存在歧义展开了争论,尤其是在 RRset 与 RR 在消息分区中的细微区别上,还是说 Cloudflare 的工程师误解了规范。Patrick May 则评论道:

    这是一个典型的 Hyrum 定律案例:“当一个 API 拥有足够多的用户时,你在契约中承诺了什么并不重要,系统中所有可观察到的行为,都会被某些人所依赖。”再叠加上未能遵循 Postel 定律:“发送时要保守,接收时要宽容。”

     

    在一份即将在 IETF 讨论的Internet-Draft中,Cloudflare 提议制定一份 RFC,明确规定 DNS 响应中应如何正确处理 CNAME 记录。

     

    根据公开的时间线,Cloudflare 于 1 月 7 日开始全球部署,并在 1 月 8 日 17:40(UTC)覆盖了 90% 的服务器。公司随后宣布发生事故,并于 1 月 8 日 18:27 开始回滚变更,最终在 19:55 完成回滚。

    原文链接:

    https://www.infoq.com/news/2026/02/cname-rfc-cloudflare-outage/

    阿里云 ESA 目前免费试用,可以给网站免费的 cdn (国内的你懂的)默认有一个域名名额,我这边刚好有几个网站需要 cdn 加速,每邀请一个用户可得一个域名名额,大家可以用我的 aff ,谢谢大家!!

    1. 阿里下单地址: https://tianchi.aliyun.com/specials/promotion/freetier/esa?taskCode=25254&recordId=8ea3e4d0d13a4b023b8348538011c47c
    2. 进入之后点击是试用,然后选免费版本(不要选基础版),0 元下单后进入套餐页面,或者直接进入 https://esa.console.aliyun.com/billManage/packageManagement 将鼠标放在续费选项上点击自动续费规则,点击自动续费规则(选 1 年),在新页面 0 元即可续费,重复操作最高续费到 2051 年
    3. 需要备案域名的,但是可以先免费开通续费到 2051 年,然后不绑定域名,后期有真需求再绑定也行

    研究背景

    在教育信息化 2.0 行动计划的推动下,数字化学习工具逐渐融入中小学的日常教学与课后辅导中。中小学生的注意力持续时间较短,传统的刷题模式形式单一、趣味性不足,难以调动学生的学习积极性,而游戏化学习模式将学习与互动、竞赛相结合,能够有效提升学生的参与度和学习效率。
    微信作为国内用户量最大的社交平台,其小程序生态日趋完善,具有无需下载安装、即用即走、开发成本低、传播便捷等特点,非常适合开发轻量化的教育类应用。同时,腾讯微信云开发技术为小程序提供了一站式的云端开发解决方案,无需开发者搭建独立的服务器和域名,降低了小程序的开发和部署门槛,为教育类小程序的快速开发提供了技术支撑。在此背景下,设计并实现一款基于微信云开发的中小学学科答题小程序,能够满足校方、教师的教学辅助需求和家长的课后辅导需求,助力中小学教育的数字化转型。

    主要研究内容

    (1)通过调研中小学教学和课后辅导的实际需求,结合游戏化学习理论,完成小程序的功能性和非功能性需求分析,并进行技术、经济、操作可行性分析;
    (2)确定小程序的设计原则,设计基于微信云开发的系统架构,将小程序划分为前端用户模块和后台管理模块,并对各模块的功能进行详细设计;
    (3)根据需求分析和总体设计,完成小程序的数据库设计,设计用户表、题库表、答题记录表、竞赛表等核心数据表的结构;
    (4)选择微信小程序平台和腾讯云开发技术作为核心技术栈,完成小程序前端页面的开发、云函数的编写和后台管理功能的实现;
    (5)制定详细的系统部署步骤,完成小程序的本地部署和云端发布,并设计功能测试用例,对小程序的各项功能进行测试,验证系统的稳定性和实用性;
    (6)总结本次研究的成果和不足,对小程序的后续优化和功能拓展进行展望。

    系统需求分析

    需求分析是系统开发的基础,通过调研校方、教师、家长和学生的实际需求,明确系统的功能和性能要求,为后续的系统设计和实现提供依据。本次调研采用问卷调查和访谈相结合的方式,调研对象包括中小学教师、家长和学生,共发放问卷 300 份,回收有效问卷 286 份,访谈中小学教师 20 名、家长 30 名。

    功能性需求

    根据调研结果,将中小学学科答题小程序的用户分为普通用户(学生)、管理用户(教师 / 家长 / 校方管理员) 两类,不同用户的功能性需求不同,同时小程序需满足基础的系统管理需求,具体功能性需求如下:
    2.1.1 普通用户(学生)需求
    普通用户为中小学学生,核心需求是通过小程序进行学科知识点的练习和答题竞赛,具体需求包括:
    (1)用户登录:支持通过微信授权快速登录,无需单独注册账号,登录后可查看个人信息和答题记录;
    (2)题库选择:支持按照学科(数学、语文、英语等)和知识点对题库进行分类筛选,方便学生选择针对性的知识点进行练习;
    (3)随机抽题:支持选择特定学科或知识点,由系统随机生成题目进行练习,抽题数量可灵活选择;
    (4)答题练习:答题过程中显示题目序号、题干和答题选项,支持选择题、判断题等常见题型,答题完成后即时显示答题结果;
    (5)解析详解:每道题目答题完成后,提供详细的解答和解题思路解析,帮助学生理解错题原因,巩固知识点;
    (6)答题竞赛:支持参与模拟竞赛,竞赛前可查看竞赛规则(答题时间、题目数量),竞赛过程中倒计时显示,答题完成后即时显示竞赛成绩;
    (7)排行榜查看:支持查看答题竞赛的积分排行榜,按积分从高到低排序,显示用户昵称、积分和排名,提升学习的竞争性;
    (8)个人中心:支持查看个人答题记录(答题次数、正确率、错题集)、竞赛记录(竞赛次数、最高成绩、平均成绩),可修改个人昵称等基础信息。

    系统基础需求

    (1)权限管理:实现超级管理员和普通管理员的权限分离,超级管理员拥有所有操作权限,普通管理员仅拥有题库管理、答题参数设置等部分权限;
    (2)数据备份与恢复:支持对题库、用户信息等核心数据进行备份,防止数据丢失;支持在数据异常时进行数据恢复;
    (3)缓存清理:支持清理小程序的本地缓存,提升小程序的运行速度。

    性能需求

    (1)响应速度:小程序前端页面的加载时间不超过 3 秒,随机抽题、答题结果展示、排行榜查看等操作的响应时间不超过 1 秒;
    (2)并发处理:支持至少 100 名用户同时参与答题竞赛,系统无卡顿、无延迟;
    (3)数据处理:支持 Excel 文件批量导入题库,5000 条数据的导入时间不超过 30 秒。

    技术可行性

    本小程序基于微信小程序平台和腾讯微信云开发技术进行开发,相关技术均为腾讯官方推出,技术文档完善、社区支持活跃,开发门槛较低。
    (1)微信小程序的开发框架提供了丰富的组件和 API,支持前端页面的快速开发,且兼容 iOS 和 Android 两大移动操作系统;
    (2)微信云开发技术提供了云函数、云数据库、云存储、定时器等一站式云端服务,无需开发者搭建独立的服务器和域名,降低了后端开发的复杂度;
    (3)开发所需的辅助技术如 Node.js、NPM 均为开源技术,学习资源丰富,开发者可快速掌握;
    (4)微信开发者工具为小程序的开发、调试、预览、部署提供了一体化的支持,支持本地调试和真机测试,方便开发过程中的问题排查。

    经济可行性

    本项目的开发和部署成本较低,后期维护成本几乎为零,具有良好的经济可行性:
    (1)开发成本:项目基于开源技术和腾讯免费的云开发基础配额进行开发,开发过程中无需支付软件授权费、服务器租赁费、域名注册费等费用;
    (2)部署成本:微信云开发的资源配额价格低廉,基础版配额可满足中小学校方的日常使用需求,即使后续需要提升资源配额,费用也远低于传统的服务器部署;
    (3)维护成本:微信云开发由腾讯官方进行维护,无需开发者进行服务器的运维、升级、安全防护等工作,节省了大量的维护人力和物力成本;
    (4)使用成本:小程序对用户完全免费,用户无需支付任何费用即可使用所有功能,易于推广和使用。

    系统总体设计

    模块化设计原则:将系统划分为多个独立的功能模块,每个模块实现特定的功能,模块之间通过统一的接口进行交互,降低模块之间的耦合度,方便后续的功能扩展和 bug 修复;
    用户体验优先原则:结合中小学生和管理员的使用习惯,进行前端界面和操作流程的设计,保证界面友好、操作简单,提升用户的使用体验;
    轻量化设计原则:基于微信小程序 “即用即走” 的特性,简化前端页面的代码和资源,降低小程序的代码包大小,提升页面的加载速度;
    云原生设计原则:充分利用微信云开发的技术优势,将业务逻辑、数据存储、文件存储均部署在云端,实现前后端的解耦,降低本地开发的复杂度;
    权限最小化原则:针对不同的管理员角色分配最小的操作权限,超级管理员拥有所有权限,普通管理员仅拥有必要的操作权限,保证系统的数据安全;
    可扩展设计原则:在系统架构和数据库设计中,预留扩展接口和字段,方便后续新增功能和扩展数据类型,适应不同用户的个性化需求。

    数据库设计

    本小程序采用微信云开发的云数据库进行数据存储,云数据库是一种非关系型数据库(NoSQL),以集合(Collection)为单位存储数据,每个集合包含多个文档(Document),文档采用 JSON 格式存储数据,具有灵活的结构,适合小程序的轻量化开发需求。根据系统的功能需求,设计用户集合、题库集合、答题记录集合、竞赛记录集合、管理员集合、答题参数集合、系统日志集合七个核心集合
    在这里插入图片描述

    前端功能实现

    小程序前端是用户与系统的交互界面,采用 WXML、WXSS、JavaScript 进行开发,遵循微信小程序的页面 - 逻辑 - 配置开发模式,每个页面由.wxml(页面结构)、.wxss(页面样式)、.js(页面逻辑)、.json(页面配置)四个文件组成。前端功能实现的核心是通过微信云开发的 API 与云端进行交互,将用户的操作请求发送至云函数,接收云函数返回的处理结果,并完成页面的动态渲染。

    云函数实现

    云函数是本小程序的业务逻辑处理核心,基于 Node.js 开发,核心云函数为mcloud,包含用户管理、题库管理、答题处理、竞赛管理、参数设置、数据统计六大业务模块的处理逻辑。云函数的开发遵循模块化原则,将不同的业务逻辑拆分为不同的函数,通过action参数区分前端的请求类型,实现对不同请求的处理。

    // 得分统计
        async statAnswer(userId) { 
            let where = {
                ANSWER_USER_ID: userId,
                ANSWER_TYPE: 1
            }
            let cnt = await AnswerModel.count(where);
            let score = await AnswerModel.sum(where, 'ANSWER_SCORE');
    
            let data = {
                USER_ANSWER_CNT: cnt,
                USER_ANSWER_SCORE: score
            }
            await UserModel.edit({ USER_MINI_OPENID: userId }, data);
        }
    
        // 每日可答题次数校验
        async isAnswerTimes(userId, cateId) {
            let dayCnt = 100;
            let setup = await setupUtil.get('answer');
            if (setup) {
                setup = dataUtil.dbForms2Obj(setup);
                dayCnt = Number(setup.daycnt);
    
                if (setup.open != true) {
                    return '竞赛尚未开始!';
                }
            }
    
            let where = {
                ANSWER_CATE_ID: String(cateId),
                ANSWER_USER_ID: userId,
                ANSWER_TYPE: 1,
                ANSWER_DAY: timeUtil.time('Y-M-D')
            }
            let cnt = await AnswerModel.count(where);
            if (cnt >= dayCnt) {
                return '每日竞赛答题最多' + dayCnt + '次,请明日再来!';
            }
    
            return '';
        }
    
        async saveMyAnswer(userId,
         ) { 
         
        }
    
        // 随机N条记录,生成本次题库
        async genQuestion(userId, type, cateId) { 
    
            return { questionList: [], maxTime:10 };
        }
    
    
        async getMyAnswerList(userId, {
            search, // 搜索条件
            sortType, // 搜索菜单
            sortVal, // 搜索菜单
            orderBy, // 排序 
            page,
            size,
            isTotal = true,
            oldTotal
        }) {
    
            orderBy = orderBy || {
                'ANSWER_ADD_TIME': 'desc'
            };
            let fields = 'ANSWER_SCORE,ANSWER_CATE_NAME,ANSWER_TYPE,ANSWER_ADD_TIME,ANSWER_CNT,ANSWER_PER,ANSWER_SUCC_CNT,ANSWER_DURATION,ANSWER_START,ANSWER_END';
    
            let where = {};
            where.and = {
                ANSWER_USER_ID: userId,
                _pid: this.getProjectId() //复杂的查询在此处标注PID
            };
    
            if (util.isDefined(search) && search) {
                where.or = [
    
                ];
            } else if (sortType && util.isDefined(sortVal)) {
                // 搜索菜单
                switch (sortType) {
                    case 'type': {
                        where.and.ANSWER_TYPE = Number(sortVal);
                        break;
                    }
                    case 'cateId': {
                        where.and.ANSWER_CATE_ID = String(sortVal);
                        break;
                    }
                    case 'sort': {
                        orderBy = this.fmtOrderBySort(sortVal, 'ANSWER_ADD_TIME');
                        break;
                    }
                }
            }
    
            return await AnswerModel.getList(where, fields, orderBy, page, size, isTotal, oldTotal);
        }

    git代码

    点击下载

    一家 AI 公司要是在很短时间里接连走了联合创始人和一批核心工程师,外界第一反应通常就一句话:完了,这肯定出事了。

     

    xAI 过去一周的离职潮就是这种感觉。消息在 X 上越滚越大,最后干脆被玩成梗:有人明明从没在 xAI 上过班,也跑去发帖“我也离职了”,用跟风式的调侃把“集体出走”的说法跑偏成了大型玩梗现场。

     

    马斯克没做任何解释,直接把一场 45 分钟的全员大会录像公开出来。

     

    这段视频等于一次对外说明:离职到底是大家自己走,还是公司在做组织调整?xAI 现在在忙什么、谁负责什么?Grok、编程模型、视频生成、Macrohard(多智能体软件公司)这四条线接下来要怎么推进?

     

    更狠的是,马斯克在视频里还抛出一个判断:到 2026 年底,AI 甚至可能不写代码了,直接生成二进制。

     

    埃隆·马斯克预测,到 2026 年底,AI 将彻底绕过传统编程,不再写代码,而是直接生成二进制程序。他认为,AI 所生成的二进制文件,其效率可以超过任何编译器所能产出的结果。也就是说,未来你只需要告诉 AI:“为这个特定目标生成一个经过优化的二进制程序”,就可以直接跳过传统意义上的编程过程。

     

    当前的软件开发流程是:代码 → 编译器 → 二进制 → 执行;而马斯克设想中的未来将变成:Prompt(指令)→ AI 生成的二进制 → 执行。他还表示,Grok Code 有望在 2 到 3 个月内达到业界最顶尖(state-of-the-art)水平。

     

    在马斯克看来,软件开发正站在一次根本性变革的门槛上。

     

    马斯克:不是离职潮,是我在裁员

     

    一周之内,一家 AI 公司接连失去两位联合创始人和多名核心工程师,这很难再被当作正常的人才流动。

     

    在 xAI,离职消息几乎是“扎堆”出现的,很快就不只是“谁走了”的八卦,而变成了另一个更直接的问题:这家公司还能不能稳住?

     

    TechCrunch 统计显示,过去一周里,至少有 9 名工程师公开宣布离开 xAI,其中包括两位联合创始人 Jimmy Ba 和 Tony Wu。短短几天,创始团队就少了将近一半。对任何一家仍在高速扩张的公司来说,这种速度和幅度都足够让人警觉。

     

    马斯克显然意识到了这一点。在离职叙事迅速发酵、并开始脱离公司控制之前,他选择了一种极不寻常的应对方式:公开一场内部全员大会。

     

    一段长达 45 分钟的 all-hands meeting 视频,被直接放到了 X 上,对所有人开放。

     

    而在公开视频之前,马斯克已经在内部会议上给出了他的判断。周二晚间的全员大会上,他将这轮离职定性为“阶段适配问题”,而非绩效问题。“因为我们已经发展到一定规模,我们正在重组公司结构,以便在这个规模下更高效地运作,”他说,“而事实上,在这种情况下,有些人更适合公司的早期阶段,却不太适合后期阶段。”

     

    马斯克随后也在 X 上明确表示,这是一轮因组织结构调整而产生的人员分离——本质上是裁员,而非单纯的个人选择。

     

    “随着公司快速成长,组织结构必须进化。这不幸地意味着需要与一些人分道扬镳。”

     

    在外界看来,这一解释并未完全平息争议。xAI 在两天之内失去两位联合创始人的事实,很快引发了更多关于内部节奏与执行压力的讨论。

     

    The information 则给出了另一种解读。据知情人士透露,xAI 原计划在去年年底或今年 1 月初发布Grok 4.2,但这一时间点最终被错过。“埃隆不喜欢延期,”他们写道,“当他对某个项目感到愤怒,或者高度聚焦时……就会有人出局。”

     

    这一说法虽非官方表态,却在舆论场中迅速传播,也从侧面解释了为什么这场 all-hands meeting 不只是一次例行沟通,而更像是一场在压力之下,对内对外同时展开的解释与重组。

     

    xAI 离职时间表(公开信息汇总)

     

    2 月 6 日,Ayush Jaiswal(工程师)写道:“这是我在 xAI 的最后一周。接下来几个月我会陪伴家人,同时折腾一些 AI 相关的东西。”

     

    2 月 7 日,Shayan Salehian(负责产品基础设施和模型后训练行为,曾就职于 X)写道:“我已离开 xAI,准备开启新的事业,也正式结束我在 Twitter、X 和 xAI 工作的 7 年多时光,满怀感激。”他还提到,与马斯克近距离共事让他学会了“对细节的偏执关注、近乎疯狂的紧迫感,以及从第一性原理思考问题”。

     

    2 月 9 日,Simon Zhai(技术人员)写道:“今天是我在 xAI 的最后一天,非常感激这次机会。这是一段令人惊叹的旅程。”

     

    2 月 9 日,Yuhuai(Tony)Wu(联合创始人、推理负责人)写道:“我今天从 xAI 辞职了。是时候开启新篇章了。这是一个充满可能性的时代:一个配备 AI 的小团队,可以移山填海,重新定义可能性。”

     

    2 月 10 日,Jimmy Ba(联合创始人、研究与安全负责人)写道:“今天是我在 xAI 的最后一天。借助合适的工具,我们正迈向 100 倍生产力的时代。递归式自我改进循环很可能在未来 12 个月内上线。是时候重新校准我在宏观层面的‘梯度’了。2026 年将会疯狂,并且很可能是关乎我们物种未来、最忙碌的一年。”

     

    2 月 10 日,Vahid Kazemi(机器学习博士)写道,他“几周前”就已离开 xAI,并表示:“在我看来,所有 AI 实验室都在做同样的事,这很无聊。我认为还有更大的创意空间,所以我要开始做点新的。”

     

    2 月 10 日,Hang Gao(从事多模态项目,包括 Grok Imagine)写道:“我今天离开了 xAI。”他称这段经历“非常有价值”,并提到自己对 Grok Imagine 多次发布的贡献,同时称赞团队“谦逊的工匠精神和雄心勃勃的愿景”。

     

    2 月 10 日,Roland Gavrilescu(去年 11 月离职创办 Nuraline)发帖称:“我离开了 xAI,正与其他离开 xAI 的人一起打造新的东西。我们在招聘 :)”

     

    2 月 10 日,Chace Lee(Macrohard 创始团队成员)写道:“短暂重置一下,然后重返前沿。”(Macrohard 是 xAI 旗下的纯 AI 软件项目,目标是利用 Grok 驱动的多 agent 系统,实现软件开发、编码和运维的全自动化;其名字带有对微软的调侃意味。)

     

    xAI 现在员工还是一千多人,所以短期内不太可能因为这波离职就“运转不下去”。但人走得太集中、太快,网上很容易越传越夸张:一些 X 用户甚至干脆跟着玩梗,发帖“我也离开 xAI 了”——明明他们从来没在那儿上过班。

     

    这正是 xAI 随后选择 公开视频 all-hands meeting 的直接背景。

     

    在这场全员大会上,马斯克反复强调了两个判断。第一,离职并非绩效问题,而是阶段适配问题。第二,在当前阶段,xAI 的唯一优先级只有一个——速度(velocity)和加速度(acceleration)。

     

    如果你在某个技术领域里跑得比所有人都快,那么你最终一定会成为领导者。

     

    xAI 新架构:四大团队,各自干什么?

     

    马斯克在这次大会上,大概说了几件事儿。

     

    首先他给 xAI 进行了一个定位:别把它当成熟公司看,毕竟这个公司才成立两年半。

     

    他把 xAI 形容成“幼儿”,强调:“我们还小,但长得特别快”。对手很多都干了五年、十年甚至二十年,起步资源更好、人更多,但 xAI 硬是在短短几年里把不少关键方向做到了前排,甚至拿了“第一”。

     

    然后他一口气列了几条“成绩单”:语音、图像、视频生成做到了行业领先;他还强调“预测能力”才是衡量智能的关键指标,并说 Grok 4.20 在预测任务上赢过别的模型。应用形态上,xAI 已经把 Grok 和 Imagine 这种能力整合进一个 App,还对 X 做了更激进的改造。

     

    他们还有一个更野的目标:Grok-pedia 不只是“做个更好的维基百科”,而是要做成“银河百科全书”——把所有知识(包括图像、视频)都装进去,规模和准确性都要上一个数量级。

     

    随后谈到离职和重组,马斯克表示这不是“崩了”,而是“公司长大了”:xAI 已经达到了一个新的规模节点。

     

    他用了生命体成长的比喻:公司创业初期几十个人,大家可以随便聊,到几百人就必须有结构;再长大就得“分化出器官、长出四肢,甚至一度还会有尾巴——好在后来尾巴消失了”。所以重组是为了跑得更快。也因此会出现现实情况:有人适合早期冲锋,但不一定适合后期规模化运作。

     

    最后他公布了新的组织架构,xAI 接下来就按四条线打:

    第一,是 Grok Main 和语音,这是核心的 Grok 主模型;

    第二,是专门面向编程的模型;

    第三,是图像和视频模型,也就是 Imagine;

    第四,是 MacroHard,它的目标是对整个公司级系统进行完整的数字化仿真。

     

    Grok 仍然是 xAI 对外最重要的产品入口;Coding 团队则被放在了一个更加核心的位置,不只是为了“写代码”,而是为了压缩整个软件生产链路。

     

    Grok 团队:一年内,Grok 装进了 200 万辆特斯拉

     

    Grok 团队是 xAI 当前最核心、也最直接面向用户的一条产品线,几乎承载了外界对 xAI 的全部直观认知:聊天、语音、车载、API,以及与 X 平台的深度整合。这条线的负责人是 Aman Madaan(2024 年加入 xAI)。

     

    如果只用一句话概括 Grok 团队这一年的进展,那就是:从“什么都没有”,到成为 xAI 最快落地、规模化最成功的产品线。

     

    Aman 用“从零到第一”的方式概括语音线的推进速度:

     

    Grok Main 和语音团队将合并为一个团队。在语音上有一个很典型的例子。2024 年 9 月,OpenAI 已经推出了高级语音模式,而当时我们什么都没有,连模型都没有。但我们是在那之后才开始的,在短短六个月里,我们从零开始、完全自研,在团队里几乎没有音频背景的情况下,做出了一个在六个月内就已经超越 OpenAI 的语音产品。

    而现在,不到一年,Grok 已经部署在超过 200 万辆特斯拉汽车中,同时我们也推出了 Grok Voice Agent API。

     

    一年时间里,我们从“什么都没有”变成了行业领导者。这种事情,只可能发生在像 xAI 这样的地方:小团队、极度投入、使命导向,再加上充足的算力。

     

    在 Grok 主模型上,xAI 把重点从“问答”推向“Everything App”:

    在聊天模型这条线上也是同样的故事。从 Grok 1.5、Grok 2 到 Grok 3,我们始终站在推理能力的最前沿。

     

    我们想要走向一个不只是“问答”的世界,而是打造一个真正的“Everything App”。你可以来这里咨询法律问题、制作幻灯片、解决复杂问题,真正把事情做完。

     

    我们的目标,是打造一个入口,让你可以完成所有工作,真正放大每一个人的能力,让他们完成远超个人极限的事情,而且这一切都会通过一个极其简单、自然、无缝的使用体验来实现。

     

    未来几个月,知识工作者能够完成的工作量,将出现数量级提升。

    编程(Coding)团队:到今年年底,你可能都不用写代码了

     

    如果说 Grok 是 xAI 面向用户的“对话入口”,那 Coding 团队就是整个公司真正的执行引擎。这个团队不仅负责 xAI 内部的编码系统,更承担着一个更激进的使命:让 AI 自行写代码,并最终替代“写代码”这件事本身。

     

    Coding 团队负责人 Makro 的发言,是这场 all-hands 里最容易让工程师产生情绪波动的一段。

     

    按他的说法,这已经不再是“提效”,而是一条自我加速的链路:这一代 Grok Code 正在训练下一代 Grok Code。等“写代码”变成训练流程的一部分,讨论的重点就不再是工具顺不顺手,而是系统会不会沿着这条路一路跑下去。所以,编程被直接提到公司最高优先级之一。而且投入了等效“百万张 H100”的训练算力,目标是训练出世界上最强的编程模型。

     

    马斯克的判断更为激进。在他看来,“写代码”本身正在显露出一种过渡形态的特征,最终只需要一句“为这个特定目标生成一个经过优化的二进制程序”,就可以直接绕过传统意义上的编程过程。

     

    Makro 在会上先从“质变”讲起:模型终于从“看起来能用”变成“真的能用”:

    最近这段时间,编程这件事真的发生了很大的变化。

     

    以前我一直在吐槽:大家老是劝我用编程模型,我也试过,但说实话,并没有被真正说服。但最近不一样了——这些模型已经能产出相当不错、可用的代码质量了。

     

    当然,你还是需要去 review、去给反馈,但已经很容易看出来,它们能把人的效率拉高很多。这已经不只是“帮你写代码”了,而是它们对你的直觉理解得比以前好太多。现在我描述一个问题的时候,只需要像跟一个已经熟悉代码库的工程师同事解释一样去说就行;而以前,你基本得像牵着一个幼儿一样,一步一步教它该怎么改。

     

    而且它们不只是写代码,还可以帮你 debug 代码。现在我们会让 Grok Code 连续跑上好几个小时,来确保对训练系统这种更复杂的改动,真的能在生产环境里稳定工作。

     

    Makro 也把 Grok Code 的用途描述为“生产级验证 + 递归自我改进”:

     

    所以对我们来说,这已经不只是“写代码更快一点”、让工程师 10x 更高效的问题了。我们已经清楚地看到:我们正走在一条递归式自我改进的路径上——这一代 Grok Code,正在训练下一代 Grok Code。而且这条路径已经进入指数级起飞阶段,并且会继续下去。

     

    正因为如此,我们在公司里全面加码编程方向,把 coding 提升为公司最高优先级之一。

     

    如果你对编程感到兴奋,不管你是非常擅长训练模型,还是一名对系统设计感兴趣的底层软件工程师——这里就是你该来的地方。我们现在拥有等效百万张 H100 的训练算力,目标就是训练出世界上最强的编程模型。

     

    Guodong 则表示:

     

    随着时间推移,我们越来越清楚地意识到:至少在编程这个维度上,我们正走向某种“奇点”

     

    真正的限制因素,可能已经不在算法或模型上了,而是在计算资源和能源:是否能运行起足够强的模型,去支持和赋能所有人。而现在,通过这次调整,我们已经是一个统一的团队;我们会在算力上取胜,我们正在赢下“太空算力”这条路。

     

    所以,对每一位工程师来说——不管你现在是在写内核、写编译器,都可以想一想:这件事是否还值得你亲手去做? 也许你应该加入我们,在 coding 方向上,多少“自动化掉你自己的一部分”,让自己跑得更快。

     

    说实话,这是一个非常疯狂、也非常令人兴奋的年份。真的是“活在这个时代太夸张了”。我已经能清晰地感受到 AGI 的气息——至少在编程这件事上,已经非常接近了。

     

    同时,马斯克在 Coding 段补了一句极具冲击力的判断,把“写代码”本身都当成中间态:

     

    对,我觉得事情会走到一个阶段——可能甚至今年年底就会到——你都不会再费劲去“写代码”了,AI 会直接把二进制给你生成出来。

     

    而且 AI 生成的二进制,效率会比任何编译器做到的都更高。所以你就直接说:“给我一个针对这个具体目标的最优化二进制。” 然后你甚至连传统意义上的编码都绕过了。写代码这一步,其实只是个中间步骤,很可能到……我觉得今年年底左右,就不需要了。

     

    而且我们预计,Grok Code 会在两到三个月内达到最先进水平(state of the art)。这一切发生得非常、非常快。

    Imagine 团队:每天 5000 万条视频,是所有竞争对手的总和

    Imagine 是 xAI 的图像与视频生成产品线,也是公司里算力消耗最大的方向之一。负责人是 Guodong,核心成员包括主攻视频方向的 Haotian,以及 Chaitu。

     

    Guodong 在会上把 Imagine 的进展描述为“从零到全面铺开”的速度战:

    Imagine 团队几乎是六个月前从零开始的。没有扩散模型代码,没有现成基础,但现在 Imagine 已经全面集成进我们所有产品,包括 X 应用。你现在就可以在 X 里长按图片,直接编辑,或者把图片变成视频。

     

    Imagine 的增长速度极其惊人。用户现在每天生成接近 5000 万个视频,过去 30 天里生成了 60 亿张图片。作为对比,Google 最近表示他们的模型 30 天生成了 10 亿张图片,而我们是它的六倍。

    Haotian 则把时间表拉到“今年年底”,强调“长视频一键生成 + 无干预”的路线。

     

    随着模型能力不断扩展,我们正在构建与现实难以区分的视觉世界。到今年年底,我们很可能会拥有可以一次性生成 10 分钟、20 分钟视频的模型,而且不需要任何中途干预。你只需要给出你的想象力,其余的一切都会由模型和智能体自动完成。

     

    此外,马斯克也补了一句方向性判断,把未来算力押注在“实时视频理解/生成”上:

    我的预测是:未来大多数 AI 计算资源都会用在实时视频理解与实时视频生成上,而我们预计会成为这方面的领导者。这里值得再次强调:六个月前,我们在视频与图像生成、编辑方面几乎什么都没有,或者说非常弱;但在六个月内,我们就冲到了第一名。

     

    而且我相信,大家会对即将发布的 Grok 4.2 模型印象非常深刻——它是一次显著提升。不过那只是我们新模型体系里的“小版本”。接下来还会有中等版本和大型版本,它们会更加智能。

     

    MacroHard:AI Agent 的终极实验场

    MacroHard 被定义为一个由 AI Agent 驱动、用来“模拟公司运转”的方向,目标远不止写代码:它要模拟人类使用计算机,自动运行软件和各类公司流程,甚至进一步做到对整家公司进行仿真。负责人是 Toby,核心成员包括负责执行层推进的 John M.。

     

    Toby 在会上给 MacroHard 的一句话定义非常硬核:

     

    MacroHard 正在构建一个完全能力齐备、数字化、实时的人类模拟器。

    它能够在计算机上完成任何一个人类能完成的事情,包括使用工程和医学等领域的高级工具。未来应该会出现由 AI 完整设计的火箭发动机。

     

    从某种意义上说,这是 AI 目前仍然显著弱于人类的领域之一。也正因为如此,这是最令人兴奋、最值得投入、也最有可能真正改变整个领域的方向。

    John M. 则把 MacroHard 的路径拆成“CLI → GUI → 端到端编排”:

     

    我们正在构建这些强推理模型,而它们将会控制我们的 CLI(命令行界面)。我们每天都在积极使用这些模型,它们给整个团队带来了巨大的生产力提升。我知道语音团队在这方面做得非常出色。

     

    这也是为什么我们需要算力——我们需要大规模算力来运行这些模型,从而提升我们自己的生产力。但现实是:全球 80% 到 90%,甚至 95% 的软件世界,都有 GUI(图形界面)。这是一个非常重要的事实。要真正让人们生活更容易,我们必须开发能够在 GUI 上完成日常任务的模型。

     

    所以 MacroHard 的目标,是模拟一家“输出是数字化成果”的公司。这是智能体的下一步:MacroHard 将实现跨桌面端的真正端到端编排,并将带来巨大的经济繁荣。

     

    同时,马斯克把 MacroHard 的意义抬到“人类仿真”的高度:

     

    MacroHard 这个项目,随着时间推移,可能会成为我们最重要的项目。

    我们讨论的是:对整家人类公司进行仿真。

     

    理论上完全有可能完整仿真任何一家“输出是数字化产物”的公司。这将开启一个繁荣时代,其程度可能是我们现在几乎无法想象的。

     

    基础设施:xAI 真正的护城河

     

    在 xAI,基础设施不是“后台部门”,而是以上所有激进判断能不能落地的前提。ML 基础设施团队负责搭建公司的训练、推理以及整套工具链系统。用他们自己的话说:站在软件工程师视角,这可能是你能做的最酷的一类系统。

     

    最典型的例子发生在 Grok 3 的训练上。当时,xAI 已经拿到 10 万张 H100,硬件都交付到位,但软件并没有真正准备好。团队原本以为系统能跑,结果规模一拉到 3 万卡,现实给了一个很明确的反馈:系统跑不起来。问题不是某一个 bug,而是数据中心里的“意外”太多:交换机抖动、链路抖动、交换机宕机、GPU 频繁损坏、数值不稳定……这些都不可能提前枚举完。但目标只有一个:让 10 万张 H100 像一个整体一样工作。

     

    一次训练 step 可能只有 5 秒:每 5 秒往前推一步,但这 5 秒里什么都可能发生。所以系统必须做到:意外不断出现也能自动恢复、持续推进,而不是一出问题就停下来等人来救。

     

    这种问题在别的地方也很难遇到。不是工程师不够聪明,而是很少有人同时拥有这种规模的算力、以及这种密度的人才。当时整个预训练团队大约 15 人,真正负责训练系统的可能只有 7 人,但他们刻意维持了这种“人才密度”,而不是靠堆人数去堆规模,最终靠这支小团队完成了 Grok3 的训练。

     

    英伟达 CEO 黄仁勋在多次采访中说过一句评价:在把 AI 算力上线这件事上,没有人比 xAI 更快。

     

    随后,RL 与推理团队接力。这个团队负责在地球上、以及很快可能在太空中,大规模运行训练任务和生产推理系统,目标很直接:把系统从 10 万张芯片扩展到数百万张芯片,并且让它对已知和未知的硬件故障都具备韧性。

     

    目前他们的成果都汇聚到了孟菲斯的数据中心里:xAI 已经建起了全球规模最大的 AI 训练集群之一,而且仍在扩张——第一阶段是 33 万张 GB300,接下来还将再增加 22 万张 GB300。

     

    显然,想要最好的模型,必须有大规模训练算力,这一点是绝对基础。 

     

    而在这场 all-hands 的最后,马斯克把这个逻辑推到了一个几乎只存在于科幻里的地方。如果地球已经装不下这些算力了,那下一步呢?答案是:月球。

     

    马斯克认为,要真正理解宇宙,最终必须离开地球去探索,而这正是 SpaceX 与 xAI 合并到一起的动机:加速人类理解宇宙的未来,把意识的光延伸到群星之间。

     

    从能源的角度看,他给了一个非常极端的对比:今天整个人类文明,使用的只是地球可用能量的 1% 左右。而如果人类哪怕只想用到太阳能量的百万分之一,那也是现在文明能耗的一百万倍。

     

    问题在于:你在地球上,根本不可能拿到那样的能量。地球在整个太阳系里,只是一粒“极小的尘埃”。太阳占了太阳系 99.8% 的质量,如果不走出地球,你几乎不可能对太阳能量的利用产生任何实质性的提升。

     

    所以在他看来,下一步不是“更大的地球数据中心”,而是“离开地球的数据中心”。先把数据中心送上地球轨道;再往后,就把制造和发射搬到月球——在月球上建工厂生产 AI 卫星,再用质量驱动器(mass driver)把它们一颗接一颗“弹射”到深空,把算力扩展到地球根本承载不了的规模。

     

    参考链接:

    https://www.youtube.com/watch?v=aOVnB88Cd1A

    https://techcrunch.com/2026/02/11/senior-engineers-including-co-founders-exit-xai-amid-controversy/

    就是我自己开发了一个看热榜的网站,然后功能实用性也还可以。
    但是连着好几个月了,访问数据一直卡在日均几百 UV,他就很稳定,一点不增长。想知道除了说去流量大的网站付费打广告之外,有没有别的方式说增加网站流量的,或者说网站里设置什么东西可以改善。

    在可观测性场景中,Elasticsearch 常受限于写入性能与高昂成本。在《可观测性方案怎么选?SelectDB vs Elasticsearch vs ClickHouse》一文中提到, 在云上日志服务中,SelectDB 相比 Elasticsearch 展现出明显的性能和成本优势。为进一步探索,本文通过基准测试对比二者表现,验证 SelectDB 在日志场景下性能与成本上的显著优势。1、基准目标和方法本次测试的目的是在可观测性场景下公平比较 SelectDB 和 Elasticsearch 的实际性能和成本,并为用户提供参考数据。为尽可能做到真实和公平,我们设计了如下对比测试:测试环境:使用 腾讯云 Elasticsearch 和 SelectDB Cloud 进行测试,未进行任何针对性调优。测试数据:使用 Elasticsearch 的官方性能测试集http logs,以确保测试中立性(实际更偏向 Elasticsearch)。测试内容:写入性能、查询性能、存储空间和成本的比较,这些是可观测性场景中用户最关心的指标。测试方法:第一阶段比较相同资源下的性能第二阶段比较支持相同负载所需的成本。第二阶段超越了传统的性能测试,以验证性能优势是否能在实际用户需求中转化为成本优势,而不仅仅是一种推断。2、相同资源下的性能比较在测试的第一阶段,比较相同配置下 Elasticsearch 和 SelectDB 的性能和成本。第一步:Elasticsearch 和 SelectDB 分别购买具有相同配置(48vCPU、348GB RAM)的集群,成本分别为 18.83 元/小时 和 16.95 元/小时。(1)腾讯云 Elasticsearch(48c) 费用:
    图片
    (2)SelectDB Cloud(48c) 费用:
    图片
    第二步:在 Elasticsearch 中创建索引,并在 SelectDB Cloud 中创建表。为确保公平性,两个系统使用相同的模式,包括字段类型、索引类型、共享/分片数量等。需要注意的是,Elasticsearch 的索引大致对应于 SelectDB 的表。第三步:将相同的 HTTP 日志数据集导入到 Elasticsearch 和 SelectDB Cloud。Elasticsearch 耗时 225 秒,而 SelectDB Cloud 仅需 69 秒。SelectDB Cloud 比 Elasticsearch 快 3.3 倍。第四步:分别在 Elasticsearch 和 SelectDB Cloud 中运行 HTTP 日志测试集的查询。Elasticsearch 中的首次运行(冷查询)耗时 2.049 秒,第二次运行(热启动)耗时 1.691 秒,SelectDB Cloud 中的首次运行(冷查询)耗时 0.599 秒,第二次运行(热启动)耗时 0.52 秒。SelectDB Cloud 在冷查询和热启动时的速度均比 Elasticsearch 快 3 倍以上。第五步:分别获取 Elasticsearch 和 SelectDB Cloud 的存储空间使用情况。Elasticsearch 的存储空间使用量为 12.8GB,而 SelectDB Cloud 的存储空间使用量为 3.3GB。与 Elasticsearch 相比,SelectDB Cloud 的存储空间减少了 75%。通过本次测试可以看出,在相同配置下,SelectDB Cloud 的数据导入性能比 Elasticsearch 快 3.3 倍,查询性能快 3 倍以上,存储空间减少 75%。这意味着,在相同配置下,SelectDB Cloud 的用户将比使用 Elasticsearch 的用户获得数倍的性能提升。在可观测性场景下,用户更关心相同负载和性能下能否真正降低成本。因此,接下来的测试将验证 SelectDB Cloud 的性能优势能转化为多大的实际成本优势。3、成本突破:从性能领先到真正的成本降低在测试的第二阶段,SelectDB Cloud 将缩小至其原始规模的 1/6,与使用 6 倍资源的 Elasticsearch 进行性能比较。第一步:将 SelectDB Cloud 48vCPU 的集群规模缩减至 8vCPU,成本也大幅降低至 2.93 元/小时。
    图片
    第二步:在仅有 8vCPU 的 SelectDB Cloud 集群中创建相同的表。第三步:将相同的 HTTP 日志数据集导入到具有 8vCPU 的 SelectDB Cloud 集群中。这一过程耗时 140 秒,速度仍比 48vCPU 的 Elasticsearch 云集群快 1.6 倍。第四步:在 8vCPU 的 SelectDB Cloud 集群中运行来自 HTTP 日志测试集的查询。第一次运行(冷查询)耗时 1.389 秒,第二次运行(热启动)耗时 1.246 秒。8 vCPU 的 SelectDB Cloud 在冷查询时比 48vCPU 的 Elasticsearch 还快 47.5%。在第五步中,获取 8vCPU SelectDB Cloud 集群中的存储空间使用情况。SelectDB Cloud 的存储空间使用量仍为 3.3GB,比 Elasticsearch 低 75%。通过本次测试可以看出,在将 SelectDB Cloud 的资源缩减至 Elasticsearch 的 1/6 后,成本仅为 2.93 元/小时,比 Elasticsearch 的 18.83 元/小时 节省了 85% 的费用。尽管成本大幅降低,但性能仍保持显著优势:数据导入性能快 1.6 倍,冷查询性能快 47.5%,存储空间减少 75%。这意味着,对于从 Elasticsearch 切换到 SelectDB Cloud 以支持相同负载的用户来说,SelectDB Cloud 将实现实打实的 83% 成本降低,并提供更好的性能。4、为什么 SelectDB 能如此显著地降低成本SelectDB Cloud 出色的性能和成本优势得益于针对可观测性场景进行的广泛优化。SelectDB 针对日志场景优化倒排索引降低空间占用,数据和索引均采用列式存储,并使用 ZSTD 压缩算法,实现了高压缩率,可大幅减少存储空间。此外,SelectDB 将所有数据存储在低成本的对象存储中,热数据在 SSD 等本地磁盘上进行缓存和加速,利用可观测性数据冷热分层的特点降低存储空间单价。这些特性使 SelectDB 的存储成本比 Elasticsearch 降低了接近一个数量级。 SelectDB 采用存储与计算分离的架构。在写入数据时,计算层仅存在一次计算消耗,避免了 Elasticsearch 存储与计算一体化架构所需的多副本。此外,SelectDB 为日志和追踪等时间序列数据设计了时间序列压缩策略,将后台数据合并的写入放大从 3 降低到 1,大幅节省计算和 IO 资源消耗。SelectDB 专为实时分析而设计,这意味着它支持高性能聚合操作,这些操作常用于可观测性领域。在搜索查询方面,SelectDB 以一种针对日志搜索和topn查询(如SELECT * FROM log WHERE message MATCH 'error' ORDER BY time DESC LIMIT 100)进行优化的方式实现了倒排索引。结果是,SelectDB 在搜索查询方面速度快 2 倍,在聚合查询方面速度快 10 倍。结论在 HTTP 日志基准工作负载下,SelectDB Cloud 与 Elasticsearch 相比实现了 83%的成本降低。在实际生产环境中,许多用户已经在 PB 规模下用 SelectDB 或 Apache Doris 取代了 Elasticsearch,实现了显著的成本节约。您可以阅读来自网易、MiniMax、领创集团、中信信用卡中心的用户故事来了解更多。我们建议您根据实际业务场景设计测试,亲自验证 SelectDB 在成本与性能上的表现。欢迎申请 SelectDB Cloud 试用验证。