团队代码复用标准是围绕场景、约束和协作习惯建立的轻量明确约定：基础数组用Set去重，对象数组须显式声明去重字段，复杂结构需业务侧自定义判等；工具函数须带类型标注、无隐式转换、有单元测试；PR中须拦截Set误用于对象数组、性能敏感路径低效写法及重复实现。
团队代码复用标准不是靠“写一个通用函数”就完事的，而是围绕场景、约束和协作习惯建立的一套轻量但明确的约定。重点不在方法数量，而在谁在什么情况下该用哪一种。
明确去重方法的适用边界
团队应统一规定三类场景对应的标准实现：
-
基础类型数组（数字/字符串/布尔/null/undefined/NaN）：强制使用
[...new Set(arr)]或Array.from(new Set(arr))。不接受 for 循环、indexOf、filter + indexOf 等低效写法。 -
对象数组（如
[{id:1}, {id:1}]）：禁止直接用 Set；必须显式声明去重依据，例如按id字段：arr.filter((item, i, a) => a.findIndex(v => v.id === item.id) === i)，或封装为uniqueBy(arr, 'id')工具函数。 -
深层结构或含函数/日期/正则等复杂值：不提供通用方案，要求业务侧自行定义判等逻辑（如用
JSON.stringify仅作临时兜底，需加注释说明局限）。
工具函数必须带类型与行为契约
若封装成公共工具（如 utils/array.js 中的 unique()），必须满足：
- 函数签名清晰标注输入输出类型，例如：
function unique<t>(arr: T[]): T[]</t>（TS）或 JSDoc 注明 “仅支持原始类型”； - 函数内部不做隐式类型转换（如不自动把
'1'和1视为相同）； - 附带单元测试用例，覆盖
NaN、0与false、null与undefined等易混淆组合。
代码审查中必须拦截的典型反模式
以下写法应在 PR 阶段被直接拒绝：
立即学习“Java免费学习笔记（深入）”；
- 用
Set处理对象数组却未加注释说明“此处对象引用唯一，非内容去重”； - 在性能敏感路径（如列表渲染、高频事件回调）中使用
filter + indexOf或双层循环； - 多个文件各自实现几乎相同的去重逻辑（如三个地方都写了
arr.filter((x,i)=>arr.indexOf(x)===i)），应引导提取到共享模块。
文档与新人引导要具体可执行
在团队 Wiki 的「前端规范 → 数组处理」章节中，不写“推荐使用 Set”，而写：
✅ 正确示例：const ids = [...new Set(response.data.map(item => item.userId))];❌ 错误示例：
const ids = response.data.map(item => item.userId).filter((v,i,a) => a.indexOf(v) === i);⚠️ 注意：如果
response.data 是对象数组且需按 userId 去重，请改用 uniqueBy(response.data, 'userId')（见 utils/array） 
