🌐 前后端數據序列化：從數組到字符串的旅程（附優化指南）
📜 背景：為何需要序列化？
在前后端分離架構中，復雜數據類型（如數組、對象）的傳輸常需序列化為字符串。本文以 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 流程圖）
?? 當前方案分析
? 優點
- 兼容性高
🛢? 所有關系型數據庫（MySQL/PostgreSQL）均支持字符串存儲 - 開發簡單
🛠? 避免創建關聯表（如product_photos表） - 協議友好
🌍 適配 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 |
核心原則：根據業務階段選擇合適方案，避免過度設計！ 🎯
＞)
