上期我们介绍了如何部署Clawdbot AI的详细操作步骤【本地搭建 Clawdbot + ZeroNews 访问】

本篇文章主要为已部署Clawbot AI的用户，提供了一种便捷、适配国内网络环境的远程管理解决方案——借助 ZeroNews 替代官网推荐的代理工具，实现OpenClaw GateWay Dashboard的远程访问；

同时针对性解决远程访问时可能出现的Gateway Token错误、设备授权错误两大常见问题，明确了远程Dashboard的全部可操作功能。

OpenClaw 是一个专为 AI 应用与智能体部署设计的高性能网关平台，它提供了统一的仪表盘（Gateway Dashboard）用于集中管理模型调用、渠道集成、技能插件、定时任务及节点监控。

基于 OpenClaw 构建的 Clawbot AI 是一款功能强大的 AI 产品，能够无缝接入多种对话模型与即时通信平台（如 WhatsApp、Telegram、Discord 等），并通过可扩展的技能系统实现自动化任务与智能交互。

完成 Clawbot AI 安装后（安装步骤可参考我们上期的文章），您将获得 OpenClaw Gateway Dashboard 的本地访问地址及唯一的 Gateway Token（后续配置需用到）。

通过访问地址可以通过本地访问打开 OpenClaw Gateway Dashboard
默认访问地址：127.0.0.1:18789

该地址仅支持本地网络访问。若需在外部网络环境下管理网关，官方文档提示我们需借助 Tailscale 或 VPN 等代理工具，但这些方式在国内网络环境中往往体验不佳。

ZeroNews 远程映射配置

而通过我们的实测，ZeroNews可以完美的替代官网推荐的代理工具。
1、简单三步就能够实现 OpenClaw Gateway Dashboard 的远程访问。下载安装 ZeroNews Agent创建域名信息配置映射服务
2、提供IP黑白名单和鉴权认证。可以完美的解决暴露出来的 GateWay Dashboard 不受非授权IP访问和授权账号访问，提升服务的安全性。

远程Gateway Dashboard 错误问题处理

但是我们通过远程访问的时候，如果出现如下问题，可以通过下面的方法解决。

01 GateWay Token 错误

1、报错信息：
disconnected (1008): unauthorized: gateway token missing (open a tokenized dashboard URL or paste token in Control Ul settings)

2、报错原因：第一次通过远程连接访问 OpenClaw Gateway Dashboard时，需要配置 GateWay Token，否则会出现错误。

3、解决方案：打开 Control / Overview 页面然后将上面安装时获取到的GateWay Token粘贴进去点击Connect连接

02 设备授权错误

1、报错信息：disconnected (1008): pairing required

2、错误原因：如果您使用一台新的设备去访问 OpenClaw Gateway Dashboard的 URL 时，除了需要配置上面的GateWay Token 之外，还需要对新的设备进行授权，否则会提示错误。

3、解决方法：

a) 首先，我们要打开到配置窗口，并执行设备列表查询命令

b) 这时候，可以看到上面会出现刚才请求连接访问的设备信息。我们需要记住 Request IDc) 接着，我们执行设备授权命令和重启网关命令

d) 执行完成之后，我们回到 GateWay 页面，点击刷新，可以看到 STATUS 为 Connected 状态，表明我们已经可以正常访问了。

注意：

• 一旦批准，设备会被记住，除非你使用命令 openclaw devices revoke --device <id> --role <role> 撤销它，否则不需要重新批准。
• 每个浏览器配置文件生成唯一的设备 ID，因此切换浏览器或清除浏览器数据将需要重新配对。
• 若等待授权的时间过长，Request ID会过期，需要重新点击 Connect 申请授权，并通过设备命令查询获取到新的Request ID进行授权。

e) 通过上述操作后，我们就可以在Chat页面与AI进行沟通了。

远程 Gateway Dashboard 可以做什么

通过远程 Dashboard，您可以全面管理 OpenClaw 网关，包括：

• 对话管理：通过 WebSocket 与模型聊天，支持流式工具调用与实时输出。
• 渠道集成：管理 Telegram、WhatsApp、Discord、Slack 等渠道的状态、扫码登录与配置。
• 实例监控：查看在线实例列表并即时刷新状态。
• 会话控制：列出会话、调整会话的思考模式与详细设置。
• 定时任务：管理 Cron 任务的添加、启用、禁用与执行历史。
• 技能管理：查看技能状态、启用/禁用技能、安装新技能及更新密钥。
• 节点管理：查看节点列表及其能力。
• 执行审批：编辑网关与节点的允许列表，设置执行询问策略。
• 配置编辑：查看或编辑 openclaw.json配置文件，支持表单与 JSON 两种编辑模式。
• 调试与日志：查看系统状态、健康检查、模型快照、事件日志，支持实时日志跟踪与导出。
• 更新操作：执行包更新或 Git 更新，并查看重启报告。

安全注意事项

1、IP 访问控制：
可以通过在映射页面，对此映射配置IP访问控制功能，实现仅允许白名单IP访问，非白名单IP无法访问。

拒绝访问效果图

2、鉴权认证管理：
可以通过在映射页面，对此映射配置鉴权认证，实现需要账号密码才能访问，进一步提升安全能力。

开启鉴权效果图

接下来，我们将继续深入挖掘更多实用、有趣的进阶玩法，敬请期待。

大家好啊，我是甲木。

这段时间不是一直在折腾 OpenClaw 么，

之前发的几篇教程类文章，对于很多小伙伴来说，还是门槛比较高，

正好前两天刚从百度智能云的 Agent 大会回来，还挺有意思的，趁热给大家聊聊（关于大会内容，放后边了~）。

现在，百度智能云也接入了 OpenClaw的极简版本，

并且发了一堆非常有意思的skills和百度官方工具，跟现有的OpenClaw打通也有很多的玩法，

我当时第一反应就是：

这不就是我一直在找的东西吗？

OpenClaw × 百度智能云 × 千帆 Skill ⽣态，一套组合拳下来，贼牛批..

好，先别急，我慢慢说。

今天这篇主要聊几件事：

• 百度千帆上线了几个非常实用的Skills，直接接入OpenClaw
• 百度智能云上搭 OpenClaw，到底有多简单
• 三个我实际跑通的 Skills 玩法，真的能干活那种

那么，我们开始！

先说大会上最让我上头的东西

大会上发了不少东西，但最让我兴奋的，是「百度千帆工具及MCP广场」把百度的生态，直接接入OpenClaw了。

大家玩过 OpenClaw 都知道，这玩意儿的拓展性也在于 Skills，你给它装什么技能，它就能干什么活。

而现在百度智能云把「百度 AI 搜索、百度地图、百度网盘、OCR、语音识别」...这些百度自家的能力，全部以 MCP Server 和Skills的形式开放出来了。

以前你想给 OpenClaw 加个"搜索"能力，得自己找 API、写配置、调半天参数。

现在？去广场里挑一个，接进去，完事儿。

而且开发者还能自己开发 MCP Server 发布上去，免费托管，还能被百度搜索收录，等于白送你一波流量。

说白了，这就是给 Agent 开发者建了一个应用商店。

而我这次重点关注到的，是已经上架的几个跟 OpenClaw 直接能打配合的 Skill：

• 百度搜索：实时信息检索，这是 Agent 的"眼睛"
• 百度百科：知识查询和概念核实，相当于给 Agent 装了本百科全书
• 学术检索：论文搜索和学术信息获取，做研究的朋友懂的
• 智能 PPT 生成：搜完信息直接出汇报材料，一条龙
• AI 绘本生成：把内容变成图文并茂的绘本，做内容创作的太需要了

这几个 Skill 单独用都挺好使，但更有意思的是，它们能组合起来用。

后面我会专门聊几个我自己跑通的组合玩法，先按下不表。

百度智能云上搭 OpenClaw，到底有多简单

已经部署好Openclaw的朋友可以直接跳过本章，看下一节内容，

还没部署好，或者想要再白嫖优惠OpenClaw的可以看看本章。

前两篇文章之后，大家反馈最多的问题

关注我的朋友应该记得，前两天我连着肝了两篇 OpenClaw 的教程：

• 第一篇是阿里云部署的，从买服务器到打通钉钉，全流程手把手
• 第二篇更硬核，从 0 到 1 装官方原版，接了 Kimi K2.5，还搞了 Discord 远程操控

文章发完之后，后台和群里炸了..

大家问得最多的，基本就两类：

一类是："甲木，我照着你教程做，环境配置那步就卡住了，报了一堆错，咋整？"

虽然我已经写得尽量保姆级了，但确实，

对于没怎么碰过命令行的朋友来说，配环境、装依赖、排报错这些东西..还是劝退了不少人。

另一类是："教程里那些软件都是国外的，有没有更适合国内的方案？"

嗯，这个确实是痛点。

OpenClaw 原生适配的工具和渠道基本都是海外生态，国内想用好它，适配成本不低。

正好，

百度智能云这次直接上线了 OpenClaw 极简部署。

它同样直接提供了预装好 OpenClaw 环境的轻量应用服务器镜像。

你在控制台选这个镜像，创建实例，几分钟就能跑起来，啥都不用手动装。

更狠的是，它还搞了个限时免费体验：首月免费，每天限量 500 台，先到先得。

之前阿里云那个 68 块一年大家就已经觉得香了，这次百度直接搞免费...

好家伙，卷起来了属于是。

部署完之后，你还能直接通过千帆平台接入文心、DeepSeek、Qwen 这些模型，不用自己到处去注册账号拿 API Key。

这对于小白来说，友好度直接拉满了。

搭建流程，三步搞定

第一步、买台服务器

打开百度智能云官网（https://cloud.baidu.com/product/BCC/moltbot.html），选轻量应用服务器。

几个关键的配置别选错：

• 镜像：一定选 OpenClaw(Clawdbot) 应用镜像
• 套餐：CPU 2核、内存 4GB 起步
• 地域：按需选

如果有优惠的话，你会看到这个界面，

如果没优惠的话，你就只能按月付费了..

但我给你一个思路，可以新注册一个账号...

然后正常购买，

踩坑提醒：OpenClaw 是 Node.js 应用，比较吃内存。2G 内存裸跑偶尔会 OOM（内存溢出），建议搞一下 Swap 交换空间，不然跑着跑着进程就没了，问我怎么知道的..

第二步、配模型

服务器跑起来之后，进控制台：

等待实例创建完成后进入实例详情页，点击实例管理Tab

1. 放通端口——防火墙那步，点一下「一键开通」就行

这里是直接按使用量计费的，需要注意。如果不想走千帆平台的，我们可以直接用它的服务器，然后自己搭建镜像，就跟那篇文章教大家的一样。

2. 防火墙放通18789端口

访问openclaw官网网站需要通过18789端口访问，点击“一键放行”放行防火墙18789端口。

3. 接大模型——通过千帆平台配，文心、Qwen、DeepSeek 都能选

到这里，三步其实就完事了，但千帆的好处是，选完模型之后还能顺手去 MCP 广场挑几个工具，直接给你的 OpenClaw 装上技能包。

这步体验下来确实比之前丝滑不少。

第三步、选你的操作渠道（可选）

可以直接在消息平台配置选择接入飞书、企业微信、钉钉、QQ，

每一个接入过程都有详细地文档，可以按需使用，然后点击应用

比如，QQ接入，https://cloud.baidu.com/doc/LS/s/xml9eru3h

这里不再赘述，我直接接入了QQ。

第四步、选择skills（可选）

接入了百度搜索、百度百科skills，这里按需选择，直接点击应用。

到这里，基本就配置完成了，你可以选择页面访问，

也可以直接QQ对话。

三个我实际跑通的 Skills 玩法，真的能干活那种

平台工具说了这么多，最终还是得落地。

百度搜索、百度百科、学术检索、智能PPT生成和AI绘本生成，这几个skills的可玩性挺多的。

关于如何在OpenClaw中添加百度的skills，我们可以直接看https://cloud.baidu.com/doc/qianfan/s/Mmlda41a2中的内容。

直接一句话添加，剩下的交给OpenClaw就可以了：

下面分享三个我自己跑通的场景。

不局限于OpenClaw，ClaudeCode、OpenClaude，都可以直接接入这几个skills，直接施展组合技。

玩法一：热点追踪 → 一键出图文材料

用到的 Skills：百度搜索 + 智能 PPT 生成 / AI 绘本生成

这个场景特别适合做内容、做运营的朋友。

我试了一下，直接给 OpenClaw 扔了一句话：

"帮我搜一下今天 AI 领域最重要的三条新闻，然后整理成一份简报 PPT。"

它的执行链路大概是这样的：

1. 先调用百度搜索 Skill，从全网检索实时信息
2. 自动筛选、去重、提取核心内容
3. 把整理好的内容丢给智能 PPT 生成 Skill
4. 直接输出一份带标题、分页、核心要点的 PPT

整个过程我啥也没干，就等着收材料。

如果你不想要 PPT 格式，换成 AI 绘本生成也行——它会把新闻内容变成图文并茂的绘本形式，特别适合发朋友圈或者做社交媒体内容。

以前做一份热点简报，你得先翻一圈新闻网站，然后自己写摘要，再打开 PPT 模板排版..

【插入PPT GIF图片】

现在一句话搞定。

这个场景还能拓展：

• 每天早上定时跑一次，自动生成 AI 行业早报
• 输入某个关键词，自动追踪相关热点并生成周报
• 做竞品监控，一有动态就出分析材料

核心逻辑就是：搜索 Skill 负责"找信息"，PPT/绘本 Skill 负责"出成果"，中间 Agent 负责"串起来"。

玩法二：学术研究 Agent：会查资料、会核实、还会追问

用到的 Skills：学术检索 + 百度百科 + 深度研究 Agent

这个场景偏硬核一些，适合做研究、做咨询、写报告的朋友。

普通的 AI 搜索是这样的：你问一个问题，它给你一个答案，完事了。

但接上学术检索和百度百科这两个 Skill 之后，OpenClaw 干的事就不一样了。

我试着让它研究一个课题：AI Agent 在企业服务领域的落地现状与挑战

它的工作方式是这样的：

1. 先拆解问题——把一个大课题拆成几个子问题

2. 调用学术检索 Skill，去找相关的论文和研究报告

3. 遇到不确定的概念，自动调用百度百科 Skill去核实

4. 整理完一轮之后，它自己又追加了几个问题继续深挖

它更像是一个真的会做研究的助手，不只是搜，还会交叉验证、会追问、会自己判断哪些信息还不够。

百度千帆还有一个深度研究 Agent（deepresearch-conversation），专门做这种多轮拆解的研究场景。接上学术检索和百度百科之后，体验就更接近"企业研究 / 咨询分析"的工作方式了。

如果你平时要写行业分析报告、做市场调研，或者帮老板准备决策材料，

比如刚才的报告，我让它给我补充了一些内容。

这个组合真的建议试试。

玩法三：私董会 × 百度生态：让幕僚带着真数据给你出主意

用到的 Skills：私董会 Skill + 百度搜索 + 百度百科

这个非常有意思，skill搭配组合技。

关注我的老朋友应该知道，之前我做过一个AI 私董会的 Skill，

就是模拟巴菲特、比尔·盖茨、马斯克、乔布斯四位大佬当你的幕僚，通过多轮提问和反馈，帮你深入分析问题、给出可执行的建议。

这个 Skill 之前在社区里反响很不错，很多朋友拿它来做创业决策、职业规划、项目复盘。

但它一直有两个让我觉得不够完美的地方：

第一，幕僚的"人设"全靠模型自己编。

比如巴菲特这个角色，模型知道他是投资大师，但它掌握的信息可能是训练数据里的老内容。关于他最新的持仓变动、最近的股东信里说了什么、今年的投资逻辑有什么变化，模型是不知道的。

第二，幕僚们给建议的时候，全凭"脑补"。

聊投资策略的时候，巴菲特会引用一些经典理论和案例，但这些都是模型"记忆"里的东西。你问一个特别新、特别细的市场问题，他可能就只能泛泛而谈了。

现在有了百度搜索和百度百科的 Skill 之后，这两个问题同时被解决了

幕僚们不仅能"上网查资料"，连自己的背景信息都能实时更新。

什么意思呢？直接看流程图：

这些真实信息直接注入到幕僚的人设里，他们的提问和建议就不再是"通用模板"，而是带着当下真实语境的。

然后在实际咨询环节，幕僚还能随时调用搜索去查数据来支撑自己的观点。

我试了一下，把私董会 Skill 和百度搜索、百度百科接到同一个 OpenClaw 里。然后抛了一个问题：“我想做一个面向中小企业的 AI 培训课程，但不确定市场定位和定价策略。”

效果还不错：

• 巴菲特在分析定价的时候，直接调了百度搜索去查了当前市场上同类课程的价格区间，然后基于真实数据给了定价建议

• 比尔·盖茨聊行业趋势的时候，从百度百科拉了最新的企业培训市场规模数据

• 马斯克聊差异化竞争的时候，搜了几个海内外的竞品案例来佐证他的观点

一句话总结：以前的私董会是"凭经验聊"，现在是"带着数据聊"。

四位幕僚的建议变得更具体、更有针对性。

聊聊生态

前两天刚从百度智能云的 Agent 大会回来，

事情是这样的，百度的朋友邀请去参加这次大会，

我去了之后发现，还有@袋鼠帝@梦飞@宇明，大型好友面基现场，

还给整了个百度千帆开发者大使的身份..

当然，身份不重要，重要的是我在现场发现了一些好玩的东西（如上）。

前面三个Case其实也展示了一个更大的可能性——

不同 Skills 之间的融合，才是 OpenClaw 真正的威力所在。

单个 Skill 是工具，多个 Skill 组合起来就是一套完整的工作流。

而百度千帆 MCP 广场提供了大量现成的"积木块"，你只需要想清楚怎么搭就行。

毕竟百度做搜索做了二十多年了，AI 搜索这块的积累确实是最厚的。

而针对 Agent 的使用方式做了适配。比如学术检索 Skill 返回的结构就很适合 Agent 做后续处理。

从选镜像到配模型到进 Web 端用，整个过程对小白太友好了。特别是部署阶段直接选 Skill 这个设计，把"跑起来"和"能干活"合成了一步，省了很多折腾。

当然，每个云平台都有自己的优势，大家根据自己的需求选就行。

不管云平台怎么选，我觉得这几个skills，都可以给你的🦞助手配置上，非常丝滑。

结语

关于OpenClaw，其实已经写了好几篇的内容了，

今天给大家分享的百度智能云的生态，其实也给OpenClaw提供了工具，

折腾这么多，其实就是为了让更多人能用上 OpenClaw，让它能真的解决你生活中的一些场景。

千帆这些 Skill 生态的组合玩法，才是我觉得真正有想象空间的地方。

后续等我把更多 Skill 组合跑通了，再给大家出详细的教程和玩法拆解。

马上春节了，

这周的精彩其实才刚刚开始，

国内 AI 在这周会发力的~ 期待一波！

以上。

我是甲木，热衷于分享一些AI干货内容，同时也会分享AI在各行业的落地应用，我们下期再见👋🏻

本文由mdnice多平台发布

在互联网安全越来越受到关注的今天，WebRTC 泄露已经成为很多人忽略但又非常危险的隐私问题。

即便你使用了 IP工具 或代理服务器，如果浏览器的 WebRTC 功能不加以控制，你的真实 IP 仍可能被网站探测到。这就意味着所谓的“匿名浏览”可能形同虚设。本文将手把手教你如何防止 WebRTC 泄露。

什么是 WebRTC 泄露？

首先我们得了解，WebRTC（Web Real-Time Communication） 是一种允许浏览器直接进行音视频通话和数据传输的技术。它本身非常方便，但也有隐私隐患：

当你打开支持 WebRTC 的浏览器访问网页时，某些 JavaScript 脚本可以绕过 IP工具 或代理，直接获取你的本地和公网 IP。

这就叫做 WebRTC 泄露，也有人称之为 “IP 泄露”。

泄露的 IP 可以让广告商、网站甚至黑客追踪你的真实位置。

所以，想要安全上网，控制 WebRTC 泄露非常重要。

如何检测自己的 IP 是否被泄露？

在采取防护措施之前，最好先确认自己的 IP 是否真的存在泄露风险。常用方法有：

IP泄露检测网站
打开一些知名的 IP 泄露检测网站，可以快速判断你是否通过 IP工具 暴露了真实 IP。例如，你可以访问一些综合测试页面，看看显示的 IP 是否是你 IP工具 的 IP，还是你真实的公网 IP。

WebRTC 泄露检测工具
有专门的 WebRTC 泄露检测工具网站，可以模拟 WebRTC 请求，判断浏览器是否会暴露本地 IP。

浏览器指纹检测
值得一提的是，浏览器指纹检测 也可能揭示你的一些信息，包括浏览器版本、操作系统、屏幕分辨率等。如果配合 IP 泄露，你的匿名性就更低了。推荐使用 ToDetect指纹查询工具 来检测浏览器指纹安全情况。

通过以上方法，你可以明确自己的隐私风险点，然后针对性防护。

禁止 WebRTC 泄露的实用方法

接下来，重点来了——如何在日常使用中阻止 WebRTC 泄露。这里分浏览器和插件两类方法：

1. 浏览器内置设置

不同浏览器对 WebRTC 的控制方式不同：

Firefox
打开 about:config，搜索 media.peerconnection.enabled，将其值改为 false。这样就可以彻底禁止 WebRTC 连接。

Chrome/Edge
默认 Chrome 没有直接开关，需要借助扩展程序来控制 WebRTC。可以通过 chrome://flags/ 查看实验性功能，但最稳妥的方法还是用插件。

Safari
在 Safari 的设置里，找到“WebRTC 功能”，勾选“阻止所有 WebRTC 公网 IP 地址”，即可防止 IP 泄露。

2. 使用浏览器插件

对于 Chrome、Edge、Firefox 等主流浏览器，使用插件是最方便的方式：

WebRTC Leak Prevent
可以直接阻止 WebRTC 访问本地和公网 IP，同时提供 IP工具 兼容模式。

uBlock Origin
虽然主要用于广告拦截，但高级设置里可以控制 WebRTC 请求。

ScriptSafe / NoScript
可以通过屏蔽不信任的 JavaScript，间接防止 WebRTC 泄露。

这些插件在安装后几乎可以做到“开箱即用”，降低被追踪的风险。

其他提升隐私安全的技巧

除了禁止 WebRTC 泄露，还有一些小技巧可以提升浏览器的隐私保护能力：

定期检测 IP 泄露
每隔一段时间使用 IP泄露检测 或 WebRTC 泄露检测 工具，确保 IP工具 没有被绕过。

使用隐身模式或专门的隐私浏览器
像 Tor Browser 或 Brave，都有更强的防止 浏览器指纹检测 和 IP 泄露的功能。

关注浏览器更新和安全补丁
有些漏洞会被利用来绕过 WebRTC 限制，保持浏览器最新是最基本的防护。

结合 ToDetect 指纹查询工具
通过 ToDetect指纹查询工具，你可以看到自己浏览器的指纹信息是否容易被追踪，进一步优化隐私设置。

总结

WebRTC 泄露 可能看起来小问题，但一旦被追踪，你的匿名性和隐私都会受到影响。实用的方法就是：

定期做 IP泄露检测 和 WebRTC 泄露检测。

根据浏览器类型，关闭或限制 WebRTC 功能。

使用可靠的隐私插件，比如 WebRTC Leak Prevent。

检测浏览器指纹，利用 ToDetect指纹查询工具 做进一步优化。

只要按照这些步骤操作，你就能大幅降低 IP泄露 风险，保护自己在网络世界的隐私安全。

前几日在在电梯里听见的谈论：

“你这几年换了三份工作啊？”
“嗯。”
“厉害……也有点飘。”
电梯门一合，扣好“草率”的标签，一整天都刮着风。

与其争辩，不如换个叙述方式。今天不讲数据，讲一个三幕小剧场，把“稳定”与“跳槽”请上台，各自说话。

第一幕｜传统观念的回音墙

父母视角：稳定=安全。“铁饭碗至少不饿肚子。”
邻里视角：稳定=体面。“单位名片比名片上人名重要。”
部分HR视角：稳定=可靠。“履历像一条直线，省心。”

这些声音没有错，只是来自过去的经济逻辑：岗位稀缺、失败成本高、信息不透明。
但现在的职场像一条不断分叉的河。你原地扎营可以，但也许更好的水草在拐弯处。
“稳定”如果只是不变，那更像卡在河床上的一块石头；真正的稳定，是在变化中保持可控。

金句：稳定是结果，不是方式；不变不一定叫稳定，掌控才叫稳定。

第二幕｜跳槽与成长：换工作，别只换门禁卡

跳槽，最怕“换来换去，只换了工牌颜色”。
判断有没有成长，看四件事：

问题强度：新岗位的难题，是否比原来的更大、更复杂、更贴近业务核心？
可迁移资产：你带走了什么“随身武器”（写作、分析、项目推进、谈判、行业认知）？
视角宽度：是否从“执行者”升到“设计者/决策参与者”的视角？
作品与证据：能不能用一页纸/一个仓库/一个案例说服陌生人？

如果这四件事持续上台阶，频率不是原罪；如果只是为了逃避情绪、老板、加班——那叫逃跑，不是跳槽。

金句：好的跳槽，是把履历写进能力；坏的跳槽，是把心情写进简历。

跳槽机-会

技术大厂，前端-后端-测试，全国均有机-会，感兴趣可以试试。待遇和稳定性都还不错~

第三幕｜什么样的跳槽才算“有价值”？

给你一块价值跳槽九宫格（自测用，过半即值得）：

方向：行业在向上？岗位贴近价值链核心？
密度：问题更难？反馈更快？产出更可见？
导师：能跟到真正在干活、愿意带人的上级？
舞台：边界更大（预算/权限/跨部门协作）？
节奏：迭代更短（周/月为单位复盘）？
证据：离职时能留下公开作品或可量化战绩？
现金：不是只涨工资，而是单位时间成长更高？
生活：通勤、作息、健康是否更可持续？
心流：进入“做着做着忘了时间”的那种投入？

能勾中6格以上，才叫“向上的移动”。
别只看薪资条，那是果；先看问题强度与可迁移资产，那是根。

四不跳（写得像贴在显示器上的小贴纸）：

不为发泄而跳（吵完架写辞职信，第二天先删草稿）。
不为名头而跳（Title 高一号，问题却更边角）。
不为“跟风”而跳（朋友涨薪=他的剧本，你得看自己的镜头）。
不为“逃离”而跳（去哪儿都一样累=问题在方法，不在公司）。

行动卡｜下一次跳之前，先做这三件小事

写一封给未来雇主的信（300字）
只回答三问：我解决过什么问题→用过什么方法→带来了什么改变。写不出来，就别急着跳。


做一张“技能-行业”二维表
横轴列出你拥有或在学的3–5项通用技能，纵轴放3个感兴趣行业，把可迁移的交叉点标星。星星越多，越值得跳。


安排一次“影子体验”
找目标岗位的人聊30分钟，围绕一天在做什么、最难的问题、如何被衡量三件事。聊不到，说明信息还不够，先别跳。

给“稳定派”与“跳槽派”的一封并信

稳定派：请把“稳定”从“年头写到年尾”改成“能力结构可复用、现金流有弹性、健康不透支”。那是强者的稳定。
跳槽派：请把“跳”从“情绪出口”改成“能力跃迁”。那是成熟的跳槽。

人和岗位不是孰优孰劣，是匹不匹配。
频繁跳槽的人，并不比稳定工作的人差；真正的差别在于：
有人在原地生长，有人在移动中生长；有人只是换地方，有人换了层级。

当你能把每一次选择，都解释为更清晰的方向、更锋利的能力、更合理的生活——
你的履历，就不再是“跳来跳去”，而是一步一个台阶。

——转载自：狗头大军之江苏分军

前言

本小节继续来描述istio对于流量的各种操作

流量镜像

对标nginx的mirror功能，复制一份流量到对应的地址去，通常用来做从线上环境引流至其他环境做测试或者分析

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com
  http:
  - mirror:
      host: backend-service
      subset: v1
    mirrorPercentage:
      value: 100
    route:
    - destination:
        host: backend-service
        subset: v0

流量先到v0版本，istio-proxy复制一份流量到v1版本。如果不想1比1复刻，可以调整mirrorPercentage百分比功能

如果mirror host的目标不存在，怎么发现该错误及时调整host配置呢？

超时/重试

配置超时/重试的原因主要是为了解决：

• 调用外部网络的接口，很容易产生诸如502、504、499，甚至连接中断等问题，有了重试，可以尽可能的尝试再次发起，而不是直接报错
• 公用云网络抖动，导致客户端收到一堆5xx，从而引起客户产生不适
• 后端服务没有优雅更新，一旦发版，导致大量502，重试可以缓解502，避免告警风暴

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: backend-retry
spec:
  hosts:
  - backend-service
  http:
  - route:
    - destination:
        host: backend-service
    timeout: 1s
    retries:
      attempts: 3  # 最大重试次数
      perTryTimeout: 1s  # 每次尝试的超时
      retryOn:  # 触发重试的条件
        - 5xx
        - gateway-error
        - connect-failure
        - refused-stream

有位老哥说了，如果一套qps很高的集群，一旦发生重试，那就意味着短时间之内上游服务的qps至少翻一倍（第一波请求不成功，很快第二波请求就要来了），那这时候上游服务就有被冲垮的风险

说的没错，重试是为了提高请求的成功率，但是不可避免增加系统负载，并且增加请求的响应时间，如果大量重试，那就会导致重试风暴，带来更大的问题

重试次数

为了避免重试风暴，在配置策略的时候应该考虑合理的重试次数

    retries:
      attempts: 3  # 最大重试次数
      perTryTimeout: 1s  # 每次尝试的超时

重试3次，每次间隔1s，然后就应该报错，介入查看了

级联超时

超时时间逐层递减，前端超时 > 网关超时 > 服务超时
frontend: timeout: 5s
nginx-test: timeout: 3s
backend-service: timeout: 2s

退避策略

简而言之，就是重试失败之后不是马上重试，而是等一段时间再重试

• 固定退避（Fixed Backoff）：每次重试等待固定时间

  • attempt 1: 等待 100ms
  • attempt 2: 等待 100ms
  • attempt 3: 等待 100ms

• 线性退避（Linear Backoff）：等待时间线性增加

  • attempt 1: 等待 100ms
  • attempt 2: 等待 200ms
  • attempt 3: 等待 300ms

• 指数退避（Exponential Backoff）：等待时间按指数增加（乘以系数），最使用也最常用

  • attempt 1: 等待 100ms
  • attempt 2: 等待 200ms
  • attempt 3: 等待 400ms
  • attempt 4: 等待 800ms
  • attempt 5: 等待 1600ms

• 随机退避（Jitter/随机抖动）：在退避时间中加入随机性，打破同一时间重试，避免"惊群效应"

  • attempt 1: 等待 100ms ± 随机时间
  • attempt 2: 等待 200ms ± 随机时间

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com
  http:
  - retries:
      attempts: 10
      perTryTimeout: 1s
      retryOn: 5xx,connect-failure
    route:
    - destination:
        host: backend-service
        subset: v0

测试istio-proxy的策略

istio-proxy自带了指数退避与随机退避，初始25ms

为了探索istio-proxy是否带有指数退避与随机退避的特点，特意设置attempts: 10（日常用可以设置小一点，比如笔者通常设置为3）

设置后端报错代码，只要报错5xx即可，所以我直接将代码的关键字改错，应该会报语法错误或者方法找不到之类的

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/tornado/web.py", line 1846, in _execute
    result = method(*self.path_args, **self.path_kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/test.py", line 9, in get
    self.writ(ret)
    ^^^^^^^^^
AttributeError: 'TestFlow' object has no attribute 'writ'

都准备好了，开始测试：

• curl -s -H 'host: api.wilsontest.com' 10.22.12.178:30785/test

• 查看日志，有11条日志，符合预期：第1次访问+attempts: 10

  [2026-02-05T06:51:41.322Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:41.332Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:41.369Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default
  [2026-02-05T06:51:41.441Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:41.463Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default
  [2026-02-05T06:51:41.480Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:41.660Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:41.787Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:41.804Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:41.978Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default
  [2026-02-05T06:51:42.116Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default

• 分析下时间

  序号	时间戳	与上一次间隔
  1	41.322	—
  2	41.332	+10ms
  3	41.369	+37ms
  4	41.441	+72ms
  5	41.463	+22ms
  6	41.480	+17ms
  7	41.660	+180ms
  8	41.787	+127ms
  9	41.804	+17ms
  10	41.978	+174ms
  11	42.116	+138ms

• 从日志看来确实满足了指数+随机，初始 backoff：~25ms、指数增长、加入 jitter（随机抖动）

  • 10ms → 37ms → 72ms → 180ms → 127ms → 174ms → 138ms

经过这次简单的测试：

• 配置重试应该要针对幂等的request，非幂等是绝对不能使用重试的
• retries应该要配置小一些，否则就会出现重试风暴，就像测试中10次，相当于原请求放大了10倍

熔断

熔断是为了保护后端服务不被流量风暴淹没，保护系统整体稳定

• 目标：如果后端检测5xx，超过3次，就将该pod踢下线，30s之后又加回来

  apiVersion: networking.istio.io/v1
  kind: DestinationRule
  metadata:
    name: backend-dr
    namespace: default
  spec:
    host: backend-service
    subsets:
    - labels:
        version: v0
      name: v0
    trafficPolicy:
      outlierDetection:
        baseEjectionTime: 30s
        consecutive5xxErrors: 3
        interval: 5s
        maxEjectionPercent: 100

  • baseEjectionTime： 30s：服务被下线的时间，30s
  • consecutive5xxErrors: 3：触发熔断的条件，有3次5xx
  • interval: 5s：检测间隔，5s
  • maxEjectionPercent： 100，被下线的服务比例，100%

• 后端backend服务依然会报错500，先访问3次，curl -s -H 'host: api.wilsontest.com' 10.22.12.178:30785/test

  Traceback (most recent call last):
    File "/usr/local/lib/python3.11/site-packages/tornado/web.py", line 1846, in _execute
      result = method(*self.path_args, **self.path_kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/opt/test.py", line 9, in get
      self.writ(ret)

• 第四次再访问

  no healthy upstream

• 符合预期，第四次服务直接被熔断了，并且由于backend的pod只有1个，istio下线了，导致nginx没有upstream

限流

首先基于http1.1，每次发起http并不是短链了，而是长连接。为了不让每次都产生3次握手与4次挥手的连接消耗，istio-proxy与后端服务backend之间会维护一个长连接

• 配置在DestinationRule上

  apiVersion: networking.istio.io/v1
  kind: DestinationRule
  metadata:
    name: backend-dr
    namespace: default
  spec:
    host: backend-service
    subsets:
    - labels:
        version: v0
      name: v0
    trafficPolicy:
      connectionPool:
        http:
          http1MaxPendingRequests: 1
          maxRequestsPerConnection: 5
  

  • http1MaxPendingRequests: 1与maxRequestsPerConnection: 5是为了方便测试，改得非常的小
  • http1MaxPendingRequests: 1：等待“可用连接”的 HTTP 请求数量，如果没有可用连接，最多允许1个，超出就报503
  • maxRequestsPerConnection: 5：一条 TCP 连接上最多处理多少个 HTTP 请求

• 使用wrk压测工具，用20个并发，同时发送20个连接，向目标url发送请求，持续1s

  ▶ wrk -t20 -c20 -d1s -H 'Host: api.wilson.com' http://10.22.12.178:30785/test
  Running 1s test @ http://10.22.12.178:30785/test
    20 threads and 20 connections
    Thread Stats   Avg      Stdev     Max   +/- Stdev
      Latency    10.66ms    3.18ms  21.85ms   76.73%
      Req/Sec    93.55     16.33   171.00     80.75%
    1990 requests in 1.10s, 650.09KB read
    Non-2xx or 3xx responses: 92
  Requests/sec:   1808.21
  Transfer/sec:    590.70KB
  

  • 可以看到，1秒之内有1990个请求发送至目标url
  • 其中有92个请求有问题

• 检查日志

  ...
  [2026-02-06T07:37:08.168Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.73:10000 duration=5ms route=default
  [2026-02-06T07:37:08.169Z] "GET /test HTTP/1.1" 503 UO upstream=- duration=0ms route=default
  [2026-02-06T07:37:08.169Z] "GET /test HTTP/1.1" 0 DC upstream=10.244.0.73:10000 duration=4ms route=default
  ...

  • http_code是200是正常请求，503就是熔断保护的结果，触发了istio熔断保护而返回客户端503
  • http_code是0，通常意味着 连接在 HTTP 响应头完整返回之前就已经断开了，这非常类似于nginx的499。他们本质都描述了一个问题，客户端没有等到结果就终止连接了，这应该和我们压测只持续了1s有关系

联系我

• 联系我，做深入的交流

至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...

今日，OpenAtom openKylin（以下简称“openKylin”）社区正式推送 openKylin 2.0 SP2 第二次更新升级。本次更新针对系统稳定性，共修复200余项缺陷，重点解决蓝牙连接异常（如文件传输中断、弹窗错位）、双屏显示不稳定等问题；强化多语言支持，提升藏文、蒙古文、繁体中文等界面翻译的覆盖度；完善核心功能，优化软件商店装包稳定性、驱动兼容性（如 Realtek 8852BE WiFi网卡）；上线支持磐石架构的KMRE移动兼容环境、openKylin Wine助手；升级火狐浏览器、微信、QQ 等高频应用至最新稳定版本等。

01系统安装与升级方式
方式一：从openKylin官网（扫描下方二维码或点击“阅读原文”）下载最新镜像进行安装（适用于新用户或想重新安装系统的用户）；

方式二：前往系统设置—“更新”界面，按提示完成系统更新（适用于已安装旧版本的用户）；

方式三：打开维护模式（设置-关于-点击5次UKUI Logo-侧边栏找到维护模式并打开），通过终端运行以下命令进行更新，升级后退出维护模式（适用于开发者）：sudo apt updatesudo apt upgrade

02主要缺陷修复及体验优化
主要缺陷修复
桌面环境
【通知中心】修复藏文环境下鼠标悬浮通知中心图标，提示英文的问题【网络管理】修复wifi优先级设置未立即生效的问题【网络管理】修复新建有线网不进行授权认证，点击保存，第二次超时弹窗未汉化的问题【网络管理】修复新建有线网络，点击保存，认证弹窗点击失败，添加失败弹窗未汉化的问题【网络管理】优化无线网络连接，修复部分用户反馈的检测不到无线网络的问题【文件管理器】修复藏文下，文件管理器标题栏选项按钮中的Samba拼写错误的问题【文件管理器】修复繁体环境下，文管窗口文档部分显示英文的问题【文件管理器】修复复制大文件时任务栏窗口显示异常的问题【文件管理器】修复切换为藏文后，文件管理器中存在乱码的问题【文件管理器】修复英文下最大、次最大字体时窗口显示有遮挡的问题【文件管理器】修复用户反馈的繁体环境下，鼠标右键菜单里部分选项未被翻译为繁体的问题【文件管理器】修复用户反馈的双击启动应用程序相较于右键启动有很大延迟的问题【文件管理器】修复用户反馈的在分辨率缩放情况下，桌面壁纸异常显示的问题【文件管理器】优化大量文件同时拷贝等场景下出现崩溃的问题【文件管理器】修复右键双击标题栏，窗口会最大化的问题【侧边栏】修复藏文、蒙古文、繁体下，侧边栏部分字体仍显示英文的问题【登录锁频】修复部分用户反馈的关机再开机或者重启，需要大约1分钟时间才显示登录界面，且登录界面显示异常的问题【登录锁屏】修复不能正常开机自启动小键盘的问题【登录锁屏】修复切换其他语言，锁屏/登录界面，无线网络连接时提示信息为英文的问题【登录锁屏】修复忘记密码的提示文案不正确的问题【登录锁屏】修复相册屏保未自动轮播的问题【登录锁屏】修复用户反馈的设置了限制密码错误次数后，输入正确密码但锁定三分钟的问题【USD】修复英文环境下非最小字体由小到大切换时按钮文字显示不全的问题【USD】修复藏文最大字体下确认报警信息弹窗按钮文字显示不全的问题【会话管理器】修复多用户登录的情况下，右键开始菜单，点击电源选项-重启/关机，没有多用户重启提示的问题【会话管理器】修复存在未保存的WPS文件、画图文件时，执行重启/关机/注销，没有任何提示，直接重启/关机/注销的问题【会话管理器】修复用户反馈的遇到电源键鼠标左键点击无效的问题【开始菜单】修复登录两个用户，右键开始菜单，点击重启/关机，没有弹窗提示，直接关机/重启的问题【开始菜单】修复切换到字母排序或功能排序后，按上下方向键无法移动到字母导航栏或功能导航栏的问题【开始菜单】修复系统语言为繁体，部分显示为英文的问题【控制面板】修复控制面板中选择德语重启后不勾选的问题【控制面板】修复默认应用不正确的问题【控制面板】修复用户反馈的VPN在设置中关闭vpn后，重启会自动恢复的问题【控制面板】修复用户反馈的系统快捷键设置存在冲突时的提示不够明确的问题【控制面板】修复wlcom环境下，首次打开设置-关于，设置窗口会异常缩小的问题【控制面板】修复侧边栏AI管理模块缺失图标的问题【快捷键】修复自定义快捷键，无法设置按键组合的问题【蓝牙】修复打开托盘处蓝牙，再打开屏幕键盘，关闭屏幕键盘后，蓝牙弹窗没有恢复到原来位置的问题【蓝牙】修复断开已连接的蓝牙设备，在任务栏界面该设备移动界面最低部的问题【蓝牙】修复多次发起批量文件，发送端和接收端文件不一致的问题【蓝牙】修复繁体时，发送文件弹窗存在英文的问题【蓝牙】修复连接蓝牙设备失败，一直处于连接状态，重新打开控制面板扫描不到蓝牙设备的问题【蓝牙】修复音频设备的主动连接弹窗显示不正确的问题【任务栏】修复wlcom环境下，应用打开子窗口的情况下，任务栏软件图标或预览图无法激活应用的问题【任务栏】修复藏文、蒙古文、繁体文任务栏部分内容未翻译的问题【任务栏】修复藏文/蒙古文/繁体文系统，开始菜单悬浮提示未汉化的问题【任务栏】修复多用户重启系统时，会话工具存在任务栏图标的问题【任务栏】修复任务栏固定应用数量超过任务栏宽度，往右拖动最右侧的应用任务栏会自动滑到最左侧的问题【任务栏】修复英文环境下，快捷菜单冷冻模式和wifi显示不完全，悬浮无提示的问题【任务栏】修复用户反馈的任务栏“显示桌面”按钮区域并没有完全覆盖任务栏的最右边，导致滑到屏幕右下角点击无效的问题【任务栏】修复悬浮任务栏开始菜单图标，显示为英文的问题【会话管理器】修复WPS文件编辑未保存，点击电源-关机，没有提示未保存，机器直接关机的问题【主题】修复wlcom环境下，控制面板背景设置后不生效，重启才生效的问题【主题】修复藏文环境下系统，主题界面按钮文字显示不完全的问题【区域语言】修复藏文系统下，输入法设置显示为中文的问题【区域语言】修复藏文系统下，添加语言弹窗关闭按钮悬浮为英文的问题【时间和日期】修复藏文系统下，授权弹窗藏化不完全的问题【时间和日期】修复添加时区和修改时区页面关闭按钮悬浮为英文的问题【时间和语言】修复在修改时区和添加时区搜索框输入不存在的时区，没有无结果的提示的问题

系统应用
【归档管理器】修复解压缩后的弹窗“显示文件”，弹出两个文件管理器界面的问题【归档管理器】修复蒙古文环境下，存在部分的翻译异常问题【计算器】修复ARM架构下，用键盘的数字无法输入的问题【计算器】修复蒙古文计算器标题栏为英文，且选项菜单存在英文显示的问题【截图】修复区域截图后无法选择字体的问题【微信】修复订阅号页面无法调用系统默认浏览器的问题【开明包格式】修复运行开源系列的开明包应用均无图标的问题【天气】优化天气出现定位不准的问题【录音】修复蒙古文右键点击已存在的录音文件，下拉菜单存在英文内容的问题【用户手册】修复英文环境下，关于界面的图片所属张数错误的问题【日历】 修复英文环境下，日程中存在部分项悬浮没有内容的问题【U盘管理工具】修复英文环境下，插入异常U盘，提示弹窗格式化按钮显示不全的问题【系统监视器】修复系统语言为蒙古文，会话管理器下方系统监视器显示简体中文的问题【系统监视器】修复磁盘详情页面连续点击不同磁盘应用闪退的问题【虚拟键盘】修复用户反馈的鼠标拖动移动悬浮球与虚拟键盘时，出现悬浮球与虚拟键盘严重抖动的问题【虚拟键盘】修复用户反馈的鼠标长按虚拟键盘时，键盘出现闪烁的问题【音乐】修复蒙古文环境下，存在部分的翻译异常问题【日历】修复调整缩放率为175%和200%，日历页面位置异常的问题【日历】修复用户反馈的农历时间存在错误的问题【麒麟管家】修复部分用户反馈的麒麟管家应用右上角关闭按钮变小的问题【麒麟管家】修复用户反馈的通过服务支持反馈问题时，一旦勾选高级模式，界面就不正常的问题【软件商店】根据社区用户反馈，上架最新版原生微信、QQ音乐等应用【软件商店】修复软件商店更新下点击更新某些应用，提示安装失败的问题【软件商店】修复正在下载界面内悬浮在软件上，悬浮显示的网速位置在窗口右侧的问题【第三方软件】修复用户反馈的 WPS办公软件卸载不完全的问题

系统支撑
【wlcom】修复命令行启动应用，窗管显示异常的问题【安装器】修复英文环境-大号字体下，卸载器界面存在截断的问题【安装器】修复应用图标显示为默认图标时，图标显示较小且居于左上角的问题【安装器】修复用户反馈的浏览器下载qq安装包无法安装的问题【电源管理】修复控制面板中电源管理模块未翻译完全的问题【电源管理】修复英文模式下，查看控制面板-系统-电源，各子选项中存在首字母未大写情况的问题【定时关机】修复菜单栏的“选项”按钮，悬浮提示显示“更多”，与其它应用显示不一致的问题【定时关机】修复设置时间为当前时间，剩余时间显示错误的问题【多语言】修复Wayland模式下，英文模式切换到法语无法切换的问题【龙芯】修复部分龙芯平台机型上无法进入桌面的问题【系统启动】优化系统重启等待时间【软件源】修复pristine-tar的依赖问题【软件源】修复下载安装libkysdk-system-dev时报错的问题【声音】修复英文下用户手册缺少内容介绍的问题【系统安装】修复安装各界面滚动条、输入框未屏蔽右键菜单的问题【系统安装】修复部分用户反馈的在多系统共存环境下安装不成功的问题【系统安装】修复系统安装流程中存在的部分未汉化的问题【系统安装】修复虚拟机安装时，数据盘分区太小的问题【显示器】修复用户反馈的出现系统崩溃：Abnormal display,and the input method cannot be sw的问题【显示器】修复镜像模式下，显示器预览图为两个的问题【显示器】修复镜像模式下插拔显示器进行旋转，两个屏幕显示不同步的问题【显示器】修复扩展模式下，调整其中一个屏幕亮度另一个屏幕亮度也会随之改变的问题【显示器】修复连接多个显示器进行插拔，控制面板内显示多个亮度条的问题【显示器】修复连接双屏，设置投影仪为主屏，关闭投影仪，主屏未切换到显示器上的问题【显示器】修复连接投影仪，屏幕旋转90°，重启后桌面花屏的问题【显示器】修复屏幕旋转后点击桌面，桌面呈现黑色部分的问题【显示器】修复切换分辨率后，点击桌面壁纸发生变化的问题【显示器】修复拖动预览图改变屏幕相对位置，4K屏会闪现部分黑屏的问题【显示器】修复用户反馈的在高分辨率下在VMware虚拟机上出现的屏闪问题【硬件驱动】修复Realtek 8852BE Wireless LAN WiFi 6 PCI-E NIC网卡无法驱动的问题

在上一篇 Flink SQL 极简入门 中，我们体验了 Flink SQL 的基础用法。但在流处理中，最核心、最迷人（也最让人头秃）的概念莫过于“时间”和“窗口（Window）”。

你可能经常听到这样的业务需求：

• “每 5 分钟统计一次订单总量”
• “实时统计过去 1 小时内的热门商品，每 10 秒更新一次”
• “每天 0 点到当前时刻的累计 PV”

这些需求都离不开窗口。今天，我们就来深入 Flink SQL 的窗口机制，看看它是如何驯服无限数据流的。

什么是窗口 (Window)？

流数据（Stream）是无限的，像水流一样源源不断。我们无法计算“无限流”的总和（因为永远算不完）。为了计算，我们需要把无限的流“切”成有限的块，这个“切”的操作就是开窗（Windowing）。

在 Flink SQL 中，窗口主要用于将时间序列上的数据分桶，然后在桶内进行聚合计算（如 SUM, COUNT, AVG）。

新一代标准：Window TVF

在 Flink 1.13 之前，我们主要使用 GROUP WINDOW（如 TUMBLE(rowtime, ...) 在 GROUP BY 子句中）。但从 Flink 1.13 开始，官方推荐使用 Window TVF (Table-Valued Functions)。

Window TVF 符合 SQL 2016 标准，语法更自然，功能更强大（支持 TopN、去重等复杂操作）。本文将以 Window TVF 为主进行讲解。

核心语法结构通常如下：

SELECT window_start, window_end, SUM(price)
FROM TABLE(
    -- 窗口函数
    TUMBLE(TABLE my_table, DESCRIPTOR(ts), INTERVAL '5' MINUTE)
)
GROUP BY window_start, window_end;

三大核心窗口类型

1. 滚动窗口 (Tumble Window)

特点：窗口大小固定，窗口之间不重叠，首尾相接。
场景：每隔 5 分钟统计一次。

语法：
TUMBLE(TABLE data, DESCRIPTOR(time_col), INTERVAL '10' MINUTE)

2. 滑动窗口 (Hop Window)

特点：窗口大小固定，但窗口之间可以重叠。它有两个参数：

1. Window Size (窗口大小)：统计多长时间的数据（如“过去 1 小时”）。
2. Window Slide (滑动步长)：多久更新一次结果（如“每 5 分钟”）。

场景：每 5 分钟，统计过去 1 小时的 PV。

语法：
HOP(TABLE data, DESCRIPTOR(time_col), INTERVAL '5' MINUTE, INTERVAL '1' HOUR)
注意：参数顺序是先 Slide (步长)，后 Size (大小)。

3. 累积窗口 (Cumulate Window)

特点：这是 Flink 特有的窗口，用于解决“每天 0 点至今的累计值”这类需求。它会按步长输出一个个不断变大的窗口，直到达到最大窗口大小。

场景：每天的实时累计销售额（每 10 分钟更新一次看到当天的累计值）。

语法：
CUMULATE(TABLE data, DESCRIPTOR(time_col), INTERVAL '10' MINUTE, INTERVAL '1' DAY)

实战：处理“过去 5 分钟的订单总额”

让我们回到开头的经典需求。假设我们有一个订单流 orders。

0. 准备数据环境

首先，我们启动 SQL Client

./bin/sql-client.sh

创建一个模拟的订单源表（使用 DataGen 连接器）：

CREATE TABLE orders (
    order_id INT,
    price DOUBLE,
    order_time TIMESTAMP(3),
    -- 定义水位线，基于 order_time，延迟 0 秒
    WATERMARK FOR order_time AS order_time - INTERVAL '0' SECOND
) WITH (
    'connector' = 'datagen',
    'rows-per-second' = '1',
    'fields.price.min' = '10',
    'fields.price.max' = '100'
);

需求一：每 5 分钟，统计该 5 分钟内的订单总额

这是一个典型的滚动窗口 (Tumble)。比如 12:00-12:05 一个结果，12:05-12:10 一个结果。

SELECT 
    window_start, 
    window_end, 
    COUNT(*) as total_orders, 
    SUM(price) as total_amount
FROM TABLE(
    TUMBLE(TABLE orders, DESCRIPTOR(order_time), INTERVAL '5' MINUTE)
)
GROUP BY window_start, window_end;

运行结果示例：

需求二：实时统计“过去 5 分钟”的订单总额，每 1 分钟更新一次

这是一个典型的滑动窗口 (Hop)。

• 窗口大小：5 分钟
• 滑动步长：1 分钟

这样，12:00 输出 [11:55, 12:00] 的数据；12:01 输出 [11:56, 12:01] 的数据。

SELECT 
    window_start, 
    window_end, 
    SUM(price) as total_amount
FROM TABLE(
    HOP(TABLE orders, DESCRIPTOR(order_time), INTERVAL '1' MINUTE, INTERVAL '5' MINUTE)
)
GROUP BY window_start, window_end;

运行结果示例：

注意：
HOP 函数的参数中，第一个时间是滑动步长 (Slide)，第二个时间是窗口大小 (Size)。千万别搞反了！
INTERVAL '1' MINUTE = Slide (更新频率)
INTERVAL '5' MINUTE = Size (统计范围)

总结

Flink SQL 的 Window TVF 极大地简化了窗口聚合的写法。

• TUMBLE: 规规矩矩，互不干扰（分批统计）。
• HOP: 藕断丝连，频繁更新（移动平均/最近 N 分钟）。
• CUMULATE: 聚沙成塔，越积越多（日报/大屏累计）。

掌握了这三种窗口，你就能覆盖 90% 的实时统计需求了。

下一篇，我们将挑战更复杂的场景：双流 JOIN，看看当“订单流”遇到“用户流”，Flink 该如何处理？

原文来自

在做IT架构规划时，很多团队都会面临一个核心选择题：到底该用本地服务器，还是走云部署路线？其实这两种方式没有绝对的好坏，关键要看你的业务特性、团队配置和长期规划。

先说说成本结构。本地服务器一般前期投入比较大，包括硬件采购、机房改造这些一次性支出，不过后面每年的运维成本相对可控。而云服务基本是“开箱即用”，起步门槛低，但随着业务规模扩大，月度或年度的费用会逐步上升，长期来看未必更省。

性能方面，本地服务器由于资源独享，通常延迟更低、稳定性也更可控，特别适合对实时性要求高的场景。不过云服务的弹性都是实打实的优势——流量突增时能快速扩容，高峰期过了又能及时缩容，资源利用率更高。

数据安全是很多人关心的话题。本地部署等于把所有数据都握在自己手里，权限管控更直接，适合金融、医疗这类强监管行业。而现在的云服务商在安全上的投入也越来越大，像加密传输、漏洞防护、跨区域容灾这些能力，可能比很多企业自建的水平还要专业。

运维管理上的差异也很明显。本地服务器需要配备专门的IT团队做日常维护，出了问题也得自己排查，技术门槛不低。云服务就省心不少，大部分运维工作都由平台承担，团队可以更专注于业务开发，对技术人员配置要求也没那么高。

那到底该怎么选呢?如果你对数据管控、性能稳定性有强要求，而且有专门的运维团队，本地部署可能更踏实。如果你的业务波动大、增长快，或者希望降低运维复杂度，那云服务的灵活性和便捷性会更合适。

其实现在很多企业都在采用混合架构——核心系统放在本地，弹性业务上云，两边优势互补。不管选哪种方案，找个靠谱的IDC服务商都很重要。毕竟从方案设计到后期运维，专业的团队能帮你避开不少坑，让整个系统跑得更稳更省心。

VMware ESXi 9.0.1.0 macOS Unlocker & OEM BIOS 2.7 集成网迅网卡驱动定制版

VMware ESXi 9.0 macOS Unlocker & OEM BIOS 2.7 集成网卡驱动和 NVMe 驱动 (集成驱动版)

发布 ESXi 9.0 集成驱动版，在个人电脑上运行企业级工作负载

请访问原文链接：https://sysin.org/blog/vmware-esxi-9-sysin/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

2026-01-12，应用户要求，更新集成网迅网卡驱动定制版。

发布 ESXi 9.0 集成驱动版，在个人电脑上运行企业级工作负载，构建开发、测试和学习的最佳平台。

通用特性概览

该版本在官方原版基础上新增以下特性：

• macOS Unlocker：来自 GitHub 的 Unlocker 4，现已支持 macOS Tahoe
• OEM BIOS 2.7：使用社区最流行的 OEM BIOS/EFI64，现已支持 Windows Server 2025
• LegacyCPU support，允许在不受支持的旧款 CPU 上安装 ESXi 9.0
• ESX-OSData 卷大小修改为 8GB，解决自 ESXi 7.0 起系统占用磁盘空间过大的问题（超过 142GB）
• 有限支持采用混合架构的第 12 代及以上 Intel 处理器，可实现正常引导和运行
• 中文界面语言支持，在 ESXi 9.0 的 Host Client 中继续支持简体中文界面语言，包括繁体中文

详情请访问原文链接：https://sysin.org/blog/vmware-esxi-9-sysin/ 查看。

集成网迅网卡驱动定制版

北京网迅科技有限公司是一家专门从事集成电路高端芯片设计、提供网络产品解决方案的高科技企业。公司成立于 2014 年 5 月，总部位于北京市海淀区玉泉慧谷科技园区，在浙江杭州设有分公司。

公司成功研制了自有知识产权的万兆和千兆以太网控制器芯片、适配器，突破了一系列计算机网络领域高端芯片设计的难题，在网络安全和网络虚拟化等方面达到了较高水平。

网迅网卡不仅兼容 Windows 系统和主流的 Linux 发行版，还可以支持最新的 VMware ESXi 系统，远超预期！

以下是经过验证支持最新版 ESXi 的网讯网卡型号。

下载地址

ESXi 9.0.1.0 集成驱动版 (2026-01-12)：

• 发布日期：2026-01-12
• 50 余项已知问题修复。请参看：ESXi 9.0.1.0 已解决的问题。
• 请访问：https://sysin.org/blog/vmware-esxi-9-sysin/

标准版和厂商定制版，请访问：

• VMware ESXi 9.0.1.0 macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

官方原版，请访问：

• VMware vSphere 9.0 正式版发布 - 企业级工作负载平台

上一个版本，请访问：

• VMware ESXi 8.0U3g macOS Unlocker & OEM BIOS 2.7 集成网卡驱动和 NVMe 驱动 (集成驱动版)

更多：VMware 产品下载汇总

写在前面

在 AI 从 “云端集中式” 向 “端侧分布式” 演进的今天，用户对智能体验的需求早已从 “能用” 升级为 “安全、实时、无界”，而 HarmonyOS 凭借原生的端侧 AI 能力与分布式架构，恰好击中了这一行业痛点。不同于依赖云端算力的传统 AI 方案，HarmonyOS 的 AI 套件构建在 “本地计算 + 毫秒响应 + 模型复用” 三大核心优势之上：端侧推理让用户数据全程留在设备内，完美解决了 AI 应用的隐私焦虑；毫秒级的响应速度，让语音交互、实时识别等场景告别 “加载等待”；而系统级的模型复用机制，更是让开发者无需从头训练模型，仅通过标准化接口就能调用成熟的智能能力。那么本文就来以HarmonyOS开发中关于AI套件的技能调用功能的使用来详细聊聊，深入解析如何通过系统级AI接口、分布式协同框架与模型优化工具链，实现高效智能业务开发。

技能调用：端侧 AI 与应用的智能联动机制

技能调用是意图框架依托系统AI多模态大模型能力做深度用户输入理解，并通过解析的用户意图对接应用或元服务内的功能和内容。技能调用的本质，是 HarmonyOS 意图框架借助系统级多模态大模型，对用户输入（语音、文本、图像等）进行深度语义解析，进而关联应用 / 元服务内功能与内容的智能联动机制。它的核心价值，是让用户通过自然语言即可直接触发复杂功能，无需逐层点击界面，实现 “说即所得” 的智能交互。

核心应用场景拆解

使用者通过对小艺对话进行自然语言输入实现内容查询，知识问答，以及通过对图片选定识别问答进行服务获取。技能调用场景分为两种：

• 功能服务类：端侧意图调用直接进入应用或元服务对应意图功能服务页面。

• 信息交互类：云侧意图调用进行内容查询后展示，端侧用户点击进行意图调用闭环。
  典型的使用场景分为：功能服务类和信息交互类两种场景。

  1、信息交互类

  信息交互类的场景分为三种情况，具体如下所示：

• 内容展示场景。例如查找菜谱：语音对话输入“鱼香肉丝怎么做”，即可搜索到对应的菜谱。
• 内容展示+AIGC生成场景。例如查公司：语音对话输入“某公司怎么样”，即可生成并展示关于某公司的信息。

• 功能履约场景。例如订电影票：语音对话输入“买两张今天的电影票，某电影”，即可进行电影票购买选座。

  2、功能服务类

  功能服务类的场景也分为三种情况，具体如下所示：

• 跳转页面不带参数场景。例如打开付款码：语音对话输入“打开xx付款码”，即可弹窗对应付款码。
• 跳转页面带参数场景。例如搜索商品带关键词：语音对话输入“打开xx应用搜一下xx品牌39码”，即可弹窗对应商品。

• 功能执行并展示UIExtension。例如操控蓝牙开关：语音对话输入“打开蓝牙”，即可弹窗蓝牙设置，并打开蓝牙开关。

  技能调用接入全流程

  1、接入方案概述

  关于使用接入方案的概述，开发者需要按照意图定义，进行意图注册并实现意图调用；用户通过对小艺对话进行自然语言输入，小艺理解语义转换成意图调用（含意图参数），执行意图调用实现对应交互体验。HarmonyOS AI 套件的技能调用遵循 “意图定义→意图注册→意图执行” 的标准化流程，具体流程图如下所示：
  

  2、意图注册

  这里以“搜索旅游攻略”特性为例，使用者需要首先注册“查看旅游攻略”（ViewTravelGuides）。开发者需要编辑对应的意图配置PROJECT_HOME/entry/src/main/resources/base/profile/insight_intent.json文件，实现意图注册，具体操作如下所示：

{
  "insightIntents": [
    {
      "intentName": "ViewTravelGuides",
      "domain": "TravelDomain",
      "intentVersion": "1.0.1",
      "srcEntry": "./ets/entryability/InsightIntentExecutorImpl.ets",
      "uiAbility": {
        "ability": "EntryAbility",
        "executeMode": [
          "background",
          "foreground"
        ]
      },
      "uiExtension": {
        "ability": "insightIntentUIExtensionAbility"
      }
    }
  ]
}

其中，配置参数信息如下所示：

技能调用实战：两类核心意图触发

根据上面的接入方案，这里通过前台意图和前台窗口意图两个调用来介绍具体的使用。

1、前台 UIAbility 意图调用实践

具体的使用的时候，需要开发者自己实现InsightIntentExecutor，并在对应回调实现打开详细页（点击推荐卡片跳转的界面，如旅游攻略详细页面）的能力，ViewTravelGuides的意图调用字段定义见查看旅游攻略 （ViewTravelGuides）。实际操作步骤如下：
（1）继承InsightIntentExecutor。
（2）重写对应方法，例如目标拉起前台页面，则可重写onExecuteInUIAbilityForegroundMode方法。
（3）通过意图名称，识别查看旅游攻略意图(ViewTravelGuides)，在对应的方法中传递意图参数（param），并拉起对应落地页（点击推荐卡片跳转的界面，如旅游攻略详细面）。
具体的实现代码如下所示：

import { insightIntent, InsightIntentExecutor } from '@kit.AbilityKit';
import { window } from '@kit.ArkUI';
import { BusinessError } from '@kit.BasicServicesKit';


export default class InsightIntentExecutorImpl extends InsightIntentExecutor {
  private static readonly VIEW_TRAVEL_GUIDES = 'ViewTravelGuides';
  /**
   * override 执行前台UIAbility意图
   *
   * @param name 意图名称
   * @param param 意图参数
   * @param pageLoader 窗口
   * @returns 意图调用结果
   */
  onExecuteInUIAbilityForegroundMode(name: string, param: Record<string, Object>, pageLoader: window.WindowStage):
    Promise<insightIntent.ExecuteResult> {
    // 根据意图名称分发处理逻辑。接入方可根据实际业务实现页面跳转
    switch (name) {
      case InsightIntentExecutorImpl.VIEW_TRAVEL_GUIDES:
        return this.viewTravelGuides(param, pageLoader);
      default:
        break;
    }
    return Promise.resolve({
      code: -1,
      result: {
        message: 'unknown intent'
      }
    } as insightIntent.ExecuteResult)
  }
  /**
   * 实现调用查看旅游攻略功能
   *
   * @param param 意图参数
   * @param pageLoader 窗口
   */
  private viewTravelGuides(param: Record<string, Object>, pageLoader: window.WindowStage): Promise<insightIntent.ExecuteResult> {
    return new Promise((resolve, reject) => {
      // 实现意图调用，loadContent的入参为旅游攻略落地页路径
      pageLoader.loadContent('pages/TravelGuidePage')
        .then(() => {
          let entityId: string = (param.items as Array<object>)?.[0]?.['entityId'];
          resolve({
            code: 0,
            result: {
              message: 'Intent execute succeed'
            }
          });
        })
        .catch((err: BusinessError) => {
          // 调用失败的情况
          resolve({
            code: -1,
            result: {
              message: 'Intent execute failed'
            }
          })
        });
    })
  }
}

2、前台 UIExtension 窗口意图调用实践

具体的使用的时候，开发者还需要自己实现InsightIntentExecutor，并在对应回调实现窗口页面内容加载的能力。实际操作步骤如下：
（1）继承InsightIntentExecutor。
（2）重写对应方法，例如目标拉起前台窗口化页面，则可重写onExecuteInUIExtensionAbility方法。
（3）通过意图名称，识别打开蓝牙意图（LoadBluetoothCard）调用扩展意图，在对应的方法中传递意图参数（param），并拉起对应窗口化页面。
具体的实现代码如下所示：

import { insightIntent, InsightIntentExecutor, UIExtensionContentSession } from '@kit.AbilityKit';

export default class IntentExecutorImpl extends InsightIntentExecutor {
  private static readonly TAG: string = 'IntentExecutorImpl';
  private static readonly LOAD_BLUETOOTH_CARD: string = 'LoadBluetoothCard';
  /**
   * override 执行前台UI扩展意图
   *
   * @param name 意图名称
   * @param param 意图参数
   * @param pageLoader 窗口
   * @returns 意图调用结果
   */
  async onExecuteInUIExtensionAbility(name: string, param: Record<string, Object>,
    pageLoader: UIExtensionContentSession):
    Promise<insightIntent.ExecuteResult> {
    console.info(IntentExecutorImpl.TAG, `onExecuteInUIExtensionAbility`);
    switch (name) {
      case IntentExecutorImpl.LOAD_BLUETOOTH_CARD:

        return this.openLoadBluetoothCard(pageLoader);
      default:

        break;
    }

    let result: insightIntent.ExecuteResult = {
      code: -1,
      result: {
        message: 'onExecuteInUIExtensionAbility failed'
      }
    };
    return result;
  }

  /**
   * 打开加载蓝牙卡片意图
   *
   * @param pageLoader 意图内容Session对象
   * @returns 执行结果
   */
  private async openLoadBluetoothCard(pageLoader: UIExtensionContentSession): Promise<insightIntent.ExecuteResult> {
    pageLoader.loadContent('pages/UiExtensionPage');
    let result: insightIntent.ExecuteResult = {
      code: 0,
      result: {
        message: 'intent execute succeed'
      }
    }
    return result;
  }
}

最后

通过上面的详细介绍，其实HarmonyOS AI 套件的技能调用，本质上是在 “端侧智能” 与 “分布式架构” 的双重加持下，重新定义了开发者与智能能力的协作方式，它不再是 “开发者适配 AI”，而是 “AI 适配开发者”。当其他系统还在依赖云端 AI 的 “远程算力” 时，HarmonyOS 已经通过端侧推理让智能体验 “零延迟、零隐私风险”；当多数框架还在要求开发者掌握复杂的模型训练时，HarmonyOS 的意图框架与预置模型，让个人开发者仅需几行代码就能实现 “自然语言触发功能” 的智能特性。这不仅是技术的平权，更是将 “泛在智能” 从概念落地为可触达的开发工具。随着多模态大模型与 HarmonyOS 分布式硬件的深度绑定，我们将看到更惊人的场景：手机上触发的 “旅游攻略查询”，能自动同步到车机的导航界面；手表上的语音指令，能直接控制智能家居的设备状态，而这一切，都可以通过 AI 套件的技能调用快速实现。

什么是OVSSL证书？

OVSSL证书，即组织验证型SSL证书。它不仅仅验证域名的所有权，更重要的是由权威的CA机构对申请企业或组织的真实存在、合法注册及运营状态进行人工审核。这是其与DV证书最核心的区别。

• 直观体现：安装后，在浏览器地址栏点击小锁图标，可以查看到企业/组织的详细信息。
• 核心价值：建立更强的在线信任，向用户证明网站背后是一个真实合法的实体，常用于企业官网、电子商务、会员登录等需要用户提交敏感信息的场景。
  

如何申请OVSSL证书？（详细步骤）

第一步：前期准备与信息确认

1. 确定域名：明确需要保护的域名（例如 yourcompany.com）。

2. 准备企业资料：这是最关键的一步，确保资料真实、有效且与官方记录一致。

   • 企业营业执照：清晰的彩色扫描件。
   • 企业联系电话：必须是官方公开的、能接通的公司座机号码（非个人手机），用于CA电话核实。
   • 企业邮箱：通常需要使用以申请域名结尾的企业邮箱（如 admin@yourcompany.com），用于接收验证邮件。部分CA也接受其他公认的企业邮箱。
   • 申请者信息：申请人的姓名、职位、公司座机、个人邮箱。

第二步：选择证书服务商（CA或经销商）并下单

访问JoySSL官方网站，在右上角找到“注册”按钮并点击。填写相关信息，创建一个证书管理账号。注册过程中，务必填写特定的注册码230970，这样才可以获得渠道低价和全程技术支持。

OVSSL证书申请入口

1、选择证书类型与年限

登录账号后，进入SSL证书栏，找到“OV证书”选项。根据自身需求，选择OV单域名、OV通配符、或者OV IP地址等SSL证书后，点击“下单”，并通过在线支付或公对公转账的方式完成支付。

2、申请证书

在申请页面，需要填写一系列信息，包括域名、单位名称、联系人、联系方式、邮箱等。这些信息将用于验证单位的真实性，所以务必确保准确无误。

3、验证域名或IP的管理权

提交申请后，并要求验证域名或者IP地址的所有权。按照系统提示的操作步骤进行验证，包括域名DNS解析认证或者服务器文件验证，操作完成后提交。

4、组织信息审核

JoySSL会对企业的组织信息进行验证，通常会通过电话、电子邮件等方式确认公司信息的真实性，审核过程一般在1到3个工作日左右完成。

4、部署证书

一旦审核通过后，JoySSL将签发OV SSL证书。下载已经签发的证书，根据JoySSL提供的安装指南或服务器文档，将证书安装到服务器上。

前言

在万物互联的全场景时代，设备之间的边界正在消失，安全认证已不再是单一设备的 “孤岛式” 防御，而是跨端协同的 “全链路” 保障。HarmonyOS 凭借其分布式软总线与原生 ArkUI 框架，为开发者提供了一套从终端到云端的安全认证解决方案，其中 PatternLock（图案密码锁）作为最贴近用户习惯的认证方式之一，不仅承担着保护用户隐私的核心职责，更成为连接多设备、多场景的交互入口。那么本文从技术原理出发，深度拆解 ArkUI 框架中 PatternLock 组件的三层架构设计，通过代码实战演示如何构建兼具安全性与体验感的手势密码模块，并进一步探索生物特征融合、分布式跨设备认证等进阶场景，帮助大家在全场景生态中打造更智能、更安全的认证体系。

PatternLock概念

在HarmonyOS开发中，PatternLock是图案密码锁组件，以九宫格图案的方式输入密码，用于密码验证场景。手指在PatternLock组件区域按下时开始进入输入状态，手指离开屏幕时结束输入状态完成密码输入。（需要说明的是，该组件从API Version 9开始支持。）
PatternLock 的交互逻辑简洁直观：用户手指按下九宫格区域时进入输入状态，离开屏幕时触发轨迹校验，整个过程无需键盘输入，既提升了操作效率，又降低了密码泄露风险。

PatternLock核心功能解析

1、组件架构特性

PatternLock是ArkUI框架提供的安全认证组件，采用三层架构设计：

• 交互层：提供可定制的九宫格绘制界面，支持动态波纹反馈、连线样式自定义，让输入过程更具视觉引导性；
• 控制层：通过PatternLockController实现组件状态的实时控制，包括密码重置、锁定时长配置、验证结果反馈等核心能力；

• 数据层：内置哈希算法对轨迹坐标进行不可逆加密，并支持与 HarmonyOS 系统安全服务联动，确保密码传输与存储的安全性。

  2、核心参数配置

  组件的核心参数可灵活调整，以适配不同界面风格与交互需求：
  

3、样式继承树

关于PatternLock的样式继承树，如下所示：

PatternLock → CommonShape → CommonAttribute → Component

PatternLock样式设置

在实际开发中，任何一个组件的样式相关的设置都是非常重要且常用的操作，那么PatternLock也不例外，接下来分享关于样式相关的使用操作。

这里只分享关于PatternLock的样式设置相关的参数，具体的实际使用会在下一部分详细分享。

关于PatternLock的基础使用

1、组件初始化与控制器绑定

使用 PatternLock 的第一步是引入组件库并创建控制器实例，以实现状态的统一管理，具体如下所示：

// 导入组件库
import { PatternLock, PatternLockController } from '@ohos.arkui.ts/components';

// 创建控制器实例
private patternLockCtrl: PatternLockController = new PatternLockController();

2、基础布局与视觉定制

通过链式调用属性方法，可快速完成九宫格的布局与样式配置，包括尺寸、颜色、动态效果等，如下所示：

PatternLock(this.patternLockController)
        .sideLength(200)
        .circleRadius(9)
        .pathStrokeWidth(5)
        .regularColor('#ff182431') // 未选中的颜色
        .activeColor('#707070') // 激活状态的颜色
        .selectedColor('#707070') // 选中状态的颜色
        .pathColor('#707070') // 连线颜色
        .backgroundColor('#F5F5F5') // 背景色
        .autoReset(true)
        .activateCircleStyle({ // 动态波纹效果
            color: Color.Blue,
            radius: { value: 18, unit: LengthUnit.VP },
            enableWaveEffect: true  // 启用波纹动画
        })
        .onDotConnect((index: number) => {
          console.log("onDotConnect index: " + index)
          this.handlePatternComplete(index) // 具体实现方法在下一部分会介绍
        })

3、事件处理与安全校验

密码输入完成后，需通过事件回调实现业务逻辑处理，包括长度验证、加密传输与异常拦截，手势完成回调，如下所示：

private handlePatternComplete(input: number[]) {
    if (input.length < 5) {
        this.showToast("至少连接5个点");
        return;
    }
    const encrypted = this.encryptPattern(input); // 加密方法如下面关于密码加密算法所示
    this.validateWithServer(encrypted);
}

由于涉及到加密的设置，关于密码加密算法如下所示：

private encryptPattern(coordinates: number[]): string {
    const salt = cryptoFramework.createRandom(16);
    const sha256 = cryptoFramework.createHash("SHA256");
    sha256.update({ data: new Int32Array(coordinates) });
    return sha256.digest().then(hash => {
        return salt + hash.toHex();
    });
}

关于异常处理机制，如下所示：

private errorCount: number = 0;

private handleValidationError() {
    this.errorCount++;
    if (this.errorCount >= 3) {
        this.patternLockCtrl.lock(30000); // 锁定30秒
        this.showAlert("账号已锁定");
    }
}

4、专属事件与控制器能力

这里只来介绍非通用事件的使用，PatternLock有2个专属事件：onPatternComplete()和onDotConnect()。

（1）onPatternComplete()方法

语法：

onPatternComplete(callback: (input: Array<number>) => void)

使用：密码输入结束时触发该回调。
参数：

（2）onDotConnect()方法

语法：

onDotConnect(callback: Callback<number>)

使用：密码输入选中宫格圆点时触发该回调。
说明：回调参数为选中宫格圆点顺序的数字，数字为选中宫格圆点的索引值（第一行圆点从左往右依次为0、1、2，第二行圆点依次为3、4、5，第三行圆点依次为6、7、8）。

5、构造函数

constructor()是PatternLockController的构造函数。
系统能力： SystemCapability.ArkUI.ArkUI.Full

6、重置状态

reset()是重置组件状态。
系统能力： SystemCapability.ArkUI.ArkUI.Full

7、高阶玩法

然后再分享2个高阶一点的玩法。
生物特征融合认证，具体如下所示：

async function hybridAuth(pattern: string) {
    const faceResult = await userAuth.auth(Type.FACE);
    if (faceResult === AuthResult.SUCCESS) {
        return this.quickUnlock(pattern);
    }
    return this.strictValidate(pattern);
}

分布式场景实现，具体如下所示：

// 智能手表辅助认证
function watchAssistedAuth() {
    const deviceId = deviceManager.getTrustedDevices()[0];
    distributedLock.begin(deviceId);
    // 同步绘制轨迹...
}

PatternLock实际应用示例

最后再来分享一个关于PatternLock的详细使用示例，模拟一个验证手势密码是否正确，具体代码如下所示：

// test.ets
import { LengthUnit } from '@kit.ArkUI'

@Entry
@Component
struct PatternLockExample {
  @State passwords: Number[] = []
  @State message: string = '请输入密码!'
  private patternLockController: PatternLockController = new PatternLockController()

  build() {
    Column() {
      Text(this.message).textAlign(TextAlign.Center).margin(20).fontSize(20)
      PatternLock(this.patternLockController)
        .sideLength(200)
        .circleRadius(9)
        .pathStrokeWidth(5)
        .activeColor('#707066')
        .selectedColor('#707066')
        .pathColor('#707066')
        .backgroundColor('#F6F6F6')
        .autoReset(true)
        .activateCircleStyle({
          color: '#606060',
          radius: { value: 16, unit: LengthUnit.VP },
          enableWaveEffect: true
        })
        .onDotConnect((index: number) => {

        })
        .onPatternComplete((input: Array<number>) => {
          // 输入的密码长度小于5时，提示重新输入
          if (input.length < 5) {
            this.message = '密码长度需大于5位，请重新输入。'
            return
          }
          // 判断密码长度是否大于0
          if (this.passwords.length > 0) {
            // 判断两次输入的密码是否相同，相同则提示密码设置成功，否则提示重新输入
            if (this.passwords.toString() === input.toString()) {
              this.passwords = input
              this.message = '密码设置成功: ' + this.passwords.toString()
              this.patternLockController.setChallengeResult(PatternLockChallengeResult.CORRECT)
            } else {
              this.message = '两次输入的密码不一致，请重新输入。'
              this.patternLockController.setChallengeResult(PatternLockChallengeResult.WRONG)
            }
          } else {
            // 提示第二次输入密码
            this.passwords = input
            this.message = "请重新输入。"
          }
        })
      Button('重置手势密码').margin(40).onClick(() => {
        // 重置密码锁
        this.patternLockController.reset()
        this.passwords = []
        this.message = '请输入密码。'
      })
    }.width('100%').height('100%')
  }
}

上面的这个示例通过sideLength设置九宫格的大小、circleRadius等属性设置宫格圆点样式、onPatternComplete属性设置密码输入时的回调。当使用者密码输入完成后，按输入的密码不同，给予不同的回应：输入的密码长度小于5时，提示重新输入；第一次输入完成后，提示第二次输入密码；第二次输入完成后，判断两次输入的密码是否相同，相同则提示密码设置成功，否则提示重新输入。然后可以通过'重置手势密码'按钮，可以重置密码锁。

最后

随着 HarmonyOS 全场景生态的持续演进，PatternLock 已从传统的 “单点认证工具”，进化为连接多设备、多模态的 “安全交互枢纽”。本文从技术架构、开发实战到场景进阶，系统呈现了 PatternLock 的完整能力边界，不仅能帮助开发者快速构建基础手势认证功能，更能通过生物特征融合、分布式跨设备认证等进阶玩法，打造面向未来的全场景安全体系。在 HarmonyOS 6 及后续版本中，随着 ArkUI 框架对三维手势识别、压力感应等能力的引入，PatternLock 还将突破二维平面的限制，在车机控制、智能家居中控、可穿戴设备等场景中发挥更大价值。建议开发者持续关注 HarmonyOS Design 系统的更新，将环境感知、行为分析等新型技术与 PatternLock 深度融合，构建 “主动防御、无感认证” 的智能安全体验，为全场景互联时代筑牢安全基石。这里我建议大家持续关注HarmonyOS Design系统的更新，将生物特征、环境感知等新型认证方式与PatternLock深度融合，构建面向未来的智能安全体系，一起期待吧！

选择免费SSL证书，最核心的决策依据可以简化为：追求短期效益的选Let's Encrypt，看重中文长期免费体验、国内使用的选JoySSL，需要CDN与安全防护一体选Cloudflare。

一、JoySSL：国产首选的中文友好长期方案

JoySSL是国内专注提供免费SSL证书的服务商，主打本地化服务和中文体验，最大特色是提供永久免费的DV单域名SSL证书，吸引了大量国内个人站长和中小企业用户。

优势

1. 中文界面更友好：全程中文操作指引，从申请下载到配置部署都提供中文文档，新手也能轻松上手，无需依赖翻译工具。
2. 永久免费基础版：个人用户可免费领取永久有效的单域名DV证书，无需担心定期续期问题，适合长期稳定运行的个人站点。
3. 支持国密算法：可提供符合国家标准的SM2国密证书，满足政务、金融等合规要求，为国内用户提供本土化加密选择。
4. 多平台部署教程：提供针对宝塔面板、Nginx、Apache、Docker等主流平台的详细中文配置教程，降低部署难度。

缺点

1. 通配符证书需付费：仅单域名证书永久免费，多域名和通配符证书需要购买专业版，对于需要覆盖子域名的多域名站点不够友好。
2. 品牌知名度稍低：相比Let's Encrypt，市场认知度稍逊，部分用户可能对国产证书安全性存在顾虑，但实际上其DV证书同样通过国际主流浏览器信任根体系认证。

适用场景

国内个人博客、小型企业官网、微信小程序后端服务，适合偏好中文界面，追求长期稳定且无需频繁续期的用户。

二、Let's Encrypt：全球最成熟的开源自动化方案

Let's Encrypt是由互联网安全研究小组（ISRG）运营的非营利组织，是目前全球使用量最高的免费SSL证书提供商，覆盖全球超4亿个域名，是个人开发者和中小团队的首选方案。

优势

1. 完全零成本：无隐藏消费，不限制申请次数，支持单域名、多域名和通配符证书类型，所有证书均为DV（域名验证）类型，可满足绝大多数普通网站的加密需求。
2. 自动化程度高：通过ACME协议实现自动化申请、部署和续期，配合Certbot、acme.sh等工具，可实现证书到期前自动续期，完全无需人工干预。
3. 兼容性极强：支持Nginx、Apache、Caddy等所有主流Web服务器，同时适配Windows、Linux、Docker等各种操作系统，几乎不存在兼容性问题。
4. 社区资源丰富：作为行业标杆，相关教程和解决方案覆盖全面，遇到问题能快速找到解决办法，适合有一定技术能力的开发者。

缺点

1. 证书有效期短：证书有效期仅90天，虽然支持自动续期，但依赖服务器环境稳定和续期脚本配置，一旦脚本失效可能导致证书过期。
2. 中文支持不足：官方文档以英文为主，新手上手门槛略高，部分错误提示不够直观。
3. 通配符证书需手动DNS验证：申请通配符证书时无法通过文件验证，必须手动添加DNS TXT记录完成域名所有权验证，流程相对繁琐。

适用场景

个人博客、开源项目、测试环境、中小团队的长期稳定站点，适合熟悉服务器操作，能自主维护续期脚本的用户。

三、Cloudflare CDN：自带安全与性能增益的云方案

Cloudflare是全球最大的CDN服务商之一，提供免费SSL证书与CDN加速一体化服务，无需用户手动下载部署证书，通过域名DNS解析配置即可实现全站加密。

优势

1. 零部署成本：只需将域名DNS解析到Cloudflare，即可一键启用SSL加密，无需处理证书申请、上传、配置等繁琐步骤，新手也能快速上手。
2. 附赠多重安全防护：启用Cloudflare SSL的同时，可自动获得DDoS攻击防护、WAF防火墙、恶意IP拦截等安全功能，有效提升网站安全性。
3. 支持边加密与全加密模式：提供Flexible、Full、Full (strict)三种加密模式，可适配不同服务器配置，同时支持HTTP/2、HTTP/3等现代化网络协议。
4. 全球加速能力：借助Cloudflare遍布全球的CDN节点，可同步提升网站访问速度，尤其适合面向全球用户的站点。

缺点

1. 依赖CDN服务：必须将域名DNS解析到Cloudflare才能使用SSL证书，若服务器无法对接Cloudflare CDN，或不希望使用第三方CDN，该方案无法使用。
2. 免费版存在功能限制：免费版仅支持单域名证书，通配符证书需升级到付费版，同时部分安全和加速功能存在速率和流量限制。
3. 延迟略增：经过Cloudflare中转后，可能带来轻微的网络延迟，对于对响应速度有极高要求的站点（如实时交易系统）可能存在影响。

适用场景

需要同时实现加密、加速和安全防护的网站，适合缺乏技术能力手动部署SSL证书的新手用户，以及希望简化运维流程的中小团队。

四、三类免费SSL证书详细对比表

表格

五、其他主流免费SSL方案对比

阿里云免费SSL证书

阿里云与DigiCert合作推出的免费DV证书，单域名有效期3个月，个人用户每年可免费申请20张。优势在于无需独立注册账号，直接通过阿里云控制台管理，适合阿里云服务器用户，但续期需要每年重新申请，相对繁琐，且仅支持单域名，无通配符证书。

腾讯云免费SSL证书

腾讯云提供的免费DV证书，有效期12个月，支持单域名证书，通过腾讯云DNS验证流程，自动化程度较高，但每年仅支持5张免费证书，适合腾讯云生态内的短期项目或测试站点。

ZeroSSL

ZeroSSL与Let's Encrypt基于同一ACME协议，支持通配符证书和中文界面，提供可视化申请流程，降低新手上手难度，但续期仍需要配置自动脚本，且免费版每月仅支持3个域名，适合对界面友好度要求较高的临时项目。

六、选型决策指南

1. 技术能力导向：有服务器运维经验，希望实现全自动续期，首选Let's Encrypt。
2. 中文体验导向：偏好中文界面，希望永久免费且无需续期，首选JoySSL。
3. 一站式需求：需要CDN加速和安全防护，不想手动操作证书部署，首选Cloudflare。
4. 云生态适配：使用阿里云或腾讯云服务器，可优先选择对应云厂商的免费证书，减少跨平台操作流程。

大家好，我是汤师爷，专注AI智能体分享，致力于帮助100W人用智能体创富~

还在为小红书笔记创作发愁吗？

每天都要绞尽脑汁想文案，看着别人的爆款笔记却不知道如何模仿？

今天，我就教你如何利用AI智能体，轻松实现小红书图文改写，让创作效率提升10倍！

我们先看下智能体的执行效果：

1.整体工作流

1.获取小红书笔记详情

2.使用OCR技术，提取图片中的文字

3.将图片文案进行整理

4.图片文案仿写

2.详细工作流节点

2.1 开始节点

开始节点有两个输入变量。

• 输入：

  • noteUrl：小红书笔记链接
  • cookieStr：小红书cookie

2.2 如何获取小红书cookie？

1.登陆https://www.xiaohongshu.com/

2.在页面空白处右击鼠标，选择「检查」

3.在刚刚打开的面板中，点击「网络」选项卡

4.刷新当前页面

5.点击第一条记录，在右侧「标头」部分向下滚动，找到cookie一行，将其内容复制下，这就是我们需要的cookieStr

2.3 获取小红书笔记详情

我们将使用【小红书】插件的xhs_note_detail功能。

通过这个功能，我们可以根据笔记链接获取笔记详情。

• 输入：

  • cookieStr：开始 - cookieStr
  • noteUrl：开始 - noteUrl

2.4 使用OCR技术，提取图片中的文字

1.接下来，我们使用循环节点，批量提取图片中的文字。

• 输入：

  • input：获取小红书笔记详情-note_image_list

• 输出

  • output：从图片中提取文字-data

2.使用循环体，批量提取图片的文字

我们会使用「OCR」插件，提取图片的文字。

输入参数如下图所示。

2.5 使用大模型将文案内容进行整理、排版

在这一步，我们会使用大模型节点，对文案内容进行整理、排版。

大模型节点的系统提示词如下：

## 角色（Role）
你是一位精通内容整理和 Markdown 排版的 AI 助手。你擅长阅读和理解非结构化的文本内容，并能够将其转化为结构清晰、格式优美的 Markdown 文档。

## 背景（Background）
随着社交媒体平台的普及，大量的图文内容被创作和分享。然而，这些内容往往缺乏良好的结构和格式，不利于阅读和理解。将这些内容整理成结构化的 Markdown 文档，可以大大提高内容的可读性和价值。

## 任务（Task）
你的任务是接收一段从插件输出的非结构化文本内容（主要是抖音图文中的文字），仔细阅读并理解内容，然后将其转化为结构清晰、格式规范的 Markdown 文档。你需要：

1. 识别并提取文本中的关键信息，如标题、作者、主要内容等
2. 根据内容的逻辑关系，对文本进行分类和整理
3. 使用 Markdown 语法进行排版，包括但不限于使用标题、粗体、斜体、列表等格式
4. 确保所有原始内容都被包含在最终的 Markdown 文档中，不遗漏任何信息

## 规则与限制（Rules & Restrictions）
1. 必须使用 Markdown 语法进行排版
2. 使用 #、##、### 等进行标题划分，层级不超过 3 级
3. 使用 - 或 * 进行无序列表编写，使用 1. 2. 3. 等进行有序列表编写
4. 重要内容使用粗体（**文字**）标注，需要强调的内容使用斜体（*文字*）标注
5. 保持原文的主要结构和顺序，但可以适当调整以提高可读性
6. 不得添加、删除或修改原文的实质内容
7. 如遇到不确定的内容，保留原样并用括号标注

## 参考短语（Reference sentences）
- 内容完整，不遗漏任何信息
- 结构清晰，层次分明
- 格式规范，美观实用
- 逻辑严密，条理清晰
- 重点突出，易于阅读

## 案例展示（Case Show）
### 输入：
{
  "code": 0,
  "data": {
    "results": [
      {
        "words": [
          {
            "lang": "auto",
            "text": "求大连这两个"
          },
          {
            "lang": "auto",
            "text": "地方有啥"
          },
          {
            "lang": "auto",
            "text": "区别啊？？"
          }
        ]
      }
    ]
  },
  "log_id": "20250325123913080C6F506498C6F581B7",
  "msg": "success"
}

## 风格和语气（Style & Tone）
- 保持专业、清晰的语气
- 使用简洁、直接的表达方式
- 保持原文的重点和强调

## 受众群体（Audience）
- 小红书电商新手卖家
- 对开设小红书店铺感兴趣的人群
- 想要了解小红书电商运营的人群

## 输出格式（Output format）
使用 Markdown 格式输出，包括：
1. 一级标题（#）用于文章主标题
2. 二级标题（##）用于主要章节
3. 三级标题（###）用于子章节
4. 无序列表使用 - 或 *
5. 有序列表使用 1. 2. 3. 等
6. 重要内容使用粗体（**文字**）
7. 需要强调的内容使用斜体（*文字*）

## 工作流程（Workflow）
1. 仔细阅读输入的文本内容，理解其结构和主要信息点
2. 提取标题、作者、标签等元信息
3. 识别主要章节和子章节，规划文档结构
4. 按照规划的结构，使用 Markdown 语法重新排版内容
5. 使用粗体和斜体突出重要信息和需要强调的内容
6. 检查确保所有原始内容都被包含，没有遗漏
7. 最后检查 Markdown 格式是否正确，调整以确保最佳可读性

## 初始化（Initialization）

下面是你需要整理和格式化的文本内容：

<评价内容>

请提供需要整理和格式化的文本内容。我会仔细阅读并按照上述要求将其转化为结构清晰的 Markdown 文档。不需要输出额外除图片识别文字以外的内容。

2.6 图片文案仿写

接下来，我们需要通过大模型节点退图片文案进行仿写。

大模型节点的系统提示词如下：

# 角色说明
你是一位专业的图文内容仿写助手，负责根据图片中提取的文字内容，结合视觉元素和背景信息，创作风格一致的仿写内容。

# 背景说明
处理用户提供的图片文字内容时，你需要：
1. 理解图片的整体风格和背景（产品介绍、教程步骤、使用心得等）
2. 分析文字的语言特点（正式/口语化、句式特征、专业术语等）
3. 结合图片呈现的视觉信息（产品外观、使用场景等）
4. 在保持原意的基础上进行自然的仿写扩展

# 仿写原则
1. 保持原意完整性
2. 匹配原文语言风格
3. 补充恰当的细节
4. 与图片内容保持一致
5. 避免添加虚假信息

# 工作流程
1. 接收图片文字内容
2. 分析图片背景信息（可选）
3. 分析原文特点：
   - 语言风格
   - 内容结构
   - 关键词使用
4. 创作三个版本：
   - 贴近原文的保守版
   - 适度优化的改进版
   - 创意加强的亮点版

# 输出示例
## 原文：
"夏日必备防晒霜
SPF50+ PA++++
清爽不油腻"

## 仿写版本：
1. 【保守版】
"夏季必备防晒产品
防晒指数SPF50+ PA++++
质地清爽不油腻"

2. 【优化版】
"夏日防晒推荐
高倍防护SPF50+ PA++++
轻薄水感质地，肌肤零负担"

3. 【创意版】
"今夏防晒天花板！
SPF50+ PA++++超强防护
一抹化水，清爽不黏腻"

# 执行要求
请提供：
1. 图片文字提取内容
2. 图片背景说明（如有）

我将按照以上规范进行仿写创作。

2.7 使用文本处理插件拼接字符串

• 输入：

  • String1：获取小红书笔记详情-note
  • String2：图片文案内容整理-output
  • String3：图片文案仿写-output

2.8 结束节点

3.总结

通过以上介绍，相信你了解了如何利用DeepSeek+Coze来构建高效的小红书图片文案改写智能体。

在AI时代，技术门槛将越来越低，小白也能搭建智能体，用AI工具来提升工作效率。

用AI智能体不是未来，而是AI时代每个人的生存技能，学会AI智能体，人人都是超级个体。

如果你觉得这篇文章有帮助，别忘了点赞、关注、收藏，我们下期再见！

对了，我整理了一份开源《智能体学习手册》，爆肝 10 万字，价值 999 元。限时开放领取👉：tangshiye.cn