产品图片命名规范：别再发出那张旧图

上周那份报价，是用 2024 年的一张图片算出来的。客户按老款底座报了价，你发的是新款底座，接下来吵的不是工艺也不是价格，而是"到底哪张图才算数"。那张图的文件名，没告诉你俩任何一个答案。

产品图片命名规范，是一套固定、可被机器排序的命名格式，统一套在每个 SKU 的每一张图片上：不用打开文件，就能看出是哪个产品、哪个视图、第几版、哪天定稿；两个国家的人看同一批文件，也能一眼分出哪张是现行的。它不是强迫症式的整洁，它是你手头唯一低成本的证据——证明你批准的图，就是发出去的那张。

下面给出这套格式、真正承载信息的几个字段、文件名会在哪三个地方出问题，以及在不搞坏线上 listing 的前提下改造老图片库的顺序。

产品图片命名规范要解决的三件事

文件名有三个用途，多数供应商只按第一个来设计。

第三件事最费钱。拿不出获批文件的那一刻，客户说"这不是我们谈好的表面处理"，你几乎没有还手余地——哪怕处理得完全对。一个文件夹里"最新的那张"叫 (1)，这文件夹里没人能还原三月份到底发过什么。

五个字段，顺序固定

顺序比用词更重要：字段顺序一旦固定，纯字母排序就能得到可用的列表——同一 SKU 聚在一起，视图顺序固定，最新版本排在最后。

完整文件名是 SM-CB-1200_front_v03_2026-10-29.jpg——38 个字符，没有空格，没有需要转义的符号，在访达、资源管理器和网盘里都排得对。

SKU 放第一位，是因为客户的归档系统就按 SKU 建：那是采购单上的号。用产品名开头（比如 walnut-cabinet-1200mm-2.jpg），一旦同一个柜子做两种饰面，这个 SKU 的图就被打散到字母表各处。日期单独成字段，是因为版本说明"改了什么"，日期说明"客户什么时候能看到"；半年后客户来追责，能定案的是日期。

**记住这一句：**文件名不是标签，它是你批准过哪张图的唯一记录。

视图字段：闭集，不是形容词

视图一旦允许自由填写，规范就会死掉。把清单收敛到你真正会发的那几个值。

九个值基本覆盖 B2B 询盘。真要加第十个，先写进清单再用——只存在于某个人脑子里的约定，不叫约定。

dim 和 scale 最常被混用。dim 是量出来的标注图，scale 是带参照物的场景图。客户在算能不能过门，要的是 scale；客户在填报价单，要的是 dim。两张挤在一个名字下，转发出去的多半是错的那张。

版本号和日期不是一回事

版本回答"是不是同一款产品"，日期回答"从哪天起这份文件生效"。只要重拍一次而产品没变——背景更干净、饰面打光更好——两者就会分开，而这恰好是最容易出争议的情形：产品看着略有不同，客户就以为规格动了。

三条规则，写在团队看得见的地方：

• 只有产品、饰面或尺寸变化，版本才进位。 只改打光的重拍，版本不动、日期更新；两张都要留，就在末尾加 -res：SM-CB-1200_front_v03_2026-10-29-res.jpg。
• 获批文件的名字永不改变。 出新图时，旧图移进 archive/，名字原样保留——不改名成 old，更不覆盖。
• archive 里的文件不外发。 客户要上一季的图，就带着它自己的日期改名后发出去，文件仍然能自我说明。

最后这条正是版本字段的意义：同名文件被覆盖后无法自证，你证明不了发过什么，客户也证明不了收到什么。同一套纪律也出现在产品规格变更清单里——版本必须同时走到每一份文件上。

一个实例：一次询盘，六个文件

客户问 1200 mm 胡桃木柜、900 mm 版本，以及平板包装的外箱。回复就是六个文件，靠名字就能选出来：

两件事从表里直接掉出来，40 张乱放的图给不了：两个型号的拍摄日期差了两周，日期让这件事可见——客户问 900 mm 有没有换新铰链时正好用得上；每个文件都写明自己的用途，工程师、货代、展厅经理各取所需，不用再发一封邮件。

这和单 SKU 规格页是同一个原则：一个 SKU、一页、一件事。产品图片命名规范就是把它用在页面背后的文件上，也正是家具 listing 标注案例能复制到整本目录、而不只是一次性演示的原因。它还是跨平台复用产品图片的前提——不必猜这张资产属于哪个渠道。

文件名会出问题的三个地方

这三条都不是审美意见，每一条都会悄悄把图库劈成两半。

1. 路径长度：Windows 的 260 个字符

Windows 的完整路径上限是 260 个字符，单个文件名 255 个。在测试文件夹里好好的文件，到了客户下载目录里再套三层就变成"打不开"。冗长的描述性文件名加深层文件夹，就是这么把一个好文件变成"找不到文件"的。

把文件名控制在 60 个字符内、路径控制在 150 个字符内，问题就不会发生。这也解释了为什么不要把产品标题塞进文件名：它长、和 SKU 重复，而且是被截掉的第一个。

2. 保留字符、空格和大小写

Windows 禁用 < > : " / \ | ? *，也保留 CON、PRN、AUX、NUL 这类设备名。放进 URL 之后，其余符号会被改写：空格变成 %20，# 把链接截断在锚点处，? 把后面全变成查询串。文件在你电脑上能开，发到微信里就是 404。

大小写是更安静的那个坑：Windows 和 macOS 默认不区分大小写，SM-CB-1200_front.jpg 和 sm-cb-1200_front.jpg 在 Mac 上是同一个文件，在 Linux 服务器上却是两个对象。两张都传，你说不清 listing 显示的是哪张。

只用小写字母、数字、连字符和点。连字符能穿过任何客户端、网关和 URL 解析器，下划线和空格不行。

3. 重音符号与 Unicode 归一化

两个字符看着一样，字节却可能不同。"é" 可以是预组合的单字符，也可以是 e 加组合重音；macOS 比较文件名时不区分归一化形式，Linux 服务器和对象存储通常区分。把文件夹从 Mac 拷到服务器，一个带重音的名字可能变成两个文件，或者更糟——一个覆盖另一个。

如果目录里有重音字符或中文，文件名保持 ASCII，本地语言名放进产品数据里。这样同一份文件在链条上每台机器都能用。

还有第四个坑，跟名字本身无关：CDN 是按 URL 取文件的，把同名文件替换掉之后，缓存还会继续发旧图。文件名里带版本，这个问题免费解决——新版本就是新 URL，没有陈旧内容需要清，URL 本身还兼作审计线索。

已经存在的图库怎么改

把产品图片命名规范套到存量库上，是所有人都会往后拖的那一步。别从四千个文件开始，从"还在线上"的文件开始。

1. 从报价系统导出 SKU 清单，不要从图片文件夹导——文件夹缺在售 SKU，还躺着一堆已停产的。
2. 标出近 12 个月进过 listing、目录或报价的 SKU，通常是库里的 10% 到 20%。
3. 只改这些，从最新的获批文件改起，旧版本按原名移进 archive/。
4. 当天同步更新引用：改过名就是新 URL，还指向旧路径的地方会直接报错，而不是悄悄错着。
5. 长尾部分等要用到时再说。200 个在售 SKU 上真正执行的规则，胜过一条谁都没落实的完美规范。

一次性全量改名的失败模式很典型：周五改了个文件夹，周末 listing 白屏，这套规范就被定性为"搞坏网站的那件事"。按"已经发布的内容"排优先级，迁移花一小时，不是一周。

发送前检查清单

• 文件名以 SKU 开头，SKU 与纸箱、报价单印的完全一致
• 视图值取自闭集，不是凭记忆敲的
• 版本号只因为产品、饰面或尺寸变化才进位
• 日期是定稿日，不是拍摄日
• 只有连字符，全小写，无空格、无重音、无 # 和 ?
• 文件名 60 个字符以内，套三层文件夹后仍能打开
• 旧版本在 archive/ 里，原名完整保留
• 线上 listing、目录页、已发出的报价都指向现行文件
• dim 和 scale 两张没有对调

FAQ

产品图片该怎么命名比较好？

用 SKU_视图_版本_日期.扩展名，全小写，字段顺序固定。它承载同事和客户都需要的四个事实——哪个产品、哪个视图、第几版、何时获批——而且在任何文件浏览器里都能正确排序，不依赖数据库。

文件名里 SKU 放前面还是产品名放前面？

一定是 SKU。它出现在采购单、纸箱和发票上，是客户归档系统的钥匙。产品名会随市场、饰面和语言变化，按产品名排序，一旦多出一个饰面，同一个 SKU 就会被拆到字母表两头。

产品图片文件名要避开哪些字符？

避开空格、#、?、%、&、<、>、:、"、/、\、|、*，以及重音和非拉丁字符。Windows 直接禁用其中几个，空格在 URL 里变成 %20，# 会悄悄截断链接。连字符是最安全的分隔符。

同一产品的不同视图该怎么命名？

每个视图固定一个闭集里的词——front、main、dim、detail、scale、pack、assembled、packed、break——永远不要为一次临时需求造新词。正是这个清单让字母排序表现得像联系表：同一个 SKU 的所有视图聚在一起，顺序永远一致。

图片换了，版本号该放在哪？

紧跟视图字段、放在日期之前；只有产品、饰面或尺寸变化才进位，打光变好不进位。只改了曝光的重拍，版本不动、换新日期。文件本身必须变、版本又不能动时，在末尾加 -res 这类后缀，让两份文件永远可区分。

如果版本是因为尺寸变更才跳的，光改名救不了：旧图上的数字已经和产品对不上了。这时流程才显出价值——量一次，把数值锁到照片上产品的真实边缘，按各渠道要求的尺寸重新导出，新版本来自同一个数据源，而不是靠眼睛重画。生成的场景图可以让画面好看；dim 文件上只能放量出来的数。

来源与依据

• Microsoft Learn — Naming Files, Paths, and Namespaces（保留字符、保留设备名、260 字符路径上限）
• RFC 3339 — Date and Time on the Internet: Timestamps（源自 ISO 8601 的 YYYY-MM-DD 日期格式）
• GS1 — GTIN 商品标识代码
• Unicode Standard Annex #15 — Unicode 归一化形式（预组合字符与组合字符）
• RFC 3986 — URI：保留字符与百分号编码
• AWS — 在 CloudFront 中使文件失效（缓存对象以请求路径为键）