2026年1月

Apifox 新版本上线啦!

看看本次版本更新主要涵盖的重点内容,有没有你所关注的功能特性:

  • 支持创建 MCP Client 以调试 MCP Server
  • 支持创建「测试套件」
  • 测试报告全面重构,支持结构化展示
  • 调试能力持续升级

    • 支持查看 HTTP 版本、TLS 协议等网络信息
    • array 类型参数的子元素支持直接选择枚举值
    • 调试 SSE 接口时,支持 \r\n 换行符
  • 支持导入 Hoppscotch 的 Collection
  • 优化邀请他人加入项目的流程
  • 用户反馈优化

    • 解决 MongoDB 数据库的密码包含特殊字符 % 时无法连接成功的问题
    • 解决绑定了手机号的用户无法通过“忘记密码”功能重置密码的问题

将 Apifox 更新至最新版,一起开启全新体验吧!

支持创建 MCP Client 以调试 MCP Server

Apifox 升级后,支持创建 MCP Client,开发者可以像调试 API 一样,直接调试 MCP Server 的ToolsResourcesPrompts。同时支持STDIOStreamable HTTP 协议,并可自动配置 OAuth 2.0 认证流程,极大简化连接与认证流程,全面提升 AI Agent 的开发与调试效率。

更多关于 MCP 的内容,可以前往 帮助文档查看。

支持创建 MCP Client 以调试 MCP Server

支持创建「测试套件」

Apifox 推出了「测试套件」功能,支持添加单接口用例和场景用例,并可在「静态」与「动态」两种模式间切换:

  • 静态模式用于精确指定需要执行的测试项,内容不会变动,且支持灵活调整测试步骤的顺序。
  • 动态模式可通过规则自动筛选需执行的测试项。每次运行时,系统会实时扫描项目,将所有符合条件的最新用例纳入执行。此模式下,仅可整体删除或修改过滤条件,无法单独删除组内的某个动态项。

场景用例侧重于测试流程的编排,测试套件则聚焦于灵活高效的测试执行,两者并非互相替代,而是分层协作,面向不同的使用场景,结合使用可以满足自动化测试的多样化需求。

更多关于测试套件的具体教程,可以查看往期内容《 测试用例越堆越多?用 Apifox 测试套件让自动化回归更易维护》。

支持创建「测试套件」

测试报告全面重构,支持结构化展示

最新版本的 Apifox 对测试报告界面进行了全面重构,新版测试报告支持结构化展示所有测试步骤,让测试结果的层次关系更加清晰明了。用户可以快速定位每个测试步骤的执行情况和结果,从而更高效地分析测试问题,提升测试结果的可读性和分析效率。

测试报告全面重构,支持结构化展示

调试能力持续升级

支持查看 HTTP 版本、TLS 协议等网络信息

更新 Apifox 后,开发者在调试接口时可直接查看 HTTP 版本、TLS 协议等详细网络信息,从而快速掌握接口请求的通信细节,有助于进行更精确的问题定位和性能分析。

同时,支持查看更详细的响应大小信息,包括 Body 和 Header 的大小,以及压缩前后的 Body 大小,便于判断 gzip 等压缩功能是否正常工作。

支持查看 HTTP 版本、TLS 协议等网络信息

array 类型参数的子元素支持直接选择枚举值

调试接口时,如果 array 类型参数的子元素包含枚举值,用户可直接从列表中选择,无需手动输入,简化了配置流程,提升参数配置的便捷性与准确性,使接口调试更加高效流畅。

array 类型参数的子元素支持直接选择枚举值

调试 SSE 接口时,支持 \r\n 换行符

Apifox 优化了 SSE 接口的调试体验。SSE 规范采用 \n\n 作为标准换行符,但一些实际业务中常用 \r\n (Windows 换行符) 进行分隔。Apifox 现已兼容并正确解析 \r\n 换行符,确保 SSE 流式数据能够以标准或非标准格式都能正确显示,帮助开发者更高效、准确地调试和验证 SSE 接口响应内容。

支持导入 Hoppscotch 的 Collection

Apifox 现已支持导入 Hoppscotch Collection 数据,帮助团队更便捷地将 Hoppscotch 项目迁移到 Apifox,进一步扩展了数据迁移的兼容性,降低迁移成本,提升团队协作的灵活性。

支持导入 Hoppscotch 的 Collection

优化邀请他人加入项目的流程

Apifox 对项目成员邀请流程进行了优化,除了链接邀请和邮箱邀请外,还支持直接从团队成员列表中选择成员加入项目,并可在邀请时同步设置项目权限,大幅简化了成员管理流程,让团队协作配置更加便捷高效。

优化邀请他人加入项目的流程

用户反馈优化

解决 MongoDB 数据库的密码包含特殊字符%时无法连接成功的问题

根据用户反馈,我们已修复 MongoDB 数据库连接中存在的问题:当数据库密码包含特殊字符 % 时,Apifox 现能正确处理并成功建立连接,进一步提升了数据库连接功能的稳定性和兼容性。

解决绑定了手机号的用户无法通过“忘记密码”功能重置密码的问题

现在通过"忘记密码"功能可以正常重置密码,确保用户在需要时能顺利找回账号访问权限,提升账户安全管理功能的完整性与可用性。

了解更多

当然,Apifox 产品团队为大家带来的新功能远不止以上这些:

  • 优化了前后置操作的界面
  • 优化了测试报告列表,支持结构化展示、筛选
  • 支持复制测试套件的分享链接
  • 支持调整测试套件静态步骤内资源的顺序
  • 导入 OpenAPI/Swagger 数据时,支持 Query 类型的 HTTP 方法和 additionalOperation
  • 优化了变量预览弹窗的触发时间,让其有一个合理的延迟
  • 在付费页进行续费时,逻辑更合理与友好
  • 解决在接口返回的响应数据上点击右键,没有 Copy JSONPath 等功能的问题
  • 解决当根目录的可见性为内部时,WebSocket 接口仍被发布到公开在线文档的问题
  • 解决未绑定支付方式的团队无法被正确转入组织的问题

除了新增功能,我们也对产品细节和使用体验进行了优化,具体修改内容可点击「阅读原文」前往 Apifox 更新日志查看,有任何问题欢迎在Apifox 用户群与我们交流沟通。

同时,Apifox 提供企业私有化部署版本,通过本地化部署、客制化服务,协助企业进一步提升研发团队效能。

欢迎各位用户对 Apifox 继续提出使用反馈和优化意见,我们会持续优化更新,致力于为用户提供更优秀的产品功能和更极致的使用体验!

从 Chat 到 Action,AI 正在接管我们的屏幕。但在一周 8 万 Star 的狂欢背后,爆火的应用与脆弱的安全性之间,正横亘着一道待解的基础设施鸿沟。
图片

流量高地与范式转移:从“对话”到“实战”

这几天 Clawdbot 的出圈速度很夸张。社区里最直观的信号是 GitHub star 曲线在短时间内冲到数万量级,很多讨论甚至直接把它当作“2026 开源增长最快的现象级项目之一”。 更戏剧化的是,它还带出了一个“周边行情”:大量开发者开始用 Mac mini 这类小主机来常驻运行,从而实现一个 7×24h 永不下班的“核动力牛马”,甚至出现“下单截图刷屏”“卖断货”的情况。
图片
Clawdbot 现在官方名字是 Moltbot,比较有意思的是,改名的原因是因为 Anthropic 认为 Clawdbot 这个名字太容易被市场误解为Claude Code的延展产品,所以提出了抗议,创始人“被迫”宣布改名。
图片
它的定位非常清晰:一个你自己运行的个人 AI 助手,驻扎在你已经在用的聊天渠道里,比如 WhatsApp、 Telegram、 Slack、 Discord、 Google Chat、 Signal、 iMessage、 Microsoft Teams、 WebChat 等,同时支持在 macOS、iOS、Android 上交互,并提供一个可控的 Canvas 界面。 这套“入口在聊天里,执行在你自己的环境里”的组合,就这样魔幻而又切切实实的爆火了。为什么这类东西会一波接一波地爆火?从最近一段时间的产品形态看,确实有个明显的风向在强化:大众的注意力正在从“对话型”迁移到“实操型”。对话给的是答案,实操给的是结果。对绝大多数人来说,后者更像他们心里对“AI 助理”的默认想象,这一点在 Clawdbot 的传播中被放大得很充分。

沸腾后的冷思考:是技术奇点,还是“时势英雄”?

不过这里也值得降降温。爆火当然意味着能力点戳中了人心,但它同样蕴含着几件事叠加:创作者本身的影响力与信用积累,以及社交平台的流量机制、AI时代的掉队焦虑,共同把某个叙事推到最大音量。你不需要把每一次“现象级”都理解成行业天翻地覆。更像是时势推着一个正确方向的样品突然被看见了,然后所有人的情绪一起涌上来。再说体验层面的“落差”。很多人上手后会发现,它没有想象中那么万能,这其实并不意外。因为这类个人 Agent 往往把“连接器很多”“能动手”放在第一优先级,工程细节与产品打磨会滞后,早期 UI 小问题、流程不顺手、边界场景翻车都很常见。更关键的一点在成本。只要你把它当作“经常在线的执行型助理”,模型调用和工具链路的成本就会从偶发费用变成持续开销,近几天已经陆续看到网上有人晒图仅仅使用十几个小时,就已经消耗了上百美金的token。很多用户会自然滑向一种状态:好玩大于好用,体验大于实用。真正值得认真讨论的,是它爆火后暴露出来的“安全现实”。Clawdbot 的卖点之一就是更本地化,更可控,更接近你的真实环境,它也确实会涉及对本地 shell、文件系统、浏览器等能力的调用与编排。 这让它强大,也让它变得危险。由于它拥有极高的系统权限。大部分用户担心 AI 误操作导致主力机数据受损,或是隐私信息泄露,被迫选择了“物理隔离”——用一台专门的硬件来承载这个不确定的“执行者”。这也解释了另一个看似荒诞的现象:Clawdbot 带动了 Mac mini 等小主机被抢购。很多人把它解读为“性能需求”,但更底层的心理动因往往是“把东西放在自己手里更安心”。 你会发现,这里面其实同时包含了信任与不信任。信任的是我愿意让它替我做事,不信任的是我不想把自己的数据和权限直接丢进不可控的黑盒里。

数据安全是“执行权”的护城河

同样,GUI Agent(具备图形界面操作能力的智能体)作为一个实操型的技术路线,也具备巨大的想象和成长空间。例如前段时间爆火出圈的豆包手机、Open-AutoGLM 等,它可以完成跨 App 的复杂长链路任务,但其权限的边界与数据安全的保障,将决定它是“神助攻”还是“定时炸弹”。这正是灵臂 Lybic 的出发点之一。GUI Agent 之所以想象空间更大,因为它天然能覆盖那些没有标准 API 的存量软件和复杂流程。可它也天然更危险,因为它同样处在高权限的边缘,出错时的破坏半径更接近真实世界。把这一类能力推向大众之前,一个更稳妥的路径是先把“执行空间”变成默认护栏。这也是 Lybic 想做的事之一。我们把“能不能做”之外的三件事放在同等重要的位置:隔离、可见、可止损。让模型或 Agent 在云端沙盒里执行 GUI 任务,你可以实时看到它在做什么,发现不对可以随时人工接管,任务结束可以销毁环境。这样一来,创新速度可以继续加快,试错成本被关在可控范围里,真实设备和真实数据少承担一些不必要的风险。

写在最后

Clawdbot 的爆火更像一个信号:实操型 AI 正在成为默认的大众期待。然而技术的热度终会回归工程的理性,接下来决定它们能不能长期留下来的,往往不是演示有多酷,而是执行边界有没有被认真设计。我们更愿意把这当作一个行业共同要补的基础课。让 AI 去做事之前,先给它一个合适的“房间”,再谈把它放进真实世界。

附macOS部署教程

首先打开终端运行一串神秘小代码(前提是确保node.js版本大于22)
curl -fsSL https://molt.bot/install.sh | bash -s -- --install-method git

静待下载安装完毕后,继续运行
moltbot onboard --install-daemon
然后就会看到如下界面,那么恭喜你已经成功部署了Moltbot!教程到此结束(bushi)
图片
言归正传,官方在这里也是做出了风险提示。正如上文中所说,moltbot拥有着极大的系统权限,(同时也意味着极大的风险,强烈建议使用备用机安装),所以这里选 yes,因为不选 yes 没法进行下一步,没错官方就是这么霸道。接下来根据界面提示,选择自己中意的大模型接入,我们这里选择了智谱的GLM 4.7。API key可以到对应的官网去购买/申请。
图片
鉴于我们是本地尝鲜版,为了简化流程,这里选择跳过。后续我们也会尝试去适配飞书或QQ。
图片
选择想装的skill,空格进行选中,回车确认后会自动安装
图片
再之后是各种接口设置,偷懒可以都跳过
图片
接下来是hooks设置,可以按需选择,三个选项对应的分别是:boot-md每次程序启动时,自动读取并执行一个叫 BOOT.md 的文件。用途:如果你有一些每次都要 AI 记住的规则、或者每次都要运行的初始化环境命令,可以写在 BOOT.md 里。command-logger命令日志记录器。用途:它会把你输入的所有指令和 AI 的反馈记录下来。建议勾选,万一 AI 乱改了代码,你可以翻日志找回记录。session-memory会话记忆。用途:让 AI 记住你上一次聊了什么。如果不选,它可能每次运行都是“断片”状态,不记得之前的上下文。
图片
最后选择在哪里运行
图片
Hatch in TUI (recommended)什么是 TUI? 它的全称是 Terminal User Interface。效果:就在你现在的这个黑色窗口里直接跳出一个比较漂亮的对话框。优点:速度最快,不用切换窗口,很有极客感觉。Open the Web UI效果:它会启动一个本地服务器,并在你的浏览器(如 Chrome 或 Safari)里打开一个网页版界面。优点:界面更像 ChatGPT,推荐选这个。Do this later效果:结束配置,回到命令行。用途:如果你现在只想装好,还没打算立刻开始聊天,选这个。选择 Open the Web UI 后,会自动跳转网页如下
图片
现在恭喜你真正完成配置并可以开始使用了!

代码调试是开发者日常工作中高频且核心的环节,很多开发者花费数小时甚至通宵排查一个简单 Bug,核心问题并非技术不足,而是陷入了「调试思路混乱、工具使用不当、日志记录不全」的坑。这份手册结合前后端通用调试场景,从日志分析、断点调试、常见坑点规避三个维度,拆解调试的核心逻辑与实操技巧,附具体代码示例与工具配置,帮你快速定位 90% 的开发 Bug,告别无效调试。

一、日志分析:打好调试基础,让 Bug 有迹可循

日志是调试的「第一手证据」,但多数开发者仅用 console.log/System.out.println 简单输出,导致日志信息残缺,无法定位问题。高质量的日志记录,能让 60% 的 Bug 在无需断点的情况下快速解决。

1. 日志记录核心原则:5 要素缺一不可

有效的日志需包含「时间戳、模块 / 文件、级别、上下文、具体信息」,避免无意义的日志输出。
前端示例(JavaScript/TypeScript):

// 错误示范:仅输出值,无上下文
console.log(userInfo); 

// 正确示范:封装日志函数,包含核心要素
function log(level, module, message, context = {}) {
  const timestamp = new Date().toISOString();
  console.log(`[${timestamp}] [${level}] [${module}]: ${message}`, context);
}

// 实际使用:定位用户信息获取异常
try {
  const userInfo = await getUserInfo(userId);
  log('INFO', 'user-api', '用户信息获取成功', { userId, userInfo: userInfo.id });
} catch (error) {
  // 错误日志包含错误栈、请求参数,便于定位
  log('ERROR', 'user-api', '用户信息获取失败', { userId, error: error.message, stack: error.stack });
}

后端示例(Python):

import logging
import time

# 配置日志格式:包含时间、模块、级别、信息
logging.basicConfig(
    format='[%(asctime)s] [%(levelname)s] [%(module)s]: %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S',
    level=logging.INFO
)
logger = logging.getLogger(__name__)

# 实际使用:定位数据查询异常
def get_user_data(user_id):
    try:
        logger.info(f"开始查询用户数据", extra={"user_id": user_id})
        # 模拟数据库查询
        user_data = db.query("SELECT * FROM users WHERE id = %s", user_id)
        logger.info(f"用户数据查询完成", extra={"user_id": user_id, "data_count": len(user_data)})
        return user_data
    except Exception as e:
        # 错误日志包含异常信息和上下文
        logger.error(f"用户数据查询失败", extra={"user_id": user_id, "error": str(e)})
        raise

2. 日志级别合理使用,避免日志泛滥

级别使用场景示例
DEBUG开发调试,输出详细流程 / 变量接口请求参数、函数内部变量
INFO正常业务流程记录接口调用成功、任务执行完成
WARNING非致命异常,需关注但不影响运行配置缺失、数据格式不规范
ERROR致命异常,功能无法正常执行接口调用失败、数据库查询异常
CRITICAL系统级异常,影响整体运行数据库连接失败、服务端口被占用

3. 避坑点:日志不要泄露敏感信息

调试时容易将用户密码、Token、手机号等敏感信息写入日志,需在日志输出前过滤:

// 过滤敏感信息函数
function filterSensitiveData(data) {
  const sensitiveKeys = ['password', 'token', 'phone', 'idCard'];
  const result = { ...data };
  sensitiveKeys.forEach(key => {
    if (result[key]) result[key] = '***';
  });
  return result;
}

// 使用:输出用户信息时过滤敏感字段
log('INFO', 'user-login', '用户登录成功', filterSensitiveData(userInfo));

二、断点调试:精准定位问题,替代无脑打印日志

断点调试是解决复杂 Bug 的核心手段,比反复加 console.log 高效 10 倍,前端 / 后端均有成熟的调试工具,关键是掌握「断点设置技巧」和「调试流程」。

1. 前端断点调试(VS Code + Chrome)

核心步骤:
配置 launch.json(VS Code 中):

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "调试前端项目",
      "url": "http://localhost:3000", // 项目启动地址
      "webRoot": "${workspaceFolder}/src",
      "sourceMaps": true // 开启源码映射,便于调试TS/打包后的代码
    }
  ]
}

点设置技巧:
条件断点:右键断点 → 设置条件(如 userId === 10086),仅当条件满足时触发,避免无关断点干扰;
日志断点:不暂停程序,仅输出日志(替代 console.log),适合调试生产环境 / 高频执行的代码;
命中次数断点:设置断点触发的次数(如第 5 次执行时暂停),定位循环中的偶发 Bug。

调试面板核心操作:
步进(Step Over):执行下一行代码,不进入函数;
步入(Step Into):进入当前行调用的函数内部;
步出(Step Out):从当前函数跳出,回到调用处;
监视(Watch):添加变量 / 表达式,实时查看值的变化(如 userInfo.name、list.length > 0)。

避坑点:
调试打包后的前端代码时,需确保开启 sourceMap,否则断点会定位到压缩后的代码,无法调试;
避免在 setTimeout/Promise 等异步代码中盲目断点,需在异步回调内设置断点,或使用「异步堆栈跟踪」(Chrome DevTools → Settings → Experiments → Async stack traces)。

2. 后端断点调试(以 Java + IDEA / Python + VS Code 为例)

Java(IDEA):
启动调试模式:点击运行按钮旁的「调试」按钮,或右键代码 → Debug;
关键技巧:
远程调试:配置 -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 启动参数,本地 IDEA 连接远程端口,调试线上 / 测试环境 Bug;
异常断点:Run → View Breakpoints → + → Java Exception Breakpoints,选择具体异常(如 NullPointerException),程序抛出该异常时自动暂停,快速定位空指针等常见 Bug。
Python(VS Code):
配置 launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "调试Python脚本",
      "type": "python",
      "request": "launch",
      "program": "${file}", // 当前打开的脚本
      "args": ["--env", "dev"], // 脚本入参
      "justMyCode": false // 调试第三方库代码(如需定位依赖包问题)
    }
  ]
}

避坑点:
Python 调试时,justMyCode 默认开启,会跳过第三方库代码,如需调试依赖包问题需关闭;
调试多进程 / 多线程代码时,需开启「线程 / 进程调试」,否则仅能调试主进程 / 主线程。

三、常见调试坑点与解决方案

1:环境不一致导致的 Bug(本地正常,测试 / 生产报错)

原因:依赖版本、配置文件、环境变量、时区 / 编码等不一致;
解决方案:
记录本地环境信息(npm list/pip freeze/java -version),与测试 / 生产环境对比;
使用容器化(Docker)统一环境,确保本地与线上环境一致;
日志中记录环境信息(如 process.env.NODE_ENV/System.getProperty("env")),便于排查环境相关问题。

2:并发 / 异步导致的偶发 Bug

原因:多线程 / 多进程竞争资源、异步代码执行顺序不可控;
解决方案:
日志中添加「线程 ID / 请求 ID」,追踪同一请求的所有日志(前端:requestId;后端:Thread.currentThread().getId());
断点调试时,锁定线程(Java)/ 使用「单线程模式」(前端),复现并发问题;
避免在异步代码中修改共享变量,使用锁 / 原子操作 / 不可变数据结构。

3:数据类型 / 边界值导致的 Bug

示例:前端传参为字符串 '123',后端按数字 123 处理,导致比较失败;循环中未处理空数组 / 空对象;
解决方案:
调试时重点检查变量类型(前端:typeof/Object.prototype.toString.call();后端:instanceof/type());

# Python 防御性判断示例
def process_data(data):
    if not data: # 处理 null/空列表/空字典
        logger.warning("数据为空,跳过处理")
        return []
    # 后续逻辑

4:调试后忘记移除调试代码

后果:console.log 泄露敏感信息、断点影响性能、调试代码导致生产环境报错;
解决方案:
使用 ESLint 规则(no-console)/IDE 检查,提交代码前检测调试代码;
后端使用日志框架的「环境级别控制」,生产环境关闭 DEBUG 级别日志;
使用 Git 钩子(pre-commit),自动检测并提示移除调试代码。

四、调试效率提升:工具与工作流搭配

除了基础的日志和断点调试,搭配以下工具能进一步提升调试效率:

前端:

Redux DevTools:调试状态管理,回溯状态变化;
Network Inspector(Chrome):查看接口请求 / 响应,模拟请求重放,定位接口参数 / 返回值问题;
Vue DevTools/React DevTools:调试框架专属状态、组件 props/state。

后端:

Postman/Apifox:调试接口,模拟不同参数请求,定位接口逻辑问题;
jstack/jmap(Java):分析线程死锁、内存泄漏;
pdb(Python):命令行断点调试,适配无图形界面的服务器环境;

通用:

Fiddler/Charles:抓包工具,调试前后端交互、第三方接口问题;
Diff Tool(VS Code/IDEA):对比代码版本,定位 Bug 引入的提交记录。

最后:调试的核心是「思路」,提效的核心是「工具」

代码调试的本质,是通过「日志 + 断点 + 工具」还原 Bug 发生的完整场景,找到问题的根本原因,而非临时修复表面现象。掌握调试技巧的同时,高效找到适配的调试工具、提效资源,也能大幅减少调试外的时间消耗。

我平时除了使用上述调试工具,还会在 https://bbab.net/ 这个专为数字工作者打造的创作者导航站中,找技术创作相关的资源 —— 比如调试完成后,写技术教程、做调试技巧分享所需的 AI 创作工具、排版工具、效率办公资源,它覆盖 AI 创作、内容创作、效率办公等领域,所有资源均经过精选,不用全网翻找,省出更多时间专注于代码开发与技术创作。

调试能力是开发者的核心竞争力之一,建议大家在日常开发中刻意练习调试思路,总结常见 Bug 的排查方法,形成自己的调试工作流。记住:好的调试习惯,能让你少走 80% 的弯路,把时间留给更有价值的代码设计与功能实现。

核心要点总结

日志记录需包含「时间戳、模块、级别、上下文、具体信息」5 要素,避免无意义输出和敏感信息泄露;
断点调试优先使用「条件断点 / 日志断点」,减少无关干扰,异步 / 并发代码需针对性设置断点;
规避环境不一致、并发、边界值等常见调试坑点,搭配专业工具提升调试效率;
调试后及时清理调试代码,通过规范和工具避免生产环境问题。

【近些年,随着AI大模型的爆发式增长,千卡级AI集群成为常态,推动服务器功率密度持续攀升,服务器传统粗放式的功耗管理已无法满足能效要求,为解决数据中心的能耗管理问题,OurBMC社区及其理事单位飞腾信息技术有限公司在第三届开放原子大赛中设置"基于BMC的整机功耗智能管理"赛题,旨在探索BMC管理系统部署轻量级AI模型的技术路径,促进AI在OurBMC开源项目中的应用,为数据中心提供可落地的整机功耗智能管理方案。】

大赛自启动以来,汇聚了来自全国各地的78个队伍的130多位精英选手。选手们携数十份精彩作品,投身这场为期四个月的激烈实战竞技中。在此期间,各参赛队伍不仅积累了宝贵的实践经验,也深化了对比赛的理解与感悟。本期,社区特别邀请获奖企业团队分享 「走进OurBMC第三届开放原子大赛,共同践行开放包容、共创共赢的开源精神」,让更多人领略开源的魅力,感受技术的磅礴力量。

PART.01

1昆仑太科.jpg

参赛背景

团队长期致力于OpenBMC架构与嵌入式开发,在服务器温控场景中发现传统PID控制存在功耗与散热的平衡难题。通过OurBMC社区赛事通知渠道了解到本次比赛,希望以赛事为契机,将AI算法与BMC硬件管控深度融合,验证智能温控方案的可行性,同时借助开源平台与行业伙伴交流技术思路,推动BMC技术栈的创新升级。

核心方案

本项目聚焦于服务器智能温控系统中的单变量功耗智能管理,基于开源项目openbmc-OurBMC-24.12的phosphor-pid-control库基础上,引入AI驱动的动态预测与决策机制。项目基于BMC平台,深度集成了一套完全由C++实现、以梯度提升决策树(GBDT)为预测核心、以近端策略优化(PPO)为决策核心的自适应闭环控制系统。

数据采集采用双阶段策略:快速降温阶段与低功耗稳态调控阶段,实现从异常响应到节能运行的平滑过渡。通过温度预测模型对未来温度趋势进行高精度预测,并结合PPO强化学习生成节能导向的风扇转速建议,在保障设备安全运行的前提下,显著降低系统整体功耗。

控制策略采用安全优先的融合机制:最终风扇转速控制值指令取AI建议值与超温保障输出值中的较大者,实现“安全兜底+智能节能”的双重目标。该方案在保障设备可靠性的前提下显著降低风扇功耗,有助于提升数据中心能效比(PUE),助力绿色计算。

参赛过程及心得

本次参赛面临组队分工与赛题技术融合的双重挑战,团队通过明确“真实环境搭建-相关传感器适配-算法开发-工程部署-测试验证”职责分工高效协作。在赛题解析中,攻克了AI模型轻量化适配BMC嵌入式环境的难题。同时,团队成员平衡工作与备赛时间,利用碎片化时段开展模型训练与代码调试,深刻体会到技术落地需兼顾创新与实用性,开源协作模式更能加速技术迭代与问题解决。

我对社区说

感谢OurBMC社区搭建的开源交流平台,让我们能够基于社区成熟的技术栈进行创新实践。开源生态是BMC技术发展的核心驱动力,它打破了技术壁垒,让开发者得以共享经验、协同攻坚。BMC技术栈正朝着智能化、轻量化方向演进,期待未来能与社区伙伴深化合作,在硬件管控、能效优化等场景探索更多技术方案,共同推动开源BMC生态的繁荣发展,为绿色数据中心建设贡献力量。

PART.02

2移动云硬件团队.jpg

参赛背景

作为OurBMC社区成员单位,我们通过社区获知本次大赛的相关信息,组队参加本次大赛主要基于以下几点考虑:首先想通过参加本次大赛了解目前业界对于服务器智能功耗管理的最新研究成果,拓展自己专业能力;其次是分享移动云在这方面的成果,期待评审老师和同行能对我们的方案提出宝贵的意见,助力我们在服务器智能功耗管理领域不断前进,迈出新的高度。

核心方案

本次获奖作品是“基于BMC的智能功耗管理-SFC调速方案”,其核心思想是通过BMC收集服务器的关键工况信息,离线训练工况识别模型和温度预测模型,然后将这两个模型内置到BMC系统中。在服务器工作时,首先BMC获取服务器的关键工况信息,通过工况识别模型识别当前服务器的运行工况;然后在通过温度预测模型,基于当前的服务器工况预测关键部件的温度变化;再基于预测的温度变化信息,提前响应风扇转速,在满足温度约束的条件下,通过BMC调节风扇转速达到整体功率最低。

参赛过程及心得

本次大赛在接到赛题后,基于移动云在服务器功耗管理上的积累,我们迅速组建了一只技术实力互补、充满活力的团队,团队成员间展现出极高的协同性,通过紧密无间的合作,共同投入到赛题的深入解析之中。针对赛题要求,我们认为智能功耗管理不能影响BMC其他的核心功能,因此模型的轻量化,功耗管理的冗余措施必不可少。基于此,团队通过细致的分析和思维的碰撞,成功攻克了模型轻量化、预测准确度等多个技术难题,成功构建了基于BMC的智能功耗管理方案。同时,我们也看到了其他参赛队伍的优秀作品,这些优秀作品为我们后续在服务器智能功耗管理领域的研究提供了宝贵的参考与启示。

我对社区说

感谢OurBMC社区提供了一个如此卓越的平台,众多主流厂商纷纷投身于OpenBMC的开发浪潮中,让固件开发者得以在平台上深入探索BMC领域的奥秘。在这里,我们热切的期望与国内BMC相关领域的厂商携手合作,携手推进国产BMC技术的持续创新,共通促进国产BMC生态的繁荣发展。最后祝愿OurBMC社区蓬勃发展,越办越好!

PART.03

3百敖BMC.jpg

参赛背景

通过OurBMC社区了解到本次比赛。本次竞赛课题聚焦前沿AI技术领域,极具创新性与前瞻性,激发了团队的浓厚兴趣。随着人工智能在各行业深度渗透,将AI能力融合进BMC软件,正成为推动系统智能化演进的重要方向。参赛不仅是对自身技术能力的一次锤炼,更是与行业同行交流互鉴、共同探索的宝贵机会。

核心方案

本方案基于LSTM时序预测模型构建了一套智能化自适应温控决策机制。该模型通过持续采集分析温度数据与风扇转速的关系趋势,识别其内在模式与长期依赖关系,实现对未来温度变化趋势的前瞻性预测,并输出与之相匹配的风扇转速预测。同时,系统通过专门的融合决策模块,对LSTM的预测结果与PID的控制指令进行同步的比较与评估,动态地进行智能权衡与选择,最终下发风扇转速控制指令。

在确保设备散热需求完全满足、系统安全稳定运行的前提下,该系统实现了从“被动响应式控温”到“主动优化式控温”的转变,通过预测与反馈的闭环优化,有效平滑能耗曲线,减少不必要的功耗波动,达成散热效能与能源效率的最优平衡。

参赛过程及心得

由于BMC软件”小而美”的特殊性,芯片计算能力有限,存储空间受限,如何持续更新智能预测模型并兼容现有控速方案是最大的困难。我们依靠明确的晚间协作时段与高效异步沟通,将项目经验转化为比赛优势。这段经历再次印证,清晰的技术权衡与坚定的工程落地能力,往往比单纯追求技术新颖更为重要。

我对社区说

OurBMC社区通过持续举办开源大赛,为行业搭建了宝贵的交流平台,也让我们能够更深入地洞察技术前沿、把握创新脉搏。对此我们深表感谢,并将一如既往支持社区发展,共同推动行业进步。

PART.04

4信工所.jpg

参赛背景

我们与OurBMC有不解之缘,从第一届比赛开始便持续关注相关赛事,但由于博士学业繁忙遗憾错过。本次第三届比赛以功耗管理为主题,与我们近期在服务器能效优化方面的研究高度契合,且相关成果已发表在计算机体系结构领域的顶级期刊。因此,我们非常希望借助本次比赛,向开源社区展示我们的研究方案与团队实践经验,促进互相交流与学习,为国产自主可控BMC固件的发展贡献力量。

核心方案

我们的作品名称是HyperBMC,“Hyper”寓意超越传统服务器管理范式,强调BMC不再只是远程管理芯片,而是服务器智能管理引擎。通过在BMC芯片上部署深度学习模型,动态刻画计算需求与散热能力之间的平衡关系,进而触发调控决策;同时结合主机CPU与BMC之间的带内通信机制,协同管理风扇转速与CPU频率,从而实现服务器的精细化、智能化的功耗管理,在提升能效的同时保障性能与稳定性。

参赛过程及心得

尽管我们在基于BMC的功耗管理方面有一定的积累,但是面向本次比赛仍然遇到了许多挑战。一方面是软件版本升级与适配问题。我们团队只有OpenBMC 2.8.0的开发经验,将OurBMC 24.12版本编译到现有的平台,并且将我们之前的成果迁移上来,面临着Linux内核升级和Yocto工具链变化等诸多问题。另一方面是在嵌入式上运行深度学习的挑战。我们之前的方案是在远程控制器上运行传统的机器学习模型,在此次比赛中,我们想要充分挖掘嵌入式设备的性能,不仅将智能决策卸载到BMC,并且在BMC上直接推理深度学习模型。

我对社区说

非常感谢OurBMC社区搭建了一个开放、公平且有影响力的技术交流平台,使得我们研究团队有机会将最新的研究成果与各位同行分享。希望OurBMC社区能继续推动BMC相关的开源实践与生态建设,让更多开发者、研究者参与进来,共同打造一个更智能、安全和绿色的算力基础设施技术体系。我们也期待未来能进一步与社区合作,共同探索BMC在更多场景下的应用与扩展。最后,感谢OurBMC社区长期以来在BMC自主可控道路上的贡献,祝愿OurBMC系列比赛越办越好。

PART.05

5创新无限管芯微.jpg

参赛背景

管芯微是最早一批申请加入OurBMC社区的成员单位,长期活跃于社区活动。此次得知“基于BMC的整机功耗智能管理”赛题后,我们第一时间报名,参加比赛的初衷包括:一方面题目与我们联合团队正建设的广东赫曦原子智算中心高度契合;另一方面,我们希望通过比赛把社区的BMC轻量级AI部署经验应用到实际工作中,与同行一起探索降低PUE的新路径。

核心方案

作品方案面向原子级科学计算高性能服务器(赫曦I架构),设计了一套基于BMC的温度控制与功耗管理系统。该系统包含两个核心模块:单变量功耗智能管理和整机功耗智能管理。单变量功耗智能管理通过采集主板、CPU、GPU、APU等区域的温度、负载数据,采用ANN、CNN、LSTM-FNN等AI模型动态调节风扇转速组合,实现快速降温与低功耗温控。整机功耗智能管理通过LSTM模型预测CPU、GPU、内存等设备的负载峰值与低谷,动态调整CPU/GPU频率和电压,实现按需功耗分配。系统还支持增量学习、强化学习优化及阈值控制兜底,在保障计算性能的同时有效降低运行成本、提升能效。

参赛过程及心得

本次挑战赛自启动便锚定真实场景,涉及CPU、GPU及自研APU等多类硬件,需监测与调控的参数庞杂、手段各异;尤其是APU,必须经两级代理才能获取关键指标。如何把这些分散的监控手段熔于一炉,实现整机功耗的智能管理,成为最大难点。团队通过模块化设计与任务精细化分工,紧密协同,最终攻克了这一难题。由于采用联合组队,成员分处两地,大家积极配合、相互支持,克服时间紧、异地沟通难等障碍,确保在既定节点顺利完成赛题任务。

我对社区说

OurBMC社区把“开放”写进名字,更把“落地”刻进基因。比赛过程中,我们深度用到社区开源的框架和工具,真切体会到“代码面前无门槛”的魅力。希望社区继续围绕:一方面把功耗、安全、AI等前沿插件做成“积木”,让中小企业也能搭出高可靠方案;另一方面建立“赛题—社区—商业”正循环,让好的需求立刻变成可量产的主板固件。希望通过本次大赛,与大家一起把BMC从“远程开关”升级为“绿色算力中枢”。开源不是情怀,而是降低PUE的最短路径——让我们把这条路径越走越宽!

PART.06

6国科超算.jpg

参赛背景

我们通过开放原子开源基金会、OurBMC社区公众号了解到本次比赛,参赛初衷是当前AI大模型的爆发式增长,AI服务器集群成为常态,相较于传统服务器,功耗密度陡然攀升,传统粗放式的功耗管理已无法满足能效要求。在BMC管理系统里,引进AI功耗智能管理模块,根据主板关键元器件的温度、服务器OS的负载,对服务器的整机功耗,提供精准化、智能化的调控决策。

核心方案

获奖作品核心思想是通过轻量化AI技术,优化BMC风扇控制策略和功耗节能管理,实现高效散热与节能的平衡,采用如下关键机制:

  • 全场景数据采集:服务器覆盖空载、常规负载、高负载工况,确保数据采集完整性
  • 功耗建模与特征工程:基于硬件标定“风扇ID-对应硬件温度-PWM”映射表,构建实时功耗估算模型,简化特征维度,无需复杂计算,适配轻量化模型需求
  • 模型开发与训练
    超温阶段:开发LSTM多输出预测模型,实现快速响应温度趋势
    稳温阶段: 开发Q-Learning+能耗优化模型,实现稳态能效最优
  • 轻量化部署与测试:简化模型推理链路,控制延迟<10ms,部署异常兜底机制,确保模型推理失效或可置信度低时自动切换备用控温模式

参赛过程及心得

由于本次参赛团队成员涉及到不同专业领域,赛事前期AI方面的工程师和BMC开发工程师就赛题讨论存在一定的分歧,后经带队老师统一协调讨论,敲定最终实施的方案架构,团队成员即按照方案架构进行任务分配,开始采集数据、训练模型、搭建智能管理软件架构、部署测试,期间就模型训练结果不理想、数据采集有偏差等一系列问题,多次集中讨论,攻关,逐一解决。由于要兼顾公司下发的项目任务,为此我们每个人都为比赛付出巨大的精力和努力,但成果出来后的成就感让我们疲态尽扫,收获颇丰。

我对社区说

OurBMC作为国内首个开源的BMC固件栈社区,其开源精神和技术创新是值得我们所有相关从业人员学习的。社区近年陆续举办相关的BMC赛事,其竞赛背景均是服务器行业里高度关注的技术点,吸引了众多选手一同角逐,积极推动开源社区的发展。希望OurBMC社区能够发展的越来越好,拥有更加美好的未来!

关于OurBMC

OurBMC 社区是开发者交流和创新 BMC 开源技术的根社区,社区秉承 “开放、平等、协作、创新” 原则,坚持 “开源、共建” 的合作方式,旨在共同推进 BMC 技术快速发展,辐射上下游形成产业共振,加速构建繁荣的信息系统软硬件生态。

image.png

月之暗面正式发布了 Kimi 的官方编程工具 Kimi Code。这不仅仅是一个代码生成器,而是一个可以直接在终端运行、具备自主规划能力的 AI Agent。它基于 K2.5 模型,支持多模态输入(图片和视频),并能通过 ACP(Agent Client Protocol)协议无缝集成到 VSCode、Cursor、JetBrains 和 Zed 等主流编辑器中。

image.png

对于开发者而言,Kimi Code 实现了“阅读代码”到“执行命令”的闭环,覆盖了从构建、调试、重构到测试的端到端任务。

以下是关于 Kimi Code CLI 的核心功能、安装配置及高阶使用技巧。

Kimi Code CLI 是什么

Kimi Code CLI 是一个运行在终端中的智能代理。与传统的对话机器人不同,它具备操作系统的执行权限。它可以:

  • 阅读和编辑代码:直接修改源文件,而非仅仅给出建议。
  • 执行 Shell 命令:运行构建、测试脚本。
  • 自主规划:在遇到错误时,自动分析日志并尝试修复,形成“执行-反馈-修正”的循环。

它既是一个独立的终端工具,也可以作为后端服务接入 IDE。

安装与环境配置

Kimi Code CLI 依赖 Python 环境(建议版本 3.12-3.14)。

第一步:使用 ServBay 准备 Python 环境

打开 ServBay,在「软件包」中,找到并安装 Python 3.13(这是 Kimi Code 推荐的最佳兼容版本)。

image.png

ServBay 会自动配置好环境,确保终端调用的是这个独立的 Python 版本,拥有完整的 pip 包管理能力。

第二步:安装 uv 包管理器

有了 ServBay 提供的 Python 环境后,需要先安装 uvuv 是一个极速的 Python 包管理器,也是 Kimi Code 官方推荐的底层工具。在终端执行:

pip install uv

第三步:安装 Kimi Code CLI

现在 uv 命令已经可用了,直接使用它来安装 Kimi Code:

uv tool install --python 3.13 kimi-cli

image.png

安装完成后,验证是否成功:

kimi --version

image.png

初始化与配置

在项目目录下输入 kimi 即可启动交互界面。

首次使用推荐通过 /login 命令登录 Kimi 账号,系统会自动同步可用的模型配置。如果需要使用特定的 API Key,也可以通过 /setup 手动配置端点和密钥。

项目索引

进入一个新项目时,建议先运行 /init。这会让 Kimi 分析项目结构并生成 AGENTS.md 文件。这个文件相当于给 AI 看的“项目说明书”,能显著提升后续任务的准确率。

核心工作流

Kimi Code CLI 的交互采用了类似 Shell 的混合模式,按 Ctrl-X 可在 Agent 模式(对话)和 Shell 模式(执行原生命令)之间切换。

1. 功能开发与重构

在 Agent 模式下,直接用自然语言描述需求。Kimi 会遵循“阅读 → 修改 → 验证”的流程。

例如:

“给用户列表页面添加分页功能,每页显示 20 条记录,样式参考现有的 Button 组件。”

它会自动搜索相关文件,理解上下文,进行代码修改,并保持代码风格的一致性。

2. 排查与修复

遇到报错时,可以直接粘贴错误日志,或者让 Kimi 运行测试命令。

“运行 npm test,如果有失败的用例,请帮我分析原因并修复。”

在处理复杂逻辑时,可以通过 /model 切换到支持 Thinking 模式的模型(如 k2-thinking),让 AI 在输出方案前进行更深度的逻辑推演。

3. 自动化任务

对于繁琐的批量操作,CLI 优势其实挺多的,比如:

  • 把 src 目录下所有 .js 文件的 var 声明改成 const 或 let。
  • 分析 logs 目录下的日志,统计接口平均响应时间。
  • 把 images 目录下的 PNG 转换为 JPEG。

高阶技巧

  • @路径补全:在对话中输入 @ 可以快速引用项目中的文件,例如 帮我解释 @src/core/scheduler.py 的逻辑
  • 多模态输入:支持直接粘贴剪贴板中的图片。如果是 UI 调整任务,截图给 AI 往往比文字描述更高效。
  • YOLO 模式:默认情况下,AI 的每一个文件修改和命令执行都需要用户确认。如果你在 Docker 容器或测试环境中运行,可以使用 /yolo 命令开启“大胆模式”,跳过所有确认步骤,实现全自动执行(生产环境慎用)。

集成到编辑器

Kimi Code 支持 ACP 协议,这意味着它不仅活在终端里,也能集成到 JetBrains 系列 IDE(IntelliJ IDEA、PyCharm、WebStorm 等)中。

首先需要在终端获取 Kimi 的安装路径:

which kimi

复制输出的路径(例如 /Users/username/.local/bin/kimi)。

配置 AI 助手

打开 IDE 的 AI 聊天面板(通常需要安装 AI Assistant 插件),在菜单中点击 "Configure ACP agents" ,添加如下配置:

{
  "agent_servers": {
    "Kimi Code CLI": {
      "command": "/Users/你的用户名/.local/bin/kimi", 
      "args": ["acp"],
      "env": {}
    }
  }
}

注意: command 必须填入第一步获取的完整绝对路径。

开始使用

保存后,在 AI 聊天的 Agent 选择器中即可看到 Kimi Code CLI。

总结

Kimi Code 并没有花里胡哨的功能,但是它解决了开发者的问题,开发者不需要离开终端,就能让 AI 动手写代码。配合 ServBay 提供的稳定 Python 环境,不仅安装过程更顺畅,也能让 AI 工具在隔离的沙盒中高效运行,避免对系统造成干扰。

目前该工具处于技术预览阶段,建议在非生产关键路径上先行试用。

Vercel 最近发布了 React 最佳实践库,将十余年来积累的 React 和 Next.js 优化经验整合到了一个指南中。

其中一共包含8 个类别、40 多条规则

这些原则并不是纸上谈兵,而是 Vercel 团队在 10 余年从无数生产代码库中总结出的经验之谈。它们已经被无数成功案例验证,能切实改善用户体验和业务指标。

以下将是对你的 React 和 Next.js 项目影响最大的 10 大实践。

1. 将独立的异步操作并行

请求瀑布流是 React 应用性能的头号杀手。

每次顺序执行 await 都会增加网络延迟,消除它们可以带来最大的性能提升。

❌ 错误:

async function Page() {
  const user = await fetchUser();
  const posts = await fetchPosts();
  return <Dashboard user={user} posts={posts} />;
}

✅ 正确:

async function Page() {
  const [user, posts] = await Promise.all([fetchUser(), fetchPosts()]);
  return <Dashboard user={user} posts={posts} />;
}

当处理多个数据源时,这个简单的改变可以将页面加载时间减少数百毫秒。

策略1:并行异步操作

2. 避免桶文件导入

从桶文件导入会强制打包程序解析整个库,即使你只需要其中一个组件。

这就像把整个衣柜都搬走,只为了穿一件衣服。

❌ 错误:

import { Check, X, Menu } from "lucide-react";

✅ 正确:

import Check from "lucide-react/dist/esm/icons/check";
import X from "lucide-react/dist/esm/icons/x";
import Menu from "lucide-react/dist/esm/icons/menu";

更好的方式(使用 Next.js 配置):

// next.config.js
module.exports = {
  experimental: {
    optimizePackageImports: ["lucide-react", "@mui/material"],
  },
};

// 然后保持简洁的导入方式
import { Check, X, Menu } from "lucide-react";

直接导入可将启动速度提高 15-70%,构建难度降低 28%,冷启动速度提高 40%,HMR 速度显著提高。

策略2:避免桶文件导入

3. 使用延迟状态初始化

当初始化状态需要进行耗时的计算时,将初始化程序包装在一个函数中,确保它只运行一次。

❌ 错误:

function Component() {
  const [config, setConfig] = useState(JSON.parse(localStorage.getItem("config")));
  return <div>{config.theme}</div>;
}

✅ 正确:

function Component() {
  const [config, setConfig] = useState(() => JSON.parse(localStorage.getItem("config")));
  return <div>{config.theme}</div>;
}

组件每次渲染都会从 localStorage 解析 JSON 配置,但其实它只需要在初始化的时候读取一次,将其封装在回调函数中可以消除这种浪费。

策略3:延迟状态初始化

4. 最小化 RSC 边界的数据传递

React 服务端/客户端边界会将所有对象属性序列化为字符串并嵌入到 HTML 响应中,这会直接影响页面大小和加载时间。

❌ 错误:

async function Page() {
  const user = await fetchUser(); // 50 fields
  return <Profile user={user} />;
}

("use client");
function Profile({ user }) {
  return <div>{user.name}</div>; // uses 1 field
}

✅ 正确:

async function Page() {
  const user = await fetchUser();
  return <Profile name={user.name} />;
}

("use client");
function Profile({ name }) {
  return <div>{name}</div>;
}

只传递客户端组件实际需要的数据。

策略4:最小化RSC边界

5. 动态导入大型组件

仅在功能激活时加载大型库,减少初始包体积。

❌ 错误:

import { AnimationPlayer } from "./heavy-animation-lib";

function Component() {
  const [enabled, setEnabled] = useState(false);
  return enabled ? <AnimationPlayer /> : null;
}

✅ 正确:

function AnimationPlayer({ enabled, setEnabled }) {
  const [frames, setFrames] = useState(null);

  useEffect(() => {
    if (enabled && !frames && typeof window !== "undefined") {
      import("./animation-frames.js").then((mod) => setFrames(mod.frames)).catch(() => setEnabled(false));
    }
  }, [enabled, frames, setEnabled]);

  if (!frames) return <Skeleton />;
  return <Canvas frames={frames} />;
}

typeof window 可以防止将此模块打包用于 SSR,优化服务端包体积和构建速度。

策略5:动态导入组件

6. 延迟加载第三方脚本

分析和跟踪脚本不要阻塞用户交互。

❌ 错误:

export default function RootLayout({ children }) {
  useEffect(() => {
    initAnalytics();
  }, []);

  return (
    <html>
      <body>{children}</body>
    </html>
  );
}

✅ 正确:

import { Analytics } from "@vercel/analytics/react";

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

在水合后加载分析脚本,优先处理交互内容。

策略6:延迟加载脚本

7. 使用 React.cache() 进行请求去重

防止服务端在同一渲染周期内重复请求。

❌ 错误:

async function Sidebar() {
  const user = await fetchUser();
  return <div>{user.name}</div>;
}

async function Header() {
  const user = await fetchUser(); // 重复请求
  return <nav>{user.email}</nav>;
}

✅ 正确:

import { cache } from "react";

const getUser = cache(async () => {
  return await fetchUser();
});

async function Sidebar() {
  const user = await getUser();
  return <div>{user.name}</div>;
}

async function Header() {
  const user = await getUser(); // 已缓存,无重复请求
  return <nav>{user.email}</nav>;
}

策略7-8:缓存去重

8. 实现跨请求数据的 LRU 缓存

React.cache() 仅在单个请求内有效,因此对于跨连续请求共享的数据,使用 LRU 缓存。

❌ 错误:

import { LRUCache } from "lru-cache";

const cache = new LRUCache({
  max: 1000,
  ttl: 5 * 60 * 1000, // 5 分钟
});

export async function getUser(id) {
  const cached = cache.get(id);
  if (cached) return cached;

  const user = await db.user.findUnique({ where: { id } });
  cache.set(id, user);
  return user;
}

这在 Vercel 的 Fluid Compute 中特别有效,多个并发请求共享同一个函数实例。

9. 通过组件组合实现并行化

React 服务端组件在树状结构中按顺序执行,因此需要使用组合对组件树进行重构以实现并行化数据获取:

❌ 错误:

async function Page() {
  const data = await fetchPageData();
  return (
    <>
      <Header />
      <Sidebar data={data} />
    </>
  );
}

✅ 正确:

async function Page() {
  return (
    <>
      <Header />
      <Sidebar />
    </>
  );
}

async function Sidebar() {
  const data = await fetchPageData();
  return <div>{data.content}</div>;
}

这样一来,页眉和侧边栏就可以并行获取数据了。

10. 使用 SWR 进行客户端请求去重

当客户端上的多个组件请求相同的数据时,SWR 会自动对请求进行去重。

❌ 错误:

function UserProfile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch("/api/user")
      .then((r) => r.json())
      .then(setUser);
  }, []);

  return <div>{user?.name}</div>;
}

function UserAvatar() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch("/api/user")
      .then((r) => r.json())
      .then(setUser);
  }, []);

  return <img src={user?.avatar} />;
}

✅ 正确:

import useSWR from "swr";

const fetcher = (url) => fetch(url).then((r) => r.json());

function UserProfile() {
  const { data: user } = useSWR("/api/user", fetcher);
  return <div>{user?.name}</div>;
}

function UserAvatar() {
  const { data: user } = useSWR("/api/user", fetcher);
  return <img src={user?.avatar} />;
}

SWR 只发出一个请求,并将结果在两个组件之间共享。

11. 总结

这些最佳实践的美妙之处在于:它们不是复杂的架构变更。大多数都是简单的代码修改,却能产生显著的性能改进。

一个 600ms 的瀑布等待时间,会影响每一位用户,直到被修复。

一个桶文件导入造成的包膨胀,会减慢每一次构建和每一次页面加载

所以越早采用这些实践,就能避免积累越来越多的性能债务。

总结:立即行动

现在开始应用这些技巧,让你的 React 应用快如闪电吧!

我是冴羽,10 年笔耕不辍,专注前端领域,更新了 10+ 系列、300+ 篇原创技术文章,翻译过 Svelte、Solid.js、TypeScript 文档,著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”,关注我的公众号:冴羽(或搜索 yayujs),每天分享前端知识、AI 干货。

本文围绕 Confluence 替代软件选型,测评 ONES Wiki、为知笔记、Notion、Nuclino、Outline、BookStack、Wiki.js、XWiki、Document360、Slite、Guru 等 11 款工具,聚焦权限合规、协作体验、检索效率与迁移成本,帮助管理层、PM/产品/PMO做出可落地的知识管理系统选择。

Atlassian Server 已于 2024-02-15(PT)停止支持。 同时 Atlassian 公布 Data Center 产品将在 2026-03-30(PT)开始分阶段收敛支持,并在 2029-03-28(PST)到期进入订阅到期与只读等状态。因此,今天讨论 Confluence替代软件,本质上是在决定未来 2–3 年企业知识库与协作底座的方向。

我做选型评审时,通常会用 6 个维度去测评工具,你可以把它当作“需求澄清表”,看看自己到底需要那些能力:

  1. 合规与权限:能否页面级权限?能否审计?能否 SSO/LDAP/SAML?
  2. 私有化/自托管:数据主权、网络隔离、可控运维是否匹配?
  3. 迁移成本:空间/附件/权限/用户组怎么迁?宏、历史版本怎么处理?
  4. 协作体验:多人编辑、评论批注、模板、结构化知识是否顺滑?
  5. 检索效率:全局搜索能否覆盖附件?是否有“内容可信度/验证机制”?
  6. 与工作流连接:能否和需求/任务/迭代互链?能否把知识嵌回交付过程?

2026 年 11 款 Confluence替代软件测评清单

评测声明:以下基于公开资料与企业落地经验的“组织视角评估”。不同组织的流程成熟度、权限模型与集成环境差异极大,建议以“关键知识域试点 + 指标验证”完成最后定型。

1)ONES Wiki:把知识库“嵌回”研发与项目协作上下文

核心功能:富文本/Markdown、代码块、评论批注、模板库、版本回滚、回收站恢复、全局搜索(含附件)、角色权限配置;支持文档与项目任务关联、页面树组织项目知识。

对照 Confluence 的替代点:覆盖 Confluence 常见的“空间-页面树-权限-版本-评论”主干能力,并强化“文档与工作项互链”,更适合作为项目资产库与研发知识库一体化底座。

协同与知识管理能力:优势在于“知识与交付绑定”。规范文档可关联迭代节奏;复盘文档可关联缺陷与需求;知识更容易在工作流里被复用,而不是成为旁路文件。

优势亮点(迁移与连续性):ONES 提供 Confluence 自助迁移工具,强调 API 批量迁移、迁移监控与迁移报告;并给出在资源充足情况下的迁移速率示例。

适用场景:大中小型研发组织、PMO 需要把制度/模板/复盘与项目过程绑定;以及 Jira/Confluence 迁移背景下希望降低工具割裂成本的企业。

ONES Wiki 是 Confluence 替代首选

2)为知笔记:群组资料库 + 多端覆盖

核心功能:群组、多级文件夹、@提及与评论、多人编辑、全文检索;群组权限角色清晰;多端覆盖 Windows/Mac/Linux/iOS/Android。
对照 Confluence 的替代点:适合替代 Confluence 中“部门资料库、经验库、项目资料归档”等资料沉淀场景,尤其适合多端办公。
协同与知识管理能力:群组机制天然形成知识边界,适合“先把资料集中起来”。
优势亮点:上手快、落地阻力小,适合从“集中化”启动。
使用体验:当组织进入“强治理 + 深集成 + 与研发上下文绑定”的阶段,可能需要与更平台化的协作体系协同,而不是单点替代。

3)Nuclino:轻量、实时、强调“单一事实来源”

核心功能:主打把公司知识集中到一个地方,提供现代、直观、实时的 wiki 体验,强调 single source of truth。
对照 Confluence 的替代点:适合替代 Confluence 中“团队维基/部门资料库”这类轻治理场景,尤其适合追求低摩擦协作与快速统一入口的团队。
协同与知识管理能力:链接式组织让知识更像“网络”而不是“文件夹”,有利于跨页面发现与复用。
优势亮点:上手成本低,适合“先集中、再治理”的增长型组织。
局限与使用体验:当你需要更复杂的合规模型(细粒度权限、审计、复杂审批流)或深度企业集成时,可能更早触顶。

4)Outline(开源):自托管友好

核心功能:开源协作知识库,提供自建生产环境运行的官方文档入口。
对照 Confluence 的替代点:在“页面树 + 协作编辑 + 基础权限”的主干需求上可覆盖多数使用场景,尤其适合技术团队与对数据主权敏感的组织。
协同与知识管理能力:写作体验往往更轻、更现代;但自托管的真实成本在于持续运维、备份、安全策略与身份集成。
优势亮点:当你明确要“自托管 + 轻量好用”,Outline 是务实路线。
局限与使用体验:企业级治理上限取决于你愿意投入多少工程化能力与管理员资源。

5)BookStack(开源)

核心功能:以书-章-页为核心信息结构;角色与权限可叠加生效,适合做制度、手册、SOP。
对照 Confluence 的替代点:当 Confluence 的核心价值是“制度与手册体系”,BookStack 的结构稳定性往往更强。
协同与知识管理能力:结构天然对治理友好,能逼出一致的编写、归档与检索方式。
优势亮点:对“规模化后的可维护性”更友好。
局限与使用体验:不太适合需要强数据库化、复杂知识应用化或深度自动化的场景。

6)Wiki.js(开源)

核心功能:支持 LDAP、SAML、CAS、Okta、Azure AD 等多种企业认证与安全能力。
对照 Confluence 的替代点:当你希望替代 Confluence 并把知识库嵌入企业身份体系(SSO/目录/权限策略),Wiki.js 是高性价比路线。
协同与知识管理能力:适合构建“统一入口”的企业 Wiki 门户,尤其是 IT/平台团队主导建设。
优势亮点:集成友好、扩展性强,便于贴合既有架构。
局限与使用体验:需要运维与治理能力支撑(模板、Owner、运营机制),否则容易变成“能用但不好用”。

7)XWiki(开源/企业级)

核心功能:提供 wiki 级与页面级的访问控制,可管理 read/edit/comment 等动作权限,并支持用户组权限治理。
对照 Confluence 的替代点:适合替代 Confluence 的“企业级治理平台”角色,尤其在多部门、多角色并存与强合规场景。
协同与知识管理能力:更适合把知识库当成“可运行的平台”来设计与扩展,而不只是写文档。
优势亮点:治理上限高、权限弹性大。
局限与使用体验:实施复杂度更高,建议以关键知识域试点,不要一口气全量迁移。

8)Document360

核心功能:高级搜索覆盖文章与附件;可配置内容工作流(创建-审核-发布);多工作区(Workspace)支持多文档中心管理。
对照 Confluence 的替代点:当 Confluence 承担的是“帮助中心/客户文档/制度发布”,Document360 更像知识产品化平台。
协同与知识管理能力:工作流与角色分工清晰,更利于建立“可运营、可追责、可审计”的知识体系。
优势亮点:对外知识库常见的痛点(搜索、版本、发布、分工)更对症。
局限与使用体验:对研发型组织的“过程性知识沉淀”,它偏发布运营,不一定是最佳主阵地。

9)Slite:强调备份、权限与分析

核心功能:自动备份与快速恢复、细粒度权限、访问与编辑可见性、使用分析等。
对照 Confluence 的替代点:适合替代 Confluence 的“部门文档中心/会议纪要/规范模板库”。
协同与知识管理能力:分析能力对管理者很关键——它能回答“知识有没有被用起来”,而不仅是“有没有写”。
优势亮点:备份与恢复机制对企业落地非常实用(很多事故不是写错,而是删错、改错)。
局限与使用体验:若你需要深度业务系统集成与强定制,需评估其扩展方式与边界。

10)Guru

核心功能:每张知识卡有指定验证者(Verifier)负责内容更新,验证状态贯穿搜索结果与使用场景。
对照 Confluence 的替代点:Guru 替代的不是“页面树”,而是 Confluence 里最痛的那一段:找不到、问来问去、答案不一致。它更像“知识投送系统”。
协同与知识管理能力:验证机制让知识可信度显性化,对客服、交付、售前、运营这类“边做边查”的岗位价值更直接。
优势亮点:把高频知识从群聊与口口相传中拉出来,形成可验证的单一答案源。
局限与使用体验:通常更适合与“主知识库”搭配使用,而非单独承担全域知识工程。

11)Notion:数据库化知识很强

核心功能:Wiki 形态、页面 Owner、验证机制(Verified pages/页面验证),用于保持内容可信度与新鲜度。
对照 Confluence 的替代点:适合替代“轻治理 + 强灵活”的 Confluence 使用方式,尤其在产品资料库、制度库、FAQ、培训资料等结构化场景,数据库能力能显著提升可维护性。
协同与知识管理能力:Notion 的上限高,但也最考验“信息架构”。我见过不少组织半年后陷入“入口很多、没人知道去哪找”的困境——原因通常不是工具,而是没有定义知识域边界、Owner、更新周期与归档规则。
优势亮点:验证机制把“可被信任的知识”显性化,特别适合管理层要求“知识可背书”的场景。
局限与使用体验:复杂权限矩阵、强审计与审批发布等治理深度,往往需要配套的组织机制与流程约束才能稳定运行。

Confluence替代软件的本质,是组织数字化能力建设

讨论 Confluence替代软件,最后要回答的不是“哪款工具更强”,而是:你的组织是否具备把知识当资产来经营的能力。

我建议用“三步法”把选型落到组织能力上(比“先买工具再推行”更稳):

  • 定边界:先明确 3 个高价值知识域(制度流程、项目资产、产品资料、交付手册),避免全员全域同时上。
  • 做试点:用模板与 Owner 机制跑通“写-审-用-复盘”的闭环,同时建立最低治理:权限、版本、删除恢复。
  • 做运营(指标化):建议至少盯三个指标:

    • 搜索成功率:同一问题被重复问的频次是否下降(对应 Gartner 所述“找信息难”的普遍现象)。
    • 内容新鲜度:关键页面是否有 Owner/验证周期(Notion 与 Guru 等都强调“验证/责任人”逻辑)。
    • 知识与交付连接度:关键文档是否与项目工作项互链、是否在复盘与迭代中被复用(ONES Wiki 这类路线更贴近)。

在 Atlassian 生命周期变化(Server 已停止支持、Data Center 有明确时间线)背景下,越早把 Confluence替代软件选型当作“变革项目”,越能减少未来 2–3 年的协作成本与治理风险。

随着 DeepSeek R1、Qwen 2.5 等长文本模型与 Agentic AI 的爆发,推理系统的瓶颈正从“算力”向“显存”转移。GPU 显存告急、扩容成本高昂、长序列推理卡顿,是否成为了阻碍业务创新的“显存墙”?

立春之日,破冰之时,阿里云诚挚邀请您参加《Tair KVCache 商业化暨开源发布会》,一同推开 AI 推理效率的新大门!

💻技术盛宴:六大核心议题,全景揭秘下一代推理底座

  • 从理论突破、开源工具到生产实践、商业服务,覆盖完整落地链路
  • 汇集 NVIDIA Dynamo AIConfigurator、RTP 、Mooncake等生态伙伴,展现全栈优化实力
  • 企业级 Tair KVCache 商业化服务开箱即用,助力业务快速跨越“显存墙”

本次发布会,阿里云数据库 Tair 团队将重磅开源企业级全局管理服务 Tair KVCache Manager 及高保真仿真工具 Tair-KVCache-HiSim。我们将深度解密 Tair 如何通过存算分离架构,联合 NVIDIA Dynamo AIConfigurator、RTP、Mooncake 等生态伙伴,打造“计算-存储-调度”一体化的 AI 基础设施。同时,Tair KVCache 商业版将正式亮相,为企业提供开箱即用、极致性价比的推理加速服务。这不仅是一次产品的发布,更是一场关于 AI 记忆管理的范式革命。

📅 直播时间

2026年2月4日(立春) 14:00

👉 直播链接

点此立即预约直播:https://www.aliyun.com/activity/database/tair-kvcache-release
图片

最近离职,由于某个 SB 的原因,给一个 HK DBA 做一些算不上交接,也不算不上培训的内容。
然后发现这个 DBA, git 没用过(甚至 gitlab 网页端都没使用过). 然后文件编辑器 vs code 没有用过,是一个我不认识的文本编辑器。IAC ,terraform 更不用说了,全部没有使用过,至于英文水平,不清楚,看到分享的 bookmark 上有英文学习。关于 AI 工具,应该都没使用过。


所以什么 AI 取代都太早,老老实实工作,没必要想太多。

近几年,随着网信监管持续加强,“平台是否需要展示用户IP归属地”已经不再是产品层面的可选项,而逐渐成为一项明确的合规要求,是一个涉及监管理解、产品边界、技术选型和长期维护的综合问题。本文结合平台侧实践,分享一套基于 IP查询+离线库 的合规实施思路。

为什么平台需要展示用户IP属地?

从监管角度看,IP归属地展示的核心目的在于提升信息透明度与治理能力
通过向用户展示基础属地信息,可以在一定程度上减少误导性传播,也为平台在内容治理、风险处置和舆情应对中提供基础支撑。需要强调的是,监管要求展示的并不是精确定位信息,而是相对粗粒度的归度,通常到国家或省级即可。这本身就是在合规要求与用户隐私保护之间取得的平衡。

合规实施前必须明确的几个边界

在动手实现之前,有几个问题必须先统一认识。
首先,展示粒度要克制,不应展示到城市、区县甚至更精细的位置。其次,IP归作为客观提示信息存在,而不应被用于用户画像、标签或推荐权重计算。再次,展示逻辑必须统一,避免同一用户在短时间内频繁出现属地变化,造成误解或投诉。从监管实践看,真正容易出问题的往往不是“少展示了一点”,而是展示过度或口径不一致
平台需展示用户IP属地.png

为什么不建议完全依赖在线IP询接口?

不少平台最初的实现方式,是在请求链路中直接调用第三方在线ip接口。这种方式在功能验证阶段确实省事,但在合规场景下风险明显。

一方面,在线接口存在稳定性和延迟问题,一旦异常,前端展示就会受到影响;另一方面,第三方接口的数据和算法更新不可控,历史展示结果难以复现;此外,在涉及用户访问行为数据时,还需要额外评估数据出境与合规风险。因此,在正式合规方案中,我们更倾向于把IP归属地身可控范围内**。

IP查询+线库的整体实现思路

最终,我们采用的是一种相对稳妥的方式:获取用户IP → 本地离线库解析 → 统一展示规则输出。

整个过程不依赖外部网络请求,解析逻辑、数据版本和展示口径均由平台统一控制,便于长期维护和合规审计。

后端实现示意

下面以之前的后端实例为例

服务启动时加载IP离线库

public class IpLocationService {

    private static IpOfflineDb ipDb;

    public static void init() {
        // 启动时加载离线库到内存
        ipDb = IpOfflineDb.load("/data/ip/ip_offline.dat");
    }
}

请求链路中解析用户IP归属地

public static String resolveIpLocation(String ip) {
    IpLocation loc = ipDb.lookup(ip);
    if (loc == null) {
        return "未知";
    }

    // 合规展示:只到国家 / 省级
    if ("CN".equals(loc.getCountryCode())) {
        return loc.getProvince();
    }
    return loc.getCountryName();
}

前端展示字段示例

{
  "user_id": "123456",
  "content": "……",
  "ip_location": "北京"
}

在前端层面,仅作为提示信息展示,不参与排序、推荐或用户标记。

合规实现中的几个实践经验

在实际运行过程中,有几点经验非常重要:

  • IP离线库更新不宜过于频繁,避免属地展示抖动
  • 历史内容的属地展示口径应保持一致
  • IP归属地展示逻辑应有统一配置,避免各业务线自行实现
  • 所有变更都应具备可追溯记录,方便监管核查
    IP归属地展示不是一次性功能,而是一项长期存在的合规能力

在这套方案中,我们最终为平台接入了IP数据云的IP离线库。其数据更新节奏相对稳定,解析结果在长期使用中保持一致性,同时在本地可控、性能和维护成本方面都比较符合合规系统的要求。

如今,Mend.io 正在扩展其应用安全 (AppSec) 能力,为五款最受欢迎的代理式集成开发环境 (Agentic IDE)——包括 Windsurf、CoPilot、Claude Code、Amazon Q Developer 和 Cursor——提供安全保障,确保开发者能够以人工智能的速度高效工作,而无需在安全性上做出任何妥协。

软件创造的新纪元
代理式IDE正在重新定义代码的编写方式。现在,开发者可以直接与智能编码代理协作,在数秒内即可生成、重构和调试整个代码库。谷歌和微软等主要科技领导者估计,其高达30%的代码现已由人工智能生成,而且这一数字仍在持续增长。

但这种加速发展也带来一个紧迫的问题:在代码被审查或测试之前,由谁来保障其安全?传统的安全工具介入时机过晚,通常是在人工智能生成的代码已经进入代码仓库之后。

在代码诞生的瞬间构筑安全
我们将安全性直接融入人工智能工作流。通过 Mend MCP 服务器,我们将 Mend SAST 和 Mend SCA 嵌入到代理式IDE中,使开发者在人工智能代理生成代码的同时就能获得实时保护。

  • 即时检测漏洞 —— Mend SAST 能够在人工智能生成代码和自定义代码的编写过程中识别其中的缺陷。
  • 自主修复问题 —— Mend SAST 和 Mend SCA 将检测结果反馈给IDE,以便在代码提交进入您的CI/CD流水线之前,解决专有代码和开源代码中的漏洞。
  • 简化安全开发流程 —— 所有这一切都在IDE内部无缝发生,不会对开发者的工作流程增加任何额外阻力。

为以人工智能速度构建的团队而生
无论是试图安全地规模化采用人工智能的开发负责人,争分夺秒以重新获得安全可见性的安全专家,还是努力在无风险前提下保持开发速度的DevSecOps主管,提供主动、自动化的安全保障来保护人工智能驱动的创新都至关重要。

通过深入开发者日常工作的AI编码环境,我们正在赋能开发团队,使其能够比以往任何时候都更快、更智能、更安全地进行软件构建。

随着人工智能编码工具生态系统的不断发展,安全也必须随之进化。Mend.io的代理式IDE集成标志着我们向自主化、人工智能原生的应用安全迈出了关键一步——在这个新范式中,代码不仅被智能地生成,同样也被智能地保护。

无论是零代码小白还是资深开发者,都能在这些平台上找到适合自己的解决方案。今天,我们就来盘点一下 2026 年最值得关注的开源低代码 / 零代码平台,帮助您找到最适合的工具。

一、敲敲云 - 永久免费开源零代码平台

2026 年 1 月 12 日,敲敲云全新版本 v2.3.0 正式发布!  这一版本最大的亮点是正式宣布永久免费开放,彻底打破了传统零代码平台的用户数、应用数、表单数等多重限制,实现真正的零门槛、零成本使用。

敲敲云专注于为企业快速构建应用和工作流,是一款强大且易用的零代码平台。用户无需编写任何代码,即可通过丰富的组件库轻松创建各类应用,真正做到了 "人人都是开发者"。

产品特点:

  • 免费零代码使用,快速上手,无需开发背景
  • 丰富的组件库和模板,满足多样化应用需求
  • 可视化流程设计器,支持拖放式工作流设计
  • 强大的工作流引擎,支持复杂流程逻辑与条件判断
  • 优秀的团队协作功能,支持资源共享和协同开发
  • 数据收集能力强,快速高效地采集业务数据

官网:www.qiaoqiaoyun.com

源码下载

快速安装

二、JeecgBoot - 免费开源低代码平台(最流行)

JeecgBoot 是国内首个免费开源的低代码平台,基于 BPM 理念,采用前后端分离架构(SpringBoot 3.x、SpringCloud、Vue、Mybatis-plus 等),支持微服务架构。其强大的代码生成器可一键生成前后端代码,极大减少重复劳动,提升开发效率。

作为国内最流行的低代码平台之一,JeecgBoot 在 Java 开发者社区中拥有极高的知名度和活跃度。

产品优势:

  • 免费开源,社区活跃,灵活度高,适合 Java 项目
  • 提供丰富低代码模块,实现真正零代码开发(在线表单、报表、大屏设计、移动配置、流程设计等)
  • 简单功能零代码配置,复杂功能低代码生成,兼顾智能与灵活性
  • 业务流程采用工作流引擎,流程与表单松耦合设计,支持灵活配置
  • 保障企业流程保密性,显著减轻开发人员负担
  • 国产数据库友好(达梦、人大金仓)

官网:www.jeecg.com

源码下载

三、积木报表 - 像搭建积木一样设计报表

积木报表 (jimureport),是一款免费的数据可视化报表,含报表、打印、大屏和仪表盘,像搭建积木一样完全在线设计!功能涵盖:复杂报表、打印设计、图表报表、门户设计、大屏设计等!

  • JimuReport 侧重传统复杂报表和打印

  • JimuBI 侧重数据大屏和仪表盘可视化设计

产品优势:

  • JimuReport 采用 Web 版报表设计器,类 Excel 操作风格,通过拖拽完成报表设计,所见即所得。
  • 领先的企业级 Web 报表,支持各种复杂报表,专注于解决企业报表难题。
  • JimuBI 是专注于数字孪生和数据可视化的工具,旨在通过直观、动态且视觉吸引力强的形式呈现实时业务数据,尤其擅长打造 交互式大屏和仪表盘
  • JimuBI 业内唯一实现全场景覆盖:同时支持大屏(炫酷动态)、仪表盘(专业分析)、门户(交互式业务看板)、移动端(随时随地查看),真正实现 "一次开发,多端适配"。
  • 大屏采用类 word 风格,可以随意拖动组件,想怎么设计怎么设计,可以像百度和阿里一样,设计出炫酷大屏!
  • 秉承 "简单、易用、专业" 的产品理念,极大的降低报表开发难度、缩短开发周期、节省成本.

官网:https://jimureport.com

代码下载

四、Budibase

Budibase 是一个开源低代码平台,可以更快地构建业务应用程序,从而增强团队能力并提高生产力。IBM、Deloitte、Proctor 和 Gamble、Rakuten 等企业在内部使用该平台。

它利用内部数据库,但也集成了领先的数据库,包括 ArangoDB、DynamoDB、Mongo DB、MySQL、S3 等。

产品特点包括:

  • 为所有团队成员快速构建内部工具
  • 在企业中设置和自动化表单
  • 创建管理面板来管理数据和
  • 团队和客户的简单门户

源码下载

五、Appsmith

Appsmith 是一个用于构建管理面板、内部工具和仪表板的低代码项目。与超过 15 个数据库和任何 API 集成。构建你需要的一切,速度提高 10 倍。允许你拖放组件来构建仪表板、使用 Java 对象编写逻辑并连接到任何 API、数据库或 GraphQL 源。

源码下载

六、BudiBase

Budibase 是一个开源的低代码平台,帮助 IT 专业人士在几分钟内在自己的基础架构上构建、自动化和交付内部工具。它专注于为开发人员提供工具,以加快一个平台内的开发、部署和集成过程。

源码下载

七、Joget

Joget 使业务用户、非编码人员或编码人员能够使用单一平台轻松构建、交付、监控和维护企业应用程序。Joget DX 在一个简单、灵活和开放的平台中结合了业务流程自动化、工作流管理和低代码应用程序开发的优点。

项目地址

八、n8n(流程自动化)

n8n 是一个开源的工作流自动化工具,主要用于连接不同的应用程序和服务,实现数据的自动化处理和流程的自动化执行。它提供了一个可视化的界面,让用户可以通过拖拽节点的方式来构建工作流,无需编写复杂的代码。

主要特点包括:

  • 节点式工作流设计:用户可以通过拖拽不同的节点来构建工作流,每个节点代表一个特定的功能或操作。
  • 丰富的集成能力:n8n 支持与多种第三方服务和应用程序的集成,如 Slack、Google Drive、GitHub 等。
  • 自定义节点:用户可以根据自己的需求创建自定义节点,扩展 n8n 的功能。

源码下载

最近想换个鼠标,目前用的是罗技的 G304 ,用了大概3年左右。

但这东西需要装电池,经历好几次鼠标带出门,拿出来没电的情况,那叫一个尴尬。很不优雅!
准备换新了,大家现在手里捏着的鼠标,是什么型号, 用了多久时间了? 可以推荐一波

备注:主要配合 MacbooK 使用。

这现在一台减 2000 那到了 18 出了 这个 air 回收是按官方卖的价格 50% 折抵 还是按照 目前减了 2000 的价格折抵呢? 我感觉应该是按照官方价格吧~ 另外你们真的没人买 512G 的吗? 我看大多数都是买的 256G

大家好,我是老刘

最近TIOBE在2026年一月的编程语言排名出来了。

不出意外的,Dart又排在25名之后了。

为啥作为跨平台一哥Flutter的编程语言,Dart的排名如此落后?除了Flutter,Dart还有哪些应用场景?

本文我们来讨论一下这些问题。

1. Dart 语言近半年排名趋势

老刘统计了 Dart 语言在 TIOBE 索引中的近半年排名趋势,发现 Dart 语言的排名一直保持在 25 名之后,而其 Ratings 也始终保持在 0.60% 左右。

日期Dart在TIOBE的排名Ratings
2025-07280.61%
2025-08280.59%
2025-09280.62%
2025-10270.62%
2025-11260.69%
2025-12260.64%
2026-01260.63%

数据来源:https://www.tiobe.com/tiobe-index/

2. TIOBE并非根据语言使用量进行排名

TIOBE 索引是一个衡量编程语言 popularity 的指标,它根据每个月的搜索量来计算每个语言的排名。

每个月,TIOBE 会发布一个排名,该排名是根据搜索量的百分比来计算的。

它聚合了全球主流搜索引擎和网站的数据,包括 Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube, Baidu 等25个以上的平台。

计算Ratings逻辑大致如下:

  • 首先计算每种语言在各个搜索引擎上的“命中数”(hits)。
  • 对这些数据进行归一化处理(消除不同搜索引擎总量差异的影响)。
  • 最后计算出该语言在所有被统计语言总搜索量中的 占比(即 Ratings) 。

所以TIOBE的排名只能代表Dart语言在众多编程语言中的受关注程度,而非其在实际开发中的使用数量。

3. 为啥Dart语言排名始终不高?

与 2025 年大幅攀升的语言(如 C# 成为 2025 年度语言、 Perl 从 32 名冲回 11 名、 Zig 冲到 42 名)相比,Dart 的排名非常稳定,没有出现剧烈的排名跳跃。

根本原因是Dart语言的排名是与Flutter深度绑定的。

和大多数编程语言不通,比如Java用于服务端开发、Android开发的多个不同的领域。

而Dart的主要应用场景只有Flutter。

如果Dart在未来没有脱离Flutter用于其它方向,那么它的排名就会继续保持在20名之后。

4. Dart排名稳定代表了什么?

我们来看一下Dart排名波动最大的时间点。

可以看到Dart语言最受关注的时间是在2017年Flutter刚发布的时候。

之后是Flutter的高速扩张然后成为客户端跨平台开发的首选框架。

最近这几年,Flutter逐步进入了稳定期,Dart语言的关注度也开始稳定下来。

所以Dart语言的排名稳定从某种程度上代表了Flutter生态相对比较稳定。

这对我们这些Flutter开发者来说是一个好消息。

毕竟没有一个程序员喜欢自己吃饭的语言框架三天两头出现大的变动。

而且语言和框架的稳定带来的另一个好处就是AI友好度的提升。

因为AI模型通常是基于某个语言或框架训练的,而如果这些语言或框架经常变化,那么在日常开发中就需要程序员不停的去修正AI生成的代码。

5. 希望Dart语言能有更多领域的应用

之前老刘就专门写过文章,之前我喜欢Kotlin的强大,现在更喜欢Dart的简洁。

[Kotlin vs Dart:当“优雅”变成心智负担,我选择了更简单的 Dart
](https://mp.weixin.qq.com/s/KyqmMXTE4GyAJU2NjJYtUg)

随着编程风格越来越趋向于简洁、稳健。

我也越来越喜欢Dart这种既能同时支持面向对象和函数式编程两种编程范式,同时又能在日常开发中保持语法简洁的编程语言。

所以老刘还是希望能有更多的领域可以应用到Dart语言。

老刘觉得在以下一些领域Dart还是有用武之地的:

服务端开发 (Backend)

如果能用 Dart 写后端,实现**前后端同构**,复用同一套 Model 和 业务逻辑,将极大地降低全栈开发的门槛。像 Serverpod 和 Dart Frog 这样的框架已经开了个好头,但还需要更完善的生态。

命令行工具 (CLI)

Dart 优秀的 AOT 编译能力,使其生成的二进制文件启动极快且无需依赖环境。编写跨平台的脚本工具,Dart 其实比 Python 或 Node.js 更具部署优势。

WebAssembly (Wasm)

随着 Dart 对 WasmGC 的支持日益完善,未来 Dart 代码将能以近乎原生的性能运行在浏览器中,这为高性能 Web 应用提供了新的可能。
当然这部分可能还是和Flutter有很大的绑定关系。

总结

如果Dart能像JavaScript从浏览器走向Node.js那样,成功在服务端或CLI领域突围,那么对于我们这些Flutter开发者来说,将是一个好消息。

因为这意味着我们掌握的这门语言,将拥有更广阔的舞台,而不仅仅局限于画UI。

那么作为开发者,我们不妨在日常的小工具、脚本或者简单的后端服务中,多给 Dart 一些机会。

毕竟,生态的繁荣,离不开每一个开发者的尝试与贡献。

🤝 如果看到这里的同学对客户端开发或者Flutter开发感兴趣,欢迎联系老刘,我们互相学习。

🎁 点击免费领老刘整理的《Flutter开发手册》,覆盖90%应用开发场景。可以作为Flutter学习的知识地图。

🚀 覆盖90%开发场景的《Flutter开发手册》

📂 老刘也把自己历史文章整理在GitHub仓库里,方便大家查阅。
🔗 https://github.com/lzt-code/blog

大家好,我是 Immerse,一名独立开发者、内容创作者、AGI 实践者。

关注公众号:沉浸式AI,获取最新文章(更多内容只在公众号更新)

个人网站:https://yaolifeng.com 也同步更新。

转载请在文章开头注明出处和版权信息。

我会在这里分享关于编程独立开发AI干货开源个人思考等内容。

如果本文对您有所帮助,欢迎动动小手指一键三连(点赞评论转发),给我一些支持和鼓励,谢谢!


Vercel 开源了一个项目,叫 agent-skills。

他们把团队积累的 React、Next.js 开发经验,打包成了 AI 可以直接调用的技能包。

写代码时,AI 会自动检查性能问题、可访问性、最佳实践。相当于自动 Code Review。

3 个技能包

react-best-practices:40 多条规则,分 8 个类别。

包括消除请求瀑布流、优化包体积、服务端性能、客户端数据获取。每条规则标注优先级(Critical、High、Medium)。

web-design-guidelines:100 多条规则。

涵盖可访问性、焦点状态、表单处理、动画、排版、图片、性能、导航、暗黑模式、触控交互、国际化。

vercel-deploy-claimable:在聊天窗口直接部署到 Vercel。

支持 40 多种框架,部署完给预览地址和认领地址。

安装和使用

npx add-skill vercel-labs/agent-skills

装完不需要配置,AI 自动检测使用场景。写 React 组件时自动检查性能,说要部署时自动调用部署功能。

工具支持

这个思路的价值

把经验和最佳实践结构化,让 AI 能理解和执行。

比文档好用,AI 会在写代码时主动提醒你。这些技能遵循 Agent Skills 标准,是开放格式。


项目地址:https://github.com/vercel-labs/agent-skills

引导语:在管理 Active Directory (AD) 时,了解用户的登录时间对于安全审计和账号管理至关重要。然而,AD 中提供了多个相关属性,如 LastLogon、LastLogonTimestamp 和 LastLogonDate,它们的作用和适用场景各不相同。本文将深入剖析它们的区别,帮助您更高效地管理用户登录数据。

简介:Active Directory 维护着多个用户登录时间的属性,包括 LastLogon、LastLogonTimestamp 和 LastLogonDate。虽然它们都与用户登录记录相关,但在同步机制、精确度和适用性上存在显著差异。本文将对这三个属性进行详细对比,帮助 IT 管理员正确理解并合理利用这些信息,以优化安全策略和资源管理。

关键词:Active Directory、LastLogon、LastLogonTimestamp、LastLogonDate、用户登录时间、AD 账户管理、安全审计

什么是Active Directory登录属性?
Active Directory操作中的安全标识符是记录用户授权过程信息的基础参数。它们使管理员能够追踪访问活动并识别潜在问题,例如长期未登录的用户。

举例来说,当企业需要识别已闲置90天的账户时,通常会使用LastLogonTimeStamp属性。而另一方面,在取证调查中则需要依赖LastLogon属性的精确结果——该属性记录了用户在特定域控制器(DC)上的实际登录时间。

什么是LastLogon属性?
LastLogon属性记录了用户在特定域控制器(DC)上的最后一次登录时间。该属性具有非复制特性,意味着每个域控制器都会独立保存其专属记录。虽然它能提供最精确的登录时间数据,但若需获取域内全局信息,必须向所有域控制器发送查询请求。

LastLogon属性的核心优势在于其高精度特性。然而由于该属性未在域控制器之间同步,对于管理大规模环境的管理员而言,这反而成为痛点。例如,若企业部署了五台域控制器,每台控制器都将单独保存用户的LastLogon记录。

使用 PowerShell 查询 LastLogon
要从所有 DC 收集用户的 LastLogon,可以使用 PowerShell。此脚本会获取并汇总数据:
$Username = "john.doe"
$DCs = Get-ADDomainController -Filter *
$LastLogonResults = foreach ($DC in $DCs) {
Get-ADUser -Server $DC.HostName -Identity $Username -Properties LastLogon |
Select-Object @{Name="DomainController";Expression={$DC.HostName}},
@{Name="LastLogon";Expression={[DateTime]::FromFileTime($_.LastLogon)}}
}
$LastLogonResults | Sort-Object LastLogon -Descending
此脚本会查询所有 DC 的用户 LastLogon 属性,返回结果并按日期排序。

什么是LastLogonTimeStamp属性?
LastLogonTimeStamp属性提供域级登录活动视图。与LastLogon不同,该属性会在所有域控制器(DC)间同步更新,因此管理员可通过任意域控制器获取统一数据。但其更新周期较长:属性默认值为0,仅当用户最近一次登录发生在14天或更早前时才会触发更新。

该属性通过更新延迟机制平衡了复制流量与管理实用性。它能便捷追踪闲置账户,为审计工作提供基础支持,但由于更新频率较低,无法用于高精度登录时间追踪。

修改更新频率
管理员可以通过修改 Active Directory 中的 ms-DS-Logon-Time-Sync-Interval 属性来调整默认的 14 天间隔。例如,要将间隔改为 7 天,请使用以下 PowerShell 命令:
Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com" -Partition "CN=Configuration,DC=yourdomain,DC=com" -Add @{msDS-LogonTimeSyncInterval=7}
这种调整允许更频繁地更新,提供相对最新的登录数据,同时仍能最大限度地减少复制流量。

什么是 LastLogonDate 属性?
LastLogonDate 属性是 LastLogonTimeStamp 属性的人性化版本。它以可利用的格式提供相同的信息,由主体根据需要进行解释。

如果管理员需要用户操作的整体信息,而又不需要转换原始时间戳,那么使用 LastLogonTimeStamp 属性是最理想的选择。与 LastLogonTimeStamp 类似,它也会复制到所有其他 DC 上。

使用 PowerShell 获取 LastLogonDate
要检索用户的 LastLogonDate,请执行以下操作:
Get-ADUser -Identity "john.doe" -Properties LastLogonDate | Select-Object Name, LastLogonDate
该命令以简单明了的格式输出用户名及其最后登录日期,有助于快速查看。

追踪登录属性的重要性

  • 识别闲置账户

    • 休眠账户因易被攻击者重新激活而构成重大安全威胁。通过登录属性追踪用户活动,管理员可快速判定并禁用长期未使用的账户。
  • 检测可疑行为

    • 异常登录(如深夜或凌晨时段的系统访问)可能是账户遭劫持的信号。LastLogon等属性详细记录登录会话信息,帮助管理员回溯安全事件的时间线以调查可疑案例。
  • 支持合规审计

    • 《通用数据保护条例》(GDPR)和《健康保险流通与责任法案》(HIPAA)等法规要求严格监控用户访问行为。登录属性作为关键审计证据,是企业维持合规的重要支撑。
  • 简化审计流程

    • LastLogonDate等集中化存储的登录数据大幅简化审计工作。管理员可直观分析访问模式趋势,在提升效率的同时降低审计复杂度。

Lepide如何助力安全运维
Lepide Active Directory审计工具提供全域用户活动实时可视性,支持对安全事件与异常登录的即时响应。通过持续监控认证活动,管理员能在可疑模式或未授权访问发生时即刻介入调查,而非依赖定期审计被动发现问题。其Active Directory清理方案通过识别/禁用休眠账户,有效缩减攻击面,降低未授权访问风险。

除实时威胁检测外,Lepide还提供:

  • 可定制化告警机制:针对特定安全场景(如登录失败、非工作时间访问、异常行为模式)配置触发规则
  • 全景合规支持:详细日志记录与合规报告自动生成功能,完整留存历史数据并构建符合GDPR/HIPAA等标准的审计轨迹

通过部署Lepide解决方案,企业可实现:
✅ Active Directory环境全景洞察
✅ 安全防护体系强化升级
✅ 合规性要求自动化满足
✅ IT运维效率显著提升

立即掌控Active Directory安全态势
[点击预约个性化演示],了解Lepide如何帮助您:

  • 监控全域登录活动
  • 实时检测安全威胁
  • 持续保持合规状态

常见问题
Q. 为什么每次登录后都不更新 LastLogonTimeStamp?
为尽量减少复制流量,LastLogonTimeStamp 更新的频率较低,通常每 14 天更新一次,除非另有配置。
Q. 如何获取用户最准确的最后登录时间?
查询所有域控制器上的 LastLogon 属性,并使用最新的时间戳。
Q. 能否修改 LastLogonTimeStamp 属性的更新频率?
可以,可以通过修改域配置中的 ms-DS-Logon-Time-Sync-Interval 属性来调整更新频率。
Q. 在 Active Directory 中,LastLogonDate 是否默认可用?
是的,LastLogonDate 是一个计算属性,默认情况下可用,它提供了 LastLogonTimeStamp 的人可读格式。

项目介绍

基于深度学习的智能害虫识别系统,帮助农业生产者快速、准确地识别农作物病虫害,提高病虫害防治效率,保障农业生产安全。系统采用前后端分离架构,前端使用Vue3+Element Plus构建用户友好的交互界面,后端采用Flask框架提供高效的数据处理和API服务,核心识别算法基于TensorFlow深度学习框架和ResNet50卷积神经网络模型。

系统主要功能包括:用户注册与登录、害虫图片上传、实时识别、识别历史记录查询、数据统计可视化等。用户可以通过上传害虫图片,
图片
图片
图片

选题背景与意义

随着全球人口的增长和农业现代化的推进,农作物病虫害防治面临着越来越大的挑战。传统的病虫害识别方法主要依赖人工经验,存在识别效率低、准确率不高、受主观因素影响大等问题。尤其是在大规模农业生产中,病虫害的及时识别和防治显得尤为重要,直接关系到农作物的产量和质量。

近年来,深度学习技术在计算机视觉领域取得了显著进展,卷积神经网络(CNN)在图像识别任务中表现出了优异的性能。ResNet50作为一种深度残差网络,具有强大的特征提取能力和梯度传播效率,能够有效解决深度网络训练中的梯度消失问题。

关键技术栈:ResNet50

ResNet50是微软研究院提出的一种深度残差网络结构,是ResNet(Residual Network)系列网络中的经典模型之一。它由50层卷积神经网络组成,通过引入残差连接(Residual Connection)解决了深度网络训练中的梯度消失问题,使得构建更深层次的神经网络成为可能。

ResNet50的核心创新点在于残差块(Residual Block)的设计。传统的卷积神经网络在堆叠多层后会出现退化现象,即网络深度增加但性能反而下降。ResNet通过在残差块中引入恒等映射(Identity Mapping),使得网络可以学习到残差信息,避免了退化问题的发生。残差块的结构可以表示为:y = F(x, {Wi}) + x,其中F(x, {Wi})是残差函数,表示学习到的特征与输入之间的差异。

技术架构图

图片

系统功能模块图

图片

演示视频 and 完整代码 and 安装

地址:https://www.yuque.com/ziwu/qkqzd2/qis0k3f4bsvy0xop

随着电子签章应用在市场越来越普及和受追捧,超级大厂也相继推出了自己的电子签章产品,如华为的华为云电子签、阿里的阿里云电子签、腾讯的腾讯电子签服务。那这些大厂推出的电子签章产品和服务与传统第三方电子签公司北京安证通有什么相同和区别呢?接下来我们通过多个维度进行差异化的浅析。1. 核心定位与生态整合
图片

  1. 技术架构与优势
    图片
  2. 合规性与认证
    图片
  3. 定价与成本
    图片
  4. 适用场景与客户群体
    图片
  5. 优势与局限性对比云厂商电子签的优势:1) 生态协同:与现有办公流、业务系统无缝衔接。2) 成本优势:云用户可享受集成套餐优惠。3) 快速部署:针对通用场景开箱即用。北京安证通的优势:1) 专业性:深耕电子签名领域,功能更细致。2) 中立性:数据不绑定单一生态,适合多平台协作。3) 行业方案:更适配高频复杂场景

出于市场对网络安全的不断重视,众多企业也逐渐开启网站的SSL证书部署,既响应政策号召,又可避免被潜在的网络攻击威胁。正因如此,当企业在官网上看到绿色的安全锁标志时,通常认为数字证书的任务已经结束。事实上,真正的风险往往从安全证书部署完成后才开始显现。从证书签发机构的可信度,到服务器配置的细节,再到日常维护和管理,每一个环节的疏忽,都有可能让这一重要的安全措施失去应有的效果,甚至演变成新的攻击途径。JoySSL通过长期的安全审查和行业研究发现,多数企业在部署SSL证书后,常常忽略其生命周期内的安全管理工作,从而无形中埋下了严重的隐患。这些问题并非SSL技术的固有缺陷,而是源于“部署即完成”的错误观念以及粗放的管理方式。

证书安全锁不彻底 身份验证模糊

安全锁标志并不意味对所有内容的保护,主网页采用HTTPS加密,但部分资源如图片或样式表,仍通过HTTP协议加载,从而形成混合内容,导致浏览器降低网站的安全评级,未加密的HTTP资源可能会被篡改。

对金融、政务、电商等平台,仅使用DV证书无法有效向用户证明企业的真实身份,尤其在防范钓鱼攻击方面,信任缺陷尤为突出。EV证书显示的绿色地址栏,能够为企业提供对抗仿冒行为的显著可视化优势。

过期证书服务中断 一证通用弊端

未能及时续期是证书服务中断的主要原因,依靠个人记忆来管理大批量证书的续期工作,极易出现疏漏,从而导致关键业务平台因证书过期而无法正常运行。引入自动化的监控,建立完整的证书生命周期管理机制,方能有效降低中断风险。

私钥作为SSL证书体系的核心,需要极高的保护措施。若在多台服务器间重复使用同一私钥,将私钥以明文存储在共享目录或代码仓库中,一旦私钥泄露,所有相关服务均可能受到安全威胁。

颁发机构不被信任 证书无人管理

并非所有证书颁发机构都具备同等的可信度,较为冷门的颁发机构其根证书可能难以得到广泛认可,应优先选择与全球顶级根证书库合作的供应商。

随着企业业务规模的不断扩大,可能会产生大量无人维护的数字证书。一旦出现过期或配置问题,便可能引发安全漏洞与业务中断的风险。企业需完善并维护统一的证书管理清单,确保安全措施全面覆盖。

主动部署数字证书 打造安全堡垒

部署SSL证书,只是创建可信通信环境的开端,而非安全策略的最终目标。其实际效果取决于配置的规范性、管理的高效性以及应对的及时性。JoySSL市场总监表示,当下互联网环境形势严峻,企业应将SSL证书管理作为核心的安全运营工作,系统化解决常见的风险。让SSL证书成为坚固、可靠且持续有效的安全屏障,为企业的数字化转型提供全面且专业的保障。

Aspire 13.1作为增量更新发布,它基于 Aspire 13 引入的多语言平台基础。此次发布专注于通过增强命令行界面、更深入地支持 AI 辅助开发工作流程、改进仪表板体验以及更清晰的 Azure 环境部署行为来提高开发者的生产力。

 

据团队报告,此次更新旨在使日常开发任务更可预测、更易于自动化,并与现代 AI 编码工具更好地对齐。

 

Aspire 13.1 中的一个核心新增功能是通过与模型上下文协议(Model Context Protocol,MCP)集成,扩展了对 AI 编码智能体的支持。一个新的命令允许项目在初始化时支持 MCP,使兼容的 AI 工具能够发现 Aspire 集成、检查应用程序结构并与运行中的资源交互。

 

aspire mcp init
复制代码

 

连接后,AI 智能体可以查询应用程序状态、查看日志并通过暴露的端点检查跟踪。这种集成旨在简化开发过程中 AI 助手的使用,而无需为每个工具进行自定义设置。

 

Aspire CLI进行了几次更新,旨在减少创建、运行和维护项目时的摩擦。如前所述,项目创建命令现在可以选择通道,并且一旦选择,将全局保持,确保新项目的行为一致。

 

CLI 还能检测到已经运行的实例,并在启动新运行之前自动停止它们,从而避免常见的冲突。安装脚本现在支持一个选项来跳过修改系统 PATH,这在受控环境中非常有用。

 

此次发布的仪表板更新专注于清晰度和可见性。新的参数标签允许直接从资源详情中查看和管理配置值。GenAI 可视化器已增强,以更好地显示工具定义、评估和相关日志,并支持预览音频和视频内容。仪表板的几个稳定性问题也得到了解决。

 

(GenAI 可视化器工具定义,来源:官方Aspire文档

 

Azure改进方面,Aspire 13.1 引入了更清晰的命名和更强大的验证。Azure Redis 集成已重命名,以更好地匹配底层服务,并且在部署过程中更早地执行额外检查,以便尽早发现配置问题。

 

Azure 资源现在暴露出标准化的连接属性,这些属性在支持的语言中通用,使得非.NET 应用程序能够使用一致的设置进行连接。还增加了对 Azure App Service 中部署槽的支持和对默认角色分配的更精细控制。

 

通过引入通用容器注册表资源,容器和部署工作流得到了改进,允许开发者锁定 Azure 容器注册表之外的注册表。容器镜像推送现在更加明确和可预测,特别是在部署到 Azure 容器应用时。Docker Compose 支持已得到改进,以增强可移植性并减少并行构建期间的竞争条件。

 

此次发布还包括针对JavaScript和前端开发的更新,例如一个新的起始模板,该模板结合了 ASP.NET Core 后端和基于 Vite 的前端,改进了开发中的 HTTPS 处理,并修复了与包管理器相关的问题。

 

证书处理得到了简化,新增了配置 HTTPS 和在支持的容器中终止 TLS 的新 API。

 

此外,Aspire 13.1 还稳定了之前预览版中的几个集成,包括 Dev Tunnels、端点代理支持和 Azure Functions。模板已更新以反映一致的模式,并且广泛的错误修复集提高了跨平台的可靠性。

 

Aspire 13.1需要.NET 10 SDK 或更高版本。建议从早期版本升级的开发者查看已记录的重大变更,特别是围绕 Azure Redis API 和重命名的连接属性。

 

对于感兴趣的读者,完整的发布说明和详细文档可在官方Aspire存储库和文档渠道中找到。

 

原文链接:

https://www.infoq.com/news/2026/01/dotnet-aspire-13-1-release/