Interplanetary Shipyard在8月24日发布公告：资助方Protocol Labs不再续签资金，9月30日之后，公司将停止一切IPFS相关工程与运维。Kubo、Helia、Boxo、Rainbow、IPFS Desktop等核心库失去专职维护者，ipfs.io、dweb.link、check.ipfs.network等公共网关也将无人接盘。公告用词克制，但细读之下藏着一个更扎心的事实：Shipyard两年前成立的初衷，正是让IPFS摆脱对Protocol Labs的资金依赖，如今却被Protocol Labs亲手断供解散。
IPFS协议本身不会因为一家公司撤资就消失，但公共网关、引导节点、安全补丁这些真正决定用户体验的部分，恰恰是最依赖持续资金的环节。更值得盯住的是，作为域名和基础设施实际所有方的Protocol Labs，截至目前没有公开表态，也没说清ipfs.io之后归谁管——这份沉默，比断供本身更说明问题。
一张停摆清单，一个没人回答的问题
Shipyard声明里列出的受影响项目不算短：Kubo、Helia、Boxo、Rainbow、IPFS Desktop、IPFS Companion、Someguy、Service Worker Gateway、IPFS Check。公共基础设施同样要停摆，包括ipfs.io、dweb.link、delegated-ipfs.dev、IPFS引导节点，以及Wikipedia-on-IPFS这类协作集群。
声明里有一句话轻描淡写：Protocol Labs作为域名和基础设施所有方，"将决定其未来"。但这话等于没说——因为Protocol Labs自己的官网至今没有一个字回应这次断供，也没有指定任何接管方。
这不是孤立事件。2025年9月，Shipyard已经完成过一次libp2p维护团队的移交，这次是IPFS本体工作的终止。一年之内连续两次断供，看起来更像分阶段清退，而不是一次性决定。
为脱离依赖而生，被依赖方断供而亡
Shipyard在2024年成立时，定位就是从Protocol Labs独立出来的维护者集体，目的是让IPFS核心维护不再捆绑在单一公司的资金表上。这是开源基础设施领域常见的"退出到社区"思路：把团队从原厂剥离，换取治理独立性，避免关键协议的命运系于一家公司的财报。
结果两年后，原厂一句不再续签，独立团队就散了。这说明组织独立和资金独立是两回事——Shipyard换了牌子，钱包却没换主人。这不是IPFS一家的问题，很多打着社区自治旗号的开源团队，资金链条最终还是系在一两个金主身上，出资方一撤，"社区维护"的说法就露了底。
去依赖之名立，依赖之实存。
协议不会死，网关会先扛不住
技术上要分两层看。IPFS作为协议和内容寻址模型不会消失：已经部署的节点、已经pin住的内容、Kubo之外的独立实现都还能跑。真正的风险在维护和运营层——没有专职团队，安全补丁和版本发布会慢下来甚至停摆；公共网关一旦停运，那些把链接硬编码在ipfs.io、dweb.link上的NFT项目、网站会直接打不开；引导节点的可靠性也会下降，虽然DHT、mDNS这类其他节点发现机制还能撑一阵。
商业网关服务商Pinata已经把这次事件解读为公共网关补贴时代的结束，建议开发者尽快从免费公共网关迁移到自托管或付费专用网关。这等于把去中心化理想里"免费公共物品"的那部分，重新推回商业市场。
- 风险.把链接硬编码在ipfs.io、dweb.link上的应用，9月30日后随时可能打不开。
一个月窗口期，谁该现在动手
依赖Kubo、Boxo做生产环境的团队，得提前评估安全补丁真空期怎么扛，是自己养内部维护力量，还是转向Filecoin这类带经济激励的存储层做持久化补充。NFT、Web3网站如果还在用ipfs.io、dweb.link这类公共网关，最现实的动作是趁窗口期把网关地址换掉，别等到9月30日才发现链接失效。
接下来最该盯的，是Protocol Labs会不会在9月30日前给出接管方案，是否有社区或商业组织愿意接手Kubo、Helia、Boxo这几个核心库——这才是决定IPFS未来几年热度的变量，而不是"IPFS会不会死"这种伪命题。