剪藏下来的正文还在，配图却是空白或破图，分叉点通常只有一个：这张图在剪藏时被下载转存到了本地或图床，还是仍然指向原站的图片地址。前者打不开，多半是附件丢了、路径错了、客户端没渲染出来；后者打不开，多半是原站删图、防盗链或跨域限制。所以不要急着换工具或重装，先打开那条笔记，看图片地址指向哪里。
判断路径分三步：看图片地址的形态，是本地/附件路径还是 http(s) 原站链接；再断网重开同一条笔记，联网能显示、断网空白说明依赖原站；最后换一条多图文章重剪一次，看是全图失效还是个别图失效。地址形态和断网对照只是判断依据，最终还要结合原站是否仍可访问、剪藏工具是否开启图片本地化选项来确认。这三种现象可以被观察和复现，但不要据此推断具体原因，需结合自己的客户端和原站环境确认。
复现一条图片打不开的剪藏笔记
先固定一条问题样本，不要随手换笔记看，否则偶发的加载失败会和真实问题混在一起。挑一条你已经确认图片打不开的剪藏笔记，逐项记录三件事：显示表现、出现位置、出现数量。
- 显示表现：是彻底空白占位，还是破图图标，还是能读到 alt 文本但图不出来，还是加载动画转完仍为空白。这几种在排查时指向不同方向，建议截图留档。
- 出现位置：正文第几张图、是否只发生在首图、是否集中在文末、是否只出现在图注或表格里。位置比总数更能看出规律。
- 出现数量：给图片按 1、2、3 编号，标注每张的状态，例如「1 正常 / 2 空白 / 3 正常 / 4 破图」。先有清单，后面的对照才有基准。
做完记录后，把这条笔记关闭重开一次，再换一个客户端或换一台设备打开同一条。如果重复两三次仍然复现，可以认为不是一次性的网络抖动；如果只在某一台设备上空白，则更可能是本地渲染或缓存问题。
在笔记里查看图片地址指向哪里
这一步的目的只有一个：区分「转存到本地」和「引用原站链接」。多数笔记客户端至少有一个入口能看到地址，可以先从这几个界面找：编辑器里选中图片后查看「链接 / 属性 / 复制图片地址」；把笔记导出为 Markdown 或 HTML，再看源码；或者直接去附件目录、本地数据目录里看有没有对应的图片文件。
导出后可以用命令快速看一遍所有图片引用，下面这段只是通用骨架，路径替换成你自己的导出文件：
# 统计图片引用条数
grep -o '!\[[^]]*\]([^)]*)' note.md | wc -l
# 列出每张图指向的地址
grep -o 'https\?://[^)" ]*' note.md | head -20看地址形态就能大致分类。偏向转存的形态通常是相对路径或本地路径，例如 assets/xxx.png、file:///...、attachment://...，或者自家图床、对象存储的域名；导出时这类图片一般会跟笔记一起打包成目录。偏向引用原链的形态是完整的 https://原站域名/...，域名与剪藏文章所属站点一致，URL 上常带 ?w=、?imageView2、?x-oss-process 这类图片处理参数。对存疑的地址，可以用一条 HEAD 请求看原站是否还回应图片：
curl -I -L "https://原站域名/path/to/image.jpg"需要克制的地方在于：地址指向原站，只说明它是引用，不等于图一定已经丢了。原站可能有防盗链、限流或临时故障，联网状态下换个网络环境再试一次，才能把「原站不可用」和「客户端没拉到」分开。地址指向本地，也不能直接判定图片完好，路径错、附件被清理同样会空白。
断网状态下重新打开同一条笔记
用网络这一个变量来对照，是最省事的判断方式。操作顺序建议是：先记下联网时这条笔记的图片状态，然后断开网络（关闭 Wi-Fi、拔掉网线或开飞行模式），重启笔记客户端，再打开同一条笔记，看图片是否显示。
- 断网仍正常显示：图片大概率已经落到本地或客户端缓存里，属于转存或缓存命中。
- 断网变成空白、恢复网络后又出现：图片依赖原站，属于引用原链。
- 断网和联网都空白：要么转存文件损坏或路径失效，要么原站本身已经拿不到图。
这里有一个容易误判的点：不少客户端在联网浏览时会把图片缓存到本地，断网后仍能显示，这并不能证明剪藏时做了转存。要减少干扰，可以先清理该客户端的缓存，或者换一台从未打开过这条笔记的设备再断网试一次，两次结果一致再下判断。
换一条多图文章重做剪藏
单条笔记的现象可能带有偶然性，换一条图片较多的文章重新剪藏一次，能把「整站问题」和「单张图问题」区分开。建议找一篇十张图以上、图片分布在正文各处的文章，用同样的工具、同样的设置剪藏，然后按位置逐张核对。
记录方式做成一张小表就够了，不需要复杂统计：
- 总张数（剪藏后应有多少张）
- 成功张数、失败张数
- 失败图的位置分布：首图、正文中段、文末、懒加载图、图注图
规律通常比数字更有意义。全部图片失效，往往指向原站整体防盗链，或者剪藏时没有开启图片下载；只有文末和长列表里的图失效，常见原因是没有触发页面滚动、懒加载图片还没出现就被抓取；零散几张失效，更可能是那几张原图被删除、被替换，或者跨域策略不同。把新笔记的现象和第一条笔记对比，如果表现一致，说明问题更可能出在工具设置或原站策略上，而不是某一条笔记的数据损坏。
整理剪藏后补存图片的可行动作
确认是引用原链之后，补救的方向是把图片落到本地，并保留一份可核对的清单。检查动作可以固定下来：导出笔记为 Markdown，统计图片引用数量，再和文章页面上你数到的图片数量对照；如果导出包里带附件目录，直接数一下目录里的文件数。数量对不上，再按位置定位缺的是哪几张。
补存顺序建议按重要性排，不要一上来就全量重下：先补封面、图表、公式截图、流程图这类信息承载大的图，再补装饰图和分隔图。可行的动作有几种，可以按环境选择：
- 手动另存：打开原文章，把关键图片下载到笔记的附件目录，再用编辑器的替换图片功能把原链换成刚存下来的本地文件。
- 批量下载：如果导出的 Markdown 里已经有一份图片地址清单，可以用循环逐条拉取，下面对应的骨架只是示意，文件名规则和保存目录需要按自己的结构改：
mkdir -p assets
while read -r url; do
fname="assets/$(basename "${url%%\?*}")"
curl -L `--fail` -o "$fname" "$url" || echo "failed: $url"
done < urls.txt- 改设置重剪：在剪藏工具里开启图片本地化或附件下载选项，再对原文重新剪藏一次，然后和新旧两条笔记对照图片数量。
- 原图已删的情况：尝试从网页快照、站内备份或你自己的其他剪藏里找回；确实找不回的，在对应位置留一行文字说明，避免以后看笔记时误以为内容完整。
最后要留的边界是：只要图片仍指向原站，它的可用性就取决于原站是否长期保留文件、是否调整防盗链策略，这一点无法由剪藏工具单方面保证。需要长期留存的内容，剪藏后顺手做一次数量核对并把关键图转存，比事后逐条补救更省事。