2026年3月

  • 楼主正在开发一个加载视频字幕的插件,对于没有原生字幕的视频想获取其音视频文件,然后使用模型进行字幕转录,现在卡在如何下载 YouTube 音视频上面,不知有什么好的方式
  • 或者不用下载音视频转录,有其他直接获取识别字幕的方式

HTML 文档只有两个核心区域:<body><head>
<body> 放的是用户真正在屏幕上能看到的具体内容(比如文字、按钮和图片);而 <head> 则是网页的“幕后配置区”。<head> 里的信息不会显示在页面的正文里,但它主要负责告诉浏览器这网页该怎么显示、告诉搜索引擎这网页讲了啥内容,以及规范在社交软件中转发链接时图文卡片长什么样。

别觉得看不见就不重要。如果 <head> 没配好,页面很容易出现中文乱码、加载卡白屏,或者在各大搜索引擎里压根搜不到你。

一、 <head> 应该写在哪?

<head> 标签必须放在 <html> 标签内部,并且一定要写在 <body> 前面。
因为浏览器读取代码的规则是死理,永远“从上到下”。它必须先拿到 <head> 里的各项前置配置和规则,才能正确去画后续 <body> 里的肉眼可视内容。

<!DOCTYPE html>
<html lang="zh-CN">
  <head>
    <meta charset="utf-8">
    <title>基础页面定义</title>
  </head>
  <body>
    <!-- 页面正文内容 -->
  </body>
</html>

二、 <title>:网页的“大名”

1. <title><h1> 别搞混

  • <title> 是整个网页的名字。它不占页面里的排版空间,只显示在浏览器的最顶端标签页上、浏览器的收藏书签里,以及搜索结果的首行蓝字上。每个页面只能写一个 <title>
  • <h1> 则是写在你的网页正文里、一眼就能看到排版大标题。

2. <title> 的三个实际用处

  • 找网页必备:大家上网时经常开十几个标签。标签页最上面那一小条字就是 <title>,写清楚了才能让用户一眼找到并切回你的网页。
  • 默认的收藏名字:用户点击收藏你的网页时,浏览器会自动抓取 <title> 里的字当做保存名字,不需要手打。
  • 搜索引擎的“命门”:百度、谷歌等搜索引擎把 <title> 看得极重。你的 <title> 里包含了什么词,直接决定了别人搜哪些词能找到你。

三、 <meta>:网页的“说明书”

<meta> 标签专门用来存各种“设置说明”和“摘要”,全靠它跟浏览器以及搜索引擎的爬虫沟通。

1. 字符编码:<meta charset="utf-8">

计算机底层只认识 0 和 1。想在屏幕上正常显示中文字,就需要指定一本“翻译字典”。早期错用了只包含英文字母的字典,大家在看中文网页时就会满屏乱码。

UTF-8 是现在全球通用的标准,支持世界上几乎所有的文字。加上这句,只要是现代浏览器就绝不会乱码。
注意:这行代码必须是 <head> 里的第一行!要确保浏览器在往下遇到任何中文字之前,已经被通知要用这本“最全字典”去解码。

<head>
  <meta charset="utf-8"> <!-- 必须放在其他所有标签之前 -->
  <title>基础页面</title>
</head>

2. 页面简介:<meta name="description">

这个标签是专门留给搜索引擎爬虫看的。你在这里写的一段话,会直接用来当作搜索结果里大标题下方的那段灰色摘要文字。

<meta name="description" content="本文为你拆解HTML头部的6大核心配置,帮你彻底解决页面乱码与搜索盲区大坑。">
  • 怎么写:字数建议控制在 50 到 160 字之间。太短讲不清重点,太长了在搜索页面会被截断显示成省略号。
  • 放关键词:把跟网页最相关的“干货名词”写成自然通顺的一句话,以此吸引别人点击。(提示:以前有一种专门罗列关键词的 <meta name="keywords"> 标签,现在已经被各大搜索引擎当做作弊废弃了,千万别再写。)

3. Open Graph (OG) 标签:社交图谱属性数据

Open Graph(开放图谱协议)旨在解决链接分享时的富媒体展示问题。

真实场景说明
假设你写了一篇文章,把文章链接发到微信聊天框或朋友圈。

  • 没有配置 OG 标签时:微信只能识别出一个干巴巴的蓝色超链接,或者随机瞎抓取页面里的一张图(有可能抓成了毫不相干的微信付款码或者网站的 LOGO)作为配图,很难看。
  • 按规范配置 OG 标签后:当你发出链接时,微信会自动将这个链接渲染成一张“漂亮的卡片”——有你专门指定的高清封面图、加粗的独立标题,以及两行核心摘要。

常见的刚需级配置项包含这三条:

<meta property="og:title" content="社交卡片独立抓取的加粗标题">
<meta property="og:description" content="社交卡片下的描述区域文本">
<meta property="og:image" content="https://xxx.com/cover.jpg"> <!-- 建议采用 1200x630 的通用规则外链图 -->

四、 网站小图标:<link rel="icon">

也叫 favicon,就是日常打开网页时,显示在浏览器最顶端标签页最左边的那个微型图标,你把网页存到手机桌面时通常也是用它做图标。

现在不用死磕老旧的 .ico 格式了。建议直接拿一张你的 .png.svg 图片放进去,主流终端现在全兼容:

<link rel="icon" href="/favicon.png" type="image/png">

五、 引入外部文件:CSS 和 JavaScript

为了后续修改方便并让多个页面能共用一套代码,我们一般不会把样式和交互全糊在一个文件里,而是把负责“长啥样”的 CSS 和负责“有什么动作”的 JS 单独存成文件,再通过头部把它们接进网页来。

1. 引入 CSS

<link rel="stylesheet" href="style.css">

当浏览器读到这句代码时,会故意停一下加载页面的手头工作,专门去等 style.css 文件下载完。这么干是为了保证用户第一眼看到的就是带颜色、带排版的工整网页,而不是先看到毫无样式的黑白丑文章,等 CSS 来了才突然“闪一下”大变样。

2. 引入 JS 与防卡顿神器 defer

如果不加防备直接引入 JS 文件(比如写成 <script src="script.js"></script>)极易出大事故:浏览器遇到这行代码,会立刻定住网页内容的读取进度,非去下载再运行这写 JS 代码不可。万一代码里写了“点击网页最下面的XX按钮”,但刚才浏览器因为被卡住还没画出这个按钮,整个网页就会当场报错崩溃死在那。

想解决这个问题,加上 defer 参量就行了:

<script src="script.js" defer></script>

加上 defer,其实就是给浏览器传了个话:“你去后台悄悄把这 JS 下载着,别耽误前面正常读代码铺网页。等到整个网页的内容全被你按顺序画完了,你再把下载好的 JS 拿出来运行”。完美做到画面秒开、零卡顿。

六、 声明当前网页的语言:<html lang="zh-CN">

写在代码最顶层的 <html> 标签上,用来向外界明确声明这个网页的主体是什么语言。看似是个没啥用的细节,但不写很容易踩三个暗坑:

  • 坑死搜索引擎排名:像谷歌这种面向全球的引擎,如果搞不清你这是什么语言的区域网,肯定不敢轻易把你推在中文搜索的高权重名次里。
  • 乱弹机器翻译报错:经常用 Chrome 浏览器的朋友可能会遇到,进了某个明明都是方块字的中文网,浏览器却抽风瞎弹出一个框问“需不需要把此页翻译成中文”。这就是因为没标语言导致它犯糊涂了。
  • 逼疯视障读屏用户:盲人上网用的是专门听网页念字的辅助系统。如果你没明确告知语言,有的老外系统的读屏软件,就会拿满嘴洋腔怪调硬念你的中文字,完全听不懂。

小结与下篇预告

<head> 的 7 个核心配置:

  1. <meta charset="utf-8">:防乱码。
  2. <title>:定页面大名、抢搜索排名。
  3. <meta name="description">:提供搜索页的灰色摘要。
  4. OG 标签:搞定微信转发卡片的图文展示。
  5. <link rel="icon">:挂载标签栏小图标。
  6. <link>:引入 CSS 铺样式;<script defer> 引入 JS 加动作且防卡顿加载。
  7. <html lang="zh-CN">:敲定网页所属语言。

配完<head>,终于要进入能在网页上写字的 <body> 区域了。
但很多人上来就会踩一个坑:为了让字变大,直接写一大堆 <span><div> 然后强行加粗变大。这种做法在机器眼里完全是无效信息。

在下一篇《05. HTML标题与段落》里,我们会讲讲机器是怎么“读”网页的,以及怎么用一套严丝合缝的标题(h1~h6)和段落(<p>)搭出清晰的页面骨架。

大家好!经过几个月的精心打磨,我的视频处理应用 Vexo - Video Editor (视频工具箱) 终于在 Google Play 正式上架了!

这是一款专业的一站式视频处理工具,集成了日常所需的各种视频操作功能,无需在多个 APP 之间切换,让视频处理变得简单高效。


🛠️ 核心功能

  • ✂️ 视频裁剪 - 精确到毫秒级的视频截取,随心剪出精彩片段
  • 🗜️ 视频压缩 - 智能压缩算法,大幅减小文件体积同时保持清晰画质
  • 🔗 视频合并 - 多个视频文件无缝拼接,支持批量处理一键合成
  • 🎵 音视频合并 - 为视频添加背景音乐或配音,轻松制作专业感作品
  • 🎭 提取背景音 - AI 智能分离人声与背景音,素材提取更自由
  • 📐 区域裁剪 - 自由框选画面区域,精准裁出你想要的视频内容
  • ⚡ 变速处理 - 灵活调整视频播放速度,慢动作与快进随意切换
  • 🚫 去水印 - 智能识别并去除视频水印,画面干净清爽
  • 🖼️ 修改宽高比 - 支持 16:9 、9:16 、1:1 等多种比例,一键适配各平台
  • 🎞️ 视频转 GIF - 将精彩视频片段转换为高质量 GIF 动图,表情包制作利器
  • 💬 视频添加字幕 - 支持自定义字体、颜色、样式,字幕添加专业又简单
  • 🖼️ 视频换封面 - 自由设置视频封面帧,让你的作品第一眼就吸引人
  • ✂️ 视频分段 - 智能切割视频为多个片段,批量导出更方便
  • 🎨 视频加贴纸 - 海量趣味贴纸随意添加,让视频创作更有趣
  • 💬 视频自动提取并添加字幕 - 开发中...
  • 后续持续添加更多功能!


应用截图
应用截图
应用截图
应用截图

🎁 限时福利活动

为了回馈 V2EX 的技术同行们,特地准备了 一些 PRO 终身版兑换码,先到先得!

兑换码列表:

4QKWHJKWBGCUKPAQ53MPMJE
V3LK664EKS60UX1NF4LAYU4
0MDN0LQATD8AMNDJEXSNS3X
JA4TN5B37EDWL8MZM4DH53G
EBYZ21GRX2F3QV68NLXWF0W
EMGYWUFBCLYEFKKW4C7E966
XC5R6KM79WXCA1LZJM340UH
LWS5GQ0GV7RJNQUD4G1V0BJ
RN4RUKT603WFXW2STFK216M
NN12ZZ0ZLQ7YYCJPYBU4LGP
38RXAETNVQY4YDZ65QK4XAQ
X6S684EYDRXFRL1PRHX7924
25HAAX41S2NZS4ANFKS2TBF
DDXBS8UUSFAV7Z8VU1RV9XL
A32E536T515VUS36NEM8E2R

兑换码用完? 可以发邮件到:[email protected] 申请额外兑换码


📲 兑换步骤

  1. Google Play 下载 Vexo - Video Editor 应用
  2. 打开应用,点击 "购买 PRO 版本"
  3. 支付方式选择 "兑换代码"
  4. 输入上方的兑换码即可免费获得 PRO 终身版


⏰ 重要提醒

  • ⚠️ 兑换码有效期仅一周,请尽快使用
  • 🌟 如果觉得好用,恳请在 Google Play 给个五星好评
  • 💬 如果兑换码用完可以邮件,后续兑换码以评价好礼送出
  • 🐛 使用中遇到任何问题或有功能建议,欢迎通过邮件反馈


📱 下载地址

Google Play: https://play.google.com/store/apps/details?id=com.aicareles.vexo


💬 最后

希望这个工具能帮到有视频处理需求的朋友们!作为独立开发者,我会根据大家的反馈持续优化和更新功能。

感谢 V2EX 社区的支持!🙏

开源维护者正在以惊人的速度关闭对外部贡献者的大门。今年 1 月,Daniel Stenberg关闭了 cURL 为期 6 年的缺陷赏金项目。Mitchell Hashimoto禁止了 Ghostty 中的 AI 生成代码。Steve Ruiz 更进一步——tldraw 现在会自动关闭所有外部拉取请求。这些都不是孤立的事件。它们是对 RedMonk 分析师 Kate Holterhoff 所说的“AI 垃圾”(AI Slopageddon)的回应,即 AI 生成的贡献如此庞大且质量低下,以至于维护者无法跟上。

 

但中欧大学(Central European University)和基尔世界经济研究所(Kiel Institute for the World Economy)最近的一份研究报告显示,表面的危机掩盖了更深层次的结构性威胁。该研究对“氛围编码”(vibe coding)进行了建模,让 AI 智能体在开发者不阅读文档、报告错误或与维护者互动的情况下选择和组装开源包。

 

他们的经济模型显示,当开源项目依赖于用户参与以获得回报、文档访问、缺陷报告和社区认可时,广泛的氛围编程创造了一个负反馈循环。随着开发者将包选择委托给 AI,更少的人会查看文档,更少的人类缺陷被提交,维护者的动力也会减弱。尽管 AI 提高了生产力,但模型预测软件的可用性和质量将会下降。

 

ChatGPT 启动后的六个月内,Stack Overflow的活动减少了25%。Tailwind CSS 的下载量上升,而文档流量下降了 40%,收入下降了 80%。对于 Stenberg 来说,转折点是在支付了 86,000 美元之后:到 2025 年,20%的提交是 AI 生成的,整体有效率下降到 5%。

 

这场危机不仅限于缺陷赏金。Stacklok 的联合创始人 Craig McLuckie描述了优秀的第一期标签是如何吸引工程师们成长为贡献者的。他说:

 

现在我们标记为“好的首次问题”,在不到 24 小时内就会被大量低质量的氛围编程垃圾淹没,这占用了我们做真正工作的时间。

 

Holterhoff 将问题归咎于一个破碎的过滤器。从历史上看,编写代码需要时间和精力,需要筛选出不认真的参与者。AI 消除了这个障碍。

 

作为回应,Hashimoto 在 Ghostty 上采取了零容忍政策,禁止未经批准提交 AI 代码的贡献者:

 

这不是反对 AI 的立场。这是反对白痴的立场。Ghostty 是用大量 AI 辅助编写的,我们的许多维护者每天都在使用 AI。我们只是想要高质量的贡献,无论它们是如何制作的。

 

Ruiz 甚至更进一步。在发现他自己的 AI 脚本创建了写得不好的议题后,贡献者将它们喂给他们的 AI 工具,基于幻觉生成拉取请求后,他关闭了外部贡献:

 

编写代码如果是最容易的那部分,我为什么要让别人来编写呢?

 

平台激励加剧了这个问题。GitHub 在 2025 年 5 月推出了 Copilot 问题生成,而没有给维护者提供过滤 AI 提交的工具。Flux CD 的核心维护者 Stefan Prodan总结了这种不匹配的问题:

 

AI 垃圾正在 DDOS 开源维护者,托管开源项目的平台没有动机去阻止它。相反,他们被激励去夸大 AI 生成的贡献,以向他们的股东展示“价值”。

 

研究人员提出了一个 AI 平台版“Spotify 模型”,在这个模型中,AI 平台根据包的使用情况重新分配订阅收入,但他们的计算显示,氛围编程用户需要贡献目前直接用户收入的 84%,这是一个不切实际的阈值。开源基金会已经发布了侧重于许可而非质量的政策。Linux 基金会处理许可兼容性;Apache推荐使用“Generated-by:”标签。两者都无助于洪水。Gentoo LinuxNetBSD完全禁止 AI 贡献,尽管正如 RedMonk 的 Holterhoff 所指出的,在一两年内,检测违规将在功能上变得不可行。

 

Koren警告说,破坏将是不均衡的:

 

流行的库将继续能找到赞助商。较小的、小众的项目更有可能受到影响。但许多目前成功的项目,如 Linux、git、TeX 或 grep,都是从一个人试图解决自己的问题开始的。如果小型项目的维护者放弃,谁来生产下一个 Linux?

 

目前,像 Stenberg、Hashimoto 和 Ruiz 这样的维护者正在通过一个接一个地关闭项目来回答这个问题。

 

原文链接:

https://www.infoq.com/news/2026/02/ai-floods-close-projects/

还记得上一篇咱们聊过怎么用 1Panel 拯救 Docker 困难户吗?这一篇就是讲解怎么安装最近最流行的软件 openclaw ,现在已经超越 react 和 Linux 在 github 榜单第一位了。

正是 openclaw 的爆火,我们既然已经安装了 1Panel 面板搭好了,如果不跑点好玩的容器岂不是浪费?今天我就带大家玩个大的——在自己的 VPS 上部署一个私人 AI 助理:OpenClaw 。

image

什么是 OpenClaw ?

简单说,它就是你梦想中的 “低配版的贾维斯” (Jarvis) 原型。

项目地址

在以前传统的 AI 我们只能在网页或者 APP 上跟它聊天,或者想 opencode 一样在命令行聊天,但是 openclaw 的体验完全不一样。OpenClaw 的牛逼之处在于,它可以连接你所有的社交软件——**Telegram 、WhatsApp 、Slack 、Discord 。

部署好之后,它就是一个 24 小时在线的私人助理。你可以直接在 Telegram 里问它问题,让它帮你总结群聊消息,甚至通过 API 调用工具。最重要的是,数据掌握在自己手里,速度快,还不用看别人的脸色。

准备工作

  1. 一台装好 1Panel 的 VPS(。

  2. DeepSeek 的 API Key(其他的模型也可以)。

如果想买 VPS 可以:传家宝 VPS 监控

我这里使用的是一台 RackNerd 的 2.5GB 内存的机器,我测试下来最低 2GB 就可以部署,但是如果需要使用浏览器或者其他软件配合最好内存在 8GB 左右会更合适。


第一步:在应用商店“一键安装”

这就是我为什么推荐新手用 1Panel 的原因,部署这种复杂的应用,根本不需要写 Docker Compose 文件。

  1. 登录你的 1Panel 面板。

  2. 点击左侧菜单的 「应用商店」

  3. 在搜索框输入 OpenClaw

  4. 点击 “安装”

image

第二步:配置参数

点击安装后,会弹出一个配置窗口。这里有几个需要注意的地方,大家跟着我填,别填错了:

  • 名称:默认 openclaw 即可。

  • 版本:选 latest 或者最新的版本号。

  • 端口:保持默认( WebUI 18789 ),除非你的端口被占用了。

  • 模型提供商:下拉选择 DeepSeek(模型供应商很多选择自己喜欢的就好)。

image

  • 模型:填入 DeepSeek Chat

image

  • 设置模型账户:点击创建模型账号

  • API Key:把你从 DeepSeek 后台申请的 sk-xxxx 开头的密钥填进去,名称随意填写你能记住的就可以,添加好后选择你的账户。


    DeepSeek API 申请地址

  • Token / 令牌:这里会自动生成,自己保管好,登入的时候需要使用。

image

image

  • 端口外部访问一定要勾选,否则你进不去后台。

确认无误后,点击 “确认” 开始安装,经过一阵跑码之后等待安装完成(可能时间有点久需要耐心一点)。

第三步:登录

如何访问后台?

OpenClaw 为了安全,不允许直接访问 IP:端口,必须带上 Token 。 你的访问地址格式应该是: http://你的 VPS_IP:18789?token=刚才复制的 Token

你如果怕忘记可以把这串地址保存到你浏览器的书签里面去,下次就可以直接打开了。

image

第四步:链接聊天软件(可选操作)

如果你是想在浏览器上使用,这一步就可以不需要了,你的 AI 已经在运行了,但是如果你想让它对接聊天软件,我们需要还需要给他对接聊天软件比如 Telegram 。

1Panel 的强大之处又来了,我们不需要 SSH 连服务器敲命令,直接在网页上搞定。

  1. “已安装应用” 找到 OpenClaw 。

  2. 点击顶部的 “进入安装目录”

  3. 看到文件列表顶部那个 “终端” 按钮

image

  1. 在弹出的黑色框框里,输入下面这行命令(以连接 Telegram 为例):

    docker compose -f docker-compose-cli.yml run --rm openclaw-cli channels add

接下来的交互流程:

  1. 系统会问你选择哪个 Channel ?用键盘上下键选择 Telegram

image

  1. 它会问你要 Bot Token


    • 去 Telegram 找 @BotFather 申请一个机器人,把 Token 粘贴进来。
  2. 设置完成!

如果没生效,可以重启一下 openclaw ,然后在尝试一下。

现在,打开你的 Telegram ,找到你的机器人,给它发一句“你好”,看看是不是 DeepSeek 在回复你?

image


总结

到这里,你就已经拥有了一个运行在自己服务器上的小龙虾了,你可以随时在手机控制它,随时随地的操作玩耍了。 其实很多厂商已经内置了 openclaw 的镜像系统了,但是我更喜欢自己折腾一下,去捣鼓一下。1Panel 也出了官方的 openclaw 安装教程但是不够全面,在这里我就添加了一下自己的设置和踩坑的过程。

如果有需要后续我也会更新更多 openclaw 高级玩法的教程。

  1. 以 claw 为首的 agent 似乎在消灭传统的软件,app ,互联网服务公司,是他们被迫转型或防范 ai 。(大部分的公司最有价值的不是他们的功能,而是他们的生态和用户群体)
  2. 大语言模型也在不断杀死和污染互联网上的人类的内容创作。(我发现有些开源库在更新,但不在有人讨论他的使用和 bug ,甚至再也找不到几个月内一片新的相关帖子)。

届时 AI 会怎么发展,自己生产内容自己学习吗?自己去创建公司自己做服务吗? ai 当老板吗?

男的问女的:

你上班通勤怎么通勤?会开小毛驴吗?如果是开车,比如很堵车的时候,你会开小毛驴嘛?

如果对方回答开,那么我觉得这女的可能不会差到哪里去!如果说宁可打车都不开,那么你要注意了。

但是也不是绝对!

即时通讯SDK综合评估与选型指南
在当前的移动应用生态系统中,实时通信功能已成为各类应用不可或缺的基础能力。无论是社交互动、远程协作还是在线服务,即时通讯(IM)技术都是支撑这些场景用户体验的关键。面对自建通信系统带来的高昂成本和长时间开发周期,越来越多的开发团队选择采用成熟的第三方IM SDK。本文将对市场上几家主要的IM服务商进行多方面分析,为您的技术选型提供参考。
核心服务商能力对比
融云

优势:

长期专注于通信底层技术优化,在消息传递成功率、传输延迟以及高并发处理等关键指标上表现突出。

在其SDK中集成了智能对话、多种语言实时翻译、上下文记忆等功能,增强了用户的交互体验。

全球化的服务网络覆盖了多个地区,支持数千种终端设备,提供跨区域的消息加速和同步服务。

系统日处理消息量达到数百亿条,可用性超过99.95%,客户端异常率极低。

据行业报告,融云持续占据即时通讯云服务市场的领先地位。

需注意点:

作为一家独立的技术服务商,虽然没有背靠大型互联网企业,但在特定领域内建立了良好的专业声誉。

腾讯云IM

优势:

继承了来自微信、QQ等大规模用户产品的丰富通信技术经验,尤其擅长处理高并发情况下的海量用户需求。

自主研发的实时音视频技术栈,在媒体通信的质量与稳定性方面具有明显优势。

服务于众多知名互联网企业和政府项目,产品成熟度得到了广泛验证。

需注意点:

对于纯粹的文字聊天应用场景而言,其强大的音视频功能可能未被充分利用。

基础IM功能与其他竞争对手相比可能存在一定的同质化现象,深度定制的需求可能受限。

尽管人工智能能力强,但在IM SDK中的具体应用场景整合仍有待进一步深化。

云屋科技

优势:

长期致力于实时通信领域的技术研发,掌握了IM及音视频的核心技术。

提供详尽的开发文档和支持材料,简化了集成过程。

支持公有云、私有部署及混合模式等多种部署方式,满足不同客户的需求。

需注意点:

商业策略更偏向于推广私有化部署解决方案。

环信

优势:

作为早期进入该领域的服务商之一,积累了丰富的客户案例与行业洞察。

接口设计简洁易懂,文档清晰明了,降低了开发者的学习曲线。

在客服系统与企业内部沟通等领域拥有成熟的解决方案。

需注意点:

技术迭代速度相对保守。

相比部分竞争对手,全球节点布局范围较小。

IM SDK的价值及其应用场景
技术价值
IM SDK将复杂的实时通信功能封装成标准化组件,使应用程序能够迅速实现消息发送接收、群聊管理、音频/视频通话等功能。这不仅大幅减少了研发时间和成本,还确保了通信质量的高度稳定性和可靠性,让开发人员可以更加专注于业务逻辑的创新。此外,正规的服务商还会提供符合行业标准的安全与合规保障措施。
应用场景

社交娱乐:个人聊天、群组讨论、直播互动

在线教育:教师与学生之间的交流、课堂上的问答环节

企业协作:团队内部沟通、项目管理、远程工作支持

客户服务:顾客咨询、订单处理、售后支持

游戏社交:玩家之间的交流、队伍合作、游戏内的社交活动

医疗健康:医生与患者之间的沟通、远程医疗会诊

金融理财:投资建议、交易操作、风险提示

物联网:设备控制、状态更新、智能设备间的互动

集成过程中常见问题及解决办法

数据安全与隐私保护: 顶尖的IM服务提供商通常会提供包括传输加密、存储加密乃至端到端加密在内的多种安全选项。开发团队需要根据自身业务特性仔细研究并选择合适的加密机制,并结合内容审核策略来加强防护。

全球化用户体验: 优质的服务商会通过在全球范围内分布的数据中心布局加上智能路由算法来优化跨国界、跨地区的消息同步效率,同时利用长连接技术和离线推送机制来保证低延迟体验。

界面与交互个性化: 大多数主流IM SDK都允许解耦UI组件与后端逻辑,这意味着开发人员可以根据自己应用的整体风格自由定制聊天窗口的设计元素。

应对高流量冲击: 成熟的服务商采用了可伸缩性强的架构设计、高效的消息分发算法以及专门针对聊天室的大规模用户支持模块来应对突发性的流量高峰。

跨平台兼容性: 当前市面上领先的IM SDK普遍支持iOS、Android、Web端、桌面版软件、小程序等多种平台,并提供了统一且详细的API接口说明文档。

总结与建议
选择适合您项目的IM SDK时,请从以下几个角度出发进行全面考量:

业务需求匹配程度:明确自己对于文字聊天、多媒体信息交换、语音或视频通话等方面的具体要求。

性能参数:关注如消息送达率、端到端延迟时间、最大并发数限制等关键性能指标。

定制化可能性:评估UI定制灵活性、特殊类型消息扩展能力以及嵌入特定业务逻辑的成本效益比。

长期运营成本:综合考虑初次集成所需投入、后续运维支持费用以及基于使用量计费模式下的总体开销。

服务质量和生态体系:考察供应商提供的技术文档质量、技术支持响应速度、现成行业解决方案的完备程度及其合作伙伴网络。

即时通讯是构建现代应用程序基础设施的重要组成部分,其稳定性和可扩展性直接关系到最终用户体验和业务发展。希望本篇文章能帮助您做出明智的选择,助力您的产品取得成功。

图片

在建筑、机械制造、航空航天等高算力设计领域,传统工作站带来的硬件高要求、运维繁琐、协同低效、数据安全等痛点,始终制约着行业创作与发展的效率。
点量软件凭借十六年视频流传输与编解码核心技术沉淀,打造了点量三维云设计系统——专为高算力需求行业量身定制的云端协同解决方案,以云端化、轻量化、协同化的核心优势,重构专业设计工作模式,让设计摆脱设备与空间的束缚,实现高效创作与协作的全新体验。

一、硬核技术加持,轻量操作亦有专业体验

点量三维云设计实现算力上云、终端减负,让轻量操作也能拥有媲美本地的专业设计体验。
1、云端部署,轻量接入:将专业 3D 设计软件全量部署于云端高性能服务器集群,用户无需本地安装大型软件,打开网页或轻量客户端即可操作,普通电脑、平板、手机、瘦终端均可适配,真正即点即用。
2、超清低延,体验拉满:支持 4K/60Hz、超清分辨率与4:4:4真色彩编码,精准还原设计细节与渲染色彩;自研传输协议实现10-30ms毫秒级响应,鼠标操作顺滑,同步本地手感。
3、全向兼容,零门槛上手:兼容 Solidworks、AutoCAD、UG等主流设计软件,适配Windows、国产信创、Android等全终端系统,各类交互设备无缝衔接,设计师无需改变操作习惯。

二、全域协同升级,打破设计沟通的空间壁垒

针对传统设计协同的诸多痛点,点量三维云设计将极致协同融入核心,打通跨空间、跨团队的设计沟通壁垒。
1、实时协作,高效评审:支持多人同屏实时旁观,方案评审、新手培训无需面对面;参会者可一键接管主控权,远程演示、即时修改设计方案,沟通调整一步到位。
2、内置通讯,数据互通:系统内嵌私有化通讯工具,协作沟通无需切换应用,设计与交流同步进行;打通云端与本地数据流,文件复用更便捷。
3、流程简化,告别混乱:从初稿构思到跨部门、跨地域评审,再到定稿修改,全流程无缝衔接,彻底告别图纸上传下载的繁琐,杜绝版本混乱问题。

三、安全与成本双优,企业设计管理更省心

立足企业实际工作需求,点量三维云设计实现数据安全与成本优化双重保障,让设计管理更高效、更省心。
1、全维防护,守护数据资产:设计数据全量云端存储,终端仅传输操作画面视频流;搭配精准权限控制、USB 映射禁用等功能,实现图纸不落地,从源头杜绝泄密、磁盘故障等风险,用户间数据严格隔离。
2、资源复用,降低运营成本:支持License授权复用,算力与授权按需分配、错峰使用,提升正版软件利用率,避免临时使用的成本浪费;服务器端集中部署、统一升级维护,减少 IT 运维工作量与成本。
3、国产适配,助力转型发展:全面兼容鲲鹏、海光等国产CPU,麒麟、统信 UOS 等国产操作系统及国产显卡,为企业国产化转型提供稳定、专业的技术支撑,适配国产化办公场景

从高端制造业的零部件设计仿真,到建筑家居的 BIM 设计,再到医疗影像阅片、3D设计教学培训,点量三维云设计正在让越来越多的创作者摆脱硬件的束缚,专注于设计本身。

云端设计,协同无界 | 点量三维云设计,让创作更自由

引言

Python 是当今最广泛使用的编程语言之一,但许多开发者对其底层执行机制知之甚少。Python 常被笼统地称为"解释型语言",但这一说法并不完全准确。CPython——Python 的参考实现——实际上采用了编译 + 解释的混合策略:先将源代码编译为一种中间表示——字节码(bytecode),再由 Python 虚拟机(PVM)逐条执行这些字节码指令。这个过程对用户几乎完全透明,却是理解 Python 性能特征、跨平台能力和扩展机制的关键入口。

本文将从编译流程、字节码结构、缓存机制、跨平台通用性、跨语言交互、GIL 与并发模型以及性能评估等多个维度,对 Python 3 的字节码机制进行全面梳理。


1. 从源码到字节码:编译流程

当执行一个 .py 文件时,CPython 内部经历以下几个阶段:

  1. 词法分析(Tokenizing):将源代码文本分解为 token 流。
  2. 语法分析(Parsing):根据 Python 语法规则,将 token 流构建为抽象语法树(AST)。
  3. 编译(Compiling):遍历 AST,生成字节码指令序列,封装为 code object。
  4. 执行(Executing):PVM 的求值循环(eval loop)逐条取出并执行字节码指令。

编译产物——即字节码——会被缓存为 .pyc 文件,存放在源文件所在目录的 __pycache__ 子目录下,文件名包含 Python 版本标识,如 module.cpython-312.pyc。下次导入同一模块时,若源码未发生变化,CPython 直接加载 .pyc,跳过前三步,从而节省编译开销。


2. 字节码的结构与表示

2.1 指令格式

Python 字节码面向一个栈式虚拟机。每条指令由操作码(opcode)和可选参数组成。操作码定义了指令类型(如加载变量、执行运算、跳转等),参数则索引到 code object 的常量池、变量名表等数据结构中。

使用标准库的 dis 模块可以直观地查看字节码:

import dis

def add(a, b):
    return a + b

dis.dis(add)

输出示例:

  2           0 LOAD_FAST                0 (a)
              2 LOAD_FAST                1 (b)
              4 BINARY_ADD
              6 RETURN_VALUE

其中 LOAD_FAST 将局部变量压入操作数栈,BINARY_ADD 弹出栈顶两个值相加后将结果压回栈顶,RETURN_VALUE 返回栈顶值给调用者。

2.2 Code Object

每个函数、模块和类体编译后都会生成一个 code object(可通过 func.__code__ 访问)。code object 包含以下关键字段:

  • co_code:原始字节码序列(Python 3.11+ 内部结构有所调整)。
  • co_consts:常量池,存放函数体中出现的数字、字符串、None 等字面量。
  • co_varnames:局部变量名称元组。
  • co_names:全局变量和属性名称。
  • co_stacksize:执行该代码块所需的最大操作数栈深度。

code object 是不可变的,这意味着字节码一旦编译完成就不能被修改——这也是 .pyc 缓存能够安全复用的基础。

2.3 求值循环

CPython 的核心执行引擎位于 C 源文件 ceval.c 中的 _PyEval_EvalFrameDefault 函数。它维护一个值栈(value stack),通过一个巨大的 switch-case(或计算跳转表)逐条分发字节码指令到对应的 C 代码段执行。

Python 3.11 引入了 specializing adaptive interpreter(PEP 659),在运行时将通用指令替换为针对特定类型优化的快速版本。例如,当 BINARY_ADD 连续多次操作 int 类型时,解释器会将其特化为 BINARY_ADD_INT,跳过类型检查,直接执行整数加法。这一机制带来了显著的性能提升。


3. 缓存机制与失效策略

3.1 .pyc 文件格式

.pyc 文件由 16 字节的头部和序列化的 code object 组成。头部包含以下字段:

偏移大小内容
04 字节Magic number(标识 CPython 版本)
44 字节位字段(标识失效策略类型)
88 字节时间戳 + 文件大小,或源码哈希

Magic number 是跨版本兼容性的第一道防线:CPython 3.11 的 magic number 与 3.12 不同,版本不匹配时直接丢弃缓存。

3.2 时间戳失效(默认策略)

这是 CPython 自诞生以来使用的传统方式。导入模块时,解释器对源文件执行一次 stat 系统调用,将获取到的最后修改时间(mtime)和文件大小与 .pyc 头部记录的值进行比对。两者都匹配则认为缓存有效;任一不匹配则重新编译源文件并写入新的 .pyc

这种方式的优点是速度极快——只需一次轻量的系统调用,无需读取源文件内容。但它存在一个根本性缺陷:时间戳是文件系统的元数据,而非源码内容的函数。相同的源码在不同机器上编译,因 mtime 不同会产出字节不同的 .pyc 文件。这在需要可复现构建(reproducible build)的场景(如 Bazel 等基于内容的构建系统)中是不可接受的。

3.3 哈希失效(PEP 552,Python 3.7+)

为解决上述问题,PEP 552 引入了基于哈希的缓存失效机制。.pyc 头部存储源文件内容的 64 位 SipHash 值,导入时 CPython 读取源文件并重新计算哈希进行比对。该机制又分为两种模式:

  • Checked hash:导入时始终验证哈希,不匹配则重新生成 .pyc
  • Unchecked hash:导入时直接信任缓存,由外部系统(如 Linux 发行版包管理器)负责保持缓存一致性。

哈希方式的代价是需要读取整个源文件并计算哈希,比简单的 stat 调用更昂贵。因此默认策略仍为时间戳方式,哈希方式主要面向发行版打包和自动化构建等高级场景。

可通过 py_compilecompileall--invalidation-mode 参数选择模式,运行时也可使用 --check-hash-based-pycs 选项覆盖默认行为。

3.4 完整的判断链路

综合来看,CPython 导入模块时的缓存判断遵循如下流程:

Magic number 匹配?
  ├─ 否 → 丢弃缓存,重新编译
  └─ 是 → 读取位字段,判断失效策略类型
           ├─ 时间戳策略 → stat 源文件,比对 mtime 和 size
           └─ 哈希策略
                ├─ Checked → 读取源文件,计算并比对哈希
                └─ Unchecked → 直接信任缓存
           匹配?
             ├─ 是 → 加载 .pyc 中的 code object
             └─ 否 → 重新编译源文件,写入新 .pyc

4. 跨平台通用性

Python 字节码在设计上是平台无关的。同一份 .pyc 文件理论上可以在任何操作系统上被相同版本的 CPython 执行,因为字节码运行在虚拟机之上,不直接对应任何硬件指令集。

4.1 版本强绑定

字节码格式随 CPython 版本变化,magic number 保证了版本隔离。CPython 3.11 的 .pyc 无法被 3.12 加载,反之亦然。跨平台通用的前提是同一 CPython 版本

4.2 字节序与字长无关

字节码本身是字节流,不存在大小端问题。code object 中的常量(整数、浮点数)由 marshal 模块以固定格式序列化,不依赖平台的原生字长或字节序。

4.3 平台差异的下沉

字节码层保证了可移植性,但实际的平台差异被隔离在两个地方:

  • 标准库的平台相关部分:如 os.fork()(仅 Unix)、signal 模块等,调用这些功能的代码在某些平台上不可用。
  • C 扩展模块:编译为 .so(Linux/macOS)或 .pyd(Windows)的原生库是平台相关的二进制文件。

换言之,字节码层负责逻辑的可移植性,平台差异被推到了 VM 以下和扩展模块中。

4.4 其他 Python 实现

PyPy、GraalPy 等替代实现有各自独立的字节码格式,与 CPython 不互通。跨实现的可移植性只在源码层面成立,不在字节码层面。


5. 跨语言交互:从字节码世界跳入原生代码

字节码机制在遇到跨语言调用时,本质上是从字节码世界跳出 VM,进入原生代码世界。这一跳转有多种路径,但核心边界始终由 CPython 的 C API 定义。

5.1 C 扩展模块(CPython C API)

这是最传统、最成熟的方式。用 C/C++ 编写的扩展模块编译为共享库,通过 CPython C API 注册函数和类型。当字节码执行 CALL_FUNCTION 等指令时,VM 检测到目标是一个 C 级别的 PyCFunction,就直接调用其函数指针,完全绕过字节码解释。这也是 NumPy、pandas 等库高性能的根本原因——热路径全部运行在编译好的原生代码中。

5.2 ctypes 与 cffi

这两个库允许 Python 在运行时动态加载共享库并调用其中的函数。从字节码角度看,ctypes.cdll.LoadLibrary() 和后续的函数调用都是普通的 Python 方法调用(走正常的字节码路径),但在 C 层面它们通过 libffi 完成了参数打包、ABI 调用和返回值拆包。

5.3 Cython 与 PyO3(Rust)

Cython 将类 Python 语法编译为 C 代码,再编译为标准的 C 扩展模块。PyO3 让 Rust 代码直接实现 CPython C API。两者的最终产物都是标准扩展模块,VM 以完全相同的方式调用它们。对字节码层来说,调用一个 Rust 函数与调用一个 C 函数没有任何区别。

5.4 关键约束:引用计数与对象协议

无论采用哪种跨语言方式,原生代码都必须遵守 CPython 的引用计数规则(Py_INCREF / Py_DECREF)和对象协议。字节码中的每条指令都假设操作数是合法的 PyObject*,如果 C/Rust 侧破坏了这一约定,就会导致段错误或内存泄漏。这是跨语言交互中最大的风险点,也是 PyO3 等高层封装库试图消除的痛点。


6. GIL 与并发模型

GIL(全局解释器锁)与字节码执行的关系极为紧密,因为它直接控制着哪个线程能进入求值循环

6.1 传统模型(GIL 启用)

CPython 的求值循环在执行字节码时持有 GIL。Python 3.12 及之后的版本基于时间片(而非指令计数)来决定是否释放 GIL 以让其他线程运行。I/O 操作和 C 扩展可以通过 Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS 宏主动释放 GIL,使其他线程得以并行执行字节码。

这就是多线程在 CPU 密集型任务上无法真正并行、但在 I/O 密集型场景下仍然有效的根本原因。

6.2 自由线程模式(PEP 703,Python 3.13+)

CPython 3.13 引入了实验性的 --disable-gil 构建(free-threaded CPython),这是 Python 并发模型的一次根本性变革。在这种模式下,字节码执行层面发生了深层变化:

  • 偏置引用计数(Biased Reference Counting):引用计数从简单的递增/递减改为偏置方案,避免多线程下的原子操作瓶颈。
  • Per-object 细粒度锁dictlist 等可变对象内部加了独立的锁,替代原来 GIL 提供的隐式全局互斥。
  • Adaptive interpreter 的线程安全适配:多个线程可能同时特化同一段代码,特化过程需要保证原子性。
  • C 扩展兼容性声明:扩展模块需要通过 Py_mod_gil slot 声明自己是否支持 free-threaded 模式,不支持的模块会回退到单线程执行。

6.3 对字节码本身的影响

无论 GIL 是否启用,字节码指令集是相同的。差异在于 VM 的执行策略:有 GIL 时,同一时刻只有一个线程在执行字节码,天然线程安全;无 GIL 时,VM 必须在更低层次(对象级锁、原子操作)保证一致性。从开发者角度看,Python 代码和字节码不需要改动,底层运行时语义的变化对上层透明。


7. 性能评估:字节码缓存的加速效果

7.1 加速的本质

首先必须明确一个关键区别:.pyc 缓存只加速程序的加载(import)过程,不加速实际的运行时执行。有无 .pyc,运行期间执行的字节码指令是完全相同的。缓存节省的是导入阶段的词法分析、语法分析和编译开销。

7.2 实测数据

对大型项目的影响显著。一项针对 Bazaar(包含数百个 Python 文件的版本控制工具)的基准测试表明:禁用字节码缓存后,启动速度下降了一倍多——有 .pyc 缓存时快了超过 2 倍。这符合直觉:大型项目导入上百个模块,每个模块都要重新解析和编译,开销显著累积。

但对于 CPU 密集型的长时间运行任务(只用到少量模块),有无 .pyc 之间几乎没有可测量的差别。因为编译成本只在导入时发生一次,运行阶段执行的字节码完全相同。

7.3 字节码执行层面的优化

除了缓存带来的加载加速外,CPython 近年来在字节码执行效率上也取得了重大进展:

  • CPython 3.11:引入 specializing adaptive interpreter 和 inline cache,相比 3.10 平均快约 25%,部分纯 Python 工作负载快了近 2 倍。
  • Deep freeze 技术:将标准库的 code object 直接嵌入解释器二进制文件的数据段中,使加载内置模块的成本降低到仅需解引用一个指针,完全消除了 .pyc 的 I/O 和反序列化开销。
  • Register-based interpreter 研究:学术界的 RegCPython 项目证明,将 CPython 的栈式架构改为寄存器式架构,在最优情况下可实现约 1.29 倍的加速,且不破坏现有的语法和 ABI 兼容性。

7.4 小结

字节码缓存的收益与项目规模直接相关。对于导入大量模块的应用,.pyc 缓存可以将启动时间缩短一半甚至更多;对于简单脚本或长期运行的服务,启动开销占比极小,缓存的加速效果可以忽略不计。真正影响运行时性能的是字节码解释器本身的优化(如 adaptive specialization),而非缓存机制。


8. 总结与展望

字节码作为 Python 执行模型的中间层,扮演着承上启下的关键角色。它向上屏蔽了硬件与操作系统的差异,提供了跨平台的可移植性;向下通过 C API 定义了与原生代码交互的统一边界;在并发维度上,通过 GIL 策略的灵活切换适配了不同的线程模型——而字节码指令集本身在这三个维度上都保持了稳定。

展望未来,Python 字节码机制仍在持续演进:

  • Free-threaded CPython 的成熟将从根本上改变 Python 的并发能力,字节码执行层面的同步策略也将随之完善。
  • JIT 编译(如 CPython 3.13 中开始实验的 copy-and-patch JIT)将字节码的热点路径编译为原生机器码,有望带来更大的性能飞跃。
  • 字节码格式的持续优化,如 inline cache、指令特化、乃至未来可能的寄存器式架构迁移,都在不断缩小 Python 与编译型语言之间的性能差距。

理解字节码机制,不仅有助于编写更高效的 Python 代码,也为深入参与 CPython 核心开发和性能优化提供了必要的知识基础。


参考资料

  • PEP 552 — Deterministic pycs(哈希缓存失效机制)
  • PEP 659 — Specializing Adaptive Interpreter(自适应特化解释器)
  • PEP 703 — Making the Global Interpreter Lock Optional(可选 GIL)
  • CPython 官方文档:What's New In Python 3.11(性能改进说明)
  • RegCPython: A Register-based Python Interpreter for Better Performance(ACM 论文)
  • Python dis 模块官方文档

不知不觉中,发现自己的某音关注已经到达了一千多个。如果想让关注数量显示得少一点,就需要一个一个点击取消关注。这种方式非常浪费时间,而且很不优雅。
图片
有没有什么方式可以自动取消关注?

有的。

本文将完整演示如何使用 Automa 编写一个自动批量取消关注的脚本,并分析其优缺点。

想看视频讲解也可以看视频

https://www.bilibili.com/video/BV1uzAizVEcx/?aid=116150042103...

一、什么是 Automa?

Automa 是一个谷歌浏览器扩展程序,用于对浏览器进行自动化操作。
图片
它主打低代码、无代码模式,只需安装一个浏览器插件,就可以对浏览器执行自动化流程。
图片
自动化工具其实是一个很大的类别:最轻量级的是 Automa,只需插件即可运行。更专业的工具包括 Selenium、Playwright 等。企业级自动化工具包括 RPA,例如 UiPath 等。
图片
今天我们重点体验 Automa 的实际使用效果。

二、安装 Automa

安装步骤如下:打开谷歌浏览器点击右上角 → 管理扩展程序
图片
打开 Chrome 应用商店
图片
搜索 Automa
图片
点击“添加到 Chrome”
图片
添加扩展程序并等待下载完成安装完成后,即可在浏览器右上角看到 Automa 图标。

三、脚本思路规划

在正式编写工作流之前,我们需要先规划逻辑。目标:找到文本为“已关注”或“相互关注”的按钮,然后点击。通过观察页面可以发现:
图片
按钮类型为 button文本可能是“已关注”或“相互关注”因此核心逻辑是:选择文本为“已关注”或“相互关注”的按钮 → 点击

四、设置中文界面

打开 Automa:点击右上角 Automa 图标
图片
进入 Dashboard
图片
Settings → Language → 选择简体中文
图片
虽然部分仍为英文,但基本可以使用。

五、创建工作流

    1. 新建工作流点击“新建工作流”命名为:抖音取消关注
      图片
  1. 选择元素使用元素选择器:选择“已关注”按钮切换为 XPath 方式定位
    图片
    新手如果不熟悉 XPath,可以借助ai工具生成,我这里用了豆包生成:选择所有文本为“已关注”或“相互关注”的按钮。
    图片
    验证选择器,确认可以正确选中按钮。
    图片

六、编写点击逻辑

拖入:

点击元素
将 XPath 粘贴进去

添加触发器(开始节点)

点击运行测试:
图片
可以看到按钮被成功点击。
图片

七、加入循环

当前仍需手动运行多次,因此需要加入循环。

步骤:添加“重复任务”设置执行次数正确连接流程
图片

⚠ 第一个 Bug

如果从重复任务的上方节点回连,会造成无限循环。正确方式:必须连接到“重复”计数节点,否则不会正确计数。
图片
修正后即可正常计数执行。

八、加入延迟(解决风控问题)

问题:点击速度过快,一秒几十次,平台会判定为非人工操作,点击无效。

解决方案:添加“延迟”模块。每次点击后延迟 500 毫秒(0.5 秒)再进入下一轮循环这样更接近人类操作速度。
图片
测试后发现:可以正确执行指定次数不再出现无限循环点击速度合理

九、第二个 Bug:页面未自动加载

当设置 1000 次运行时,脚本会提前停止。

图片

原因:抖音关注列表不是一次性加载,需要向下滚动才会继续刷新。Automa 本身不支持真实鼠标滚轮控制,滚动元素等模块无法达到预期效果。理论上可以用 JS 实现,但会比较复杂,不适合零基础新手。

解决方案:手动滚动页面,将列表全部加载出来,再运行脚本。十、最终执行结果在手动加载全部关注列表后:设置重复 1000 次执行脚本关注数量明显减少刷新页面确认:
图片
取消关注确实生效。

十一、总结

经过约 20 分钟,从零开始完成了抖音批量取消关注脚本的编写。

通过这次实战,可以总结三点:
1️⃣ Automa 确实适合解决重复性低价值点击操作例如:批量取消关注,简单表单自动点击,效率提升非常明显。
2️⃣ 它并非无脑拖拽工具你仍然需要具备:页面元素结构认知,XPath / CSS 选择器基础,基本逻辑理解风控意识,否则很容易出问题。拖拽形式既是优点,也是缺点:优点:小白容易上手,缺点:复杂逻辑会变得很混乱,AI 目前也无法直接生成这种拖拽式流程,开发效率反而低于代码rpa
3️⃣ Automa 是轻量级自动化工具适合:简单浏览器流程自动化,轻度重复操作,

不适合:大规模数据采集,复杂逻辑控制,工程级自动化部署,

如果需求复杂,建议使用:Selenium,Playwright,企业级 RPA 工具

近日,外媒《The Information》披露,人工智能巨头 OpenAI 正着手开发一款全新的代码托管平台,直接将竞争目标对准微软旗下的 GitHub——当前全球最主流的代码协作与托管平台。

这一举措不仅意味着 OpenAI 将拓展新的业务边界,更引发了行业对其与主要股东微软关系的广泛关注。

消息人士向该媒体透露了 OpenAI 这一秘密项目的相关细节。

据悉,促使 OpenAI 下定决心开发这一替代产品的核心原因,是 GitHub 近几个月来频发的服务中断问题。

根据 GitHub 官方状态页面记录,自 2025 年下半年以来,该平台多次出现服务异常,包括 2025 年 8 月因数据库基础设施变更引发的全球大规模宕机,以及 11 月、12 月先后出现的 Copilot 服务中断、登录流程故障、代码空间连接异常等问题,这些中断不仅影响普通开发者,更严重干扰了 OpenAI 内部的研发进度,成为其自主开发代码托管平台的直接诱因。

《The Information》进一步补充,目前 OpenAI 的这款代码托管项目仍处于早期研发阶段,按照现有进度,可能还需要数月时间才能完成开发并推向市场。

值得关注的是,参与该项目的内部员工透露,团队已开始探讨产品的商业化路径,其中就包括将代码库作为增值服务,向 OpenAI 现有的庞大客户群体开放购买权限,这意味着该产品未来有望成为 OpenAI 新的营收增长点。

截至目前,这一报道尚未得到多方权威证实。

路透社明确表示,无法独立核实该消息的真实性;而 OpenAI、GitHub 以及微软三方,截至发稿前均未对该传闻作出任何置评回应,也未披露任何与该项目相关的官方信息,留给行业诸多猜测空间。

从行业格局来看,若 OpenAI 最终推出这款代码托管产品并实现商业化出售,将成为其发展历程中一次大胆的突破——这意味着 ChatGPT 的创建者将直接与持有其大量股份的微软展开正面竞争。

据悉,微软目前持有 OpenAI 营利实体 27%的股份,是其单一最大股东,双方自 2019 年起建立深度合作关系,微软通过 Azure 云服务为 OpenAI 提供算力支持,同时享有相关技术的 IP 授权。此次 OpenAI 计划推出 GitHub 替代方案,无疑将对双方的合作关系带来新的考验。

值得注意的是,OpenAI 近期的资本表现为其拓展新业务提供了坚实支撑。

该公司最新完成的一轮私募融资规模达 1100 亿美元,由亚马逊领投 500 亿美元,英伟达与软银各出资 300 亿美元,融资后估值突破 8000 亿美元,刷新了全球私有企业融资规模纪录。这一巨额融资吸引了大型科技公司与知名投资机构的积极参与,即便当前市场存在对 AI 行业估值泡沫的担忧,但这一举措也清晰表明,全球人工智能领域的投资竞赛依然活跃,资本对 AI 技术的长期发展依然保持高度信心。

业内分析认为,OpenAI 此次布局代码托管领域,既是为了解决自身面临的服务稳定性痛点,将代码资产控制权掌握在自己手中,也是其依托自身 AI 技术优势、拓展业务边界的重要尝试。

未来,若该产品成功推出,有望凭借 AI 技术与代码托管的深度融合形成差异化优势,与 GitHub 展开竞争,进而重塑全球代码托管市场的格局。而其与微软的合作关系如何平衡,产品最终能否实现商业化落地,仍有待进一步观察。

参考链接:

https://www.thestar.com.my/tech/tech-news/2026/03/04/openai-is-developing-alternative-to-microsoft039s-github-the-information-reports

第七章 分区表管理与使用

在ESP32中,分区表是定义Flash存储区域的关键组成部分。它决定了应用程序、数据存储和OTA更新等如何在芯片内部分配和管理,从而影响到整个应用的性能和功能。
本章将分为如下几个小节:
7.1 分区表概述
7.2 分区表API函数

7.1 分区表概述

在ESP32开发中,分区表(Partition Table)是一个关键的系统组件,用于定义芯片上Flash存储器的分配方式。通过分区表,可以指定Flash存储的不同区域分别用来存放应用程序、文件系统、OTA更新数据等。简单来讲,分区表用于告诉ESP32设备如何划分其内部的Flash存储区域。每个分区都有特定的用途,例如:
1)factory分区:存储应用程序固件。
2)ota分区:用于存储空中下载(OTA)更新的固件。
3)nvs分区:用于存储非易失性存的数据,常用于保存配置信息。
4)spiffs/fat分区:文件系统分区,用于存储用户数据。
5)phy_init分区:专门用于存储Wi-Fi和蓝牙物理层初始化数据的区域
6)自定义分区:用于存储用户的数据。
接下来,笔者将重点讲解分区表的格式及分区表条目结构。通过化整为零的方式,我们将逐步了解分区表的各个组成部分,深入剖析每个元素的作用和意义。

7.1.1 分区表的格式

ESP32的分区表通常使用两种格式来定义存储空间的布局:
1)csv格式:开发人员使用的格式,方便更改和配置各个分区的偏移地址和大小。它是易于阅读和修改的文本文件。
2)bin格式:用于烧录到设备的二进制文件。在编译过程中,系统会将CSV格式的分区表转换为bin格式,供烧录工具使用。
在编写程序时,开发人员可以通过修改 .csv 文件来定义各个子分区,如应用程序代码、OTA更新、SPIFFS文件系统等的存储区域。当项目编译时,CSV格式会自动转化为BIN文件,并在烧录设备时使用。下面我们来看一下本书籍提供的例程示例分区表,如下内容所示。

图7.1.1.1 书籍示例的分区表
上图中,分区的大小和偏移决定了每个分区在闪存中的位置和空间分配,以下是各个子分区的描述内容:
1,nvs分区:用于存储非易失性存储数据,通常用于保存设备的配置参数。它从地址0x9000开始,占用24KB的空间。这部分存储器为设备提供了一个可以在断电后仍然保存数据的区域。
2,phy_init分区:用于存储物理层初始化数据,主要用于Wi-Fi或蓝牙的硬件配置。该分区从地址0xF000开始,占用4KB的存储空间。
3,factory分区:是设备默认的应用程序存储区,它从地址0x10000开始,占用1MB的空间。设备上电后,会从这个分区加载并运行主要的程序代码。
4,vfs分区:用于FAT文件系统存储,适合用于文件操作或存储大容量数据。它从地址0x200000 开始,占用10MB的空间,通常用于挂载外部存储设备,如SD卡。
5,storage分区:用于SPIFFS文件系统,适合存储小型文件或嵌入式应用中的配置数据。该分区从地址0xC00000开始,占用4MB的空间。
为了帮助读者更好地理解分区表,以下将以图形化的形式进行描述,如下图所示。

图7.1.1.2 16MB Flash划分区域示意图
从上图可知。用户可根据需求调整分区的大小和偏移位置,但笔者建议尽量不要修改启动区域和分区表烧入区域,保持默认设置。这有助于避免潜在的启动问题和系统不兼容情况,从而确保系统的稳定性和正常运行。值得注意的是:Factory /OTA等程序存储分区视为加密分区,用户不可随意修改。
综上所述,分区表是用户为系统准备的Flash区域划分目录,系统从地址0x8000读取分区表信息,以了解区域的范围、大小及各自的功能和作用。

7.1.2 分区表条目结构

分区表中的每个条目都由以下几个部分组成:
1,Name:分区的名称,用于标识该分区的具体用途。
2,Type:分区的类型,主要分为 app(应用程序) 和 data(数据)。
3,SubType:分区的子类型,用于进一步说明数据的用途,例如 nvs(非易失性存储)、phy(物理初始化数据)、fat(FAT文件系统)和 spiffs(SPIFFS文件系统)。
4,Offset:分区在闪存中的起始地址,通常以十六进制表示。
根据这些关键字段,系统能够精确定位每个分区并执行相应操作。例如,系统通过Name字段识别分区的用途;通过Type和SubType进一步明确数据的类型和处理方式;Offset则帮助系统找到分区在闪存中的起始位置和大小。这些信息使系统能够准确地进行读写、擦除等操作,从而确保分区操作的可靠性和有效性。
根据乐鑫ESP-IDF编程指南所示,分区表的长度为0xC00字节,最多可容纳95条分区表条目,也就是说每个条目占用32字节(3072 (0xC00十进制数值)÷ 95 = 32)。接下来,我们来看一下在ESP-IDF(SDK)程序中如何定义分区表结构体,以下是相关代码:

/**
 * @brief       ESP32 分区结构体
 */
typedef struct 
{ 
    esp_flash_t* flash_chip;            /* 指向所使用的 Flash 芯片的指针 */
    esp_partition_type_t type;          /* 分区的类型 */
    esp_partition_subtype_t subtype;    /* 分区的子类型 */
    uint32_t address;                   /* 分区在闪存中的起始地址 */
    uint32_t size;                      /* 分区的大小 */
    uint32_t erase_size;                /* 分区的擦除大小 */
    char label[17];               /* 分区的标签,最多可包含16个字符(末尾包含终止符)*/
    bool encrypted;                     /* 是否启用加密 */
    bool readonly;                      /* 是否为只读分区 */
} esp_partition_t;

很多人认为,通过调用sizeof(esp_partition_t)可以获取分区表条目的大小,其实并不完全正确。因为每个分区表条目由Name、Type、SubType和Offset组成,上述结构体成员变量仅部分描述了这一结构。下面笔者将基于分区表条目的组成,对esp_partition_t结构体进行一次缩减,代码如下:

/**
 * @brief       ESP32 分区结构体
 */
typedef struct 
{ 
    esp_partition_type_t type;          /* 分区的类型 */
    esp_partition_subtype_t subtype;    /* 分区的子类型 */
    uint32_t address;                   /* 分区在闪存中的起始地址 */
    char label[17]; /* 分区的标签,最多可包含16个字符(末尾包含终止符) */
} esp_partition_t;

这样我们就可以得到描述每个条目的结构体,然后使用sizeof(reduced_esp_partition_t)来获取分区表条目的大小。经过系统计算,最终得出的大小接近32字节。这确认了每个条目的存储结构符合预期。
注意:为确保分区表的完整性,系统在分区表末尾附加了MD5校验和(根据分区表内容计算,可在设备启动阶段用于验证分区表的完整性),以便在运行时进行验证。整个分区表占据一个完整的Flash扇区,大小为0x1000(4KB)。因此,紧随分区表之后的任何分区,其起始地址必须位于默认偏移地址 + 0x1000处,以避免与分区表区域重叠。这种设计确保了分区表与其他数据区域的安全隔离,并有助于系统在启动时正确加载各个分区。
若读者想关闭MD5校验和操作,则可以在Menuconfig菜单配置下失能MDK5校验和,如下图所示。

图7.1.2.1 Menuconfig菜单下失能MDK5校验和
在上图中,取消勾选红色框中的选项即可关闭MD5校验和。

7.2 分区表API函数

esp_partition组件是ESP-IDF中用于管理ESP32及其系列芯片上Flash分区的关键组件。它提供了一组高层次的API函数,允许开发者方便地访问和操作定义在分区表中的各个分区。这些高层次的API函数为开发者提供了简洁易用的接口,以进行读取、写入、擦除分区内容等操作。这些分区表API函数可以在components/esp_partition/include/esp_partition.h路径下找到。
1,根据一个或多个参数查找第一个分区esp_partition_find_first
该函数是用于根据一个或多个参数查找第一个分区,该函数原型如下所示:

const esp_partition_t *esp_partition_find_first(esp_partition_type_t type,
                                                esp_partition_subtype_t subtype,
                                                const char *label)

函数形参:

表7.2.1 esp_partition_find函数函数描述
返回值:
句柄:指向 esp_partition_t 结构体的指针。
NULL:未找到分区。
2,从分区中读取数据esp_partition_read
该函数是用于从分区中读取数据,该函数原型如下所示:

esp_err_t esp_partition_read( const esp_partition_t* partition,
                              size_t src_offset, void* dst, size_t size)

函数形参:

表7.2.2 esp_partition_read函数函数描述
返回值:
ESP_OK:读取成功。
ESP_ERR_INVALID_ARG:超过分区大小。
ESP_ERR_INVALID_SIZE:读取会超出分区边界。
3,将数据写入分区esp_partition_write
该函数是用于将数据写入分区,该函数原型如下所示:

esp_err_t esp_partition_write( const esp_partition_t* partition,
                               size_t dst_offset, void* src, size_t size)

函数形参:

表7.2.3 esp_partition_write函数函数描述
返回值:
ESP_OK:如果数据写入成功。
ESP_ERR_INVALID_ARG:如果 dst_offset 超出了分区大小。
ESP_ERR_INVALID_SIZE:如果写入范围超出了分区边界。
ESP_ERR_NOT_ALLOWED:如果分区为只读。
4,擦除分区的一部分区域esp_partition_erase_range
该函数是用于擦除分区的一部分,该函数原型如下所示:

esp_err_t esp_partition_erase_range(const esp_partition_t *partition,
                                    size_t offset, size_t size)

函数形参:

表7.2.4 esp_partition_erase_range函数函数描述
返回值:
ESP_OK:如果范围擦除成功。
ESP_ERR_INVALID_ARG:如果传入的参数无效(如 iterator 或 dst 为 NULL)。
ESP_ERR_INVALID_SIZE:如果擦除范围超出了分区边界。
ESP_ERR_NOT_ALLOWED:如果分区为只读。
上述列举的函数是访问和操作分区表时常用的API函数。若需进一步了解或学习其他剩余的分区表API函数,可查阅esp_partition.h头文件。如果读者想了解这些函数的使用方法,可以查看本书提供的示例28_chinese_display下的fonts.c文件,笔者使用这些函数将GBK字库更新至storage分区,并完成了汉字显示实验。

VMware Cloud Foundation 9.0.2.0 发布 - 领先的多云平台

高效管理虚拟机 (VM) 和容器工作负载,为本地部署的全栈超融合基础架构 (HCI) 提供云的优势。

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

作者主页:sysin.org


2026 年 1 月 20 日,VMware Cloud Foundation 9.0.2.0 已正式发布。

多年来,数字化转型一直被描绘成一种二选一的抉择:要么在公有云中快速推进,要么保留本地部署的控制权——但往往要以牺牲敏捷性、增加复杂性以及技术债务为代价。这种权衡如今已不再合理。

现代工作负载,尤其是 AI 和数据密集型应用,正在推动一种全新的现实。以 PB 级规模的数据集,不可能轻易在不同区域之间传输。监管要求日益严格,越来越多的关键工作负载必须留在主权边界之内。同时,“按需付费”的云模式所带来的账单和成本冲击,也逐渐让各行业的财务团队措手不及。

借助 VCF 9.0,我们正在重新定义现代私有云的能力——融合了云体验的速度与灵活性 (sysin),以及企业在本地部署中所需的性能、治理和成本控制。

当构建得当时,一个现代私有云应当具备以下特点:

  • 将服务器、存储和网络视为灵活的软件资源池;
  • 向开发人员提供自助式 API,而不是排队等候的服务单系统;
  • 支持虚拟机、容器以及新兴的 AI 服务作为一等工作负载并行运行;
  • 在核心数据中心、边缘节点以及主权设施之间保持一致性,无需政策混乱;
  • 内建可审计的安全机制,并为工作负载在任何位置的运行提供合规保障。

VMware-sysin

概述

VMware Cloud Foundation

VMware Cloud Foundation 是一个统一的私有云平台,将公有云的规模与敏捷性与私有云的安全性与高性能相结合,从而提升生产力并降低总体拥有成本(TCO)。该平台通过在所有终端上集成企业级计算、网络、存储、管理和安全功能,实现基础架构的现代化。

借助自动化基础架构与智能运维,组织能够优化性能、降低成本并减少运维负担。VMware Cloud Foundation 还提供自助式 IaaS 平台,具备现代化云界面 (sysin),可加速创新并运行虚拟机、容器和 AI 工作负载。

内置的安全性和弹性能力可保障业务安全,确保业务连续性,让团队专注于创新,而非应对安全威胁。

新增功能

VMware Cloud Foundation 9.0.2.0 | 2025 年 1 月 20 日

VCF 9.0.2.0 是一次维护版本发布,包含更新后的物料清单(BOM)。该版本主要针对产品的可支持性进行改进。各组件的更新功能列表如下:

  • vCenter
  • ESX
  • vSAN
  • NSX
  • VCF Installer
  • VCF Operations
  • VCF Automation

有关 VMware Cloud Foundation 9.0 各组件的详细新增功能,请参阅各组件的发行说明和本站相关页面。

VCF Installer 新功能

在 VCF 9.0.2 中,在 Binary Management(二进制管理)界面,您可以在 VCF Operations > Build > Lifecycle 中,为 VCF 实例的安装、补丁和升级二进制文件手动同步元数据。

产品支持公告

此前,仅用于管理且网卡速率低于 10Gbit 的主机会被阻止使用,导致 VCF 管理域和工作负载域部署失败。
从 VCF 9.0.2 及更高版本开始,在满足以下条件的情况下 (sysin),配备 1Gbit 网卡的 ESX 主机将获得支持。

  1. 在管理域或工作负载域创建流程中,在 Network settings 页面,为 VM Management Network 选择 Use a separate, dedicated network(使用独立的专用网络)选项。
  2. 使用配备 1Gbit 及以上网卡的 vSphere Distributed Switch,且仅用于管理流量
  3. 为 vSAN、vMotion 和 NSX 流量使用单独的 vSphere Distributed Switch,并使用一个或多个 10Gbit 网卡

VCF Installer 已知问题

将 SDDC Manager 设备从 5.2.2 升级到 9.0.2 后,可能会看到 502 网关错误

解决方法:请确认 /etc/hosts 文件中的 SDDC Manager 配置是否正确。

下载地址

VMware Cloud Foundation 9.0

请访问:https://sysin.org/blog/vmware-cloud-foundation-9/

更多:VMware 产品下载汇总