简单来说。 两个应用用的插件格式是 PicGo 定义的；PicGo 自带 PicGo Cloud 图床服务，内置配置同步和相册同步；npm 上有 219 个基于 PicGo 编写的插件。PicList 是一个分支，把水印、压缩和远程文件管理直接做进了应用里，插件方面读取的是 PicGo 的插件，没有自己的一套。
选 PicGo，如果你想要更大的插件生态、第一时间用上新的扩展点，以及不需要自己折腾 WebDAV 或 Git 就能用的图床。选 PicList，如果你想要不装任何东西就能用的内置图片工具和远程文件浏览，并且能接受插件相关的变化总是晚一步才跟上。
一览
| PicGo | PicList | |
|---|---|---|
| 上传到自己的图床 | 支持 | 支持 |
| 没有图床怎么办 | PicGo Cloud，内置，有免费额度 | 需要自备 |
| 插件 API | 由它定义 | 读取 PicGo 的 |
| 应用内置上传器 | 8 个，包括自家的 PicGo Cloud | 更多，但没有一个是它自己运营的 |
| 水印、压缩、格式转换 | 通过插件 | 内置，可按图床分别配置 |
| 管理图床上已有的文件 | 自己上传记录的相册 | 远程浏览、重命名、删除 |
| 配置同步 | 内置，可选端到端加密（v3.0.0+） | 通过 WebDAV 或 Git |
| 多设备相册同步 | 通过 PicGo Cloud 内置（v3.0.0+） | 通过 WebDAV 或 Git |
| npm 上的插件包 | 219 | 0，读取 PicGo 的 |
| 脚本系统 | 无 | 有 |
| 代码签名 | macOS 和 Windows | macOS |
| 首次发布 | 2017 | 2023 |
| GitHub Star | 27.1k | 3.7k |
功能放在哪里
这才是真正要紧的差别，而且从两个项目核心包的依赖上就能看得一清二楚。
PicList-Core 直接内置了存储服务和图片处理：AWS S3 SDK、qiniu、webdav、一个 SSH 客户端，再加上用于水印和格式转换的 sharp、heic-convert 和 text-to-svg。装上 PicList，这些东西就全在你的磁盘上了，不管你用不用 S3、会不会加水印。
PicGo-Core 两样都不内置。PicGo 应用里有 8 个内置上传器：GitHub、阿里云 OSS、腾讯云 COS、七牛、又拍云、SM.MS、Imgur 和 PicGo Cloud，但它们背后的代码并没有写死在核心里，图片处理更是完全没有。其他一切都以插件的形式加入。
PicList 开箱支持的图床更多。但真正要紧的是它加不了的那一个：PicGo Cloud 是我们自己运营的服务，而不是对接你已经付费的某个存储，所以在两边的列表里，它是唯一一个在你还没有任何图床时就能直接用的选项。
插件生态是 PicGo 的
PicList 兼容 PicGo 插件。它自己的 README 就是这么写的，它的插件加载器找的也是名为 picgo-plugin-* 的包，和 PicGo 用的完全一样。
不对称体现在数字上。npm 上以 picgo-plugin 关键词发布的包有 219 个，以 piclist-plugin 发布的一个都没有。有人为某个新图床写上传器时，是为 PicGo 写的，PicList 顺带继承过去。这对 PicGo 用户是实打实的优势，也是 PicList 能用得这么好的原因之一。
不过这也意味着兼容是单向的。插件作者针对 PicGo 开发和测试，所以插件会随着 PicGo 新功能的上线而跟进；PicList 要等下一次同步上游时才能拿到这些。PicList 自己的 README 说的是兼容大多数现有 PicGo 插件，而不是全部；遇到不兼容的插件，就得有人去 fork 一份。npm 上的 picgo-plugin-pic-migrater-piclist 正是因为这个原因才存在的。
这也决定了谁来定格式。插件 API 是 PicGo 的，所以 PicGo 新增一个扩展点时，插件可以立刻用上，而 PicList 要等下一次合并上游才会有。这个时间差是结构性的，跟谁发版快慢无关：下游分支跟随上游 API，反过来则不成立。
还有一个值得了解的连带影响。因为 PicList 把水印、压缩和格式转换做进了应用，这些功能可能会和做同样事情的插件重叠，你就得决定由哪一层来负责这次处理。在 PicGo 上只有一层：没装插件，这一步就不会发生。
纠正一些仍在流传的对比说法
PicGo 3.0 在 2026 年 7 月发布，而不少广为流传的对比文章写在它之前。如果你看到过 PicGo 缺少下面这些功能的说法，那在当时是对的，现在已经不是了：
- 配置同步。 v3.0.0 已上线，支持自动、服务端加密和端到端加密三种模式。
- 云端相册管理与同步。 同样在 v3.0.0 上线，支持导入已有的本地上传记录，并通过 PicGo Cloud 在多设备间同步。
- macOS 和 Windows 代码签名。 PicGo 在两个平台上都已签名，旧文章里提到的 Gatekeeper 警告已不再出现。
PicList 确实领先的地方
与其等别人来指出，不如我们自己直说：
- 管理图床上已有的文件。 PicList 可以跨存储服务浏览、搜索、重命名和删除远程文件。PicGo 的相册只覆盖通过 PicGo 上传的内容。
- 零配置的图片工具。 水印、压缩、缩放、旋转和格式转换都是内置的，还能按图床分别配置。PicGo 每一项都需要一个插件。
- 脚本系统和主题。 不依赖 Node 环境的生命周期脚本，外加一个主题仓库。
怎么选
选 PicList，如果你要直接在应用里管理图床上的文件，或者想要水印和压缩功能，又不想先去找插件。
选 PicGo，如果你想要应用自带的图床、最丰富的插件选择且没有内置行为需要绕开，或者只想要一个能把截图变成链接的最轻量工具。
PicGo Cloud 是没法拿功能清单来比的那部分。两个应用各自提供的本地功能，水印、压缩、远程文件浏览，另一方都可以加上。图床服务则不同：它需要存储、CDN、自定义域名，还需要有人来运营。PicGo Cloud 让你一登录就有一个能用的图床，还带免费额度，配置同步和相册同步也都走同一个账号。没有背后的服务，同步就只能让应用指向你自己维护的 WebDAV 或 Git 仓库。它也是新能力最先落地的地方，因为这是我们自己可以持续建设的东西，而不是对你自备存储的一层包装。
无论选哪个，都不会被锁死。你的图片存在你配置的图床上，而不是在应用里，两者读取的又是同样的插件包，所以以后切换只需要重新配置，谈不上迁移。唯一的例外是你存在 PicGo Cloud 里的内容，它跟着账号走，而不是跟着应用走。
常见问题
Q：PicList 比 PicGo 好吗？
A：两者的侧重点不同。PicList 把水印、压缩、云端文件管理和主题都打包进了应用，装好就能用。PicGo 保持核心精简，把这类功能交给插件，用什么装什么。如果你想要免配置的云存储浏览和图片编辑，PicList 开箱能做的更多。如果你不想背着一堆自己从来不碰的功能代码，PicGo 是更轻量的那个工具。
Q：PicList 是 PicGo 的分支吗？
A：是的。PicList 于 2023 年 1 月从 PicGo 分出，并自称是在 PicGo 的基础上构建的。它沿用了 PicGo 的上传器模型和插件格式：PicList 加载名为 picgo-plugin-* 的包，和 PicGo 用的一样。
Q：PicGo 插件能在 PicList 里用吗？
A：大多数可以，因为 PicList 读取的是同样的 picgo-plugin-* 包。反过来的情况基本不存在：npm 上 picgo-plugin 关键词下有 219 个包，piclist-plugin 下一个都没有，所以插件生态是 PicGo 的，PicList 是在使用它。
Q：PicList 的内置工具会和插件冲突吗？
A：可能会重叠。水印、压缩和格式转换既是 PicList 的内置功能，也有对应的 PicGo 插件，所以如果你装了一个做同样事情的插件，就需要决定由哪一层来执行。PicGo 完全没有内置图片处理，所以要么装了插件，要么这一步就不会发生。PicList 也说自己兼容的是大多数 PicGo 插件，而不是全部，还有少数插件单独发布了 PicList 专用的 fork 版本。
Q：PicGo 有配置同步和云相册吗？
A：有，从 2026 年 7 月的 v3.0.0 开始。配置同步支持自动、服务端加密和端到端加密三种模式，云相册管理通过 PicGo Cloud 在多设备间同步。2026 年年中以前写的对比文章都早于这两个功能，在这一点上已经过时了。
Q：PicGo 在 macOS 和 Windows 上签名了吗？
A：两个平台都签名了。旧文章里描述的未签名安装包和 Gatekeeper 警告已不符合当前版本的情况。
Q：我可以在两者之间切换吗？
A：两者读取同样的图床配置和同样的插件包，所以换过去只是重新配置，谈不上迁移。无论怎么换，你已上传的图片都不受影响，它们存在你配置的图床上，而不是在应用里。
本文内容已于 2026 年 9 月对照各项目的公开仓库和 npm 核实。PicList 开源于 Kuingsmile/PicList；如果这里有任何过时的信息，欢迎告诉我们，我们会及时更正。