学js数组遍历应建立“意图—方法—边界”三层判断习惯：先明确业务意图（副作用/生成新数组/筛选/聚合/查找），再选对应方法，最后确认中断能力、返回值、稀疏数组等边界行为。
学JS数组遍历，关键不是背方法，而是建立“意图—方法—边界”三层判断习惯：看到一个遍历需求，先问自己要什么（纯执行？生成新数组？找某个值？中途退出？），再选匹配的方法，最后确认它的行为边界（能不能 break？返回啥？改不改原数组？）。
按业务意图分类掌握
别从语法开始记，从你每天写的代码场景倒推：
-
只做副作用操作（比如发请求、改DOM、打日志）→ 优先用
forEach，语义清晰；但一旦需要中途跳出（如找到就停），立刻换for或for...of -
要生成新数组（比如把 ID 列表转成对象映射）→ 用
map；要筛选数据（如只留有效订单）→ 用filter；要聚合计算（如求总金额）→ 用reduce -
要找某个元素或位置→
find返回值，findIndex返回索引，some/every返回布尔值并自带短路；它们比手写 for 循环更安全、更易读
重点搞清三类易错边界
很多 bug 不是写错了，是没看清方法的契约：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
-
中断能力：
forEach、map、filter内部不能用break或return false终止循环；想退出只能抛错（不推荐）或换for/for...of -
返回值：
forEach固定返回undefined，所以arr.forEach(...).map(...)会报错；而map和filter返回新数组，天然支持链式调用 -
稀疏数组和原型污染：
for...in会遍历非数字属性和继承方法，绝对不要用于数组；for和for...of只访问实际索引，更可靠
多维数组别硬套 for 嵌套
遇到嵌套结构（如菜单树、权限配置），先判断数据是否规则：
- 如果层级固定且较浅（如二维表格），用双层
for或for...of+entries()更直观 - 如果层级不固定或可能加深（如动态表单、地区树），直接上递归函数，核心逻辑就是“当前项是数组就继续遍历，否则处理”
- 如果只是想取所有叶子节点做统一处理，
flat(Infinity)配合forEach或map是最快捷的取巧方案
动手时带验证意识
每次写完遍历逻辑，快速过三关：
- 空数组会不会报错？（
map、forEach都能安全处理空数组） - 中间修改原数组（如
splice）会不会影响后续索引？（正向遍历时会漂移，倒序 orfilter更稳） - 异步操作里用
forEach循环发请求，闭包捕获的index或item对不对？（推荐用for...of或for，避免箭头函数闭包陷阱）
