企业官网建设流程全解析

做嵌入式这行的，文档和固件里塞图片是躲不掉的事——原理图截图、接线示意、上位机界面预览、OTA 升级前后的对比图、测试报告的波形图，随便一个项目攒下来就是上百张。早年大家的做法都很朴素，图片直接丢进代码仓库的docs/images/目录，Git 慢慢就胖成几个 G，clone 一次能等到怀疑人生，CI 拉代码的时间也越来越离谱。后来我开始把图片挪出去做图床外链，仓库瞬间瘦身，但新的麻烦也接踵而至：外链会不会哪天突然 403？嵌入式设备端能不能顺利把这张图拉下来解码显示？换域名之后几百篇文档里的链接怎么批量替换？这篇文章就围绕测试嵌入式图床外链这件事，把我从选型、搭建、测试到巡检的完整流程摊开讲一遍，不管你是刚接触嵌入式的新手，还是已经在带项目的老手，应该都能抄到能直接落地的东西。

1. 需求拆解：嵌入式项目为什么要把图片挂成外链

1.1 从"图片塞进仓库"到"外链托管"的真实痛点

嵌入式项目的仓库和纯软件项目不太一样。纯软件项目可能就几张架构图，嵌入式项目光是硬件相关就有一堆：核心板引脚定义图、电源树、时钟树、DDR 布线示意、外设接线照片、示波器抓的波形、逻辑分析仪截图，再叠加软件侧的流程图、状态机图、上位机界面截图、量产烧录工装照片。一个中等规模的项目，图片数量轻松破两百，单张 PNG 截图两三兆是常事。

这些图片如果全部进 Git，会有三个直接后果。第一是仓库体积失控，我见过一个项目.git目录 6.8G，其中 90% 是历史版本的截图，clone 要十几分钟，换了新同事第一句就是"这仓库怎么这么大"。第二是 Git 对二进制文件的差分压缩几乎无效，改一张图就存一份完整副本，历史越长越臃肿。第三是图片和代码耦合，文档里的图想更新得走一次提交流程，评审、合并、CI 全跑一遍，为了换一张示意图，性价比极低。

把图片迁到图床、文档里只留外链，本质上是一次"关注点分离"：代码仓库只负责代码和文本，二进制资源交给专门的对象存储服务托管。这么做之后，仓库回到几十兆的量级，文档更新图片只需要替换一个 URL，成本几乎为零。代价是引入了外部依赖——链接可能失效、可能被防盗链拦、可能有访问限速，而"测试"这件事的价值，恰恰就在于把这些外部依赖的风险摁到可控范围里。

1.2 外链方案的三种类型与选型逻辑

图床外链不是只有一种做法，我实测下来把它归成三类，各有适用场景。

我的选型结论很明确：正式项目一律用对象存储自建图床，理由不是它免费或方便，而是它把三个关键控制权交回给了你——访问权限、缓存策略、域名生命周期。这三个东西直接决定了外链的长期可用性，也是后面所有测试项的基础。

公共免费图床我只在两种场景下用：一是临时贴一张截图到聊天群里讨论，二是博客里放一些可有可无的装饰图。凡是出现在产品文档、固件说明、客户交付资料里的图片，绝对不要用公共图床，因为这类图床的运营方随时可能调整策略，你的文档会在某天集体变成一堆红色叉号，而那时候你已经不记得当初传的是哪张图了。

自建图床的另一个隐性好处是：你可以对"外链行为"做完整测试。公共图床你没法看服务端日志，没法改防盗链规则，没法调缓存 TTL，出了问题只能干瞪眼。自建环境下这些全是你能改的变量，测试才有意义。

2. 图床外链环境搭建：从存储桶到加速域名

2.1 存储桶与访问权限的关键参数

搭自建图床的第一步是开一个对象存储桶。这里最容易被忽略、也最容易导致外链失效的，是权限配置。我建议的配置是：

• 读写权限：桶本身保持私有，通过"公共读"策略或单独的读取策略让图片可被匿名读取。切忌整个桶开"公共读写"，那等于把你的存储空间交给全网。
• 访问控制：如果图片属于内部资料，就不要用匿名读，改用带签名的临时 URL。但要注意签名 URL 会过期，不适合写进长期文档。
• 地域选择：选靠近主要访问者的地域。如果你的设备端和用户都在国内，就别选远距离地域，跨地域访问延迟能差出两三倍。
• 存储类型：图片是低频访问但需要长期保存的资源，用标准存储还是低频存储要想清楚。低频存储单价便宜但取回有额外费用，文档图片访问量不大的话低频存储更划算。

这里有个参数计算值得展开。假设你有一个项目，图片 500 张，平均每张 400KB，总容量 200MB。如果放在标准存储，月成本按每 GB 几毛钱算，大概是零点几元；换成低频存储能再降一半左右。这点钱不值得纠结，真正贵的是流量。假设你的文档每天有 300 次访问，每次平均拉 5 张图，每张 400KB，日流量就是 300×5×0.4MB = 600MB，一个月约 18GB。这就是为什么必须挂 CDN：CDN 的回源比例通常能压到 5% 以下，流量成本能降一个数量级，同时访问延迟也明显改善。

2.2 上传工具链与命名规范

上传这件事，手动在控制台点"上传"按钮只能应付前二十张图，之后就必须要自动化。我用的是命令行工具加图床客户端的组合：

• 命令行工具：对象存储服务商一般都会提供 CLI 工具，支持cp、sync之类的命令，适合批量上传和脚本集成。
• 图床客户端：像 PicGo 这类工具可以配置自定义存储，复制到剪贴板后一个快捷键就上传并自动拿到 Markdown 链接，适合写文档时的即时插图。
• 自建上传接口：如果团队多人协作，可以写一个简单的上传服务，统一做压缩、改名、加水印，避免每个人上传的图片格式五花八门。

命名规范比上传工具更重要，我踩过坑之后定了一套规则，你直接抄：

{项目代号}/{文档模块}/{yyyyMM}/{内容描述}-{8位随机}.{ext} 示例： motor-ctrl/hardware/202406/clock-tree-a3f92b1c.png motor-ctrl/firmware/202407/ota-flow-77de10aa.webp

这样做有四个好处。第一，目录结构清晰，按项目和月份归档，找图和清理旧图都方便。第二，内容描述让人工可读，出问题时不用翻聊天记录猜这是哪张图。第三，随机后缀保证唯一性，避免同名覆盖——这个坑我踩过，两个不同的截图都叫screenshot.png，后传的把先传的覆盖了，另一篇文档里的图直接变成了不相干的内容。第四，扩展名明确，方便后面做压缩格式的批量替换。

注意：图片一旦发布外链，就不要再修改原文件内容，只在需要更新时上传新链接。原因很直接——CDN 和浏览器都可能缓存旧版本，你改了内容但 URL 没变，用户看到的可能是几小时前的旧图，排查起来非常费劲。要更新就换新链接，旧链接留着不删。

2.3 HTTPS 证书、CDN 缓存与跨域配置

HTTPS 是硬性要求，不是可选项。原因有两个：一是现在的主流文档平台、内部 Wiki 系统都跑在 HTTPS 下，嵌入 HTTP 图片会被浏览器当成混合内容直接拦截；二是嵌入式设备端做 TLS 校验时，证书链必须完整，否则mbedTLS这类轻量库会握手失败。

证书方面，用自动签发的免费证书就够了，关键是配置自动续期并加监控。我见过不止一次因为证书过期导致整个文档图片全挂的情况，而且这种故障特别隐蔽——你打开文档发现图没了，第一反应是图床出问题，查半天才发现是证书三天前过期了。

CDN 的缓存策略要注意区分。图片这类静态资源，缓存时间可以设长，我一般用 30 天，配合文件名带哈希的命名方式，更新时天然是新 URL，不存在缓存不一致问题。但如果你的 URL 是可变的（比如latest.png这种），缓存就要设短，或者发布后主动刷新。

跨域配置只在特定场景下才需要。如果你的文档是纯 Markdown 渲染成<img>标签，不涉及 Canvas 读取像素，那不需要 CORS。但如果你要在网页里用 JavaScript 做图片处理、或者用 Canvas 绘制后再导出，就必须在存储桶上配置Access-Control-Allow-Origin。这个配置很容易漏，症状是图片能显示但脚本读取时报错，排查起来比较绕。

3. 外链测试的核心项与实操脚本

3.1 可用性巡检：状态码、响应时间与内容类型

外链测试最基础的一项就是批量探活。但只检查返回 200 是不够的，我总结了五个必须校验的字段：

1. HTTP 状态码：200 是正常，403 通常是防盗链或权限问题，404 是文件不存在或被删，302 要警惕是不是被重定向到了错误页面。
2. Content-Type：必须是image/png、image/jpeg、image/webp之类的图片类型。如果返回text/html，说明这个 URL 实际返回的是错误页面，虽然状态码可能是 200。
3. Content-Length：和本地文件大小对比，差异超过 5% 就要留意，可能是被服务端二次压缩或截断了。
4. 响应时间：首字节时间超过 1 秒就要标记，超过 3 秒基本可以判定异常。
5. TLS 证书有效期：剩余天数少于 30 天就该告警。

下面这个 Python 脚本是我实际在用的巡检工具，用requests加线程池，一次性检查几百个链接：

import csv import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed TIMEOUT = 10 HEADERS = {"User-Agent": "Mozilla/5.0 (link-checker)"} def check_one(item): url = item["url"] expect_size = int(item.get("size", 0)) start = time.time() try: # 用 stream 模式，只读响应头不下载完整图片，省流量 resp = requests.get(url, headers=HEADERS, timeout=TIMEOUT, stream=True, allow_redirects=True) elapsed = time.time() - start ctype = resp.headers.get("Content-Type", "") clen = int(resp.headers.get("Content-Length", 0)) result = { "url": url, "status": resp.status_code, "ctype": ctype, "length": clen, "elapsed": round(elapsed, 3), "verdict": "OK", } if resp.status_code != 200: result["verdict"] = f"HTTP_{resp.status_code}" elif not ctype.startswith("image/"): result["verdict"] = "NOT_IMAGE" elif expect_size and abs(clen - expect_size) / expect_size > 0.05: result["verdict"] = "SIZE_MISMATCH" elif elapsed > 3: result["verdict"] = "SLOW" return result except requests.exceptions.Timeout: return {"url": url, "verdict": "TIMEOUT", "elapsed": TIMEOUT} except Exception as e: return {"url": url, "verdict": "ERROR", "msg": str(e)} def main(): with open("links.csv", newline="", encoding="utf-8") as f: items = list(csv.DictReader(f)) bad = [] with ThreadPoolExecutor(max_workers=16) as pool: futures = {pool.submit(check_one, it): it for it in items} for fut in as_completed(futures): r = fut.result() if r["verdict"] != "OK": bad.append(r) print(f"[BAD] {r}") print(f"总计 {len(items)} 条，异常 {len(bad)} 条") if __name__ == "__main__": main()

links.csv里的格式是这样，用 Excel 也能直接编辑：

url,size https://img.example.com/motor-ctrl/hardware/202406/clock-tree-a3f92b1c.png,412356 https://img.example.com/motor-ctrl/firmware/202407/ota-flow-77de10aa.webp,98321

这里有个实操细节：一定要用stream=True。我第一版脚本没用这个参数，跑一次巡检把几百张图全下了一遍，流量费直接多出十几块，而且速度慢得离谱。stream=True时requests只读到响应头就返回，不碰响应体，速度快十倍不止。

3.2 防盗链与跨域测试怎么造条件

防盗链是外链失效的头号杀手。原理很简单：对象存储或 CDN 会检查请求头里的Referer，不在白名单里的就返回 403。这个机制对网页图片有用，但它会误伤很多场景，比如本地 Markdown 编辑器打开时 Referer 是空、命令行工具下载时没有 Referer、某些内部系统会带上自己的域名。

测试方法就是手动构造不同的 Referer 去请求，看返回码：

URL="https://img.example.com/motor-ctrl/hardware/202406/clock-tree-a3f92b1c.png" # 1. 不带 Referer（本地编辑器、命令行场景） curl -s -o /dev/null -w "no-referer: %{http_code}\n" "$URL" # 2. 带正常站点 Referer curl -s -o /dev/null -w "normal: %{http_code}\n" \ -H "Referer: https://docs.example.com/page.html" "$URL" # 3. 带未授权 Referer curl -s -o /dev/null -w "foreign: %{http_code}\n" \ -H "Referer: https://other-site.com/" "$URL" # 4. 看完整的响应头，确认 Content-Type 和缓存策略 curl -sI -H "Referer: https://docs.example.com/" "$URL"

判读标准很明确：如果你希望本地编辑器和命令行工具也能访问（绝大多数文档场景都需要），那第 1 项必须返回 200。如果返回了 403，说明存储桶配置了"必须带白名单 Referer"，这时候要么把空 Referer 加进白名单，要么干脆关掉防盗链，改用带签名的 URL 或其他访问控制手段。

提示：防盗链白名单里加"空 Referer"这个操作，不同服务商的配置入口不一样，有的在 CDN 的"防盗链"设置里能直接勾选"允许空 Referer"，有的需要在 Referer 白名单里加一条空规则。配置完一定要用上面的命令复测一遍，我第一次配的时候以为加了个*就完事，结果空 Referer 还是被拦，后来才发现*是通配符但不匹配空值。

跨域测试相对简单，核心是看响应头里有没有Access-Control-Allow-Origin：

curl -sI -H "Origin: https://docs.example.com" "$URL" | grep -i "access-control"

如果没有任何输出，说明没配 CORS。纯<img>标签展示不受影响，但一旦你的页面用 JS 去fetch这张图或者画到 Canvas 上就会失败。

3.3 弱网与并发下的表现测试

文档场景下，图片加载慢一点无所谓；但如果你打算让嵌入式设备端也去拉这些图（后面第 4 节会展开），弱网测试就绕不过去了。我常用的模拟手段是给curl限速，模拟 4G 弱网或者现场调试时的低速链路：

# 限制下载速度 200KB/s，模拟弱网环境，统计各阶段耗时 curl -s -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} \ tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} size:%{size_download}\n" \ --limit-rate 200k "$URL"

这个命令输出的六个时间点非常有价值。time_namelookup是 DNS 解析耗时，正常应该在几十毫秒内，超过 200ms 说明 DNS 有问题；time_connect是 TCP 建连耗时；time_appconnect是 TLS 握手完成时间，减去 connect 就是握手耗时；time_starttransfer是首字节时间，也就是 TTFB；time_total是总耗时。

我实测过一张 400KB 的图在 200KB/s 限速下，总耗时约 2.3 秒，其中 TLS 握手占了近 400ms。这个数据直接影响后面的超时参数设计——如果设备端把超时设成 2 秒，这张图在弱网下必然失败。

并发测试用ab或wrk都能做，目的是摸清存储桶或 CDN 的限流阈值：

# 100 个并发请求，总共 1000 次 ab -n 1000 -c 100 -k "$URL"

重点关注两个指标：非 2xx 响应的比例，以及 95 分位响应时间。如果出现大量 429 或 503，说明触发了限流，这时候要去看服务商的流量控制配置，或者降低并发。正常 CDN 抗几百并发毫无压力，限流通常出现在回源阶段——也就是缓存没命中，请求穿透到存储桶时。

这里补一个容量估算的例子。假设你的产品有 2000 台设备在现场运行，每台设备每次启动会拉取 10 张配置图片，每张平均 300KB。如果某天你推送了一次固件更新导致全部设备同时重启，那么瞬时流量就是 2000×10×0.3MB = 6GB。如果 CDN 命中率 90%，回源流量是 600MB；如果 CDN 缓存因为 URL 变更全部失效，回源流量就是 6GB，源站很可能被打爆。所以图片 URL 变更要分批发布，或者提前预热 CDN 缓存。

3.4 图片一致性校验：防止被偷偷二次压缩

这一项很多人不做，但它的重要性被严重低估。有些 CDN 或存储服务会开启"图片处理"功能，自动把 PNG 转成 WebP、或者根据 User-Agent 返回不同格式、或者做有损压缩。对 PC 浏览器来说这是优化，对嵌入式设备来说可能是灾难——你的解码库只支持 PNG，服务端却返回了 WebP，设备端直接解析失败。

校验方法就是下载回来算哈希，和本地原文件对比：

# 本地文件哈希 md5sum local-image.png # 远端文件的哈希（注意要绕过缓存，加随机参数） curl -s "$URL?t=$(date +%s)" | md5sum

两个哈希完全一致，说明文件原样返回；不一致就有问题。如果确实需要服务端做转换，那就必须保证设备端支持转换后的格式，并且转换参数固定（比如统一转 WebP 质量 85%），不能是服务端随机决定的。

注意：校验哈希时务必带上一个随机查询参数，否则命中的是 CDN 缓存，你验证的其实是缓存里的旧版本。我踩过这个坑，原文件已经更新但 CDN 还在回旧图，curl拿到的哈希一直是旧文件的，白折腾了半小时才发现要加随机参数。

4. 嵌入式设备端加载外链图片的专项测试

4.1 设备端加载链路与资源预算

把图床外链用在嵌入式设备上，典型场景是 HMI 界面通过网络加载图标、开机动画帧、产品示意图，或者远程更新界面素材而不重新烧固件。这个链路比 PC 端长得多，每一环都可能出问题：

设备上电 -> 网络就绪 -> DNS 解析域名 -> TCP 建连 -> TLS 握手（校验证书） -> 发送 HTTP GET -> 等待首字节 -> 分片接收数据 -> 写入缓冲区 -> 解码（PNG/JPEG/WebP）-> 渲染到帧缓冲 -> 释放内存

资源预算是设备端最硬的约束，必须先算清楚。假设你用一块 800×480 的 RGB565 屏幕：

• 帧缓冲：800 × 480 × 2 字节 =768KB，这是单纯显示一张全屏图的最低开销。
• 解码缓冲：PNG 解码需要额外的行缓冲和中间状态，lodepng这类库通常还需要 100KB 到 1MB 不等的临时空间，取决于是否启用流式解码。
• HTTP 接收缓冲：如果一次性接收整张图再解码，需要和图片体积等量的缓冲。一张 400KB 的图就需要 400KB 内存。
• 总计：一张全屏图最坏情况下可能要 1.5MB 到 2MB 的 RAM。

如果你用的是只有 512KB SRAM 的 MCU，那整图方案根本不成立，必须改成流式解码 + 分块渲染：HTTP 分片接收，边收边喂给解码器，只保留解码所需的行缓冲。这种方案对图片格式有限制（通常是逐行编码的 PNG 或 baseline JPEG），而且要处理好网络中断时的重试。

带宽预算同样要算。假设设备通过 4G 联网，实测下行 300KB/s，一张 300KB 的图传输需要 1 秒，加上 DNS 解析 200ms、TCP 建连 300ms、TLS 握手 500ms，总耗时约 2 秒。如果设备端超时设成 3 秒，余量只有 1 秒，网络稍有波动就会失败。我的经验是把超时设成理论耗时的 3 倍以上，也就是 6 到 10 秒，同时加 2 到 3 次重试，重试间隔用指数退避。

4.2 LVGL 与裸机 HTTP 客户端加载实测要点

在 LVGL 环境里加载网络图片，我踩过几个比较典型的坑，这里逐个说。

第一个坑是 TLS 证书链。设备端用mbedTLS做 HTTPS 请求时，需要预置 CA 根证书。如果你的图床域名用的是免费证书，签发机构的根证书可能不在设备端的证书列表里，握手直接失败。解决办法是把完整的证书链（服务器证书 + 中间证书 + 根证书）都打进固件，或者用mbedTLS的证书包功能一次性打包。要命的是根证书有有效期，几年后过期了设备就连不上了，所以固件里要有证书更新机制，或者干脆用支持远程更新的证书包。

第二个坑是内存碎片。设备长时间运行、反复加载图片，malloc出来的缓冲如果大小不一，很容易把堆打碎。我的做法是预分配一块固定大小的接收缓冲区，所有图片走同一个缓冲，用完就复用，尽量避免动态分配。

第三个坑是重定向。有些 CDN 会把请求 302 重定向到另一个节点，如果你的 HTTP 客户端不处理 302，就会拿到一个空响应或者一段 HTML。测试时一定要构造这种情况验证，或者直接要求 CDN 关闭重定向。

第四个坑是响应头解析。嵌入式 HTTP 客户端很多是手写的，很容易在处理Content-Length、Transfer-Encoding: chunked、Connection: keep-alive这些头时出问题。特别是 chunked 编码，如果客户端不支持，会一直读到连接关闭才结束，看起来像卡死。测试时可以让服务端强制返回 chunked 编码来验证。

实测的一套快速验证流程是这样：先在 PC 上用curl确认链接和格式没问题，再用设备的网络模块裸发一次 GET 请求（先不解码），把响应头和收到的字节数打印出来，确认数据完整，最后才接入解码和渲染。分层验证能大幅缩短排查时间——如果连数据都没收全就去查解码，基本是白费功夫。

5. 自动化巡检与失效告警体系

5.1 定时任务、断链检测与告警

人工跑巡检脚本只能解决一时的问题，长期方案是把第 3 节的脚本挂到定时任务上。我的做法是用cron每天凌晨跑一次，把异常结果落到日志文件，同时推送告警：

# 每天凌晨 3 点执行巡检，结果写入日志 0 3 * * * cd /opt/linkcheck && /usr/bin/python3 check.py \ >> /var/log/linkcheck/$(date +\%Y\%m\%d).log 2>&1

告警通道方面，办公协作工具一般都支持自定义机器人 webhook，一段 POST 请求就能把异常列表推送到群里：

import requests, json def notify(webhook, bad_list): if not bad_list: return lines = [f"- {r['url']} => {r['verdict']}" for r in bad_list[:20]] text = "图床外链巡检发现异常：\n" + "\n".join(lines) payload = {"msgtype": "text", "text": {"content": text}} requests.post(webhook, json=payload, timeout=5)

告警设计上有两个经验值得说。第一是分级：403/404 这类确定性故障立即告警，响应时间偏慢这类"疑似问题"只记日志不打扰人，否则天天被误报骚扰，最后你会把告警静音，真出事反而不知道。第二是去重：同一个链接连续三天异常，只在第一天告警，否则每天刷屏。

5.2 链接迁移与批量替换策略

图床域名变更、存储桶迁移是迟早会遇到的事。这时候几百篇文档里的链接要批量替换，手动改是不现实的。我的做法是提前在文档里统一使用一个可替换的前缀，比如都写成https://img.example.com/开头，迁移时用一条命令搞定：

# 批量替换指定目录下所有 md 文件里的域名前缀 grep -rl "img.example.com" --include="*.md" ./docs \ | xargs sed -i 's|img\.example\.com|img-new.example.com|g'

替换完必须重新跑一遍巡检，因为新域名下的路径可能和旧的不完全一致——这一点我吃过亏，旧图床文件名做了小写转换，新图床保留原样，导致部分含大写的路径全部 404。

提示：迁移时保留旧域名一段时间，配置 301 重定向指向新域名。这样即使有遗漏的链接，也不会立刻断掉，给排查留出缓冲期。重定向配置至少保留半年。

6. 常见问题排查实录与避坑清单

6.1 故障速查表

下面这张表是我这几年积累的故障速查，基本覆盖了 90% 的外链问题：

6.2 几个我踩过的坑和对应的经验

坑一：图片压缩格式选错。早期我把所有截图都存成 PNG，一张 1920×1080 的界面截图能有 3MB。后来统一转成 WebP（质量 85%），体积降到 200KB 以下，压缩比超过 90%。但要注意，如果你的嵌入式设备端不支持 WebP 解码，就只能用 JPEG 或者继续用 PNG 加pngquant压缩。格式选择必须设备端和 PC 端一起考虑，不能只顾网页好看。

坑二：忽略 DNS 解析时间。有一次设备端加载图片特别慢，我一直以为是带宽问题，后来用curl -w一测才发现time_namelookup高达 600ms。原因是设备端配的 DNS 服务器响应慢。换成响应更快的 DNS 之后，整体加载时间直接少了三分之一。排查网络问题一定要分段看耗时，不要凭感觉。

坑三：文件名里的特殊字符。我在 URL 里用过中文文件名和空格，在浏览器里能正常显示（浏览器会自动编码），但在命令行工具和嵌入式 HTTP 客户端里就变成了乱码或者请求失败。文件名只用小写字母、数字、连字符，不用中文、空格和大小写混用，这个规则一旦坚持下来，能省掉大量莫名其妙的 bug。

坑四：以为挂了 CDN 就万事大吉。CDN 的缓存命中率不是 100%，冷门图片经常要回源。如果源站的带宽或 QPS 限制很低，回源请求一多就会被限流。所以测试要覆盖回源场景，不能只测缓存命中。方法是请求一个从未被访问过的 URL，看响应时间是否明显变长。

坑五：忘了给外链加上备份。不管图床多稳定，都要有一份本地或另一存储的备份。我的做法是本地保留一份完整的images/目录，并且定期用工具把远端和本地做一次校验对比。真遇到图床服务出问题，至少能在半小时内把图片全部重新上传到备用存储，改一遍链接就恢复了。

最后分享一个我在实际项目里养成的习惯：每完成一批文档，就把所有外链导出成一份清单文件放进仓库，跟着代码一起提交。这份清单不需要很大，只是 URL 列表加对应的本地文件哈希。它有三个作用——新同事能快速知道所有图片资源在哪，迁移时能有据可查，出故障时能立刻判断到底是哪几张图出了问题，而不是在几百篇文档里一页页翻。