我们是否需要关注JS非原始值的可变性带来的意外修改问题？

核心结论 #

要不要做克隆没有绝对的标准答案，完全取决于你的函数语义和使用场景，但默认优先写无副作用的纯函数，不要为了可有可无的性能优化引入隐性bug。

示例代码的问题说明 #

你写的likePosts函数从命名来看，语义是「接收帖子数组，返回点赞后的新数组」，几乎所有调用这个函数的开发者的预期都是原传入的数组不会被修改。你这种暗地修改原对象的写法属于「隐性副作用」，如果后续有其他逻辑复用了originalPosts，直接就会出现预期外的bug，这种排查成本比那点克隆的性能开销高几十上百倍。

可以不克隆的场景 #

只有同时满足以下两个条件的时候，你才可以选择直接修改原对象，不做克隆：

• 你给函数加了明确的语义标识，比如命名为likePostsMutate，或者加注释明确说明「该函数会修改传入的原数组对象」，让调用方提前知情
• 你能100%确认后续所有业务逻辑都不会再用到传入的原数组，原数组在调用完这个函数之后就可以被回收

性能顾虑的实际情况 #

绝大多数普通业务场景下，浅克隆几十上百甚至上千个普通对象的性能损耗可以忽略不计，你随便一个普通接口请求的开销都比这个大得多。不要提前做无意义的性能优化，反而引入不稳定的风险。
只有当你真的遇到了大数据量（比如几万、几十万条对象）的场景，并且通过性能测试明确证明克隆操作确实成为了瓶颈的时候，再针对性改用可变修改的方案即可。

推荐的默认写法 #

如果没有特殊的性能需求，默认写无副作用的纯函数，浅克隆对象即可：

const likePosts = (posts) => posts.map((post) => ({
  ...post,
  isLiked: true
}));

这种写法完全不会修改原数组里的对象，调用方不需要额外担心副作用问题，代码可维护性高得多。

通用编码习惯参考 #

日常写代码默认都会做浅克隆保证函数无副作用，只有在明确需要优化性能的特殊场景才会改用可变修改的方案，同时一定会给对应函数加明确的命名和注释说明会修改入参，避免后续维护踩坑。

内容的提问来源于stack exchange，提问作者Raul