茶饮多层菜单里，子选项为何不会自动跟随父选项的门店范围

茶饮菜单可能先呈现一组定制选项，再展开下一层选择。对于整理菜单需求的人，问题不只在于“下一层叫什么”，还在于下一层与上层到底共享了哪些信息。Square美国帮助页介绍的嵌套modifier set，提供了一个具体的软件例子：菜单中的父子联系，并没有把两个集合合并成一个对象。[1]

该页先把modifier解释为销售时可提供的定制选择，随后用先选饼皮、再选饼皮内馅说明多层嵌套。本文借其结构提出一个假设的茶饮菜单：某项附加选择下面还有细分类别。这个例子仅帮助识读层级，不对应真实门店的商品、原料或后台配置，也不安排饮品制作。

原文Tips明确指出，嵌套集合拥有独立的地点和渠道分配，不继承父级modifier的分配。因此，上层在某家门店可用，不能直接推定下层也在同一门店可用。菜单结构回答“谁关联谁”，地点安排回答“在哪里可用”；两份信息可以有关联，却没有因嵌套而自动变成同一份。

渠道也保持这种独立性。页面下一节说明，只有与商品地点、渠道相符的集合才能添加到商品；集合没有分配到某一渠道时，即使商品在那里可用，买家也不会在那里看到该集合。对茶饮菜单说明而言，一张层级示意图能表达选项之间的联系，却仍不能单独证明各点单渠道都显示完整的下一层。这是按原帮助页作出的信息分析，不是本文对任何实际页面的测试结果。

另一条规则涉及删除的对象。原页说，删除嵌套关系只会移除父子链接，不会删除底层modifier set。假设一份需求记录写着“去掉下一级”，就仍需说明它指的是解除本处联系，还是让集合本身不再存在。两个说法涉及不同对象；仅凭某个菜单位置不再展示子选项，也不能断言原集合已经被删除。

层级本身还有边界。原帮助列明最多三层、不允许集合包含自身或父集合；文本类型集合可以被嵌套，但不能再有子集合。这些限制属于Square本次所读功能说明，不是所有点单软件通用的菜单规则。把一张无限延展的树形图交给软件需求方，不能假定其中每条关系都能照图表达。

整理茶饮多层菜单的资料时，因而可以分别说明集合名称、父子联系及各自地点渠道；遇到“移除”则具体说清移除的是哪一种对象。本文没有登录后台、点击设置或验证实际订单，也不讨论配方、价格和经营资格。这里要解释的是：选项之间有联系，联系所连接的对象仍保有自己的范围与规则。