JavaScript 语言中有了 for 循环语句，为何还要有 forEach、map、reduce 等这些高级的语法，仅仅是为了代码简洁吗？但是代码执行效率可能会有所下降吧（未证实过，只是猜测。。）？

简洁还不够吗

执行效率的下降基本可以忽略不计，代码的简洁和可读性都大幅提高

函数式编程必备 forEach map reduce

这些不是语法，只是封装起来更好用而已

你说的这些都是 function 吧，并不是语法。。。

谈下我的看法
用 for 迭代的话，需要事先声明多个临时变量，并且这些临时变量是在比逻辑代码层级更高的 block scope 中
引入了 forEach/map/reduce 之后，可以以更 functional 的方式来编写代码

这些方法都有自己的适用场景



表述有误，确实不能称为语法，是实例方法

每个方法都挺有用的

就是语法糖
js 不光有语法糖
还有语法糖的语法糖....

如果没有这些方法，你也会自己封装一个的

建议看一下 SICP

连语法都不是的东西，也成“语法糖”了
大家各种语言都别用标准库了

其实，这些语法糖，是 js 补上了缺的作业罢了。
很多脚本语言，这些语法都是相通的

没有的时候嫌弃 JS 是残缺的语言，有了又嫌弃 JS 太复杂？

这不是语法，这只是方法。

我给你讲，这些语法糖超甜的说。

学一点 SICP，终身受益。

forEach 不保证顺序执行的

作为函数式爱好者，我已经 1 年多没用过 for 循环了，除了一次写堆排序。

执行效率是引擎该考虑的事情，没多少项目需要从这几行代码上考虑效率问题

刚看了下。。。说错了，forEach 是顺序执行的

我理解的执行效率，是代码运行所需要的时间。之于 for 循环或 forEach、map、reduce 的效率，个人认为应比较的是循环的性能，说白了就是看谁先执行完呗。所以，我在提问中的意思是：对于处理某一个数组，用 for 可能会比这些数组的实例方法要快些吧？




这些不应该是封装的实现吗？

沙子能烧成砖头，沙子和砖头都能用来盖房，你盖房会用沙子还是砖头？

为了让你一边喝 java(咖啡)一遍码代码

我还是只用 for，因为用 node，需要 await

c++语言中有了 for 循环语句，为何还要有 range based for、std::for_each、std::reduce 等这些高级的语法

写起来比较方便，多次的 mutation 很好 chain。
如果效率对你的应用特别重要，还是考虑不要用 js 比较好。

That ’ s why I love Golang.

JS 一開始想假裝自己是 Java
JDK1.4(含)以前沒有 forEach, 因此 JS 也沒有
後來 JS 認清自己的本質, 打造了 forEach, map, reduce 等裝備靠攏函數式語言.

直接 for 循环更快，毕竟 map，reduce 组合相当于又跑了几次循环，但是用这点速度换取可读性和简洁性明显更划算

语言本身就是人写的，主要是给人看，其次给机器读


await 也可以不用 for
```
const delay = (ms) => new Promise(resolve => setTimeout(() => resolve(), ms))
const arr = [1, ,2, 3]
;(async () => {
await arr.reduce(async (promise, s) => {
await promise
await delay(1000 * s)
console.log('delay', s, Date.now())
}, Promise.resolve())
})()
```

没看懂你什么意思，我原本意思是用 forEach 没法在里面 await，也没法等待整个循环结束。


指的是这个吗? 中循环导致执行先后不能确定，中可以按照 for 遍历的顺序去执行？
let arr = [1, 2, 3, 4, 5]
let delay = count => {
return new Promise((resolve, reject) => {
setTimeout(() => {
console.log(count)
resolve('ok')
}, count * 1000 * Math.random())
})
}
;(async () => {
// 1
arr.forEach(async (item) => {
await delay(item)
})
// 2
// for (let index = 0; index < arr.length; index++) {
// await delay(arr[index])
// }
})()

大概就是这个意思吧。确实不用 for 也可以解决，但是比较麻烦。然后你的似乎也没法等待全部完成，外面还要再嵌套一个 promise all。反正就是哎呀……麻烦……

这些你都能自己写函数工具然话封装 只是这些默认给你封装好了 直接拿来用 不喜欢的话可以不用 但别人用的话你会看不懂 所以多学无害 如果你真研究透了他是怎么封装的 还会激发你的创造力自己封装造轮子

https://jsperf.com/multiple-recurssion-methods-compare/1

函数式因为要构建新的 stack 和作用域 所以会更慢，不过很多时候写起来就是舒服