阅读日记条目时会重新加载其远程图片吗？
通常，包含图片 URL 的日记条目会在应用程序或浏览器显示该条目时触发对该图片的请求。但这并不意味着每次都会从远程服务器下载该图片：有效的浏览器缓存可能会直接提供该图片，或者应用程序可能以其他方式处理图片。实际的第一步检查是该条目是指向网络 URL，还是指向随日记一同保存的图片。离线测试可以提供线索，但不能证明完全没有发生网络请求。
Markdown 中的图片链接代表什么？
在标准 Markdown 中，类似 `` 的图片语法通过 URL 来标识图片。[CommonMark 图片教程](https://commonmark.org/help/tutorial/08-images.html)明确指出了完整的网络 URL 是有效的图片目标地址。该语法本身并不代表图片已被复制到日记中或保存在本地。
当读者显示该条目时，软件可能会将该 URL 渲染为图片来源。在网页中，浏览器的 `<img>` 元素将图片嵌入文档中，其 `src` 属性用于标识要显示的资源，正如 [MDN 的 `<img>` 参考文档](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img)中所述。请求是否会到达远程服务器取决于缓存机制以及具体的应用程序、浏览器和网络路径。
浏览器每次阅读都会连接服务器吗？
并没有固定规则要求它每次都重新获取图片。浏览器在发出请求时会检查其 HTTP 缓存；如果存在匹配且有效的缓存响应，浏览器就可以使用该缓存，而无需为该图片连接源服务器。[web.dev 的 HTTP 缓存指南](https://web.dev/articles/http-cache)解释了新鲜度取决于响应的缓存信息，并且缓存的响应只要保持新鲜就可以被重复使用。
如果缓存的响应陈旧或需要验证，浏览器可能会连接服务器以检查存储的副本是否仍然有效。服务器可以确认该副本仍然有效，因此这种检查并不意味着重新下载了完整图片。[MDN 的 HTTP 缓存指南](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching)涵盖了新鲜度、验证以及不应缓存响应的情况。清除缓存、缓存过期、URL 变更、应用程序行为或缓存设置都可能改变后续阅读时发生的情况。
因此，审慎的答案是：显示远程图片可能会导致网络请求，但这并不一定意味着每次都会传输图片字节数据——也不意味着每次查看都会连接源服务器。缓存显示和全新获取在屏幕上的显示效果可能完全相同。
如何区分 URL 和已保存的附件？
检查图片引用或应用程序的附件信息（如果它公开了此类信息）。以 `https://` 或 `http://` 开头的目标地址指向远程网络地址。相对路径或特定于应用程序的附件名称则需要进一步检查。在网页中，相对路径可能会解析为另一个网络地址；它并不能证明文件存在于本地设备上。日记应用程序的存储和渲染规则决定了其目标地址。仅凭 Markdown 本身无法保证看似本地的引用具有可移植性，也无法保证文件存储在条目内部。
一个有用的区分点在于哪些内容必须保持可用：远程 URL 取决于远程资源持续存在且可访问；本地附件则取决于相关文件是否存在于应用程序预期的位置。为了妥善保存日记照片文件，请遵循应用程序自身的导出或备份说明。本文关注的重点是远程加载这一独立问题，而不是对任何特定应用程序存储格式的保证。
离线对比能说明什么？
若要进行无害检查，请在一次性测试条目中使用非敏感图片的 URL。在联网状态下查看该条目，然后断开设备网络并重新打开该条目。如果图片在离线状态下仍然显示，这表明存在可用的缓存副本或其他本地副本。如果没有显示，则应用程序此时可能需要远程资源——但仅凭该结果并不能准确确定具体原因。
这种对比无法证明正常的在线阅读不会发出网络请求。浏览器可能在断网前已发出请求、检查了 Service Worker 或应用缓存，或者显示了已保存在本地的图片。同样，离线时看到图片并不能证明条目的 Markdown 包含附件：应用程序完全可能只是缓存了远程响应。对于基于浏览器的日记，可以在联网时使用浏览器的网络开发者工具观察请求行为，并检查图片请求及其缓存状态；测试结果仅反映该测试环境下的情况，并不代表以后的每一次阅读或每台设备。
实用检查清单
对于必须以可预测方式显示的条目，请检查图片引用，如果它本应是本地图片，请确认对应的本地附件是否存在。如果是远程 URL，则其可用性和更新行为将取决于主机和缓存机制。使用在线网络面板观察请求，并将离线重新打开作为有限的对照参考。请将每个结果视为针对所测试应用程序、浏览器和缓存状态的依据——而不是通用的保证。