在设计中后台产品时，我们会碰到各种需要多层目录（或级联选择）的场景。
最近在应对多层目录的需求时踩了小坑，好在后来意识到问题，及时修正了方案。不聊问题，先来看看常见形式：
形式一：多层目录
常用于文件或报表索引，层级深度为3-4，模块位于侧边导航处，每层可点击+展开/收起。
confluence.jpg
bdp 个人版
利
- 信息层级清晰直观
- 左右映射，索引与内容一致性
- 直接了当，随时在不同内容间切换
弊
- 界面冗余
- 分散用户注意力
- 索引易被遮挡，需Hover或横向滚动
形式二：产品服务List
常用于控制台/产品官网，特点是深度为1-2层，Hover即出现，平铺展示所有项目。
aliyun
baiduyun
利
- 平铺全集，便于发现和寻找服务
- 内容区足够大，极少存在遮挡
- 默认收起，不占页面空间
弊
- 仅适用于1-2层深度
形式三：级联选择
常见于控制台导航栏选择服务或表单级联选择框，深度较自由，一般为2-3层。
aliyun 级联选择
antdesign 级联选择框
利
- 便于一次性选择
- 可承载较多选择项，兼容性佳
弊
- 不利于频繁切换
形式四：分步选择
常用于较谨慎表单操作，将3-4甚至更多层级打散，页面每次平铺显示本层内容，逐层确定。
应用
最近一次应对这个问题时，首先尝试的是多级目录这一最原始的手法，考虑到于内容易被遮挡，便努力尝试了其他方式，包括级联选择、平铺展示全集、打散分步选择等能想到的各种方法。想了一圈，有找到「看起来」更好的方式，但中后台产品最重要的还是业务逻辑，于是最后又回到了原点，选择了多级目录。
控制台类产品设计往往建立在已有的设计规范/原则的基础上，然而即使是同一控制台的不同模块，在形式上也未必完全一致，即实际解决方案没有那么「漂亮」。十全十美的规范不存在，如果强行套用，就要以牺牲部分用户体验为代价了。
