写在前面
我用的组合是 Typora + Cloudflare R2，图片访问走自定义域名，上传走 PicGo。理论上这套东西搭起来很顺，网上教程也不少，但实际弄的时候还是踩了几个坑。这篇就是把整个排查过程记下来，主要是给以后的自己看，顺便如果你也在用类似的组合，可能也能少折腾一会儿。
踩到的问题主要集中在三个地方：
- Typora 自带的
PicGo-Core (command line)版本太旧，跑不起来新插件 PicGo App输入框里写正则和直接改config.json转义方式不一样- 开了
pathStyleAccess=true之后，最终图片链接会莫名多一个桶名
Typora 自带的 PicGo-Core 先别用
我最开始很自然地选了 Typora 偏好设置里的 PicGo-Core (command line)，看着像官方做好的集成，结果测试图片上传直接报错：
[PicGo ERROR]: SyntaxError: Unexpected token '?'[PicGo WARN]: Can't find uploader - smms, swtich to default uploader - smms[PicGo ERROR]: Error: Can't find smms config我以为是 S3 参数填错了，翻来覆去检查密钥、endpoint、bucket，折腾了一圈，最后才发现问题根本不在配置——是 Typora 自己下载到本地的那个 picgo.exe 版本太旧，新版的 aws-s3 插件根本加载不起来，加载失败之后又退回到默认的 smms 上传器，所以才一直报找不到 smms 配置。
所以如果你也碰到类似报错，可以先绕过这个内置选项，走另外两条路：
- 直接用 PicGo App（图形界面）
- 或者用 Custom Command（调用本机装好的 PicGo CLI）
方案一：PicGo App
配置
Typora 偏好设置 → 图像，上传服务 改成 PicGo(app)，然后保证 PicGo App 已经打开在后台跑着就行。
PicGo App 里的 Amazon S3 配置（Cloudflare R2 填 S3 兼容参数）：
| 字段 | 填什么 |
|---|---|
| 应用密钥 ID | Access Key ID |
| 应用密钥 | Secret Access Key |
| 桶名 | picture |
| 上传文件路径 | img/{year}/{month}/{day}/{md5}.{extName} |
| 地区 | auto |
| 自定义节点 | https://你的账户.r2.cloudflarestorage.com |
| 拒绝无效 TLS 证书连接 | yes |
| ACL 访问控制列表 | public-read |
| ForcePathStyle | yes |
| 自定义输出 URL 模板 | https://你的图片域名/{path:/^picture\//g,''} |
| Bucket 前缀 | no |
我自己填的模板长这样：
https://img.picr2.online/{path:/^picture\//g,''}坑：正则转义
这个是最容易搞错的地方。
在 PicGo App 输入框里写：
https://img.picr2.online/{path:/^picture\//g,''}存进 config.json 之后会变成：
"outputURLPattern": "https://img.picr2.online/{path:/^picture\\//g,''}"也就是说 GUI 里写单反斜杠，JSON 里会自动变双反斜杠。如果你手动改了 config.json，或者直接把 JSON 里的写法粘到 GUI 输入框，正则就会失效，最终图片链接会多出一截桶名：
# 不对的https://img.picr2.online/picture/img/2026/03/15/xxx.png
# 想要的https://img.picr2.online/img/2026/03/15/xxx.png为什么会多出 /picture/
这个问题本身也值得说一下。开了 ForcePathStyle = yes 之后，插件内部拿到的原始路径格式是：
/{bucketName}/{objectKey}也就是：
/picture/img/2026/03/15/xxx.png所以输出模板如果只是简单写 {path}，桶名就会直接带进去。要把它去掉，就得在模板里用正则替换：
https://img.picr2.online/{path:/^picture\//g,''}方案二：Custom Command（更推荐）
为什么我更喜欢这套
主要是因为不依赖 Typora 自带的那个旧版 picgo.exe，而是直接调你本机装好的 PicGo CLI。插件版本、Node 环境、配置文件都是你自己控制的，出了问题也可以直接在终端里手动跑一遍复现。
安装
先确认本机有 Node：
node -vnpm -v然后全局装 PicGo 和 S3 插件：
npm install -g picgopicgo add s3picgo use uploader aws-s3如果你在 GUI 里创建过一个叫 s3 的配置，也可以显式指定：
picgo use uploader aws-s3 s3PicGo CLI 默认配置文件在：
C:\Users\你的用户名\.picgo\config.jsonTypora 里怎么填
偏好设置 → 图像，上传服务 选 自定义命令，命令填：
C:\nvm4w\nodejs\picgo.cmd upload路径改成你本机 Node 的实际位置。
最小可用的 config.json
用 Custom Command 的话，我建议把配置文件精简一下，只保留真正需要的字段：
{ "picBed": { "current": "aws-s3", "uploader": "aws-s3", "transformer": "path", "aws-s3": { "accessKeyID": "你的AccessKeyID", "secretAccessKey": "你的SecretAccessKey", "bucketName": "picture", "uploadPath": "img/{year}/{month}/{day}/{md5}.{extName}", "region": "auto", "endpoint": "https://你的账户.r2.cloudflarestorage.com", "proxy": "", "rejectUnauthorized": true, "acl": "public-read", "pathStyleAccess": true, "outputURLPattern": "https://img.example.com/{path:/^picture\\//g,''}", "urlPrefix": "", "urlSuffix": "", "disableBucketPrefixToURL": true } }, "picgoPlugins": { "picgo-plugin-s3": true }}关于 s3 和 aws-s3 同时出现
如果你以前在 GUI 里改来改去，配置文件里可能会看到 s3 和 aws-s3 同时存在，看上去像重复，实际上很多是旧字段、缓存或历史残留。
picgo-plugin-s3 现在真正读的是 picBed.aws-s3，所以如果只用一套方案，其他的可以直接删掉，保持干净。
怎么选
如果只看能不能跑，两套都行。
但如果你本机已经有 Node 和 PicGo CLI，建议直接走 Custom Command，省心很多。PicGo App 适合不想碰命令行、就要图形界面的场景，不过要注意 GUI 正则转义那个坑。
排错清单
配好了还是不工作，可以按这个顺序查：
- Typora 是不是还在用自带旧版
PicGo-Core - 本机
picgo命令能不能直接在终端跑 picgo-plugin-s3有没有装endpoint、bucketName、accessKeyID、secretAccessKey有没有填对pathStyleAccess和你的对象存储是否匹配- 自定义域名能不能直接访问对象
outputURLPattern有没有正确去掉桶名前缀- GUI 输入框和 JSON 文件里的反斜杠转义有没有搞混
最后
整个弄下来，感觉最绕的地方不是哪一步特别复杂，而是 Typora、PicGo App、PicGo CLI、S3 接口、对象存储、CDN、自定义域名这几层叠在一起，每一层看着都没问题，但一旦某个地方有点偏差，最后就是一个莫名其妙的错误链。
配好之后其实很稳，之后截图直接拖进 Typora 就能用，也不用管其他的。
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时