5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？ 当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。 这个思路到今天我依然觉得是对的。 但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。 这也是我重新做 ZPan V2 的起点。 连作者自己都懒得运维 以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。 每一件单独看都不难。 麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。 我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。 所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。 现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。 这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。 ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。 也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务： zpan.space 。 这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。 但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。 所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space 。 V2 不只是一个网盘 如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。 但现在我更愿意把它叫做一个 S3 原生的文件托管平台 。 这个差别在哪里呢？ 传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。 文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。 ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。 所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。 这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。 文件管理重新做了一遍 V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。 这里面有一些看起来不显眼但很关键的变化。 比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。 再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。 这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。 图床是一等场景 我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。 V2 把图床作为核心场景来做。 你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。 这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。 分享不只是发一个链接 网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。 文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。 这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。 团队、配额和权益 V1 更偏个人使用，V2 从一开始就有组织和团队的模型。 每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。 V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。 这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。 WebDAV 、后台任务和远程下载 V2 也在补齐外部访问和文件工作流。 WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。 后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。 远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。 这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。 把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。 比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。 这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。 我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。 版本分层：开源、支持与商业化 V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。 这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。 Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。 Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。 Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。 这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。 适合谁用 如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。 如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。 如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。 如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。 但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。 顺便聊聊 Agent Kanban 最后再聊一下这次重做的开发方式。 ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。 我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。 这件事不只是“用 AI 写代码”这么简单。 过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。 真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。 Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。 ZPan V2 算是我的一个验证场。 整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。 最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。 所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。 最后 几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。 几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。 ZPan V2 想做的就是这个入口。 如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。 GitHub： https://github.com/saltbo/zpan ZPan 官方服务： https://zpan.space Agent Kanban： https://agent-kanban.dev 如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
刚刚看到佬友们在讨论这个，然后刚好去notion上写笔记的时候看到了这个 剧透 41 个帖子 - 23 位参与者 阅读完整话题
IT之家 6 月 9 日消息，苹果公司今天（6 月 9 日）发布博文，宣布由于受到《数字市场法》影响， Siri AI 不会随着 iOS 27、macOS 27 等系统更新面向欧洲市场上线。 苹果软件工程高级副总裁 Craig Federighi 表示，公司对欧盟用户无法同步获得 Siri AI 感到失望。苹果希望最终仍把这项能力带入欧盟，并会继续与监管机构沟通。 欧盟用户将暂时无法使用回看对话的独立应用、扩展后的视觉智能、集成写作工具、iOS 相机中的 Siri 模式，以及苹果在 WWDC26 公布的其他 Siri AI 能力。 苹果公司称，Siri AI 基于端侧处理与 Private Cloud Compute（私有云计算），设计目标就是尽量少暴露用户数据。 但按照欧盟监管方对 DMA 的当前解释，苹果必须让任何虚拟助手直接访问用户私密数据，并可直接操控其他已安装应用，而缺少必要保护。 为回应监管要求，苹果提出名为 Trusted System Agent（可信系统智能体）的中间方案，让其他虚拟助手在安全前提下获得与 Siri AI 相同的功能权限。 同时，苹果还给出 1 个 18 个月的渐进上线计划。不过，欧洲委员会没有接受这些提案。
IT之家 6 月 8 日消息，微软昨天在新一届 XBOX Games Showcase 中宣布，未来 17 款新游戏将首发入库 XGP 订阅服务， 包含《神鬼寓言》《战争机器：事变日》《光环：战役进化》等重量级大作 。 IT之家汇总首发入库完整名单如下： 游戏名称 登陆平台 发售时间 《战争机器：事变日》 Xbox Series X/S 2026/10/6 《神鬼寓言》 PC、PS5、Xbox Series X/S 2027/2/23 《光环：战役进化》 Xbox Series X/S、PC、PS5 2026/7/28 《共鸣：瘟疫传说传承》 Xbox Series X/S、PC、PS5 2026/8/27 《宝贝龙：超越领域》 Xbox Series X/S、PC、PS5、Switch 2 2027 年春季 《发条革命》 Xbox Series X/S 2027 年 《女神异闻录 4 Revival》 Xbox Series X/S、PC、PS5 2027/2/18 《女神异闻录 6》 Xbox Series X/S、PC、PS5 暂未公布 《腐朽之都 3》 Xbox Series X/S、PC、PS5 2027 年 《坏喜鹊》 Xbox Series X/S、PC 2027 年 《卧龙 2：凤火连天》 Xbox Series X/S、PC、PS5、Switch 2 2027 年早期 《欢迎入教》 Xbox Series X/S、PC、PS5 2027/3 《Senua》 Xbox Series X/S、PC、PS5 2027 年 《我的世界：地下城 2》 Xbox Series X/S、PC、PS5、Switch 1、Switch 2 2026/9/29 《魔术师：魔鬼的交易》 Xbox Series X/S、PC、PS5 2027 年 《不朽遗志》 Xbox Series X/S、PC、PS5 2026/9/27 《瓶中永夏》 Xbox Series X/S、PC 2027 年
写在前面： 本文首发于 Asahi Blog ，可能会出现 用词不当、不分主次、逻辑不明 等各种 错误 ，以及 入机式发言 ，希望各位佬友批评指正。 升级完 OpenList 的那一刻，我以为只是常规的 bugfix 更新，结果打开主页一看——评论区消失了。 CSS 好端端的，Waline 的样式文件请求返回 200，但 <div id="waline"> 里空空如也，高度是一个令人绝望的 908.812×0 。 折腾了一段时间之后，把问题锁定在了 v4.2.2 的一个 Breaking Change 上。这篇文章就把整个来龙去脉记录下来，顺带把修复方案整合一下，希望踩过同样坑的朋友少花点时间。 问题复现 根据 Waline快速上手中的方案 ，在旧版本（≤ 4.1.10）中仅需在主页的 元数据 README 里写一段 HTML，CSS 和 JS 全部内联： <!-- Waline 容器 --> <link rel="stylesheet" href="https://unpkg.com/@waline/client@v3/dist/waline.css" /> <div id="waline-comment" style="margin: 20px auto; max-width: 960px;"> <h2 style="text-align:center">- 评论 Comments -</h2> <div id="waline"></div> </div> <!-- Waline JS 初始化 --> <script type="module"> import { init } from 'https://unpkg.com/@waline/client@v3/dist/waline.js'; init({ el: '#waline', serverURL: 'https://comments.example.com', emoji: false, comment: true, search: false, path: window.location.pathname, }); </script> 升级到 4.2.2 之后，这段代码的表现变成： <link> 的 CSS 请求正常发出并返回 <script type="module"> 中的 JS 完全没有执行 #waline 容器尺寸为 908.812×0 （宽度撑开了，但高度为 0，Waline 从未初始化） 根本原因：PR #2346 把过滤逻辑从后端搬到了前端 v4.2.2 的 Release Notes 里有两条 Breaking Changes，其中一条就是： settings : Move FilterReadMeScripts to frontend - by @xrgzs in #2346 这条改动对应 commit a5ba6a0 ，看一下实际 diff 就很清楚了。 旧版后端做了什么 旧版的 server/handles/down.go 在代理 .md 文件时，如果 FilterReadMeScripts 开关为 true （默认开启），会在 后端 走一套完整的处理流水线： 用 goldmark 把 Markdown 源文件渲染成 HTML 用 bluemonday 的 UGC Policy 对 HTML 进行 sanitize（消毒） 把清洗过的 HTML 以 text/html 形式返回给前端 bluemonday 的 UGC Policy 会 剥除 <script> 、 <link> 等危险标签 ，这是它的设计初衷。但这套流水线只在 直接代理 .md 文件 时（走 /d/ 路径）才触发，主页展示 README 走的是 /api/fs/get API 接口，后端直接原样返回 Markdown 内容，不经过 bluemonday。 所以旧版真正起作用的机制在前端：前端把 README 内容渲染为 HTML 注入到页面后，会对其中的 <script> 标签做一次 克隆重新 append 的处理，让它们实际执行。 <script type="module"> 就是通过这个机制被触发的。 新版改动：32 行代码的删除 commit a5ba6a0 从 down.go 里 整体删除 了那 31 行后端清洗逻辑，同时移除了对 goldmark 和 bluemonday 两个依赖库的引用，并在 setting.go 里给 FilterReadMeScripts 的配置加上了注释 // frontend ，意思是：这个开关的实际执行逻辑已经全部交给前端负责了。 这是一次架构上的合理重构——把视图层的过滤放在前端做，后端减负，逻辑更清晰。 但问题在于 ：前端新版本对 README 内容里 <script> 标签的处理比之前更严格， type="module" 形式的脚本会被 直接过滤掉，不再执行 。 这就解释了所有现象： 现象 原因 CSS 正常加载 <link> 标签通过了前端的过滤，或走了不同处理路径 JS 完全不执行 <script type="module"> 被前端新过滤器丢弃 #waline 高度为 0 容器 div 存在，但 Waline 从未初始化，内容为空 顺便一提， <script type="module"> 在被 innerHTML 动态插入 DOM 时，浏览器本身也不会自动执行——这是浏览器的安全规范，ES Module 的 import 语义只在顶层脚本上下文有效。所以即使前端没过滤，不经过特殊处理的 module script 也跑不起来。旧版前端的克隆 append 机制恰好绕过了这个限制，新版则没有。 完整修复方案 修复思路是把代码分散到三个不同的注入点，各司其职，完全绕开 README 的过滤器： 第一步：自定义头部（Custom Head）—— 放 CSS 进入 设置 → 全局 → 自定义头部 ，填入： <link rel="stylesheet" href="https://unpkg.com/@waline/client@v3/dist/waline.css"> <head> 里的 <link> 走标准 HTML 解析路径，完全不经过任何 README 过滤器，稳定可靠。 第二步：自定义 Body（Custom Body）—— 放 JS 初始化逻辑 进入 设置 → 全局 → 自定义 Body ，填入以下完整代码： <!-- 引入 UMD 版本的 Waline（挂载到 window.Waline 全局变量） --> <script src="https://unpkg.com/@waline/client@v3/dist/waline.umd.js"></script> <script> (function() { let walineInstance = null; let initTimer = null; function doInitWaline() { const walineEl = document.querySelector('#waline'); if (!walineEl || typeof Waline === 'undefined') return; // 容器内已有内容，说明 Waline 正常挂载着，无需重复初始化 if (walineEl.children.length > 0) return; // 有旧实例先销毁，防止内存泄漏 if (walineInstance && typeof walineInstance.destroy === 'function') { try { walineInstance.destroy(); } catch(e) {} walineInstance = null; } walineInstance = Waline.init({ el: '#waline', serverURL: 'https://comments.example.xyz', // 替换为你的 Waline 服务地址 emoji: false, comment: true, search: false, path: window.location.pathname, }); } // 防抖：SPA 路由切换时 DOM 频繁变动，延迟 300ms 等待稳定 function debouncedInit() { clearTimeout(initTimer); initTimer = setTimeout(doInitWaline, 300); } // 1. 页面首次加载 doInitWaline(); // 2. 监听 DOM 变化（SPA 框架动态重建 DOM 时触发） const observer = new MutationObserver(debouncedInit); observer.observe(document.body, { childList: true, subtree: true }); // 3. 拦截 History API（前进/后退/框架内部路由跳转） const originalPushState = history.pushState; const originalReplaceState = history.replaceState; history.pushState = function() { originalPushState.apply(this, arguments); debouncedInit(); }; history.replaceState = function() { originalReplaceState.apply(this, arguments); debouncedInit(); }; window.addEventListener('popstate', debouncedInit); })(); </script> 为什么改用 UMD 而不是 ESM？ 原来的 import { init } from '...waline.js' 是 ES Module 写法，有两个问题：一是动态插入的 <script type="module"> 浏览器不执行；二是前端过滤器会丢弃它。改用 waline.umd.js 后，脚本加载后直接把 Waline 挂到 window 上，后续代码用 Waline.init() 调用，完全是普通的全局变量方式，没有任何模块化限制。 为什么需要 MutationObserver 和 History API 拦截？ OpenList 是基于 SolidJS 的 SPA（单页应用）。当你从别的目录切换回主页时，整个 DOM 树会被 SolidJS 销毁并重建，之前初始化的 Waline 实例也随之消失。如果只在页面加载时初始化一次，路由切换回来后评论区就空了。 MutationObserver 监听 document.body 的子树变化，每次 DOM 重建后都会触发重新初始化； history.pushState/replaceState 的拦截则覆盖了框架内部路由跳转的场景；300ms 防抖避免 DOM 频繁变动时重复触发。 第三步：主页元数据 README —— 只保留容器 div 回到主页元数据，把 <script> 和 <link> 全部删掉，只保留 HTML 容器： <div id="waline-comment" style="margin: 20px auto; max-width: 960px;"> <h2 style="text-align:center">- 评论 Comments -</h2> <div id="waline"></div> </div> 纯粹的 <div> 不含任何可执行内容，不会被任何过滤器动到。JS 找到这个 #waline 容器后负责挂载，CSS 从 <head> 里来，三方各归其位。 三种注入点的本质区别 理解这三个位置的差异，以后遇到类似问题就不会懵了： 注入点 处理机制 能跑 <script> ？ 能跑 <link> ？ 主页元数据 README 前端 Markdown 渲染 + 新版过滤器 （被过滤） 看情况，不稳定 自定义 Body 直接注入 <body> ，不走 README 过滤器 自定义 Head 注入 <head> ，标准 HTML 解析 README 的设计初衷是内容展示，过滤脚本是合理的安全考量。需要执行 JS 的逻辑就应该放到 Custom Body/Head 这两个专门为此设计的位置。 1 个帖子 - 1 位参与者 阅读完整话题
小米米家空调强劲风立式超 3 匹现已开售，售价 5999 元，国补价 4825 元起 + 6 期免息 。 今日下单京东选择“ 以旧换新 ”： 选择“厨房小电 → 普通餐具”补贴 10 元，实付 4816 元。 选择“大家电 → 挂机 *”补贴 10 元 + 旧机抵 400 元，国补后实付 4477 元。 京东 小米 米家空调强劲风 立式超 3 匹 以旧换新 4816 元 直达链接 京东无门槛红包至高 26618 元，支持即领即用： 点此抽取 。 * 京东回收不看旧机成色，老旧坏皆可，有这个旧货的“尸体”即可。 据介绍，这款新品支持 1800m³/h 大风量、115° 超广域扫风、16m 远距送风 ，客餐厅冷暖全覆盖。新品还支持 140Hz 超高频强劲模式，一键强劲模式，制冷量提升 32.5%，制热量提升 26.5%。 该产品配备 25.1cc 双缸压缩机，纯铜管双排换热器。APF 4.90 超一级能效，官方宣称“全年省电 660 度”。 智能化方面，新品支持 超级小爱控制 、全链路 OTA、智能诊断、车家联动等。 京东 小米 米家空调强劲风 立式超 3 匹 以旧换新 4816 元 直达链接 京东 618 无门槛红包 面额至高 26618 元，每天抽 3 次： 点此抽红包 淘宝 618 无门槛红包 面额至高 26888 元，每天抽 1 次： 点此抽红包
IT之家 6 月 8 日消息，安克旗下 35W 半导体风冷三合一无线充电器将于今天 10 点发售，该产品最大的特点是其底座部分提供了一块触控屏幕，首发价为 1199 元。 京东 安克 35W 半导体风冷三合一无线充电器 1199 元 直达链接 该产品采用安克家族式深空灰配色，尺寸为 169 x 125 x 138 毫米，重量 620 克，可以为苹果 iPhone、Apple Watch、AirPods 同时充电，其底部配备一块 1.62 英寸面板，支持显示充电功率 / 温度信息，支持选择三种充电模式。 该散热器内置 TEC 风冷散热技术，可以帮助手机在充电时降温，还支持通过 App 查看充电信息，并内置 ActiveShield 5.0 安全系统守护充电安全。 IT之家附产品参数： 京东 安克 35W 半导体风冷三合一无线充电器 1199 元 直达链接 京东 618 无门槛红包 面额至高 26618 元，每天抽 3 次： 点此抽红包 淘宝 618 无门槛红包 面额至高 26888 元，每天抽 1 次： 点此抽红包
IT之家 6 月 8 日消息，今日，世嘉宣布《女神异闻录》系列作品终于迎来了万众期待的正统新作 ——《女神异闻录６》。 官方介绍称，本作将在继承长久以来备受玩家喜爱的系列独特世界观与创新游玩体验的同时，在全新的舞台中为玩家们带来全新的故事，新作现已确定登陆 Xbox Game Pass 以及 Xbox Series X|S、Windows、PlayStation®5 和 Steam 平台。在此之前，官方还带来了先导预告片。 Atlus 在 2021 年 7 月确认《女神异闻录 6》存在，当时这家公司在 Green 求职平台发布多条招聘信息，Atlus 执行制作人平冈直人在招聘信息中表示，公司正在为《女神异闻录 6》招聘更多人手，回应玩家不断升高的期待值。 IT之家注意到，尽管 Atlus 在四年半以后才正式公开《女神异闻录 6》，但外界普遍认为项目进展稳定。
（ AI 润色） 去年首发入手的 iPhone 17 ，用了快一年，一直表现堪称模范生。 平时不打游戏、不重度使用，手机基本都是冰冰凉凉，续航也相当稳定。 结果大概从两个月前开始，画风突变： * 莫名发热，揣兜里像暖手宝； * 电量尿崩，掉电速度堪比股市跳水； * 待机都发烫； * 充电更是热情似火。 最离谱的是，后台什么都没开，手机放桌上自己都能发热。 这两个月我几乎把能试的方法都试了一遍： ✔ 重启 ✔ 关闭后台 ✔ 检查电池健康 ✔ 备份恢复 ✔ DFU 恢复出厂设置 ✔ 恢复备份 甚至翻遍了国内外各种技术论坛、Reddit 、MacRumors 等帖子，怀疑过系统、怀疑过电池、怀疑过基带，差点开始怀疑人生。 然而问题始终存在。 就在我准备认命的时候，居然在小红书刷到了一个帖子。 方法有两个： 方法一： 微信 → 我 → 设置 → 帮助与反馈 → 右上角小扳手 → 重新载入数据 方法二： 备份微信聊天记录 → 删除微信 → 重装微信 → 恢复聊天记录 本着死马当活马医的心态，我先试了第一种。 结果…… 手机不热了。 续航恢复了。 待机掉电正常了。 就这么简单。 我当时看着手机陷入了沉思： 苹果工程师查日志查不出来的问题，微信小扳手一拧解决了。 折腾两个月，各种恢复刷机操作猛如虎，最后发现真正需要恢复的是微信。 所以如果你的 iPhone 最近也出现： * 异常发热 * 待机耗电快 * 电量尿崩 * 后台耗电异常 尤其微信使用频率比较高的话，建议先试试这个方法。 当然，这并不能证明一定是微信的问题。 但至少我的手机，在按下“重新载入数据”那一刻，仿佛完成了一场赛博驱魔仪式。 最后想问一句： 张小龙到底在微信里养了什么？ 一个聊天软件，硬是让我以为自己买到了电暖宝。
（ AI 润色） 去年首发入手的 iPhone 17 ，用了快一年，一直表现堪称模范生。 平时不打游戏、不重度使用，手机基本都是冰冰凉凉，续航也相当稳定。 结果大概从两个月前开始，画风突变： * 莫名发热，揣兜里像暖手宝； * 电量尿崩，掉电速度堪比股市跳水； * 待机都发烫； * 充电更是热情似火。 最离谱的是，后台什么都没开，手机放桌上自己都能发热。 这两个月我几乎把能试的方法都试了一遍： ✔ 重启 ✔ 关闭后台 ✔ 检查电池健康 ✔ 备份恢复 ✔ DFU 恢复出厂设置 ✔ 恢复备份 甚至翻遍了国内外各种技术论坛、Reddit 、MacRumors 等帖子，怀疑过系统、怀疑过电池、怀疑过基带，差点开始怀疑人生。 然而问题始终存在。 就在我准备认命的时候，居然在小红书刷到了一个帖子。 方法有两个： 方法一： 微信 → 我 → 设置 → 帮助与反馈 → 右上角小扳手 → 重新载入数据 方法二： 备份微信聊天记录 → 删除微信 → 重装微信 → 恢复聊天记录 本着死马当活马医的心态，我先试了第一种。 结果…… 手机不热了。 续航恢复了。 待机掉电正常了。 就这么简单。 我当时看着手机陷入了沉思： 苹果工程师查日志查不出来的问题，微信小扳手一拧解决了。 折腾两个月，各种恢复刷机操作猛如虎，最后发现真正需要恢复的是微信。 所以如果你的 iPhone 最近也出现： * 异常发热 * 待机耗电快 * 电量尿崩 * 后台耗电异常 尤其微信使用频率比较高的话，建议先试试这个方法。 当然，这并不能证明一定是微信的问题。 但至少我的手机，在按下“重新载入数据”那一刻，仿佛完成了一场赛博驱魔仪式。 最后想问一句： 张小龙到底在微信里养了什么？ 一个聊天软件，硬是让我以为自己买到了电暖宝。
（ AI 润色） 去年首发入手的 iPhone 17 ，用了快一年，一直表现堪称模范生。 平时不打游戏、不重度使用，手机基本都是冰冰凉凉，续航也相当稳定。 结果大概从两个月前开始，画风突变： * 莫名发热，揣兜里像暖手宝； * 电量尿崩，掉电速度堪比股市跳水； * 待机都发烫； * 充电更是热情似火。 最离谱的是，后台什么都没开，手机放桌上自己都能发热。 这两个月我几乎把能试的方法都试了一遍： ✔ 重启 ✔ 关闭后台 ✔ 检查电池健康 ✔ 备份恢复 ✔ DFU 恢复出厂设置 ✔ 恢复备份 甚至翻遍了国内外各种技术论坛、Reddit 、MacRumors 等帖子，怀疑过系统、怀疑过电池、怀疑过基带，差点开始怀疑人生。 然而问题始终存在。 就在我准备认命的时候，居然在小红书刷到了一个帖子。 方法有两个： 方法一： 微信 → 我 → 设置 → 帮助与反馈 → 右上角小扳手 → 重新载入数据 方法二： 备份微信聊天记录 → 删除微信 → 重装微信 → 恢复聊天记录 本着死马当活马医的心态，我先试了第一种。 结果…… 手机不热了。 续航恢复了。 待机掉电正常了。 就这么简单。 我当时看着手机陷入了沉思： 苹果工程师查日志查不出来的问题，微信小扳手一拧解决了。 折腾两个月，各种恢复刷机操作猛如虎，最后发现真正需要恢复的是微信。 所以如果你的 iPhone 最近也出现： * 异常发热 * 待机耗电快 * 电量尿崩 * 后台耗电异常 尤其微信使用频率比较高的话，建议先试试这个方法。 当然，这并不能证明一定是微信的问题。 但至少我的手机，在按下“重新载入数据”那一刻，仿佛完成了一场赛博驱魔仪式。 最后想问一句： 张小龙到底在微信里养了什么？ 一个聊天软件，硬是让我以为自己买到了电暖宝。
（ AI 润色） 去年首发入手的 iPhone 17 ，用了快一年，一直表现堪称模范生。 平时不打游戏、不重度使用，手机基本都是冰冰凉凉，续航也相当稳定。 结果大概从两个月前开始，画风突变： * 莫名发热，揣兜里像暖手宝； * 电量尿崩，掉电速度堪比股市跳水； * 待机都发烫； * 充电更是热情似火。 最离谱的是，后台什么都没开，手机放桌上自己都能发热。 这两个月我几乎把能试的方法都试了一遍： ✔ 重启 ✔ 关闭后台 ✔ 检查电池健康 ✔ 备份恢复 ✔ DFU 恢复出厂设置 ✔ 恢复备份 甚至翻遍了国内外各种技术论坛、Reddit 、MacRumors 等帖子，怀疑过系统、怀疑过电池、怀疑过基带，差点开始怀疑人生。 然而问题始终存在。 就在我准备认命的时候，居然在小红书刷到了一个帖子。 方法有两个： 方法一： 微信 → 我 → 设置 → 帮助与反馈 → 右上角小扳手 → 重新载入数据 方法二： 备份微信聊天记录 → 删除微信 → 重装微信 → 恢复聊天记录 本着死马当活马医的心态，我先试了第一种。 结果…… 手机不热了。 续航恢复了。 待机掉电正常了。 就这么简单。 我当时看着手机陷入了沉思： 苹果工程师查日志查不出来的问题，微信小扳手一拧解决了。 折腾两个月，各种恢复刷机操作猛如虎，最后发现真正需要恢复的是微信。 所以如果你的 iPhone 最近也出现： * 异常发热 * 待机耗电快 * 电量尿崩 * 后台耗电异常 尤其微信使用频率比较高的话，建议先试试这个方法。 当然，这并不能证明一定是微信的问题。 但至少我的手机，在按下“重新载入数据”那一刻，仿佛完成了一场赛博驱魔仪式。 最后想问一句： 张小龙到底在微信里养了什么？ 一个聊天软件，硬是让我以为自己买到了电暖宝。
（ AI 润色） 去年首发入手的 iPhone 17 ，用了快一年，一直表现堪称模范生。 平时不打游戏、不重度使用，手机基本都是冰冰凉凉，续航也相当稳定。 结果大概从两个月前开始，画风突变： * 莫名发热，揣兜里像暖手宝； * 电量尿崩，掉电速度堪比股市跳水； * 待机都发烫； * 充电更是热情似火。 最离谱的是，后台什么都没开，手机放桌上自己都能发热。 这两个月我几乎把能试的方法都试了一遍： ✔ 重启 ✔ 关闭后台 ✔ 检查电池健康 ✔ 备份恢复 ✔ DFU 恢复出厂设置 ✔ 恢复备份 甚至翻遍了国内外各种技术论坛、Reddit 、MacRumors 等帖子，怀疑过系统、怀疑过电池、怀疑过基带，差点开始怀疑人生。 然而问题始终存在。 就在我准备认命的时候，居然在小红书刷到了一个帖子。 方法有两个： 方法一： 微信 → 我 → 设置 → 帮助与反馈 → 右上角小扳手 → 重新载入数据 方法二： 备份微信聊天记录 → 删除微信 → 重装微信 → 恢复聊天记录 本着死马当活马医的心态，我先试了第一种。 结果…… 手机不热了。 续航恢复了。 待机掉电正常了。 就这么简单。 我当时看着手机陷入了沉思： 苹果工程师查日志查不出来的问题，微信小扳手一拧解决了。 折腾两个月，各种恢复刷机操作猛如虎，最后发现真正需要恢复的是微信。 所以如果你的 iPhone 最近也出现： * 异常发热 * 待机耗电快 * 电量尿崩 * 后台耗电异常 尤其微信使用频率比较高的话，建议先试试这个方法。 当然，这并不能证明一定是微信的问题。 但至少我的手机，在按下“重新载入数据”那一刻，仿佛完成了一场赛博驱魔仪式。 最后想问一句： 张小龙到底在微信里养了什么？ 一个聊天软件，硬是让我以为自己买到了电暖宝。