Lodash对Map/Set支持有限且行为隐晦：默认不接受Map/Set，map/filter等函数仅取value或报错，类型检测在IE11/小程序中失准，API返回类型不稳定，无键值语义封装，环境差异易致线上失效。
识别三方库（如 Lodash）在处理现代 Map/Set 时的兼容性陷阱，关键不是看它“能不能用”，而是看它“怎么用”、用完“结果是否符合预期”。Lodash 对 Map 和 Set 的支持有限且隐含行为多，容易在类型推断、迭代逻辑和错误边界上埋坑。
不默认支持 Map/Set 的原生语义
Lodash 的 map、filter、find 等主函数，**默认只接受数组或普通对象**。虽然部分版本（如 v4.17.21+）通过内部 getTag 检测尝试兼容 Map/Set，但实际行为与原生迭代器不一致：
-
_.map(new Map([['a', 1], ['b', 2]]), v => v * 10)返回的是[10, 20]（仅取 value），而非[['a', 10], ['b', 20]]或键值对结构 -
_.filter(new Set([1, 2, 3]), n => n > 1)可能返回空数组或报错，取决于 Lodash 版本——v4 未实现Set迭代适配，v5 已移除对Set的隐式支持 - 它不会调用
Map.prototype.entries()或Set.prototype.values()，而是依赖Symbol.iterator的存在与否做降级处理，而早期 Lodash 构建环境（如小程序、旧版 Webpack）可能屏蔽该 symbol
类型检测绕过导致静默失败
Lodash 使用 Object.prototype.toString.call + 兼容补丁判断数据类型，但在某些运行时中会失准：
- IE11 或微信小程序基础库低版本中，
Map和Set的toString返回[object Object]，Lodash 就把它当普通对象处理，进而尝试遍历keys或values属性——但这些属性不可枚举，结果为空数组或undefined - 若传入一个被代理过的
Map（如通过Proxy封装），getTag可能返回[object Object]，触发错误分支，却无任何警告 - 这种类型误判不会抛错，而是返回不符合直觉的结果，调试时难以定位
API 行为与原生不一致，破坏函数式链式习惯
开发者常依赖 .map(...).filter(...) 链式调用，但 Lodash 对非数组输入的返回值类型不稳定：
-
_.map({a: 1}, x => x)返回[1]（数组），而_.map(new Map([['a', 1]]), x => x)在某些版本返回[1]，另一些返回Map实例本身（如果启用了lodash-webpack-plugin的模块化裁剪） -
_.toArray(new Map([['x', 10]]))是唯一明确支持Map的工具方法，但它把键值对转为二维数组[["x", 10]]，而Array.from(map)结果相同——此时用原生更直接、无依赖 - 没有等价于
map.keys()、map.values()、set.forEach()的语义化封装，强行用_.map处理Map容易丢失键信息
构建与运行时环境进一步放大差异
即使代码在开发环境正常，上线后也可能失效：
- 小程序中全局对象被重写（如
global.Map = Map），但 Lodash 内部仍可能缓存旧引用或跳过检测逻辑 - 使用
lodash-webpack-plugin并启用caching或curry特性集时，Map相关路径可能被剔除，导致运行时报undefined is not a function - TypeScript 类型声明（@types/lodash）往往滞后，
_.map的泛型签名未覆盖Map输入，IDE 不报错但运行出错
