统一管理商品缩略图的核心是将其作为可版本化、可批量操作的静态资产，而非硬编码在HTML中；需强制命名规范（如product-1-thumb-200x150.jpg）、构建时注入路径、容器控制宽高比、独立CDN强缓存。
统一管理商品缩略图资源，核心不是“存到哪”，而是“怎么让缩略图不随 HTML 散落、不被重复生成、不因路径错乱集体失效”。必须把缩略图当作可版本化、可批量操作的静态资产来对待，而不是写死在 src 里的字符串。
缩略图文件命名必须带尺寸后缀
别用 product-1.jpg 这种模糊命名。浏览器和构建工具无法识别它是不是缩略图，CI/CD 流程也无从校验尺寸合规性。
- 强制采用
product-1-thumb-200x150.jpg、product-1-thumb-400x300.jpg格式：前缀一致（便于 glob 匹配），thumb-明确语义，尺寸数字紧贴，不含空格或特殊字符 - 避免用
@2x后缀替代尺寸——product-1-thumb@2x.jpg不告诉你实际像素，也无法用于srcset的w描述符 - 批量生成时用 ImageMagick 或 Sharp 脚本统一加后缀，例如：
convert input.jpg -resize 200x150 product-1-thumb-200x150.jpg
HTML 中只通过 data-src 引用原图，缩略图路径由 JS 或构建时注入
硬编码 src="images/thumb-200x150.jpg" 是最常见也是最危险的管理方式：一旦目录结构调整，所有页面都要 grep + 替换；本地开发和生产环境路径不一致时直接 404。
- 缩略图
img只保留语义化属性：data-product-id="123"、data-fullsrc="full-123.jpg"，真实src留空或设为占位图 - 在页面加载时，用 JS 扫描所有
[data-product-id]，拼出缩略图路径：const thumbSrc = `/assets/thumbs/${id}-thumb-200x150.jpg`，再赋值给img.src - 更稳妥的做法是构建阶段（如 Vite / Webpack）用插件自动替换
data-thumb-pattern属性，生成最终 HTML，彻底剥离运行时路径逻辑
用 CSS Grid + aspect-ratio 统一控制缩略图容器，而非 img 自身宽高
直接在 img 上写 width="200" height="150" 看似简单，但会导致：响应式断点失效、高 DPR 设备下模糊、无法统一裁剪策略、与父容器 max-width 冲突二次压缩。
立即学习“前端免费学习笔记（深入）”；
- 缩略图容器（如
<figure class="product-item">）设aspect-ratio: 4/3和overflow: hidden，确保不同尺寸缩略图视觉高度一致 -
img本身只设width: 100%; height: 100%; object-fit: cover;，靠容器约束比例，不依赖图片原始尺寸 - 这样后续想把所有缩略图从 4/3 改成 1/1，只需改一处 CSS，不用碰任何 HTML 或图片文件
所有缩略图请求必须走独立子域名或 CDN 路径，并启用强缓存
缩略图是典型的“高读低写”静态资源，但很多人把它和 HTML 放一起，导致每次部署都清掉全部缩略图缓存，用户重复下载。
- 把缩略图放在独立路径，例如
https://thumbs.example.com/v1/，和主站分离，便于单独配置缓存策略 - HTTP 响应头必须包含：
Cache-Control: public, max-age=31536000, immutable（一年不可变），配合文件名哈希或版本号（如v1/）确保更新可靠 - 本地开发时用
http://localhost:3000/thumbs/代理到真实缩略图服务，避免路径硬编码污染代码
最容易被忽略的是：缩略图不是“能显示就行”的临时产物，它是产品数据模型的一部分。当你发现要手动改 50 张图的尺寸、或某次上线后所有缩略图变模糊，问题从来不在 HTML 写法，而在你没把它们当成需要版本管理和自动化发布的资产。
