在filter、map等数组方法的回调中写副作用是否合理？如何在团队规范？

不合理的核心原因 #

• 违背方法的设计语义：filter、map、reduce等方法的设计初衷就是基于纯函数生成新数组，回调应当仅返回计算结果，不修改任何外部状态。你给出的示例中将filter当作forEach使用，完全忽略了filter本身的返回值，还会额外生成一个无意义的和原数组长度一致的新数组，属于冗余的性能浪费。
• 可读性极差：开发者看到map/filter这类方法时，第一默认认知是“这里会生成新数组做数据转换”，不会预期存在外部副作用，后续维护代码的人很容易忽略隐藏的状态修改，埋下bug隐患。
• 可维护性低：散落在回调里的副作用会导致状态变化轨迹难以追溯，单元测试也需要额外关注外部变量的初始状态，大幅提升调试和测试成本。

团队规范落地方案 #

你之前推测lint工具无法检测是误区，这类问题完全可以通过规则+流程强约束：

• 首先明确团队编码规则：
  • 强制约定map/filter/reduce/some/every等带返回值的数组方法，回调必须为纯函数，禁止修改外部状态，也禁止忽略方法的返回值
  • 所有需要执行遍历副作用的场景，统一使用forEach或者for of循环，语义上明确告知其他开发者“此处存在遍历副作用”
• 其次用ESLint规则自动化校验：
  开启eslint-plugin-unicorn的no-array-method-return-value-ignored规则，直接拦截所有忽略map/filter等方法返回值的写法，你示例中的误用场景会直接触发报错。还可以额外配置规则限制上述数组方法的回调内不允许修改外部作用域变量，完全可以做到自动化检测，不需要人工逐一排查。
• 最后同步CR标准：
  把这类误用案例加入团队代码反面样例库，Code Review阶段只要出现这类写法直接打回修正，几次迭代后团队就能形成统一的编码习惯。

你给出的场景正确改写参考如下，无额外变量、无副作用，可读性更强：

const input = ['apple', 'boy', 'carrot'];
const output = input.map(w => w + '_suffix');
console.log(output); // ["apple_suffix", "boy_suffix", "carrot_suffix"]

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