2026年1月

在这里插入图片描述

摘要

随着 HarmonyOS / OpenHarmony 在手机、平板、智慧屏、车机等多设备上的落地,应用的复杂度正在明显提升。页面不再只是简单展示,而是伴随着网络请求、数据计算、设备协同等大量逻辑。如果这些逻辑处理不当,很容易出现页面卡顿、点击无响应,甚至 Ability 被系统回收的问题。

线程阻塞,已经成为鸿蒙应用开发中最容易踩坑、也最影响体验的问题之一。本文将结合实际开发场景,用尽量口语化的方式,聊一聊在鸿蒙系统中如何系统性地避免线程阻塞,并给出可以直接运行的 Demo 代码。

引言

在早期的应用开发中,很多开发者习惯把逻辑直接写在点击事件里,或者在页面加载时同步读取数据。这种写法在简单页面中问题不大,但在 HarmonyOS 这种强调流畅体验和多设备协同的系统中,很容易暴露问题。

鸿蒙的 UI 是声明式的,系统对主线程(UI 线程)非常敏感。一旦主线程被占用,页面掉帧、动画卡住、操作延迟都会立刻出现。因此,理解哪些操作会阻塞线程,以及如何把这些操作合理地“挪走”,是每个鸿蒙开发者绕不开的一课。

下面我们从原理、工具、代码和真实场景几个角度,完整地拆解这个问题。

为什么线程阻塞在鸿蒙中这么致命

UI 线程到底在忙什么

在 HarmonyOS 中,UI 线程主要负责三件事:

  • ArkUI 页面渲染
  • 用户事件分发(点击、滑动等)
  • Ability 生命周期回调

简单理解就是:只要和“看得见、点得动”有关的事情,几乎都在 UI 线程上完成

一旦你在这里做了耗时操作,比如计算、IO、网络等待,页面就会立刻表现出“卡”的感觉。

常见的阻塞来源

在实际项目中,最容易导致阻塞的操作通常包括:

  • 同步网络请求
  • 文件读写
  • 数据库查询
  • 大量 for 循环计算
  • 人为 sleep 或死循环

这些操作本身不一定是错的,问题在于它们被放在了不该放的线程上

鸿蒙中避免线程阻塞的核心思路

一个总原则

可以把鸿蒙里的线程使用总结成一句话:

UI 线程只处理 UI,其他事情交给异步、线程池或 Worker。

围绕这个原则,系统也提供了多种工具,帮助开发者把任务“分流”。

异步编程是第一道防线

使用 async / await 处理耗时逻辑

在 ArkTS 中,官方推荐优先使用 Promise 和 async / await。它的好处是代码结构清晰,而且不会阻塞 UI 线程。

示例:页面加载网络数据

@Entry
@Component
struct AsyncDemo {
  @State message: string = '加载中...'

  build() {
    Column() {
      Text(this.message)
        .fontSize(20)
        .margin(20)

      Button('重新加载')
        .onClick(() => {
          this.loadData()
        })
    }
  }

  async loadData() {
    this.message = '请求中...'
    let response = await fetch('https://example.com/data')
    let result = await response.text()
    this.message = result
  }
}

代码说明

  • loadData 使用 async 声明,不会阻塞 UI
  • await 只是暂停当前函数执行,不会卡住页面
  • UI 更新完全由状态变化驱动

这是最基础、也是最常用的一种防阻塞方式。

TaskPool:处理计算和 IO 的利器

什么时候该用 TaskPool

当你遇到下面这些情况时,TaskPool 几乎是必选项:

  • 大量计算
  • 批量数据处理
  • 文件压缩、解析

可运行 Demo 示例

import taskpool from '@ohos.taskpool'

@Concurrent
function calculateSum(count: number): number {
  let sum = 0
  for (let i = 0; i < count; i++) {
    sum += i
  }
  return sum
}

@Entry
@Component
struct TaskPoolDemo {
  @State result: string = '等待计算'

  build() {
    Column() {
      Text(this.result)
        .fontSize(18)
        .margin(20)

      Button('开始计算')
        .onClick(() => {
          this.startTask()
        })
    }
  }

  startTask() {
    this.result = '计算中...'
    taskpool.execute(calculateSum, 1000000).then(res => {
      this.result = `结果是:${res}`
    })
  }
}

代码说明

  • @Concurrent 表示该函数可以并发执行
  • TaskPool 自动管理线程,不需要开发者手动创建线程
  • UI 线程只负责接收结果和更新状态

在真实项目中,使用 TaskPool 往往能立刻解决页面卡顿问题。

Worker:长期后台任务的选择

Worker 的使用场景

如果任务具有下面这些特点,就更适合使用 Worker:

  • 长时间运行
  • 需要持续处理数据
  • 与 UI 强隔离

比如日志分析、音视频处理、复杂解析等。

示例:使用 Worker 处理数据

主线程代码

let worker = new Worker('workers/data_worker.ts')

worker.postMessage({ action: 'start' })

worker.onmessage = (e) => {
  console.log('收到结果:', e.data)
}

Worker 线程代码

onmessage = function (e) {
  if (e.data.action === 'start') {
    let result = 0
    for (let i = 0; i < 500000; i++) {
      result += i
    }
    postMessage(result)
  }
}

代码说明

  • Worker 与 UI 线程完全独立
  • 即使计算时间较长,也不会影响页面交互
  • 通过消息机制进行通信

结合实际场景的应用示例

场景一:列表页面加载大量数据

问题:

  • 首次进入页面时一次性处理全部数据
  • 页面明显卡顿

解决思路:

  • 网络请求使用 async
  • 数据整理放入 TaskPool
async loadList() {
  let data = await fetchData()
  taskpool.execute(processData, data).then(list => {
    this.list = list
  })
}

场景二:文件导入与解析

问题:

  • 文件较大
  • 解析过程耗时

解决思路:

  • Worker 负责解析
  • UI 只显示进度
worker.postMessage({ filePath })

场景三:复杂计算驱动 UI 更新

问题:

  • 计算逻辑和 UI 耦合

解决思路:

  • 计算完全放到 TaskPool
  • UI 只订阅结果

QA 环节

Q:async / await 会不会阻塞线程?
A:不会,它只是让出执行权,不会卡住 UI 线程。

Q:TaskPool 和 Worker 怎么选?
A:短期、一次性的任务优先 TaskPool,长期或持续任务用 Worker。

Q:能不能在生命周期里做耗时操作?
A:不建议,生命周期函数应尽量轻量。

总结

线程阻塞并不是某一个 API 的问题,而是设计问题。在 HarmonyOS 中,系统已经为我们准备好了异步模型、TaskPool 和 Worker,只要遵循“UI 线程只做 UI”的原则,大多数卡顿问题都可以提前避免。

在真实项目中,提前做好任务拆分、线程规划,比后期排查卡顿要省心得多。这也是鸿蒙开发从“能跑”到“跑得顺”的一个重要分水岭。

本文引用了45岁老架构师尼恩的技术分享,有修订和重新排版。

1、引言

分布式IM聊天系统中,IM消息怎么做到不丢、不重、还按顺序到达?这个问题,涉及到IM系统的两个核心:1)消息不能丢(可靠性):比如用户点了发送,不能因为服务宕机或网络抖动,消息石沉大海。比如地铁隧道、电梯间,网络断了又连,消息不能卡住不动(要确保弱网也能用)。2)顺序不能乱(有序性):比如“在吗?” 回成 “吗在?”,群聊时间线错乱,体验直接崩盘。这二大痛点,是IM聊天系统架构的命门所在。下面是一张IM消息从发出到接收的关键路径:
图片

2、系列文章

为了更好以进行内容呈现,本文拆分两了上下两篇。本文是2篇文章中的第 1 篇:《如何保障分布式IM聊天系统的消息有序性(即消息不乱)》(☜ 本文)《如何保障分布式IM聊天系统的消息可靠性(即消息不丢)》(稍后发布..)本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

3、传统技术方案的瓶颈,怎么破?

早期做消息有序,很多人第一反应是搞个“全局发号器”——所有消息排一队,挨个编号再发。理想很丰满,现实很骨感:高并发下一拥而上抢号,发号器直接被打满;更致命的是,它一旦宕机,全链路雪崩。这就像春运火车站只开一个售票窗——再快也撑不过三分钟。所以,我们必须换思路:不搞大一统,而是分片独立发号,让每个“窗口”自给自足,互不干扰。

4、痛点拆解:为什么消息会乱?

我们先还原一个真实场景: 想象一下你和朋友聊天:你说:“1 吃饭了吗?”他回:“2 刚吃完。”你又说:“3 吃啥呢?”结果对方手机上显示成:“3  吃啥呢?” → “1 吃饭了吗?” → “2 刚吃完。”这不是 bug,是分布式系统的常态。三条消息走不同服务节点、经不同网络路径,到达时间完全不可控,最终呈现顺序错乱。会乱 问题本质是什么?一个要“串行等”,一个想“并发冲”,天然冲突。这时候有人会说:那我加个全局排序服务不就行了?可以,但代价太大——一个中心节点最多撑几万 QPS,面对百万群聊、亿级用户,还没上线就已过载。所以,全局有序不是解,而是枷锁。我们要的不是“天下大同”,而是“各聊各的别乱就行”。

5、最终方案:分而治之 + 局部有序

真正的突破口在于:我们根本不需要全局有序,只需要“会话内有序”。你和张三的聊天记录不能乱,但你和李四的聊天跟王五的完全无关——何必放一起排序?这就引出了经典策略:分而治之 + 局部有序。具体怎么做?两步走稳: 第一步 - 业务分区: 哈希分片,锁定归属用 sessionId 做一致性哈希,确保同一个会话的所有消息始终路由到同一个处理节点。按“会话ID”做哈希,算出该消息该由哪个节点处理。同一会话 → 哈希值一样 → 路由到同一台机器 → 所有消息串行处理,天然避免跨节点乱序。这样一来,单个会话内的消息在服务端就是串行处理的,天然不会乱。 第二步 - 局部序号:独立发号,局部递增每个会话独立维护一个计数器,每来一条消息就+1,作为它的“官方序号”。每个会话,可以配一个独立计数器(比如 Redis 的 INCR),每来一条消息就+1,生成唯一 SEQ。客户端不管什么时候收到消息,只认这个序号,按序号从小到大排列展示。这个 SEQ 就是这条消息的“官方身份证号”,客户端只认这个,不看接收时间。这就像电影院检票——你可以早到晚到,但座位按票号定。哪怕后排观众先进场,也不会坐到前排去。PS:IM消息ID生成相关的文章可详细阅读以下资料:《IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)》《IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)》《IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略》《IM消息ID技术专题(四):深度解密美团的分布式ID生成算法》《IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现》《IM消息ID技术专题(六):深度解密滴滴的高性能ID生成器(Tinyid)》《IM消息ID技术专题(七):深度解密vivo的自研分布式ID服务(鲁班)》

6、实践落地(核心片段伪代码)

1)服务端分片路由逻辑:来看关键实现:如何把消息精准投递给“对的人”。String sessionId = msg.getSessionId();//这里是伪代码,实际代码以mq 的负载均衡机制为准int nodeIndex = Math.abs(sessionId.hashCode()) % clusterNodeCount; //这里写个伪代码,代表mq  主从复制ClusterNode targetNode = clusterNodes.get(nodeIndex);targetNode.sendMsg(msg);核心就一句:基于会话 ID 哈希取模,固定路由。从此,每个会话都有了自己的“专属服务通道”,不再受其他会话影响。2)服务端序号分配逻辑:接下来,给每条消息发“通行证”:long msgSeq = redis.incr("msg_seq_" + sessionId);msg.setSeq(msgSeq);msg.setUniqueKey(sessionId + "_" + msgSeq);这里用了 Redis 的 INCR,保证同一个会话下的 SEQ 绝对递增,且线程安全。同时用 sessionId_seq 作为唯一键,既能幂等去重,也能防止重试导致消息重复入库。实战提示:如果你的 Redis 是集群模式,记得确保同一个会话的 key 落在同一 slot,否则 INCR 可能跨节点失效。3)客户端排序逻辑:最后一步,客户端收尾:别急着渲染,先排好队。//这里是伪代码, 先排序List<Msg> sortedMsgs = msgList.stream()    .sorted(Comparator.comparingLong(Msg::getSeq))    .collect(Collectors.toList());//这里是伪代码, 再渲染renderMsgList(sortedMsgs);无论消息以什么顺序到达,统统按 seq 升序排列后再上屏。哪怕第100条先到,第1条后到,也能正确归位。这也是为什么我们强调“客户端必须信任服务端 SEQ”——它是唯一真相源。

7、方案总结:放弃全局有序,换高可用与高性能

总结一下,这套方案的核心思想就一句话:不要为“假需求”买单——我们不需要全局有序,只需要业务上有意义的有序。你看微信、钉钉、飞书,哪一个是把全平台消息排成一条队列的?没有。它们都选择了“会话级隔离 + 局部有序”的设计,这才是工业级系统的通用解法。背后的分布式哲学也很清晰:
图片

最终换来的是:1)高并发支持(水平扩展);2)高可用(无单点);3)强一致体验(用户无感知)。这正是中高级开发者必须掌握的权衡思维:不是技术做不到,而是要不要做。有时候,“不做全局有序”,反而是最正确的选择。

8、 IM消息有序性架构的核心流程总结

最后,一张图串起全流程:
图片
从发起到渲染,全程围绕“会话隔离”和“局部发号”展开。每一个环节都在为同一个目标服务:在分布式环境下,低成本实现用户可感知的“顺序正确”。

—— 下篇《如何保障分布式IM聊天系统的消息可靠性(即消息不丢)》稍后发布,敬请期待 ——

9、参考资料

[1] 什么是IM聊天系统的可靠性?
[2] 什么是IM聊天系统的消息时序一致性?
[3] 微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
[4] 马蜂窝旅游网的IM系统架构演进之路
[5] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等
[6] 从新手到专家:如何设计一套亿级消息量的分布式IM系统
[7] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等
[8] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制
[9] 阿里IM技术分享(四):闲鱼亿级IM消息系统的可靠投递优化实践
[10] 阿里IM技术分享(八):深度解密钉钉即时消息服务DTIM的技术设计
[11] 基于实践:一套百万消息量小规模IM系统技术要点总结
[12] 一套分布式IM即时通讯系统的技术选型和架构设计
[13] 转转平台IM系统架构设计与实践(一):整体架构设计
[14] 移动端弱网优化专题(一):通俗易懂,理解移动网络的“弱”和“慢”
[15] 移动端弱网优化专题(二):史上最全移动弱网络优化方法总结
[16] Web端即时通讯实践干货:如何让你的WebSocket断网重连更快速?
[17] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
[18] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
[19] 移动端IM中大规模群消息的推送如何保证效率、实时性?
[20] 如何保证IM实时消息的“时序性”与“一致性”?
[21] 一个低成本确保IM消息时序的方法探讨

即时通讯技术学习:

(本文已同步发布于:http://www.52im.net/thread-4887-1-1.html

看了 vercel 刚发布的 react-best-practices-skill,觉得还不错,然后这周末就花两天用 Claude Code + GLM 4.7 写了个用来做在线订阅转换的工具:Clash Converter ,欢迎大家来体验或者提意见

  • 域名成本 12.99$
  • CICD 用的免费的 Github + Cloudflare Workers
  • LogoNano Banana Pro + Chatgpt生成的

今日速览

  1. 1Code:给 Claude Code 加个光标界面,开发效率翻倍
  2. Boom video for Mac:专为出镜人士设计的直播录屏神器
  3. TranslateGemma:谷歌开源翻译模型,支持 55 种语言
  4. Dynamic Content by beehiiv:一键为不同读者定制专属邮件
  5. Stracti:不用写代码,也能轻松造个 AI 机器人
  6. ChatGPT Translate:用 ChatGPT 翻译,保留原汁原味
  7. Orca:学语言像玩游戏,边玩边练口语
  8. Flight Follower:航空迷必备,无广告追踪头顶飞机
  9. Waylight for macOS:AI 助手懂你电脑里的一切,还能帮你记日记
  10. LocalMark Studio:本地优先的 Markdown 编辑器,又快又私密


1Code

如果你用 Claude Code 搞开发,1Code 就是你的效率加速器。它提供了一个类似光标的用户界面,让你在 Mac 和网页上并行运行 Claude Code 代理,开发速度嗖嗖往上提。

  • 在 Mac 上本地运行,支持工作树模式,灵活又方便
  • 网页端提供远程沙箱,实时预览应用,手机也能随时查看状态
  • 并行运行多个代理,功能开发就像开了挂

官网 PH


Boom video for Mac

教练、创作者、创始人看过来——Boom 让你在镜头前瞬间变专业。它是个专为演示设计的视频应用,直播录屏一气呵成,告别繁琐的后期编辑。

  • 在 Zoom、Meet 或 Teams 上直播,自带专业布局和电影级切换效果
  • 录制教程、演示超简单,说完就停,视频自动生成
  • 实时切换场景,支持 Stream Deck,操作流畅如丝
  • 内置虚拟摄像头和网络摄像头增强,效果直接拉满
  • 无需编辑、时间轴或后期制作,上手即用

官网 PH


TranslateGemma

谷歌这次玩真的,把自家翻译模型 Gemma 3 开源了。TranslateGemma 支持 55 种语言,交流起来既准又快,移动端、本地设备、云端都能跑。

  • 基于谷歌 Gemma 3 模型,翻译质量杠杠的
  • 覆盖 55 种语言,全球沟通无压力
  • 专为移动和本地设备优化,性能不打折
  • 云端环境也适配,灵活部署随心选

官网 PH


Dynamic Content by beehiiv

想给每个读者发不一样的邮件?beehiiv 的动态内容功能让你梦想成真。一次发送,千人千面,个性化营销就这么简单。

  • 根据读者展示不同内容,邮件营销更精准
  • 无需编码或定制模板,在编辑器里点点就行
  • 操作简单,没有额外复杂性,新手也能玩转

官网 PH


Stracti

造个 AI 机器人,不用碰代码?Stracti 让你梦想照进现实。通过可视化界面,轻松创建和运行机器人,自动化工作流从此告别“黑箱”。

  • 无代码平台,网页、桌面、移动端都能建机器人
  • 桌面应用本地运行,数据安全有保障
  • 基于屏幕 AI 检测,适配真实工作流程,不依赖 API
  • 操作历史清晰可见,完全掌控自动化过程

官网 PH


ChatGPT Translate

翻译工具千千万,但能保留语气的没几个。ChatGPT Translate 用 AI 瞬间翻译 50+ 语言,原意、上下文、语气统统在线。

  • 输入、粘贴、语音或上传文本,翻译方式任你选
  • 支持正式、随意等多种风格,翻译细腻又地道
  • 适合日常交流、旅行、学习和专业场景,一工具全搞定

官网 PH


Orca

学语言枯燥?Orca 把它变成游戏。通过真实生活短语的小课程,边玩边练,口语听力阅读全提升,还能挑战别人冲排名。

  • 围绕真实短语设计课程,学完就能流利交流
  • 每个级别教 15 个日常表达,实用又接地气
  • 互动发音游戏通关才能继续,学习动力满满
  • 挑战其他学习者,排名上升超有成就感

官网 PH


Flight Follower

航空迷的福音来了!Flight Follower 是 iOS 上免费的实时航班追踪器,无广告干扰,让你随时随地掌握头顶飞机的动态。

  • 通过 Siri 识别飞过的飞机,好奇就问问
  • 查看航班实时状态,信息一手掌握
  • 原生小部件追踪飞机,桌面一目了然
  • 快速 ADS-B 地图探索,飞行轨迹尽收眼底

官网 PH


Waylight for macOS

Waylight 就像你电脑里的私人助理,它懂你的会议、文档、标签和消息,还能帮你记日记、列待办,2020 年后苹果芯片的 Mac 都能用。

  • 理解电脑上所有活动,建立私密记忆库
  • 随时提问关于看到的内容,答案即时又准确
  • 自动生成待办列表和日记,生活整理得井井有条
  • 专为 Apple Silicon 优化,运行流畅不卡顿

官网 PH


LocalMark Studio

写 Markdown 要速度也要隐私?LocalMark Studio 专注本地优先,笔记存浏览器,文件结构真实,功能丰富到让你惊喜。

  • 本地存储用 IndexedDB,数据安全自己掌控
  • 创建文件夹和文件,重命名删除操作顺手
  • 命令面板快速调用功能,效率翻倍
  • 智能粘贴 HTML 转干净 Markdown,省心省力
  • 分屏实时预览,滚动同步,写作体验丝滑
  • 可选 Mermaid 图表和 KaTeX 公式,扩展性超强

官网 PH

Go-WXPush - 微信消息推送服务 (基于 golang)

这是一个基于 golang 开发的微信测试公众号模板消息推送服务。它提供了一个简单的 API 接口,让您可以轻松地通过 HTTP 请求将消息推送到指定的微信用户。 github 地址 https://github.com/hezhizheng/go-wxpush

✨ 特性

✅ 完全免费,下载即使用
✅ 支持 Docker 一键部署(镜像容器大小仅 2MB)
✅ 每天 10 万次额度,个人用不完
✅ 真正的微信原生弹窗 + 声音提醒
✅ 支持多用户
✅ 提供免费服务 https://push.hzz.cool (请勿滥用)
✅ 跳转稳定,自带消息详情页面 (默认使用 https://push.hzz.cool/detail , 可自己部署后使用参数替换)

⚠️ 部署条件 (具体可查看 github )

🚀 部署指南

下载编译好的文件启动

  • 启动参数
    • 命令行启动参数(可不加,启动之后直接在 url 上拼接参数也可) ./go-wxpush_windows_amd64.exe -port "5566" -title "测试标题" -content "测试内容" -appid "xxx" -secret "xxx" -userid "xxx-k08" -template_id "xxx-Ks_PwGm--GSzllU" -base_url "https://push.hzz.cool"
    • url 请求参数(get) 与命令行参数名称一致 /wxsend?appid=xxx&secret=xxx&userid=xxx-k08&template_id=xxx-Ks_PwGm--GSzllU&base_url=https://push.hzz.cool&content=保持微笑,代码无 bug!

自行编译可执行文件(跨平台)

复制
# 用法参考 https://github.com/mitchellh/gox
# 生成文件可直接执行 
gox -osarch="windows/amd64" -ldflags "-s -w" -gcflags="all=-trimpath=${PWD}" -asmflags="all=-trimpath=${PWD}"
gox -osarch="darwin/amd64" -ldflags "-s -w" -gcflags="all=-trimpath=${PWD}" -asmflags="all=-trimpath=${PWD}"
gox -osarch="linux/amd64" -ldflags "-s -w" -gcflags="all=-trimpath=${PWD}" -asmflags="all=-trimpath=${PWD}"
gox -osarch="linux/arm64" -ldflags "-s -w" -gcflags="all=-trimpath=${PWD}" -asmflags="all=-trimpath=${PWD}"

🐳 Docker 启动

  • 将编译好的文件放在与 Dockerfile 同目录
  • 构建镜像
复制
docker build -t go-wxpush:v2 .
  • 启动镜像,参数与命令行保持一致
复制
docker run -d -p 5566:5566 --name go-wxpush0 go-wxpush:v2 \
-port "5566" \
-title "测试标题" \
-content "测试内容" \
-appid "xxx" \
-secret "xxx" \
-userid "xxx-k08" \
-template_id "xxx-Ks_PwGm--GSzllU"

🐳 Docker 一键部署

复制
# 重新部署请先拉一遍最新的镜像
docker pull hezhizheng/go-wxpush:v4
# 参数格式与终端启动保持一致, 替换成实际值即可
docker run -it -d -p 5566:5566 --init --name go-wxpush4 hezhizheng/go-wxpush:v4 \
-port "5566" \
-title "测试标题 5566" \
-content "测试内容 5566" \
-appid "xxx" \
-secret "xxx" \
-userid "xxx-k08" \
-template_id "xxx-Ks_PwGm--GSzllU" \
-tz "Asia/Shanghai"

⚙️ API 使用方法

服务部署成功后,您可以通过构造 URL 发起 GET 请求来推送消息。

请求地址

复制
http://127.0.0.1:5566/wxsend

请求参数

参数名类型是否必填描述
portString指定启动端口(仅针对命令行)
titleString消息的标题。
contentString消息的具体内容。
appidString临时覆盖默认的微信 AppID。
secretString临时覆盖默认的微信 AppSecret。
useridString临时覆盖默认的接收用户 OpenID。
template_idString临时覆盖默认的模板消息 ID。
base_urlString临时覆盖默认的跳转 URL。
tzString时区(默认东八区)

使用示例

基础推送

向默认配置的所有用户推送一条消息:

复制
http://127.0.0.1:5566/wxsend?title=服务器通知&content=服务已于北京时间%2022:00%20 重启

临时覆盖用户

向一个临时指定的用户推送消息:

复制
http://127.0.0.1:5566/wxsend?title=私人提醒&content=记得带钥匙&userid=temporary_openid_here

Webhook / POST 请求

除了 GET 请求,服务也支持 POST 方法,更适合用于自动化的 Webhook 集成。

请求地址

复制
http://127.0.0.1:5566/wxsend

请求方法

复制
POST

请求头 (Headers)

复制
{
  "Content-Type": "application/json"
}

请求体 (Body)

请求体需要是一个 JSON 对象,包含与 GET 请求相同的参数。

复制
{
  "title": "Webhook 通知",
  "content": "这是一个通过 POST 请求发送的 Webhook 消息。"
}

使用示例 (cURL)

复制
curl --location --request POST 'http://127.0.0.1:5566/wxsend' \
--data-raw '{
    "title": "来自 cURL 的消息",
    "content": "自动化任务已完成。"
  }'

成功响应

如果消息成功发送给至少一个用户,服务会返回 "errcode": 0 状态码。

失败响应

如果发生错误(如 token 错误、缺少参数、微信接口调用失败等),服务会返回相应的状态码和错误信息。

CVE-2024-3400 Palo Alto Networks PAN-OS命令注入漏洞

Real World CTF 6th Router4 writeup

Exploiting File Writes in Hardened Node.js Environments

CVE-2024-41592 vigor 栈溢出漏洞分析

CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析

议题分享:Vigor2960 Memoirs \nPursuit of the Elusive 0day & 1day

议题分享: 企业设备安全设备漏洞分析与利用

议题分享: When ASUS IoT Devices Play Hide-and-Seek with Security

CVE-2025-36463 Sudo_chroot Elevation of Privilege 漏洞分析

CVE-2025-32023 Redis 漏洞分析


过去两年间,科技行业的领军者 —— 包括英特尔(Intel)、超威半导体(AMD)、高通(Qualcomm)等芯片巨头,以及软件架构巨头微软(Microsoft)—— 都在不遗余力地推广 “AI PC” 概念,试图推动一轮大规模硬件更新周期。然而,戴尔(Dell)近期坦诚承认:对绝大多数消费者而言,人工智能尚不足以成为购买新电脑的动力,甚至可能产生反效果。据《PC 玩家》(PCGamer)报道,戴尔已意识到,行业内铺天盖地的 “AI PC” 营销操作,与终端用户的实际需求之间存在巨大脱节。
戴尔方面表示,尽管公司仍致力于集成神经处理单元(Neural Processing Units, NPUs)并强化设备端推理能力,但市场实证表明,将 AI 定位为核心卖点 “未能有效刺激销量”。对普通消费者(而非科技爱好者)而言,AI 不仅无法激发购买热情,反而常引发他们对数据隐私安全实际用途模糊性的疑虑。戴尔的观察显示,理性消费者仍将决策锚定在传统实用指标上:价格、性能、电池续航与可靠性
与行业执着于 “每秒万亿次运算(TOPS)” 和专属 “Copilot 键” 不同,用户更看重设备的耐用性、运行流畅度和实际价值。这一现象凸显出当前消费级 AI 领域的关键短板:缺乏一款能打动用户的 “杀手级应用(Killer App)”,导致用户不愿为 “理论上的好处” 升级硬件。正因如此,在 2026 年国际消费电子展(CES 2026)上,戴尔发布的 XPS 系列笔记本调整了宣传方向,将重点转向便携性与耐用性。为提升该系列的高端定位,戴尔还采取了大胆的品牌策略:机身标识用 “XPS” 取代原有的 “Dell” logo,且宣传材料中刻意弱化了 AI 功能的提及。
尽管承认营销方向与用户需求存在偏差,戴尔仍强调,AI 仍是未来硬件更新周期的重要长期驱动力。行业共识认为,AI 必须从单纯的 “热门概念” 转变为无缝、可感知的实用工具,而实现这一转变的关键在于构建更完善的软件生态,而非简单堆砌硬件参数。戴尔的坦诚,实则揭开了行业内的 “公开秘密”:2024 至 2026 年间,尽管 NPU 的设备渗透率不断提升,但对普通办公和网页浏览等常规场景的体验提升微乎其微
当 Windows Copilot 等功能仍依赖云端连接,且设备端生成式 AI 能力表现平平之时,消费者自然会回归理性,对比屏幕画质、设备续航等实际参数。AI PC 并非虚幻概念,其发展路径类似早期 5G 手机 —— 必须先搭建好硬件基础,后续才能出现足以证明其价值的软件应用。除非人工智能能进化为类似 Wi-Fi 那样 “无形却不可或缺” 的基础设施,否则过度宣传反而可能引发消费者的抵触情绪,让他们觉得自己是在为冗余功能支付溢价。

苹果与谷歌已正式确认,下一代 Siri 将采用 Gemini 模型与 Google Cloud,双方达成一项为期多年的合作。
此前,苹果一直为 Siri 使用自研 AI 模型,但在性能上与 GPT、Gemini 甚至 Copilot 相比都显得力不从心。
如今,苹果与谷歌开启了多年合作。作为合作的一部分,未来版本的 Siri 将基于 Gemini 模型 运行。
此外,苹果的 Foundation Models(基础模型) 将以谷歌的 Gemini 为底层,并部署在谷歌云平台上。

谷歌在一份新闻稿中表示:

“这些模型将为未来的 Apple Intelligence 功能提供支持,包括将于今年推出的更具个性化的 Siri。”

苹果方面称:

“经过审慎评估,苹果认为谷歌的 AI 技术为 Apple Foundation Models 提供了最强大的基础,并对其将为苹果用户带来的创新体验感到兴奋。”

苹果强调,Apple Intelligence 将在苹果设备与 Private Cloud Compute(私有云计算) 上运行,公司长期坚持的隐私承诺 不会受到任何影响

Apple Intelligence 的发展历程一直充满波折

Siri 问世至今已超过十年。尽管它曾是最优秀的 “个人助手” 之一,但如今的大型语言模型(LLMs)在能力上已远超苹果的实现。
在 2024 年的 WWDC 上,苹果宣布正在开发 Apple Intelligence,其中也包括一个更具 AI 能力的 Siri,例如支持个人上下文理解与屏幕内容感知。
然而,这些功能一再延期。
部分功能最终上线,但用户抱怨 Apple Intelligence 的准确性不佳,在执行复杂指令时经常失败。
尽管苹果的 AI 体验本应以 “安全” 和 “隐私友好” 为卖点,但最终呈现的初始体验却远未达到革命性的高度。
如今,苹果与谷歌合作,借助 Gemini 升级 Siri 体验。但这是否能实现苹果曾经承诺的那种革命性突破?只有时间能给出答案。

新一轮网络攻击正借助ValleyRAT_S2 恶意软件悄然入侵各类组织机构,该病毒可实现长期潜伏,并窃取目标机构的敏感金融数据。
ValleyRAT_S2 是 ValleyRAT 恶意软件家族的第二阶段载荷,基于 C++ 语言开发。一旦侵入目标网络,它就会以完整远程访问木马(RAT)的形态运行,让攻击者获得对受感染系统的高度控制权,同时搭建起稳定的数据外传通道。
当前,该攻击活动的主要传播途径为伪造的中文办公软件、破解版程序,以及伪装成人工智能表格生成工具的植马安装包。
在诸多攻击案例中,恶意软件会通过DLL 侧载技术实现植入:攻击者诱导一个带有合法数字签名的应用程序,加载看似正常的恶意动态链接库文件,例如命名为steam_api64.dll的恶意模块。

网络安全团队 APOPHiS 通过追踪多起相关攻击事件,确认ValleyRAT_S2 是此类入侵活动的核心第二阶段后门程序

除此之外,该恶意软件还会通过鱼叉式钓鱼邮件附件,以及被劫持的软件更新渠道进行传播。

恶意文档或压缩包会将载荷文件释放至系统临时文件夹等路径,例如:

C:\Users\Admin\AppData\Local\Temp\AI自动化办公表格制作生成工具安装包\steam_api64.dll

攻击的第一阶段以躲避安全检测为核心目标,而 ValleyRAT_S2 则会接管后续操作,负责长期驻留控制、系统信息探查、凭证窃取及金融数据收集等关键任务。

ValleyRAT_S2 激活后,会对系统进程、文件系统及注册表项展开扫描,随后通过自定义 TCP 协议,连接预先写入代码的命令与控制(C&C)服务器,例如27.124.3.175:14852。该病毒具备文件上传下载、执行 Shell 命令、注入恶意载荷、记录键盘输入等多种功能,

这些特性使其能够精准窃取网银账户凭证、支付交易数据及内部财务文档。

持久化机制与监控守护功能

ValleyRAT_S2 的一大高危特性,是其多层级持久化设计与监控守护机制,这让它能够在系统重启或手动清理后依然存活。

恶意软件会先将相关文件释放到用户的临时文件夹(Temp)和应用数据文件夹(AppData)中,创建%TEMP%\target.pid这类进程标识文件,同时在%APPDATA%\Promotions\Temp.aps路径下生成配置文件。

它还会利用 COM 接口调用 Windows 任务计划程序,实现开机自启动;同时会在注册表启动项中写入备份路径,作为双重保障。

该病毒的一个关键特征是会生成一个名为monitor.bat的批处理脚本,以此构建监控守护循环。

这个脚本会从target.pid文件中读取恶意主程序的进程 ID,持续检查主程序是否处于运行状态,一旦发现主程序被终止,就会自动静默重启。

以下是该脚本的简化版本:
@echo off
set "PIDFile=%TEMP%\target.pid"
set /p pid=<"%PIDFile%"
del "%PIDFile%"
:check
tasklist /fi "PID eq %pid%" | findstr >nul
if errorlevel 1 (
  cscript //nologo "%TEMP%\watch.vbs"
  exit
)
timeout /t 15 >nul
goto check
这一守护循环,能让 ValleyRAT_S2 在主进程被安全工具或管理员终止后快速恢复。此外,该恶意软件还结合了结构化异常处理、沙箱环境检测,以及进程注入技术 —— 将自身注入Telegra.exeWhatsApp.exe等具有可信名称的进程中,以此实现隐蔽且稳固的持久化驻留。
对于防御方而言,这意味着单纯终止恶意进程无法实现彻底清除;想要根除该病毒,必须同时针对计划任务、批处理与 VBS 监控脚本、释放的恶意文件及后门进程等所有相关组件,开展一体化清除操作。

Moxa 的工业以太网交换机中被发现存在一个严重安全漏洞,可能威胁工业控制系统(OT)网络的完整性。该漏洞编号为 CVE-2023-38408,CVSS 评分高达 9.8(高危),意味着需要立即修复
问题出在设备所使用的 OpenSSH 组件 中,具体影响 OpenSSH ssh-agent 在 9.3p2 之前版本中的 PKCS#11 功能
该漏洞源于一个 “不可靠的搜索路径”。如果 ssh-agent 被转发到攻击者控制的系统,就可能导致远程代码执行(RCE)。像 /usr/lib 这样的目录中的代码并不一定安全,而该漏洞的出现是因为之前的问题 CVE-2016-10009 的修复并不彻底。
由于漏洞严重性极高,官方强烈建议用户立即采取修复措施以降低风险。

受影响的产品系列

Moxa 已确认两个主要产品系列受到影响:

1. EDS 系列

型号包括:EDS-G4000、EDS-4008、EDS-4009、EDS-4012、EDS-4014、EDS-G4008、EDS-G4012、EDS-G4014

受影响固件:4.1 及更早版本

2. RKS 系列

型号包括:RKS-G4000、RKS-G4028、RKS-G4028-L3

受影响固件:5.0 及更早版本

修复措施

Moxa 已发布安全补丁,但暂未提供公开下载。用户必须联系 Moxa 技术支持以获取补丁文件。
  • EDS 系列: 请求安全补丁 v4.1.58
  • RKS 系列: 请求安全补丁 v5.0.4

临时缓解方案

对于无法马上进行固件更新的组织,Moxa 建议采用纵深防御策略降低风险:
  • 限制访问: 使用防火墙或访问控制列表(ACL)仅允许可信 IP 通信;通过 VLAN 隔离工业网络。
  • 减少暴露面: 确保设备不直接暴露在互联网上,并关闭未使用的端口。
  • 加强认证: 启用多因素认证(MFA)和基于角色的访问控制(RBAC)。
  • 安全通信: 使用 VPN 或 SSH 等加密协议进行远程访问,并仅限授权人员使用。
  • 监控: 部署异常检测以发现未授权活动,并定期审查审计日志。

有监测显示,威胁攻击者在 npm 软件包仓库中上传了八个恶意软件包。这些软件包伪装成面向 n8n 工作流自动化平台的集成插件,其真实目的是窃取开发者的 OAuth 身份凭证。
其中一款名为n8n-nodes-hfgjf-irtuinvcm-lasdqewriit的软件包,仿冒了谷歌广告的集成功能。它会诱导用户通过一个看似正规的表单绑定广告账户,随后将用户的 OAuth 凭证窃取并传输至攻击者控制的服务器中。
恩多尔实验室在其上周发布的一份报告中指出:“此次攻击标志着供应链威胁进入了全新的升级阶段。” 与传统的 npm 恶意软件不同 —— 这类软件往往以窃取开发者个人凭证为目标,而此次攻击则直接针对工作流自动化平台。这类平台本身相当于一个集中式凭证存储库,会将谷歌广告、Stripe 支付、Salesforce 客户管理等数十种集成服务的 OAuth 令牌、API 密钥以及敏感凭证统一存储。
目前已被确认并下架的恶意软件包完整名单如下:
  • n8n-nodes-hfgjf-irtuinvcm-lasdqewriit(下载量 4241 次,作者:kakashi-hatake)
  • n8n-nodes-ggdv-hdfvcnnje-uyrokvbkl(下载量 1657 次,作者:kakashi-hatake)
  • n8n-nodes-vbmkajdsa-uehfitvv-ueqjhhhksdlkkmz(下载量 1493 次,作者:kakashi-hatake)
  • n8n-nodes-performance-metrics(下载量 752 次,作者:hezi109)
  • n8n-nodes-gasdhgfuy-rejerw-ytjsadx(下载量 8385 次,作者:zabuza-momochi)
  • n8n-nodes-danev(下载量 5525 次,作者:dan_even_segler)
  • n8n-nodes-rooyai-model(下载量 1731 次,作者:haggags)
  • n8n-nodes-zalo-vietts(下载量 4241 次,作者:vietts_code、diendh)
截至本文撰写时,npm 用户zabuza-momochidan_even_seglerdiendh还被列为另外四款仍可下载的软件包的作者,具体如下:
  • n8n-nodes-gg-udhasudsh-hgjkhg-official(下载量 2863 次)
  • n8n-nodes-danev-test-project(下载量 1259 次)
  • @diendh/n8n-nodes-tiktok-v2(下载量 218 次)
  • n8n-nodes-zl-vietts(下载量 6357 次)
目前尚无法确认这四款软件包是否包含类似的恶意功能。不过,逆向实验室通过 Spectra Assure 工具对前三款软件包进行的安全评估显示,其暂未发现安全隐患;而针对n8n-nodes-zl-vietts的分析结果则显示,该软件包中包含一个曾被标记为恶意软件的组件。

值得警惕的是,软件包n8n-nodes-gg-udhasudsh-hgjkhg-official的更新版本在三小时前刚刚发布至 npm 仓库,这一迹象表明,攻击者的此次攻击活动可能仍在持续
这类恶意软件包一旦作为社区节点完成安装,其外在表现与其他任何一款 n8n 集成插件无异 —— 会正常显示配置界面,并将谷歌广告账户的 OAuth 令牌以加密形式保存至 n8n 的凭证存储库。但当工作流开始执行时,它会运行恶意代码,利用 n8n 的主密钥对存储的令牌进行解密,随后将这些凭证窃取并外传至远程服务器。
这一攻击事件的出现,标志着供应链威胁首次明确将 n8n 生态系统作为攻击目标。攻击者正是利用了用户对社区集成插件的信任,进而实现其窃取凭证的目的。
此次事件也凸显出一个核心安全隐患:集成来源不可信的工作流,会大幅扩大企业的攻击面。研究人员建议,开发者在安装任何软件包前都应进行安全审计,仔细核查软件包的元数据是否存在异常,并优先使用 n8n 官方提供的集成插件。
n8n 官方同样发出警告,提醒用户警惕来自 npm 仓库的社区节点所带来的安全风险。这类节点可能会引入破坏性更新,或在服务运行的主机上执行恶意操作。官方建议,对于自托管的 n8n 实例,可通过将环境变量N8N_COMMUNITY_PACKAGES_ENABLED设置为false的方式,禁用社区节点功能。
研究人员基兰・拉吉与亨里克・普拉特指出:“社区节点拥有与 n8n 主程序完全等同的访问权限。它们可以读取环境变量、访问文件系统、发起对外网络请求,而最关键的一点是,它们能在工作流执行过程中获取到已解密的 API 密钥与 OAuth 令牌。节点代码与 n8n 运行时环境之间,不存在任何沙箱隔离机制。”
“正因如此,一款恶意 npm 软件包就足以让攻击者深度窥探目标系统的工作流、窃取各类凭证,并且在不触发即时警报的情况下实现对外通信。对于攻击者而言,npm 供应链已成为他们潜入 n8n 环境的一条隐蔽且高效的入侵通道。”

更新补充

在接受《黑客新闻》采访时,恩多尔实验室证实,npm 软件包n8n-nodes-gg-udhasudsh-hgjkhg-official确实为恶意软件,且属于此次攻击活动的一部分;其余三款软件包则被判定为良性。

新加坡网络安全局(CSA)已就研华(Advantech)IoT 产品线中一个极具破坏性的漏洞发布高优先级警报。该漏洞编号为 CVE-2025-52694,CVSS 评分高达 10.0(满分),表明其属于需要管理员立即处理的严重威胁

该漏洞为 SQL 注入漏洞。根据安全公告,成功利用后可使 “未授权远程攻击者执行任意 SQL 命令”。

这意味着,如果受影响的服务暴露在互联网上,攻击者无需用户名或密码即可发起攻击。他们只需向数据库发送恶意命令,就可能窃取敏感数据、修改系统配置,甚至完全控制整个相连的 IoT 基础设施。

该漏洞由 HCMUTE 信息安全俱乐部的 Loi Nguyen Thang 先生发现,并与研华及新加坡网络安全局合作进行了协调披露。
漏洞影响研华 IoT 生态系统的多个组件,尤其是较旧版本的管理和边缘软件。受影响的产品包括:
  • IoTSuite SaaSComposer:3.4.15 之前的版本
  • IoTSuite Growth Linux docker:V2.0.2 之前的版本
  • IoTSuite Starter Linux docker:V2.0.2 之前的版本
  • IoT Edge Linux docker:V2.0.2 之前的版本
  • IoT Edge Windows:V2.0.2 之前的版本
官方建议用户和管理员立即更新到最新版本以关闭此安全缺口。不同产品的更新方式如下:

・手动申请:

IoTSuite SaaSComposer、IoTSuite Growth Linux docker 和 IoT Edge Windows 的用户必须直接联系研华技术支持,以获取官方修复版本。

・直接下载:

IoTSuite Starter Linux docker 和 IoT Edge Linux docker 的更新可通过研华官方渠道直接下载。