不能直接用于多维数组去重，仅在子数组全为可序列化标量且键序一致时“看似有效”，但易因键序、浮点精度、null/缺失字段、枚举、对象等导致误判或报错，性能差且不安全。
serialize + array_unique 能不能直接用于多维数组去重
能，但只在特定条件下“看起来靠谱”——它确实能去掉结构完全相同的子数组，前提是子数组里不包含 resource、closure、对象（未实现 Serializable 或 __serialize）等不可序列化内容。一旦遇到这些，serialize() 会返回 false，后续 unserialize() 失败，整个数组可能变成空或报错 unserialize(): Error at offset。
为什么 serialize 后比较容易出错
序列化字符串对键顺序、空格、浮点数精度、引用关系极度敏感。以下情况会导致本该相等的子数组被判定为不同：
-
['a'=>1,'b'=>2]和['b'=>2,'a'=>1]序列化结果不同，哪怕语义相同 -
0.1 + 0.2得到的浮点数在序列化后可能带尾部精度差异（如d:0.30000000000000004;vsd:0.3;） - 含
null字段和缺失字段的子数组（如['id'=>1]vs['id'=>1,'name'=>null]）序列化结果不同 - 使用了 PHP 8.1+ 的枚举（
BackedEnum）时，serialize()行为尚未完全标准化，部分版本会丢失类型信息
array_unique 配合 serialize 的性能到底多差
这不是“慢一点”的问题，而是数据量稍大就明显卡顿：
- 每次
serialize()都要遍历整个子数组并生成字符串，时间复杂度 O(n×m)，其中 m 是单个子数组平均嵌套深度 -
array_unique()对字符串数组仍用哈希比对，但字符串越长、越多，哈希冲突概率上升，实际接近 O(n²) - 1000 个长度为 10 的关联子数组，序列化后平均字符串长度超 300 字节，内存占用翻倍，GC 压力陡增
- 线上环境实测：5000 条商品属性数组（每个含 6 个字段），该方案耗时约 1.2s；而按
id或md5(implode('', $row))预计算哈希再去重，仅需 0.04s
真正安全又可控的替代方案长什么样
别迷信“一行解决”，根据你的去重目标选更稳的路：
- 若只需按某几个字段去重（如
['sku','color','size']），用foreach+md5(implode('|', [$v['sku'], $v['color'], $v['size']]))做临时键，O(n) 完成 - 若子数组结构固定且字段名一致，先
ksort()每个子数组再serialize()，可规避键序问题 - 含对象或资源？必须改用递归遍历 + 自定义比较逻辑，
serialize()直接出局 - PHP 8.2+ 可考虑
array_reduce()+array_key_exists()构建唯一索引，避免中间字符串膨胀
最常被忽略的一点：你根本不需要“完全一致”的去重。业务上往往只要某几个字段组合唯一就够了——这时候硬上 serialize 不是稳妥，是给自己埋雷。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
