picker-view 是唯一靠谱的选择，因其支持动态控制每列 range 和 value，可实现“父→子→孙”链式依赖；multiselector 初始化后 range 锁死，无法响应父项变更，导致子列空白或回退。
不能用 multiSelector 做标签联动选择——它不支持动态 range 更新，选了“穿搭”之后，“配饰”“鞋包”这些子标签根本不会自动刷新。
为什么 picker-view 是唯一靠谱的选择
小红书式标签联动本质是「父标签 → 子标签 → 孙标签」的链式依赖，必须手动控制每列的 range 和 value。而 picker-view 提供了完全可控的索引数组接口，能精确响应每一列变化。
-
multiSelector初始化后就锁死二维数组，改了第一列数据，第二列range不会变，value还指着旧索引，结果就是空白或回退到 0 -
picker-view的value是纯数字数组（如[0, 2, 1]），只要确保每个值都 range[i].length，就能稳住不越界 - 真机（尤其 iOS 微信）上，
range若传对象数组（如[{id:1,name:"美妆"}]），会直接渲染失败；必须是字符串数组：["美妆", "护肤", "香水"]
picker-view 中三列联动的关键同步逻辑
核心原则：**更新第 n 列，必须重置第 n+1 列及之后所有列的 value 为 0，并同步更新其 range**。否则滑动后第三列大概率错位或为空。
- 用户选中“美妆”（第一列 index = 0）→ 触发请求获取该分类下的二级标签（如 ["底妆", "眼妆", "唇妆"]）→ 立即执行：
this.secondIndex = 0; this.thirdIndex = 0;，再setData新secondRange和新value: [0, 0, 0] - 用户再选中“眼妆”（第二列 index = 1）→ 请求三级标签（如 ["眼线", "睫毛膏", "眼影盘"]）→ 执行：
this.thirdIndex = 0;，再一次性提交thirdRange和value: [0, 1, 0] - 绝对不要在
bindchange里分多次setData：先算好全部新range、新value，再一次性提交，否则 iOS 上极易卡死
用 uni-data-picker 的隐藏陷阱
它封装了 picker-view，但 field 配置和数据结构稍有偏差就会失效，且真机调试时表现极不稳定。
-
field必须写全：field="id as value, name as text"—— 漏掉as、字段名大小写不一致（比如后端返回categoryName，你写成name），value就是undefined - 本地数据必须严格嵌套：
children字段存在，且每层都有value和text，不能混用label或title - 开启
step-search="true"后，选省会自动查市，但前提是后端返回的每条数据都有正确的parent_code（如“北京市辖区”的parent_code必须是"110000"） - iOS 微信里，如果控制台日志太多（尤其
console.log打印整个标签树），uni-data-picker弹窗可能延迟 2 秒甚至不弹 —— 调试时先关掉日志
最易被忽略的一点：**联动不是“选完父级就自动推导子级”，而是每次选择都是一次独立的数据拉取 + 索引重置动作。哪怕数据已缓存本地，也要走一遍 value 归零 + range 替换流程，否则跨平台一致性无法保障。**
