IPFS 核心团队停摆：去中心化存储还能选什么？（2026）

一、发生了什么：IPFS 的核心维护团队停摆#

2026-08-24，Protocol Labs 通知 Interplanetary Shipyard（IPFS 主力维护团队）不再续签资助。Shipyard 的任务是维护 IPFS 的核心实现和公网设施，包括：

• Kubo（Go 参考实现，IPFS 最常用节点软件）
• Helia（JavaScript 实现）、Boxo、Rainbow、IPFS Desktop、IPFS Companion
• Service Worker Gateway、IPFS Check
• 公开网关 ipfs.io、dweb.link，以及 IPFS bootstrap 节点、Wikipedia-on-IPFS 协作集群

Shipyard 宣布这些 IPFS 相关工程、维护、基础设施将于 2026-09-30 起全面停摆。届时 Kubo 将不再有新特性、bug 修复、发布和长期托管——这基本等于失去一整条可维护的 IPFS 工具链。上游的 go-libp2p / js-libp2p 贡献也会停止。

二、为什么：低采用 + 高成本的老问题#

这背后是 IPFS 一直没解决的市场采用问题：

1. 采用率低：IPFS 为”去中心化 Web”而生，但这个愿景没有被大规模采用。没有广泛部署的 Web 应用，基础设施的维护成本就压不住。
2. 基础设施方连续撤退：Cloudflare（2024）、Brave（2024）、Infura（2026） 先后撤出对 IPFS 的支持，Pattern 一致——低采用 + 高维护成本。
3. Protocol Labs 重心转移：公司把资源转向了 AI 和 Filecoin 相关方向，P2P/Web3 的持续投入被搁置。

三、别误会：IPFS 协议本身没死#

这是最容易误解的一点——停摆的是”维护团队”，不是”协议”：

• IPFS 规范仍是开源的，内容寻址（CID）是永久、确定的——它不随任何一家公司的动向而死。
• IPFS 官方澄清：项目不日落、不关闭，只是从”Shipyard 集中维护”转为 IPFS Foundation 以独立维护者资助做轻量托管。
• 已 pin 的数据还在，你自托管跑的 Kubo 节点仍能继续工作。
• 托管服务（如 Pinata）、IPFS 规范本身存活。

⚠️ 但如果你是生产依赖 ipfs.io、dweb.link、Kubo、Helia 的，大约有 5 周做迁移/替代。

四、去中心化存储还能选什么#

如果 IPFS 的核心维护已经不稳，考虑替代或迁移时，这几条路值得看：

五、给你的建议#

• 正在用 IPFS（Kubo / ipfs.io / Helia）：尽快评估依赖，5 周内把关键路径迁走（换个可维护的实现，或转自托管/商用托管）。
• 考虑去中心化分发：优先看还有商业公司支撑、维护活跃的方案（如 Iroh），别把长期押在一个核心团队已撤的栈上。
• 只是想让文件”自己手里 + 跨设备”：自托管 Syncthing + Tailscale 是最省心、最可控、且完全绕过这类生态风险的组合。

一句话：IPFS 这艘大船换了船长，但也别慌——协议活得下去，你需要的是选一个”还有人认真维护”的去中心化方案，或者回到自己服务器上。

想看更多去中心化 / 自托管实践，可以翻站内上文提到的 Syncthing、Tailscale，或直接进 部署教程合集 翻个够。