前后端数据序列化：从数组到字符串的旅程（附优化指南）

🌐 前后端数据序列化：从数组到字符串的旅程（附优化指南）

📜 背景：为何需要序列化？

在前后端分离架构中，复杂数据类型（如数组、对象）的传输常需序列化为字符串。本文以 productPhotos 字段为例，解析其完整生命周期：前端数组 → 序列化为字符串 → 后端存储为字符串。

---

mysql数据库中显示的格式
["fake-strategy/Rfu4RYYxDWGI9192e57fda02253decb709d99243b267_323610.jpeg","fake-strategy/WechatIMG364_710060.jpg"]
["fake-strategy/ImHmny77At2n9192e57fda02253decb709d99243b267_629653.jpeg","fake-strategy/WechatIMG364_777011.jpg"]

safari浏览器解析预览中显示的格式
"productPhotos": "[\"fake-strategy/Rfu4RYYxDWGI9192e57fda02253decb709d99243b267_323610.jpeg\",\"fake-strategy/WechatIMG364_710060.jpg\"]",
"purchaseRecords": "[\"fake-strategy/ImHmny77At2n9192e57fda02253decb709d99243b267_629653.jpeg\",\"fake-strategy/WechatIMG364_777011.jpg\"]",

🔄 当前实现流程（Mermaid 流程图）

---

⚖️ 当前方案分析

✅ 优点

1. 兼容性高
   🛢️ 所有关系型数据库（MySQL/PostgreSQL）均支持字符串存储
2. 开发简单
   🛠️ 避免创建关联表（如 product_photos 表）
3. 协议友好
   🌍 适配 HTTP 文本传输特性

❌ 缺点

问题类型	具体表现
性能损耗	频繁的 JSON.stringify/parse 增加 CPU 开销
查询困难	无法直接使用 SQL 查询图片属性（如按类型过滤）
维护风险	字符串格式错误导致解析失败（如缺少闭合引号）

---

🚀 优化方案思维导图（Mermaid Mindmap）

---

🛠️ 具体优化建议

方案一：直接使用原生 JSON 类型（以 PostgreSQL 为例）

-- 建表语句
CREATE TABLE products (id SERIAL PRIMARY KEY,photos JSONB NOT NULL
);-- 查询示例（查找包含 "main" 类型图片的记录）
SELECT * FROM products 
WHERE photos @> '[{"type": "main"}]';

方案二：元数据扩展

// 前端数据结构升级
interface ProductPhoto {url: string;type: 'main' | 'detail'; // 明确分类size?: number; // 文件大小（KB）uploadedAt: string; // ISO 时间戳
}// 提交时自动补充元数据
form.productPhotos = photos.map(photo => ({...photo,size: calculateFileSize(photo.file),uploadedAt: new Date().toISOString()
}));

方案三：客户端压缩（减少传输量）

<template><w-form-multiple-image :before-upload="compressImage"/>
</template><script>
import imageCompression from 'browser-image-compression';export default {methods: {async compressImage(file) {const options = {maxSizeMB: 1,maxWidthOrHeight: 1920,useWebWorker: true};return await imageCompression(file, options);}}
}
</script>

---

📌 总结

方案	适用场景	技术栈要求
当前方案	简单业务快速迭代	无特殊要求
原生 JSON 类型	高频查询/更新场景	PostgreSQL/MongoDB
客户端压缩	移动端流量敏感	需兼容 Web Workers

核心原则：根据业务阶段选择合适方案，避免过度设计！ 🎯