商品列表和详情页突然出现大量破图，直接查看 pub/media/catalog/product 又能找到原图。此时不要急着重新上传全部图片。Magento 前台请求的通常是经过尺寸、主题角色和哈希目录处理后的缓存图片，404 可能发生在 URL 生成、缓存派生、Web 服务器路由或 CDN 任一层。

先比较数据库路径、原图和请求 URL

商品媒体属性通常保存相对路径，例如 /a/b/image.jpg。页面可能请求 media/catalog/product/cache/... 下的派生文件。记录一个失败 SKU、数据库 value、服务器原图路径和浏览器请求 URL，确认是所有尺寸都失败，还是只有某个 image role。

SELECT cpev.entity_id, cpev.value
FROM catalog_product_entity_varchar cpev
JOIN eav_attribute ea ON ea.attribute_id = cpev.attribute_id
WHERE ea.attribute_code IN ('image','small_image','thumbnail')
  AND cpev.entity_id = 123;

不同 Magento 版本的实体键结构可能不同，查询前先确认表结构。数据库值为 no_selection 与文件 404 也不是同一问题。

检查媒体 Base URL 和商店作用域

多商店或 CDN 环境中，Secure/Unsecure Media Base URL 可能在网站、商店视图被覆盖。HTML 生成了旧域名、错误协议或重复 media 路径时，原图存在也无法访问。使用后台配置或 CLI 查看各 scope 的生效值，不要只检查 Default Config。

图片缓存需要 Web 用户能够生成

首次请求某个尺寸时，Magento 可能读取原图并生成缓存。Web 用户对 pub/media/catalog/product/cache 没有写权限、PHP 缺少图像库、源文件损坏或内存不足，都会让派生失败。查看 Magento、PHP 和 Web 服务器日志，确认请求是 Magento 返回 404，还是 Nginx 在进入 PHP 前直接拒绝。

清理目录前先判断影响范围。后台的 Flush Catalog Images Cache 会删除派生图，随后流量会重新生成；在商品量大或高峰期执行会造成明显 CPU 与 I/O 峰值。可以通过官方图片 resize 命令预生成，再逐步切换。

Nginx、CDN 与多节点经常造成“有时能打开”

如果刷新后图片时好时坏，检查请求是否落到不同 Web 节点。共享 media 未挂载、文件同步延迟或某节点权限不同，会产生随机 404。CDN 还可能长期缓存第一次的 404，即使源站后来已经生成文件。

Web 规则应允许真实媒体文件直接返回，并让需要动态生成或占位图的路径按 Magento 推荐配置处理。不要写一个把所有 media 404 都重定向到首页的规则，这会把错误状态变成 200，影响缓存和搜索引擎诊断。

文件名大小写和迁移后的路径也值得检查

从大小写不敏感系统迁移到 Linux 后，Image.JPG 与 image.jpg 是不同文件。数据库路径、文件名和 CDN URL 必须完全一致。含空格、非标准字符的旧文件在不同编码或同步工具中也可能被改名。

修复后选择原先失败的商品，在列表、详情、购物车和邮件中检查不同 image role；再清除一个精确 CDN URL，确认新请求返回正确 MIME、200 状态和合理缓存头。只有原图与派生图的生成链路都稳定，才不需要再次人工补图。