卖刻字水杯、定制礼盒或者印图服装，最麻烦的往往是下单后的信息确认。
用户付款以后，再通过客服发送文字、图片和制作要求。客服把资料转给生产，生产发现图片模糊，又让客服回去找用户。订单虽然下了，制作却一直开始不了。
基于 Tigshop Java 商城，可以把定制信息收集放进购买流程，让资料跟着具体订单商品走。
一、定制内容要关联到购买明细
一笔订单可能买两个杯子，一个刻“生日快乐”，另一个刻名字。如果只在订单上放一个备注字段，很难分清每件商品对应哪份内容。
可以按购物项保存定制信息，提交订单时再生成订单明细快照。同一个 SKU、不同刻字内容，也不能被购物车自动合并成一行。
如果同一行购买多件、每件内容又不同，就需要继续按件记录。第一版也可以规定一份定制内容对应一个购物项，把使用方式说明白。
二、后台配置内容类型，后端统一校验
商品编辑页可以增加定制开关，再选择文字、图片或者固定选项等类型。文字配置最大长度，图片配置数量、格式和大小，固定选项则用于字体、位置等标准化要求。
提交时由后端重新校验。前端限制输入长度只是方便用户操作，不能代替服务端检查。文字长度还要明确计算口径，避免输入表情或者特殊字符后，显示和校验结果不一致。
Java 端可以建立独立的定制业务服务，负责校验、保存和读取。商品接口返回当前规则，订单保存成交时的内容。
三、上传成功，还得检查能不能生产
头像尺寸的小图也能上传，但放大印在衣服上可能完全看不清。除了文件格式和体积，还可以按商品要求检查图片像素，并提示用户查看预览。
上传内容建议保存在受控文件存储中，通过文件标识关联订单。生产人员下载时检查权限，避免客户照片通过公开链接长期暴露。
恶意文件、无法识别的图片和过期临时文件，也需要有对应处理。生产原图与前台预览图可以分别管理，防止压缩后的缩略图被误拿去制作。
四、定制加价要进入订单结算
增加刻字收十元、增加图片收二十元，这些费用需要由后端根据规则计算，并保存到订单明细。不能只在前端显示加价，提交后仍按普通商品价格结算。
优惠券是否抵扣定制费、退款时如何处理，也要形成明确规则。取消、退款和售后说明应结合具体商品及适用要求确认，再体现在页面和处理流程中。
如果制作前需要用户确认效果图，可以增加待确认、已确认、制作中等处理状态，与付款、发货状态分别管理。进入制作后是否还能修改，由后台按规则控制。
五、重点检查定制资料有没有串项
验收时用“同款商品两份不同刻字内容”走一遍下单、后台查看、生产导出和售后。再测试重复加入购物车、修改数量、图片失效和超长文字。
生产导出里要能对应订单明细、数量和定制资料。确认文字和图片没有串项，比把输入框做出来更接近这个功能真正的交付目标。
六、Java 示例：定制费用由服务端计算
请求只提交商品、数量、定制文字和上传文件标识，不接受客户端指定最终价格。服务端加载当前商品规则后计算附加费，下面的方法演示按件收费。
public BigDecimal customizationFee(BigDecimal unitFee, int quantity) {
if (unitFee == null || unitFee.signum() < 0 || quantity <= 0) {
throw new IllegalArgumentException(
"定制费或购买数量不合法");
}
return unitFee.multiply(BigDecimal.valueOf(quantity))
.setScale(2, RoundingMode.HALF_UP);
}
unitFee 从服务端规则读取。金额使用 BigDecimal，创建金额常量时用字符串或整数分值，避免通过 double 引入误差。结算预览和创建订单复用同一算价逻辑，最终成交时保存定制费快照。
{
"skuId": 10001,
"quantity": 1,
"customization": {
"text": "生日快乐",
"fileIds": [20001]
}
}
这个 JSON 是建议的请求结构，不是 Tigshop 已有接口定义。后端还要检查文件属于当前用户、审核状态符合要求，并保存不可变的成交资料。购物车区分不同定制内容时，可以生成标准化内容摘要，但合并前仍应核对实际内容，不能只依赖摘要。
