在JavaScript开发中，我们经常遇到这样的需求：给定一个对象数组，需要根据某些条件修改其中部分对象的属性，同时不能改变原始数组，而是要返回一个全新的数组。这种操作在状态管理、函数式编程以及前端框架的数据流中十分常见。如果处理不当，就可能导致引用共享、视图不更新或者难以追踪的数据变更。
为什么不能直接修改原数组
很多初学者会习惯用for循环遍历数组，然后直接修改每个元素的属性，例如arr[i].status = 'done'。这种做法在纯脚本环境里似乎没问题，但在现代前端开发中，数组往往作为状态源存在。直接修改原数组意味着新旧状态指向同一个引用，像React这样的库在做浅比较时就无法发现变化，从而导致组件不重新渲染。
另外，从函数式编程的角度看，纯函数要求相同的输入永远返回相同的输出，且不产生副作用。直接修改入参数组就是一种典型的副作用。为了让函数可测试、可组合，我们必须保证每次更新都产生一个新的数组对象，而原数组保持不动。这也是为什么不可变更新策略逐渐成为主流。
使用map实现条件更新并返回新数组
最通用也最清晰的方式是使用数组的map方法。map会遍历每一个元素，并根据回调函数的返回值构建一个新数组。我们可以在回调里判断条件，符合条件的返回一个修改后的新对象，不符合的则返回原对象（或浅拷贝后的对象）。
下面的例子展示了一个任务列表，我们要把id为2的任务标记为完成，其他任务保持不变：
const tasks = [
{ id: 1, name: '写文章', done: false },
{ id: 2, name: '改代码', done: false },
{ id: 3, name: '发版本', done: false }
];
const updatedTasks = tasks.map(function(item) {
if (item.id === 2) {
// 使用扩展运算符创建新对象，避免修改原对象
return { ...item, done: true };
}
// 不满足条件时返回原对象引用，也可写成 {...item}
return item;
});
console.log(updatedTasks);
// 输出: [{id:1,...}, {id:2, done:true}, {id:3,...}]
console.log(tasks[1].done); // false，原数组未被修改
这种写法的好处是语义明确：map本身就是“转换每个元素”的意思，读者一眼就能看出这是在生成新数组。扩展运算符...保证了只更新我们需要的字段，其余字段自动保留，且生成的是新对象引用。
如果更新逻辑更复杂，比如要根据多个条件设置不同字段，可以把判断逻辑抽成一个小函数，保持map回调简洁：
function patchTask(task) {
if (task.id === 2) {
return { ...task, done: true, updatedAt: Date.now() };
}
if (task.priority === 'high') {
return { ...task, highlighted: true };
}
return task;
}
const newList = tasks.map(patchTask);
使用三元表达式简化单条件更新
当条件非常单一时，在map里写完整的if语句显得有点啰嗦。我们可以用三元表达式让代码更紧凑，同时依然返回新数组：
const newList = tasks.map(function(item) {
return item.id === 2
? { ...item, done: true }
: item;
});
三元表达式适合“非此即彼”的更新场景。它的可读性和map天然契合，不会引入额外变量。不过要注意，如果条件分支超过两个，或者每个分支的修改字段差异很大，还是建议用if或抽离函数，否则一行代码会难以维护。
从性能角度看，三元和if在map中几乎没有差别，因为瓶颈通常在对象创建和数组分配上，而非条件判断本身。因此选择哪种纯粹看团队代码风格约定。
对比filter与concat的拆分写法
有些人会先用filter找出要更新的项，修改后再用concat或扩展运算符合并回去。这种写法如下：
const toUpdate = tasks.filter(function(t) { return t.id === 2; });
const others = tasks.filter(function(t) { return t.id !== 2; });
const updated = toUpdate.map(function(t) { return { ...t, done: true }; });
const result = others.concat(updated);
这种方案的问题在于遍历了三次数组：两次filter加一次map，而且还要处理顺序问题——concat默认把更新的项放到了末尾，若原顺序重要还得再排序。相比之下，单次map只遍历一次，且顺序天然保持一致。
当然，如果更新条件非常复杂、且待更新项极少而数组极大，先filter出少量目标再做处理在极端场景下可能节省一点对象创建开销，但绝大多数业务数组长度有限，map方案在简洁性和正确性上更优。
需要深更新的情况如何处理
前面例子都是浅层对象，如果对象里还有嵌套结构，比如user.profile.age，浅拷贝会保留内层引用。此时要手动做深层拷贝或使用专门工具：
const users = [
{ id: 1, profile: { name: 'Tom', age: 20 } },
{ id: 2, profile: { name: 'Lu', age: 25 } }
];
const newUsers = users.map(function(u) {
if (u.id === 2) {
// 手动深一层拷贝
return {
...u,
profile: { ...u.profile, age: 26 }
};
}
return u;
});
如果嵌套层级不固定，可以引入JSON.parse(JSON.stringify(obj))做快速深拷贝（注意它无法处理函数和循环引用），或者使用第三方不可变库如Immutable.js、Immer等。Immer允许你写“看似修改”的代码，实际自动生成不可变新树，对复杂对象数组更新非常友好。
不过引入依赖前先评估项目规模。多数中后台系统的数组结构并不深，手动展开一两层就够用了，避免为了少量深更新把整个项目改成依赖重型库。
总结不同策略的选用建议
对于大多数基于条件更新对象数组并返回新数组的场景，优先使用map加扩展运算符。它语法直观、一次遍历、保持顺序、易于测试。单条件用三元，多条件抽函数。只有当数组极大且更新项极少时才考虑filter拆分，并注意顺序还原。
牢记不可变原则：永远返回新数组和新对象，不碰原引用。这样无论是接入前端框架还是做单元测试，数据流向都清晰可控，也省去很多“为什么页面没刷新”的调试时间。
JavaScript对象数组immutable_update修改时间：2026-08-01 11:54:32