数据标准化应在后端还是客户端（前端、移动应用）实现？

这个问题没有绝对的标准答案，核心要围绕复用性、维护成本、逻辑复杂度这几个维度来决策，以下是通用场景的判断原则：

1. 优先后端处理的场景 #

• 多客户端复用或后续有扩展需求：如果Web、移动端、小程序等多个端都需要同一份标准化数据，或者以后可能新增客户端，后端统一处理能避免重复开发，保证各端数据逻辑一致。比如你例子里如果后续小程序也要展示"X-L"，后端改一次所有端就能同步生效，不用每个端都写一遍截取逻辑。
• 逻辑复杂或需频繁调整：如果处理涉及业务规则（比如权限过滤、多条件关联计算），或者产品需求可能经常变，后端处理更便于维护。比如以后移动端展示格式要改成"X(L)"，后端改一次就行，不用协调iOS、Android、前端团队同步更新。
• 数据语义需要结构化拆分：如果标准化是要从非结构化数据里提取业务语义（比如从product_name拆分品类、型号、尺码），后端拆分出独立字段（如category、model、size）比客户端硬截取更可靠——一旦后端字符串格式变化（比如从"Dress X - L"改成"Dress-X-L"），客户端的截取逻辑直接失效，后端结构化输出能避免这个问题。
• 大数据量或高消耗处理：批量数据格式化、复杂计算这类操作，后端服务器算力更强，能避免客户端（尤其是低配移动设备）出现性能卡顿。

2. 适合客户端处理的场景 #

• 单一客户端的轻量格式需求：只有某个端需要特殊格式，且处理逻辑简单（比如字符串截取、日期格式化、单位转换），同时后端改造成本极高（比如你提到的新增字段、额外编辑成本高），客户端处理更高效。
• 不涉及业务规则的展示层调整：纯粹是为了适配客户端UI的格式调整（比如移动端屏幕小，需要缩短文本），这类属于展示层逻辑，放在客户端更合理，不用侵入后端业务数据结构。

回到你的示例场景 #

你的情况里，后端新增字段成本高，移动端只是简单截取文本，且只有移动端需要这个短格式，客户端处理是合理的。但要注意两个点：

• 和后端约定product_name的格式稳定性，避免后续字符串格式变化导致客户端逻辑失效；
• 如果以后其他端也需要类似的短格式，还是要考虑迁移到后端统一处理，减少重复维护的成本。

内容的提问来源于stack exchange，提问作者thuleduy