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 要省事得多。 
