产品图片命名规范：改一次尺寸，旧图还在三个渠道上跑

产品图片命名规范听起来像强迫症才关心的事，直到你撞上这种情况：柜体进深从 550 改成 600，图重拍了、重标了、发给运营了，三个月后客户投诉——1688 详情页里还挂着 550 那一版。因为那张图叫「主图2-最终版-改.jpg」，没有任何人能一眼看出它是旧的。

文件名是产品图身上唯一一段会跟着文件走的信息。你后台那套整齐的目录结构，一旦图被下载、被塞进邮件附件、被丢进网盘链接、被拖进平台的选图框，就一个字都不剩了。剩下的只有文件名。

产品图片命名规范到底在解决什么问题

先给一句能单独拎出去用的定义：产品图片命名规范是一套固定的字段顺序和写法约定，让任何人只看文件名，就能判断这张图属于哪个型号、哪个视角、哪个版本、能用在哪个渠道——不用打开图，也不用问人。

它能解决的和不能解决的，值得先摆清楚：

最后一行故意留在这儿。命名规范是索引，不是内容，别指望它解决标注准确性——文末会说这件事该怎么解。

一套能用五年的文件名结构

结构就四段：{型号}_{视角或用途}_{版本}_{日期}.{扩展名}，落到实处长这样——SF-2103_dim_v3_20260822.jpg。

型号字段直接沿用你已有的那套编码，不要为图片另造一套——两套编码并存，等于把对账工作量翻倍。这套编码本身怎么定，产品型号编码规则怎么定那篇讲了尺寸变更时最容易连环出错的几处。

视角代号表：全公司只能有一份

这张表要和你的拍摄清单对齐——一个 SKU 该拍哪几张、每张对应哪个代号，最好在开拍前就定死，产品图拍摄清单可以直接拿来当底表改。

dim 这一格值得单独拎出来说：在外贸场景里，它是买家和你自己回头找得最频繁的一张，也是产品规格书里复用率最高的一张。给它一个固定代号，比什么都值。

版本号：只增不改，旧版不删不覆盖

「改一次尺寸，旧图还在三个渠道上跑」的根因不是没备份，是新旧两张图长得几乎一样、名字也差不多。三条规则：

• 版本号只增不改。v3 出来了，v2 不改名、不覆盖，移进同级的 _archive/。
• 一次尺寸变更 = 所有受影响视角同时 +1，哪怕某几张画面根本没变。
• 版本号对齐的是"这批图描述的是哪一版产品"，不是"这张图被 PS 过几次"。

第二条反直觉，但它是整套规则里最值钱的一条。只给改动过的那两张升版，你就永远无法回答"当前在售的这一版，对应的是哪一整套图"——而这恰恰是全渠道换图时唯一需要回答的问题。

三类真会出事的细节

这九个字符，Windows 上根本建不出文件

微软官方文档列出的 Windows 保留字符是：< > : " / \ | ? *，此外 ASCII 0 到 31 也不允许。还有一组更隐蔽的：CON、PRN、AUX、NUL、COM1–COM9、LPT1–LPT9 是保留设备名，连 NUL.txt 都建不出来。文档里还明确写着：文件或目录名不要以空格或英文句点结尾——底层文件系统可能允许，但 Windows 的界面不支持。

外贸场景里最常踩的是三个：斜杠（写规格时顺手写成 600/800）、冒号（写时间或比例）、以及文件名尾部那个手滑打出来的空格。

再加一条不属于"禁止"但强烈建议避免的：中文和空格。中文文件名压包发给国外客户、对方解压后变成乱码，是外贸里最高频的一类小事故——不同系统对压缩包内文件名的编码处理并不统一，而这件事你在自己电脑上永远复现不出来。空格则会让 URL 里冒出一堆 %20，也会让任何批处理脚本变得难写。发出去的图，文件名只用 ASCII。

路径长度：260 个字符不是传说

微软文档写明，在 Windows 10 1607 之前，路径最大长度 MAX_PATH 为 260 个字符；之后的版本需要改注册表或组策略才能解除这个限制。听着很宽裕，但真实场景是这样叠出来的：网盘同步目录 + 年份 + 客户名 + 项目名 + 型号 + 一个很长的中文文件名。你这边一切正常，客户那边一解压就报错。

给文件名本身定个上限：60 个字符以内，目录层级不超过四层。

日期只有一种写法不会排错

20260822 这种年在最前、月次之、日在后的顺序（也就是 ISO 8601 的年-月-日顺序），按文件名排序就等于按时间排序。22-08-2026、8.22、Aug22 都做不到——文件管理器是按字符串逐位比较的，年份不在最前面，排出来就是乱的。

这不是审美偏好，是排序结果对不对的问题。

连字符还是下划线：这件事有明确答案

如果这些图最终会进入你的独立站、会被 Google 图片索引，那么词与词之间用连字符，不用下划线。Google 官方文档的原文是 "We recommend using hyphens (-) instead of underscores (_) to separate words in your URLs, as it helps users and search engines better identify concepts in the URL."——建议用连字符而不是下划线来分隔 URL 中的单词，这样用户和搜索引擎都更容易识别其中的概念。

Google 对图片文件名本身也给了明确建议：文件名要 "short, but descriptive"（简短但有描述性），官方给的对比例子是 my-new-black-kitten.jpg 好过 IMG00023.JPG，并点名 image1.jpg、pic.gif、1.jpg 这类通用名要避免。

于是有个取舍要讲清楚：

• 图会以原文件名进入网站 URL → 全部用连字符：sf-2103-dim-v3-20260822.jpg，让搜索引擎能把每个词都切开。
• 图只在内部和客户之间流转，上平台前会被重命名 → 字段之间用下划线、字段内部用连字符：SF-2103_detail-hinge_v3_20260822.jpg，一眼能看出这是四个字段、第二个字段由两个词组成。

两种都对，但不要让两套规则同时存在于一个团队里。选一套，写进文档，写进和摄影外包的合作说明里。

命名解决"发得对"，解决不了"数对不对"

把命名理顺，你就不会再发错版本。但它管不到那张 _dim_ 图上写的 600 到底是不是量出来的 600。

这两件事的分工是这样的：命名规范让你知道该换哪些图，而你换不换得动，取决于重出一套规格图有多贵。如果每次尺寸变更都意味着让美工在修图软件里重新拉一遍箭头、重新对一遍数，那再好的命名规范也只会变成一份没人执行的文档——因为执行它的成本你付不起。

真正让这套流程转得动的，是标注本身可复用：标注线贴着产品在图上的真实边缘落点取数（贴边取数），每个数对应一个实测值而不是凭印象填的数字，更不是 AI 出图工具生成的那种"看着合理"的数字；改型号时只改数不重画，再按各平台要求的规格图尺寸一键导出。这样 v4 那一批图当天就能全渠道换完。

一组按这个思路标出来的家具图长什么样，可以看家具尺寸标注案例。

落地清单：今天能做完的十件事

• 定一张视角代号表，全公司只留一份，写进新人手册
• 型号字段直接沿用 ERP / 报价单里的型号，不另造一套
• 版本号统一用 v + 数字，只增不改
• 每个型号目录下建一个 _archive/，旧版本移进去，不删不覆盖
• 日期统一 8 位、年在最前
• 文件名只用 ASCII：英文、数字、连字符、下划线；不用中文、不用空格
• 全盘搜一遍历史文件名里的 < > : " / \ | ? * 和尾部空格
• 文件名控制在 60 字符以内，目录不超过四层
• 尺寸变更时，受影响的所有视角同批升版，哪怕画面没变
• 先挑三个主推型号按新规则重命名跑通，再全量推

倒数第二条最容易被跳过，也是最容易在半年后咬你一口的那条。

常见问题

产品图片命名规范应该包含哪些字段？

四个就够：型号、视角/用途、版本、日期。再多就没人愿意遵守了。像"拍摄人""客户名""平台名"这类信息不要进文件名——它们属于目录结构或者表格，塞进文件名只会把长度撑爆，还会因为同一张图要发三个平台而被迫复制三份。

产品图片文件名能不能用中文？

内部自己用可以，发出去的不要用。中文文件名在跨系统的压缩包传输里出乱码是常态，而且你在自己电脑上测不出来。凡是会发给客户、会上传到海外平台、会进独立站的图，文件名只用 ASCII 字符。

图片文件名不能用哪些字符？

按微软官方文档，Windows 上禁止的是 < > : " / \ | ? * 以及 ASCII 0–31，另外 CON、PRN、AUX、NUL、COM1–COM9、LPT1–LPT9 是保留设备名不能用作文件名，文件名也不能以空格或英文句点结尾。实际操作里再自我加严一条：只允许英文字母、数字、连字符、下划线和一个小数点，其余一律不用。

产品图版本管理需要专门的工具吗？

绝大多数供应商不需要。一套文件名规则 + 一个共享网盘 + 一个 _archive/ 目录，能稳稳撑到几千张图的量级。真正需要上工具的信号只有两个：同时改图的人超过三个，或者你需要记录"某张图在什么时候被谁发给了哪个客户"。在那之前上系统，只会多出一层没人维护的元数据。

图片素材怎么归档才不会越堆越乱？

按型号建目录，不要按日期建目录。日期已经在文件名里了，再用日期当目录，你会永远想不起某个型号的图散落在哪几个月。推荐三层：产品线 / 型号 /，型号目录下直接放当前版本，旧版进同级 _archive/。第三层不要再按视角分子目录——视角已经在文件名里，再建一层只会把路径撑长（还记得那 260 个字符吗）。

来源与依据

• Google 图片 SEO 最佳实践 — Google Search Central（建议使用简短但具描述性的文件名，官方对比例：my-new-black-kitten.jpg 优于 IMG00023.JPG；应避免 image1.jpg、pic.gif、1.jpg 这类通用文件名；同时说明 alt 文本应描述图片内容、不得堆砌关键词）
• URL 结构最佳实践 — Google Search Central（原文："We recommend using hyphens (-) instead of underscores (_) to separate words in your URLs, as it helps users and search engines better identify concepts in the URL."；并建议 URL 中使用可读单词而非长串 ID）
• Naming Files, Paths, and Namespaces — Microsoft Learn（Windows 保留字符 < > : " / \ | ? * 与 ASCII 0–31；保留设备名 CON / PRN / AUX / NUL / COM1–COM9 / LPT1–LPT9；Windows 10 1607 之前 MAX_PATH 为 260 个字符，之后需改注册表或组策略解除；文件或目录名不得以空格或句点结尾。文档更新日期 2024-08-28）