校服溯源码：一款一码背后的四次推翻

校服这个行业有个奇怪的现象：每个家长都想知道孩子身上这件衣服从哪来，但没人真的去查。 因为查不到——标签上印的那串执行标准号，普通人看不懂也不会去搜。

溯源码要解决的就是这最后一步。

第一个决定：一款一码，不是一件一码

最初的想法很自然：每件校服一个唯一码，扫出来就是这一件的完整档案。听起来更严谨，但算一下成本就崩了：

• 一个年级 500 人，每人 2 套，一个学校就是 1000 个码
• 工厂要逐件贴标、逐件录入
• 关键是——同一批次的衣服，面料和质检报告完全一样

也就是说，99% 的录入工作量，换来的是 1% 的信息增量。

最后改成「一款一码」：同一个款式、同一个批次，共用一个码。信息量没少，录入量少了三个数量级。

唯一性不是目的，可信才是。而可信来自「信息对得上」，不是来自「一物一码」。

第二个决定：价格必须隐藏

这一条纠结最久。展示价格对家长是好事，但对工厂是灾难——同一款校服，不同学校、不同年份的采购价可能差 30%。价格一公开，第二年的招标就没法谈了。

技术上我留了 purchaseUrl 字段，需要时跳到厂商自己的订购页。结构留好了，但默认不显示。

第三个决定：放弃自建后端

这是被时间逼的。自建后端要买服务器、要备案、要等审批，快的话两周，慢的话一个月。而我只是要验证「家长到底会不会扫这个码」。

最后选了腾讯云开发的体验版：5 个云函数 + 4 个集合，没有独立服务器，没有 ICP 备案的等待期。

这笔账很好算：先用两天验证方向，别用一个月验证决心。

第四个决定：谁来录入

厂商管理员只能编辑自己组织的数据。为此做了两层隔离：

// 云函数入口先校验归属，再执行写操作
if (style.orgId !== ctx.orgId) {
  throw new Error('FORBIDDEN');
}

简单，但足够。这个系统里最大的风险不是被黑客攻破，而是 A 厂不小心改到 B 厂的数据。

现在卡在哪

前端重构。两个历史事故让我把工具函数全抽到了 common.js：

1. config.js 误传到了云存储根目录，导致全站图片 404
2. display.js 里一个函数被误删，语法检查居然通过了

第二件事最吓人——语法正确不等于逻辑完整。所以现在部署后必须跑一遍冒烟脚本，专门验证「关键函数是否存在」「关键图片是否可访问」。