concat不修改原数组，返回新数组需显式赋值；仅浅拷贝，嵌套数组引用不变；展开运算符语义更清晰、类型推导更优，但对undefined更敏感。

concat 处理多个 URL 数组时，别直接传字符串

直接 concat 字符串会导致它被当作单个元素拆成字符数组，比如 ['/a.js'].concat('/b.css') 得到的是 ['/a.js', '/', 'b', '.', 'c', 's', 's']。这在拼接资源路径时几乎总是错的。

正确做法是确保所有参数都是数组，或用展开语法统一处理：

• 多个数组：用 urls1.concat(urls2, urls3)
• 混有单个 URL：写成 urls1.concat([urlString]) 或更推荐 [...urls1, ...urls2, urlString]
• 动态数量（如来自配置对象）：先 Object.values(config).flat() 再 concat，避免嵌套过深

静态资源路径拼接要注意前导斜杠和重复分隔符

concat 本身不处理路径语义，只是合并数组。如果原始数组里有的路径带 /static/js/ 前缀、有的是相对路径如 lib/react.min.js，直接拼完还得统一 normalize。

• 建议在 concat 后用 map 清洗：比如 url => url.startsWith('/') ? url : '/' + url
• 避免双重 //：检查是否已有协议或根路径，https://cdn.com/a.js 和 /b.css 不该被强行加前缀
• 构建时若用 Webpack/Vite，更推荐用 new URL(path, import.meta.url) 动态解析，而非纯字符串拼接

IE11 下 concat 的兼容性陷阱

虽然 Array.prototype.concat 本身 IE6 就支持，但如果你用到了 flat()、扩展运算符或箭头函数来预处理数组，整个链式调用就会在 IE11 报错。

• 纯老浏览器环境，用传统 for 循环手动 push 更稳：const all = []; urls1.forEach(u => all.push(u)); urls2.forEach(u => all.push(u))
• 如果必须用 concat，确保输入全是数组，且不依赖 ES2015+ 语法
• Babel 编译时注意 concat 不会被 polyfill，但 flat 会——别让 arr.flat().concat(...) 这种写法漏过编译检查

性能上，concat 比展开运算符稍快，但差异可忽略

对几千个 URL 以下的静态资源列表，arr1.concat(arr2, arr3) 和 [...arr1, ...arr2, ...arr3] 实测差异在微秒级。真正影响性能的是后续的去重、排序或 DOM 插入逻辑。

• 如果需去重，别在 concat 后立刻用 filter((v, i, a) => a.indexOf(v) === i)，改用 Set：[...new Set(allUrls)]
• 如果 URL 列表来自 JSON 配置，考虑服务端直接合并好再下发，省去客户端拼接开销
• 注意 Chrome DevTools 的“堆快照”里，大量短字符串拼接后未释放，可能比 concat 本身更值得优化

实际项目里最常出问题的，不是 concat 用得对不对，而是路径来源混杂（CDN 地址、public 目录相对路径、构建后 hash 文件名）又没做归一化处理。多花十秒写个 normalizeUrl 工具函数，比反复调试 404 要省事得多。