Gitea作为轻量级自托管Git服务平台，不仅提供代码托管功能，还集成了DevOps协作能力。其核心设计理念在于实现极简部署与超低资源占用，为寻求私有化GitHub替代方案的个人开发者与小型团队，提供覆盖软件开发生命周期全过程的高效协同解决方案。

Docker Compose部署方案

采用容器化部署方式可最大限度简化安装流程，以下为经过验证的Docker Compose配置示例：

services:  
  gitea:  
    image: gitea/gitea:latest  
    container_name: gitea  
    ports:  
      - 3000:3000  
      - 2221:22  
    environment:  
      - USER_UID=1000  
      - USER_GID=1000  
    volumes:  
      - ./data:/data  
      - /etc/timezone:/etc/timezone:ro  
      - /etc/localtime:/etc/localtime:ro  
    restart: always

配置参数技术解读（更多高级参数建议参考官方文档）：

:::
3000端口：Web服务访问端口，默认HTTP协议
2221端口：Git SSH服务端口，需与容器内22端口映射
USER_UID：指定运行用户ID，确保数据卷权限匹配宿主机
USER_GID：指定运行用户组ID，实现精细权限控制
/data路径：核心数据持久化存储目录
/etc/timezone：时区配置文件只读挂载，保证容器时间同步
/etc/localtime：本地时间文件只读挂载，确保日志时间准确
:::

平台使用指南

完成部署后，通过浏览器访问http://NAS设备IP地址:3000即可进入初始化界面。

初始化配置详解

首次访问需完成基础配置，各项参数设置建议如下（配置项虽多，但多数采用默认值即可满足需求）：

数据库类型选择：Gitea支持多种数据库后端，个人用户推荐选用SQLite3轻量级数据库方案，可快速完成部署验证，后续如需扩展可迁移至MySQL或PostgreSQL。

站点基础信息配置可根据实际需求调整站点名称，增强品牌识别度。

应用端口配置必须与Docker映射端口保持一致，如SSH服务端口应设定为2221，HTTP端口保持3000无需变更。

可选服务配置中，邮件服务如非必需可留空跳过。

服务器安全策略建议：私有化部署场景下应禁用用户自主注册功能，同时关闭OpenID第三方认证，确保平台访问可控。

管理员账号建议在初始化阶段直接创建，避免后续重复注册的繁琐流程。

确认所有配置项无误后，点击"立即安装"按钮启动部署流程。

基础设置与个性化

安装完成后将自动跳转至用户仪表板界面。

建议首先完善个人资料信息，点击右上角用户头像进入设置中心。

在用户设置页面可根据需要修改个人详细信息。

页面下方提供头像上传功能，支持个性化头像设置。

对于希望在私有云环境中系统化学习算法的用户而言，将优质开源教程部署至NAS设备是理想选择。Hello-Algo作为一款备受推崇的数据结构与算法入门教程，凭借其直观生动的动画图解与循序渐进的课程设计，成功降低了算法学习的门槛。该项目完全开源且免费提供，特别适合编程初学者构建扎实的算法基础。

该教程官网提供在线访问服务： https://www.hello-algo.com

Docker Compose部署方案

通过容器化技术，用户可在数分钟内完成Hello-Algo的本地化部署。以下是标准化的Docker Compose配置：

services:
  hello-algo:
    image: heizicao/hello-algo:latest
    container_name: hello-algo
    ports:
      - 8000:8000
    restart: always

访问与使用指引

部署成功后，在任意现代浏览器的地址栏输入 http://您的NAS内网IP地址:8000 即可访问图形化学习界面。

系统默认采用浅色主题，用户可根据个人偏好在设置中切换至深色模式以获得更佳的视觉体验。

Hello-Algo项目内置完整的国际化支持，涵盖简体中文、繁体中文、英语及日语等多种语言选项，满足不同地区用户的学习需求。

对于算法基础薄弱或零基础的学习者，该教程提供了明确的学习路径与导读指引。

教程核心特色在于将复杂算法原理转化为高清动画图解，每个知识点均配有分步骤的可视化演示，显著提升抽象概念的理解效率。

除理论讲解外，项目还维护着完善的代码实现库，支持Python、Java、C++、C、C#、JavaScript、Go、Swift、Rust、Ruby、Kotlin、TypeScript、Dart等十余种主流编程语言，所有示例代码均可直接运行调试。

项目综合评估

初次接触Hello-Algo这一GitHub上斩获12.6万星标的开源项目时，原本预期会是传统意义上的艰深技术文档。然而实际体验远超预期——相较于常规教材的枯燥理论堆砌，本教程创新性地融合图文动画与互动式学习，将晦涩的算法逻辑转化为易于消化的知识体系。无论您是计划系统学习数据结构的编程新人，还是需要巩固算法基础的开发者，该项目都具备极高的参考价值。

综合推荐：⭐⭐⭐☆☆（三星级）
受众定位：特别适合编程零基础及算法入门阶段学习者

使用体验：⭐⭐⭐☆☆（三星级）
内容特色：图解动画丰富，知识讲解由浅入深

部署难易：⭐☆☆☆☆（一星级）
部署评价：Docker方案极简，私有部署无障碍

核心要点

2026年5月7日，OpenAI正式推出Codex Chrome浏览器扩展，标志着编程代理可直接在浏览器环境中操控网站与应用程序。当前Codex周活跃用户量已突破400万大关，实现年初至今高达8倍的惊人增长。

400万+

周活跃用户规模

8倍

年度增长率

2026.05.07

正式发布时间

颠覆性创新：这不是普通插件，而是真正的浏览器原生AI代理

5月7日，OpenAI通过官方X账号发布Codex for Chrome扩展程序，演示视频上线不到24小时播放量即突破百万次。与此前市场猜测截然不同，此次发布并非简单的"网页嵌入桌面应用"功能，而是将Codex作为独立代理接入浏览器生态系统——该代理能够自主创建标签页、执行点击操作、填写表单、调用开发者工具，所有任务均在后台并行处理，完全不会干扰用户当前浏览界面。

这一产品决策源于精准的用户洞察。OpenAI团队在推出Computer Use（桌面应用操控）功能后发现，开发者的日常工作流90%以上集中在浏览器内完成。与其让Codex通过屏幕监控间接理解用户行为，不如直接赋予其浏览器内核访问权限。同样是辅助编程，这种原生嵌入方式的效率与准确性实现了指数级提升。

三大核心功能深度解析

▸ 多标签并行处理架构 — Codex在独立标签组中运行，与用户的活动窗口实现物理隔离。您可以在前台查阅文档，同步让Codex在后台执行自动化测试，双方操作互不影响。

▸ 原生DevTools集成 — 可直接调用Chrome开发者工具审查DOM结构、监控网络请求、分析Console日志，前端调试无需反复切换窗口即可完成闭环验证。

▸ 跨标签上下文融合 — 能够同时抓取并整合多个标签页的数据进行综合分析，彻底告别手动复制粘贴整合信息的低效模式。

关键细节在于：上述三大功能可同步激活。传统自动化工具局限于单窗口操作，而Chrome插件架构赋予Codex真正的多任务管理能力——每个任务拥有独立标签组，实现完全隔离的并行计算。

极简部署流程：三步完成永久授权

安装流程极为简洁：启动Codex桌面客户端 → 进入插件中心 → 一键安装Chrome扩展。配置完成后，通过在对话中输入@Browser指令或直接以自然语言描述需求（如"请帮我打开XX官网并提取数据"），Codex即刻接管专属标签组执行任务。

快速上手指南

1. 将Codex桌面客户端升级至最新版本（免费层级即可使用基础功能）

2. 在插件市场选择安装Chrome浏览器扩展

3. 在设置面板配置可访问网站的域名白名单

4. 对话中调用@Browser或直接用语义化指令激活功能

重要权限说明

Codex遵循严格访问控制 — 插件安装后需在Codex设置中心手动授权允许访问的域名列表，未在白名单内的网站将无法被操作。

订阅制服务 — 桌面应用本体免费，但需订阅ChatGPT Plus（20美元/月）或更高级方案。后台并行处理等进阶功能根据订阅等级差异化提供。

精准定位：Codex浏览器助手适用于哪些专业场景

● Web全栈开发者 — 编写完前端代码后，委托Codex自动在浏览器中验证渲染效果、截图对比、回归测试，彻底解放人工刷新操作

● 深度信息研究员 — 竞品对标分析、多源资料汇总、跨平台信息交叉验证等需要聚合多标签数据的复杂场景

● QA自动化工程师 — 模拟真实用户操作路径，自动完成从注册到核心功能的端到端测试链路

反之，若您仅偶尔浏览网页，该功能则显得功能过剩。Codex明确面向专业开发者群体，ChatGPT Plus订阅起价为每月20美元，当前未提供免费试用方案。

近期，Codex 的发展势头异常强劲。伴随 GPT-5.5 的发布，众多开发者明显感受到 Codex 在代码编写、项目修改及各类开发任务中的稳定性显著提升，用户体验日趋流畅。

更令人瞩目的是，Codex 的周活跃用户已突破 400 万大关。

这一增长速度远超预期。

而 OpenAI 的创新步伐并未停歇。

最新曝光的功能显示，Codex 现已具备直接操控 Chrome 浏览器的能力。

这一突破意义重大。

以往谈及 AI Agent，其能力多局限于思考、规划与内容生成。若无法真正介入网页操作、读取实时信息并执行任务，总觉得欠些火候。

如今 Codex 正补齐这一关键拼图。

通俗理解，Codex 不再局限于对话框内的建议提供，而是能够自主启动浏览器并实际操作完成任务。

对于正在使用 Codex 的开发者而言，这项功能值得立即体验。

经过深度测试，现将具体使用方法与实际能力边界整理如下。

插件配置全流程

首先在插件管理页面定位 Chrome 插件并完成安装。

安装成功后，系统将引导下载对应的 Chrome 浏览器扩展程序。

按照提示完成浏览器插件的安装配置。

当插件图标显示绿色 Connected 状态时，表明连接已成功建立。

在计算机控制面板中，可对该插件的各项权限进行精细化管理。

权限设置可根据个人安全偏好灵活调整。

Codex 的 Chrome 插件支持多标签页后台并行处理，不会干扰用户的正常操作。这意味着在执行自动化任务的同时，用户可继续其他工作，两者并行不悖。这与传统 AI 浏览器插件存在本质区别——旧版插件运行时通常会占用鼠标键盘，导致用户只能被动等待，效率低下。

由此不得不赞叹 OpenAI 的产品洞察力，总能精准解决用户核心痛点。

实战能力验证

理论介绍不如实际测试。以下通过真实案例验证功能表现。

测试任务：批量下载某热搜网站的数据。

先尝试获取单日数据以验证基础功能。

结果显示数据抓取正常且准确无误。

随后指令其提取历史数据并生成文件。

数据抓取精准度与执行速度均表现优异。

开源命令行工具

核心要点速览

OpenAI官方推出的命令行界面工具，让开发者无需编写Python代码即可在终端直接调用API接口。这款工具专为技术人员的日常调试、快速功能验证以及API使用量管理而设计，极大简化了开发流程。

项目数据概览

• GitHub星标数：266个
• 项目创建时间：7天前
• 最新发布版本：v1.1.2

一、openai-cli是什么？零基础读懂这款官方命令行工具

简单来说，openai-cli就是OpenAI官方为你打造的一款终端遥控器。在过去，调用OpenAI API要么需要编写Python或Node.js代码，要么就得手动拼接curl命令构造HTTP请求。如今只需安装这个命令行工具，通过简单的指令就能实现全部操作——发起对话、管理文件、查询用量、查看账单，所有功能均在终端内一站式完成。

这款工具的定位非常明确：面向开发者与技术运维人员，而非普通的ChatGPT网页端用户。如果你的日常工作涉及频繁与API交互——例如测试提示词、批量运行补全任务、监控组织级资源消耗——那么这款工具将帮你省去大量编写样板代码的时间成本，让工作流程更加流畅高效。

二、目标用户画像：谁最需要这款工具，谁可以跳过

强烈推荐使用的人群：

• AI应用开发者：需要频繁调用API进行功能测试和调试，快速验证不同提示词和模型行为表现的工程师
• 运维与平台管理员：负责监控组织级API用量、管理月度账单、维护多个项目和密钥的技术管理人员
• 脚本自动化使用者：希望在Bash或Shell脚本中集成AI能力，实现批量内容生成、自动化处理的开发者
• 技术评测与学习人员：想要快速体验对比不同模型输出效果，但不愿意花费时间编写样板代码的研究者

不适合使用的人群：

• 仅通过chatgpt.com网页界面使用AI服务的普通用户，且完全没有API调用需求的人

三、核心功能全面拆解：这款CLI工具能做什么

▸ 资源化的命令结构：采用openai [资源类型] [具体操作] [参数标志]的层级化设计，符合开发者直觉，命令组织逻辑清晰易懂

▸ 多格式输出支持：内置json、yaml、pretty等多种输出格式选项，并集成GJSON转换语法，方便数据解析和管道处理

▸ 智能文件处理机制：独创的@file.ext语法糖，可自动识别并正确传输文件内容，智能判断文本或二进制编码格式

▸ 完整的管理端点覆盖：提供查询组织用量、管理项目配置、验证Webhook签名等全面的后台管理功能

▸ 灵活的API地址定制：通过--base-url参数支持自定义API后端地址，轻松适配代理环境或自托管部署场景

四、三大实战场景：开发者如何真正用上openai-cli

场景一：快速测试新发布模型 每当OpenAI发布新模型时，无需再编写测试脚本，只需执行一行命令即可发送请求并查看效果：openai responses create --model <新模型名称>，验证工作瞬间完成

场景二：批量调试提示词参数 在Shell脚本中使用循环结构多次调用openai responses create命令，通过改变参数组合对比不同配置下的输出质量，大幅提升调试效率

场景三：组织级用量监控 平台管理员可通过单条命令拉取整个组织的API调用数据，按日期或项目维度进行聚合统计，实现账单监控和资源规划的自动化

五、全面对比：openai-cli vs curl vs Python SDK，哪个更适合你

六、项目成熟度评估：openai-cli现状与未来发展

客观评估：openai-cli项目创建于2026年5月1日，截至本文撰写时上线不足10天。仓库已有42次代码提交，来自4位贡献者，获得266个GitHub星标。项目已发布4个版本（最新为v1.1.2），核心的responses create命令及管理功能已可用，但API资源覆盖范围尚未全面。

今天给大家介绍一个极具实用价值的开源工具PandaScrcpy，它能让手机远程控制变得异常简单。完成部署后，您无需在本地计算机配置复杂的ADB环境，仅需使用Chrome或Edge浏览器，通过USB连接Android设备，即可实现投屏显示、远程操控、屏幕录制、快照截取、日志查看以及ADB Shell命令执行等全方位功能。

若从放松娱乐的角度看，这甚至可以成为一个高效的休闲助手。

无论是需要将安卓手机屏幕投射到电脑上进行简单操作、查看日志或截图录屏的普通用户，还是从事安卓应用测试、设备调试以及批量测试的专业开发者，这款工具都能提供显著的价值提升。

核心应用场景

安卓设备画面投射至电脑端

当您需要在电脑大屏幕上展示手机界面、录制操作教程、进行直播演示或提供远程技术支持时，该功能尤为实用。相比传统方式，浏览器端操作更加便捷灵活。

键鼠控制手机操作

连接成功后，您可以直接在浏览器窗口内操控手机，体验与scrcpy高度相似。根据项目文档说明，系统已针对触控操作、键盘鼠标控制进行了焦点管理和指针轨迹优化，确保操作精准流畅。

开发与测试调试专用

内置多项设备端实用工具，包括应用管理器、Logcat日志系统和ADB Shell终端界面，极大简化了开发与测试人员查看系统日志、调试应用程序的工作流程。

屏幕录制与画面截图

支持本地录制手机屏幕动态画面，同时可快速截取静态快照，非常适合制作测试记录、产品演示素材或技术文档配图。

远程画面共享功能

基于PeerJS技术，可将当前手机画面实时分享给其他浏览器端用户，实现远程协作或技术支持场景下的屏幕共享需求。

NAS部署完整流程

本文将以威联通NAS设备为例，详细介绍通过Docker Compose方式部署的完整流程。鉴于原项目未提供官方镜像，我已自行构建并上传至仓库，部署配置如下：

services:  
  panda-scrcpy:  
    image: ydxian/panda-scrcpy:latest  
    container_name: panda-scrcpy  
    ports:  
      - "6527:80"  
    restart: always

在威联通系统的Container Station中创建新的应用程序，将上述配置粘贴即可快速启动。

Web端使用详解

服务启动后，在浏览器地址栏输入NAS_IP:6527即可访问主界面。

若在设备选择区域出现"浏览器不支持WebUSB"的提示，这是因为WebUSB API仅在安全上下文环境中生效。解决方案有两种：配置HTTPS反向代理，或直接通过localhost访问。考虑到远程使用的便利性，强烈建议配置反向代理。

完成反向代理配置后，提示信息将消失，页面功能恢复正常。

但此时点击"添加USB设备"仍无法发现手机，原因是尚未完成手机的开发者模式配置。请使用数据线将手机连接至电脑（Mac或Windows均可），进入手机"设置"应用，滑动至"关于手机"选项，连续点击"软件版本号"七次以激活开发者模式，随后在开发者选项菜单中启用USB调试功能。

完成上述设置后，再次点击"添加USB设备"，此时手机将出现在设备列表中。选中目标设备并点击"连接"按钮。

设备配对成功后，点击"连接设备"按钮建立通信。

此时手机端会弹出授权窗口，如经常使用建议勾选"一律允许"以简化后续操作。

注：部分小米手机如遇控制问题，需在开发者选项中额外开启USB调试（安全设置）权限

连接成功后，界面流畅度表现优秀。默认视图显示设备基础信息，中部功能区提供录屏、截图、音量调节等快捷操作。

应用管理模块可读取已安装应用列表，支持对连接设备执行应用的安装、启动和导出操作。

几天前，PostgreSQL生态的顶级开源备份方案pgBackRest突然宣布停止维护，整个社区为之震动。尽管Pigsty项目同样深度依赖pgBackRest，但并未陷入恐慌——如此关键的基础设施，PostgreSQL生态绝不可能任其消亡。当时甚至承诺若无人接手将主动接盘，如今看来这一备用方案已无需启动。

David Steele在GitHub README发布“维护动态”：归档公告发布后，他的邮箱被海量邮件淹没。众多用户与厂商表达强烈挽留意愿，他本人也倾向继续维护。更关键的是，由多家赞助商组成的资金联盟已基本谈妥，几乎可以确定将获得足额资金支持继续pgBackRest的开发。

预计本周结束前将发布更明确的正式公告。从归档到逆转，仅仅七天。

此事的精髓不在于“开源社区充满爱心”这类空泛感慨。真正值得关注的是：当一项关键开源基础设施被维护者推向死亡边缘时，市场终于开始为其定价。

这是一次极为纯粹的开源公地悲剧倒逼定价实验。

七日时间线全复盘

先把关键节点梳理清楚。

4月27日，David Steele同时在GitHub和LinkedIn宣布停止维护pgBackRest并归档仓库。声明措辞克制，既无抱怨也未甩锅，仅强调两点：一是允许分叉但不得继续使用pgBackRest名称；二是归档不代表生命周期终结，现有代码可用，运行中的部署不会立即崩溃。

第一条声明尤为重要。备份工具并非普通玩具，而是供应链攻击的高价值目标。一个继承原品牌信任度的分叉若落入恶意之手，风险远超想象。要求更名是David离场时最负责任的安排。

同日，Christophe Pettus在thebuild.com发表《Notice of Obsolescence》，给出冷静判断：应将pgBackRest视为“落日部署”，等待可信分叉出现后再重新评估。

同日，Lætitia Avrot发布《pgBackRest is dead. Now what?》，标题直截了当。她的措辞更为尖锐：AI淘金热潮已彻底改变企业预算优先级。大公司愿意为内存、GPU、token一掷千金，却不愿为保障数据库灾难恢复的人付费。

这番话刺耳，却道破现实。

4月28日，Percona迅速响应。Jan Wieremjewicz发表《pgBackRest is archived, what now?》，承诺Percona将继续支持pgBackRest，但呼吁暂勿急于分叉。他们正与其他厂商商讨联合维护或基金会托管方案。文中透露关键信息：Jan在归档前一周的PGConf.DE演讲中曾引用David提出的透明出资模型，希望将维护成本分摊给多家依赖方。

此举至关重要。Percona并未宣布独占接盘，也未抢先分叉，而是率先呼吁协同。对商业供应商而言，这种克制实属罕见。

但无人及时响应。

换言之，David并非未尝试“温和定价”，只是无人买账，最终只能走向归档。

4月30日，Percona再发《Open source doesn’t die. It gets unfunded.》，将问题挑明：pgBackRest并非生命终结，而是维护资金断裂；Percona与其他公司正幕后推动解决方案。

5月1日，PGX抢先行动。Christophe Pettus旗下的PGX Inc.发布《pgxbackup: Continuity Support for pgBackRest》，将pgBackRest分叉为pgxbackup，定位专为其支持客户提供连续性版本，仅修复关键bug并兼容新PG版本。

此举合理却暗藏微妙。Percona刚呼吁“别急着分叉”，PGX三天后就推出分叉。不能指责Pettus不负责任——他必须对客户负责；但这恰恰说明所谓的“社区协调”极其脆弱。只要有一家厂商失去耐心，双轨预期立刻形成。

5月4日前后，David发布维护更新：赞助联盟基本成型，资金大概率到位。他还在寻找另一位维护者分担工作，避免项目再次沦为单点故障。

至此，逆转完成。

当年Linux基金会响应Redis协议变更、发起Valkey，按自然日算约八天，按工作日算约六天。pgBackRest此次无基金会介入、无许可证战争、无共同敌人，仅凭PG圈内协调，耗时七天。

这个速度已属罕见。

谁在为续命买单：公开信号与推测

正式赞助名单尚未公布，但现有信号已能勾勒大致轮廓。

Supabase是目前最可能被视作核心金主。

根据pgBackRest官网及README的赞助商列表，当前赞助商正是Supabase。更关键的是，Supabase在4月的Developer Update - April 2026中宣布开源Multigres Kubernetes operator，该系统直接内置pgBackRest的PITR备份功能。

这已超越“支持开源”范畴，属于产品路线深度绑定。当你将未来押注在某个备份工具上，而该工具突然失去维护者时，不出资谁出资？

以Supabase当前的估值与融资规模，供养一位pgBackRest核心维护者根本不是资金问题，而是是否愿意承担责任的问题。至于它是否为联盟中最大出资方，仍需等待正式公告。

Percona极可能是核心协调方。 Percona已公开承诺继续支持pgBackRest，且其Percona Distribution for PostgreSQL长期将pgBackRest作为推荐备份方案。客户SLA绑定于此，不可能袖手旁观。但具体出资金额与方式，同样待正式披露。目前其角色更像此次协调的组织者之一。

Cybertec、Timescale、Resonate均有可能参与。 Cybertec的容器化PG产品使用pgBackRest；Lætitia的文章也专门指出Cybertec与Data Egret拥有可临时处理pgBackRest问题的专家。 Timescale拥有公开分叉，这是依赖或评估信号，但不足以单独证明Timescale Cloud的备份链路深度绑定pgBackRest。其具备出资能力，但历史上对上游开源基础设施的投入不算特别主动，因此无法完全确定。

Pigsty v4.3 正式亮相。如果说上一版本 v4.2 的核心亮点在于"十二款内核齐发"，那么本次迭代的主题词无疑是"扩展生态密度"。

此次更新将 PostgreSQL 扩展的支持数量从 460 款激增至 510 款，创下历史新高。在操作系统兼容性方面，Ubuntu 26.04 被纳入官方支持列表，同时 Ubuntu 20.04 正式退出历史舞台。此外，Supabase、pgEdge、PolarDB、Grafana、MinIO 等核心组件也完成了集中式版本升级。

跨越式发展：迈入主流开源阵营

在 GitHub 生态中，5000 Star 标志着项目进入主流视野。这一里程碑带来的最直接福利是可获得免费的 ChatGPT / Claude 订阅资格。

Pigsty 近期成功跨越这一门槛，当前 Star 数已达 5066。在 GitHub 全平台中，Star 超过 5066 的仓库约有 11621 个，这意味着 Pigsty 已跻身全球 Top 1 万项目行列，位列前 0.005%。对于数据库发行版这一细分领域而言，Star 的含金量更为显著——按此指标，Pigsty 已成为 PostgreSQL 发行版赛道前三甲，并在 Linux 原生 PostgreSQL 发行版中独占鳌头。

更令人瞩目的是 Pigsty.IO 官网的流量表现。三月份月独立访客尚不足两千万，至四月底已突破一亿大关，其中 99% 以上流量源自 AI/Agent 访问。这表明 Pigsty 网站已成长为主流 AI 模型的关键训练语料和 AI Agent 的重要基础设施。对于个人主导的开源项目而言，这一成就尤为难得。

David Steele 亲笔：十三年心血之作正式落幕

2026年4月27日，PostgreSQL生态系统中最重要的备份解决方案pgBackRest被其创始人David Steele正式归档。

相关声明同时在GitHub和LinkedIn平台发布，措辞简洁而决绝：

pgBackRest已停止维护。若您基于此项目创建分支，请为您的项目重新命名。

经过深思熟虑，我决定终止对pgBackRest的后续开发。这绝非草率之举。过去十三年间，pgBackRest始终是我倾注心血的个人项目；在相当长的一段时间里，我幸运地获得了企业赞助支持，但我也付出了无数深夜与周末的时光，与众多贡献者携手将其打造成今日的模样。每位开源开发者都深知这种状态意味着什么，也明白一个被珍视的项目会在生命中占据何等分量。

自Crunchy Data被收购以来，我仍在持续维护pgBackRest，同时也在寻找能让我继续这项事业的职位，但迄今未果。同样，我为项目争取独立赞助的努力，也远未达到支撑其可持续运营所需的水平。

与所有人一样，我需要维持生计。而与pgBackRest相关的职业机会极为稀缺。如今我可以考虑更广泛的就业选择，但这些工作无法留给我足够时间继续投入pgBackRest。项目的日常维护、缺陷修复、PR审查、问题响应等都需要耗费大量精力，更不必说我真正热爱的新功能开发。与其勉强维持、断断续续地低效运作，不如明确画上句号。

我相信pgBackRest终将出现分支版本。但那将是全新维护者主导的新项目，他们必须像我们当年一样，从零开始重建社区信任。

最后，再次感谢多年来所有为pgBackRest贡献力量的开发者。与诸位共事，是我职业生涯的荣幸。

PostgreSQL社区遭遇重大冲击：当事实标准成为孤儿

对PostgreSQL用户群体而言，此事绝非等闲。pgBackRest早已成为PostgreSQL备份恢复领域的事实标准，更是众多DBA心目中最值得信赖的灾难恢复工具。大量PostgreSQL DBaaS服务均将其作为核心备份方案，Pigsty发行版也默认采用该工具。

pgBackRest将PostgreSQL备份技术推向了极致境界：

• 并行化备份与增量恢复，将恢复时间窗口压缩至最小
• 将原本复杂的PITR（基于时间点恢复）操作简化为单条命令
• 完美解决了备份归档、仓库管理、对象存储集成等棘手问题
• 全量、差异、增量备份，块级压缩与加密，多仓库异步归档，从备库执行备份……几乎所有DBA能想象到的备份需求，它都已实现，且表现稳定、品质卓越

笔者十年前首次为生产数据库选型备份方案时便选择了它，近期重新评估市面上所有活跃方案后，结论依然是它。当年2.0版本发布时，我甚至手动翻译了其完整文档。上个月刚借助Claude将相关文档连同Patroni、PgBouncer一起重新翻译了一遍。

这个工具我已稳定使用近十年，对其信赖有加。如今唯一的维护者却将仓库归档了。

资本游戏下的牺牲品：Snowflake收购Crunchy Data始末

David在告别信中说得直白：他未能筹集到足以维系开发的经费。

David此前担任Crunchy Data的架构师，这是一家专业的PostgreSQL服务提供商。2025年6月，数据湖仓领域的巨头Snowflake以2.5亿美元收购了Crunchy Data。

收购完成后，David花费数月时间试图在新东家或其他地方寻找能延续该项目的岗位，但最终失败。他也曾尝试独立筹措赞助资金，但距离维持生计的目标差距甚远。他需要养家糊口，因此选择果断终止，而非敷衍了事。

这里存在一个令人不安的事实：Snowflake是当前数据基础设施领域市值最高的企业之一，公开宣称要打造"AI原生Postgres"，斥资2.5亿美元收购Crunchy。但从结果看，却未继续支持David维护pgBackRest。一家小公司尚能承担的开发者成本，进入大公司后反而无法覆盖。

若此推测属实，其行为的短视程度远超商业理性的范畴。Snowflake节省的成本微不足道，却亲手抽掉了PostgreSQL生态最关键的承重支柱之一，这并非精明的商业决策，而是吃相过于难看。

本轮AI淘金热潮已彻底重塑企业预算清单。采购内存、GPU、tokens等投入能讲出清晰的ROI故事；而雇佣一名确保数据库崩溃后可恢复的专家，却无法量化回报——“坏事未发生"在董事会面前等于零价值。

社区大讨论：开源项目生死劫的三重困境

事件发酵数日以来，PG社区已沸腾：Hacker News上超过200分的讨论串、各大厂商博客的连续回应、邮件列表中"接下来怎么办"的激烈辩论。讨论主要围绕三个层面展开。

第一层：开源可持续性诊断。主流观点认为健康模式应形成良性循环：“企业投资工程师→软件创造价值→用户购买商业支持→企业再投资”。pgBackRest的困境在于该闭环未能建立——仅依赖单一公司工程师维护，未形成多厂商商业支持网络。一旦该公司被并购或战略调整，整条链路即时断裂。

**第二层：是否立即分叉。**大厂态度高度一致：暂缓分叉。 “不应出现十个分叉、每个仅一人维护"的碎片化局面才是最差结果。Linux Foundation推出Valkey替代Redis耗时六天紧急协调，多厂商共治事宜，慢而稳优于快而乱。

**第三层：分叉命名问题。**David在声明中明确表态：“我希望它被分叉，但那将是新项目、新维护者，需如我们当初般重建信任。“这意味着新项目不得继续使用pgBackRest名称。

笔者个人支持David的要求，这恰是他离场时最负责任的举措。备份工具是供应链攻击的最高价值目标之一：一个被广泛信任的备份程序若在升级中被植入恶意代码，可获取几乎所有部署实例的核心权限，接触全部历史数据。将"数千星标积累的信任"直接转让给未知继任者不是慷慨，而是不负责任。强制分叉改名，是促使用户重新进行信任评估，此乃安全工程的基本准则。

亲历者视角：pgBackRest的未来何去何从

笔者得知此消息时深感遗憾。

作为pgBackRest的深度用户，若无人接手，我本人也愿意扛起维护重任。

此前我已接手MinIO的维护，因自身需求在原厂放弃后fork维护至今。我认为在不新增功能的前提下，接手pgBackRest维护并非不可行。

不过，我认为pgBackRest未必会走到那一步，其未来存在几种可能路径。

可以确定的是，5月温哥华PGConf.Dev大会极可能将此作为核心议题讨论。涉及PG生态主要厂商核心利益的工具，社区不会坐视不管。

现实预期是，社区协商产生新分叉，类似Redis改协议后社区另立Valkey。鉴于不可沿用原名，新项目可能命名为pgbackrest-ng、pgbacknext或其他。此方向的关键在于需要一家或多家厂商作出长期承诺并达成共识。

较坏情况是，既无牵头者，也未进PGDG，厂商间未达共识，陷入"各维护内部fork"状态：Percona一份、EDB一份、各云厂商一份。此结局最糟糕，真正的"Fork战争”。

最理想结果是PGDG内核团队接手，作为contrib模块或纳入PGDG全球开发组项目集。但实话实说难度较大，且其他备份工具维护者未必乐见。

当前现状是，Percona已明确表态将继续为自家客户提供pgBackRest支持。这意味着至少在企业客户层面，pgBackRest不会立即失去所有支撑。Crunchy现有产品与文档仍深度集成pgBackRest，但截至目前未见其对项目长期维护作出新的公开承诺。

笔者也在此明确表态：若无他人维护，我将自己接手。当然若他人维护得当，我也乐见其成为上游，专注验证、打包分发及用户反馈。

用户行动指南：冷静评估而非恐慌性迁移

短期来看，我给诸位PostgreSQL DBA的建议是：若您正在使用pgBackRest，无需过度担忧。切勿恐慌，更无需急于迁移。

pgBackRest是极其成熟的软件，归档的是代码仓库——不再接受PR、不再修复bug、不再发布新版本，但代码本身依然存在，今天运行良好的系统，明天仍可继续运行。

当前使用pgBackRest会有什么问题？ 如果您一直使用PostgreSQL 18配合pgBackRest v2.58，这套组合可运行至天荒地老。

风险的出现需要时间，可能是数月乃至数年后。例如今年9月PG19发布，或后续大版本引入需适配的内核改动，抑或对象存储、依赖库、安全漏洞需要后续修复时，问题才会显现。pgBackRest当前版本兼容PG18，但新大版本若需内核层适配，或出现必须修复的安全问题，情况将变得棘手。然而这是中长期担忧，而非当下危机。

更重要的是，目前没有任何工具能完全平替pgBackRest的功能完备度：

• Barman（EDB维护）是最可靠备选之一，3.18版本新增云存储块级增量备份能力，但该特性较新，成熟度与一体化体验距pgBackRest尚有差距
• WAL-G是实用的云归档与恢复工具，在K8s/云原生场景应用广泛，但在完整备份仓库治理能力上与pgBackRest并非完全重叠
• pg_probackup（Postgres Professional出品）曾是唯一能在功能维度与pgBackRest抗衡的对手，其块级PTRACK增量备份甚至更激进。但作者公司为俄罗斯背景，2022年后处境复杂；更关键的是该工具历史上曾出现恢复后数据丢失、无效页面等严重问题（如#474[1]、#249[2]）。对备份工具而言，这是致命污点，令我个人在推荐时极为慎重

从一个化学扩展说起

一切始于两天前的一则GitHub Issue。一位用户在使用RDKit——化学信息学领域无可争议的标准库时遇到了难题。虽然该库能在PostgreSQL中实现分子结构存储、子结构检索和相似性计算等核心功能，但PGDG官方打包版本竟然缺失了关键的InChI功能。这位用户花费了大量时间折腾编译参数，最终虽勉强跑通，但仍希望Pigsty能提供原生支持。

RDKit确实是一块难啃的硬骨头。大约两年前我曾尝试将其纳入Pigsty的扩展仓库，目标是从Debian移植到EL系列系统。但现实很残酷：Boost、Eigen、RapidJSON、Cairo等依赖项环环相扣，再加上InChI、Avalon等可选模块，每个组件都有独立的编译开关和操作系统兼容性问题。几番尝试未果后，我只能暂时搁置。

然而这次情况截然不同——Coding Agent时代已经到来。

借助Codex / Claude Code处理这类"构建系统考古"任务堪称降维打击。过去需要反复试错数周的工作，如今只需一两轮对话就能自动完成。在最新版本中，我不仅解决了PGDG打包的InChI支持问题，更将编译参数优化做到了极致。整个流程顺畅得令人难以置信，用户反馈也极为满意。

这种来自开源社区的积极互动总能带来最大的成就感。

趁热打铁

既然构建流程已经跑通，我索性将积压已久的几个"历史遗留难题"一并解决。

plv8扩展首当其冲。这个V8引擎的PostgreSQL绑定之前在EL10上始终无法编译通过，此次通过打上多个补丁终于实现了稳定构建。

duckdb_fdw的兼容性难题也得到了优雅解决。该扩展允许从PG内部直接读写DuckDB文件，但此前会与DuckDB官方的pg_duckdb扩展发生共享库冲突，我不得不暂时将其隐藏。新版本通过将duckdb_fdw作为pg_duckdb的子扩展，共享同一份libduckdb库，彻底消除了冲突，两个扩展终于能够和平共处。

工具链已然成熟，我萌生了一个更大胆的想法：何不将PostgreSQL生态中那些值得收录但一直未能攻克的扩展全部纳入？于是催生了这次史诗级更新——新增32个扩展，更新22个扩展，Pigsty扩展仓库总量正式突破500大关，达到惊人的504个。

完整扩展目录: pigsty.cc/ext[2]

这五百多个扩展的构成颇具深意：约70个是PostgreSQL自带的Contrib扩展，150个来自PGDG官方打包，剩下的330个全部由我个人维护构建。可以说，在PostgreSQL扩展生态这个赛道上，Pigsty已经做到了前所未有的深度和广度。

横向对比更能体现这一成就的分量。主流云服务商如Supabase，在去除PG自带的35个Contrib扩展后，实际提供的第三方PG扩展不足30个。这意味着Pigsty的扩展数量是商业产品的十倍以上。

新扩展全景扫描

本次新增的32个扩展技术密度极高，可归为四大类别：

数据域革命：将化学分子、RDF三元组、BSON、Protobuf、循环日程等复杂对象提升为数据库一等公民，彻底打破传统关系模型的边界。

查询能力跃升：涵盖稀疏线性代数与图算法、Datalog图查询引擎、全文检索增强、混合排序融合、递归SQL模板引擎等前沿能力。