完全隐藏会让用户误以为功能不存在
别名: 隐藏当不存在 · missing feature misconception
概念解释
把无权项从导航里拿掉之后，选择场上没有缺口、没有灰位、没有名字。人会把「看不见」读成「这个产品没有这个能力」。隐藏被理解成不存在（hidden nav implies absence）是隐藏策略的认知代价：省掉了假入口，也抹掉了「它在，只是你还去不了」这句话。代价在用户已经听说过该能力、或正在与有权限的同事协作时最大。
机制
导航是产品能力的公开目录。目录上没有的项，默认不在商品里。培训材料、合同条款、同事一句「你去导出那边看」，都会指向一个名字；导航上对不上这个名字时，人不会先猜权限，而会猜自己用错了产品、版本不对、或同事在吹牛。客服工单于是变成「你们到底有没有导出」，而不是「如何开通导出」。隐藏把权限问题翻译成了存在问题。
探索型用户更吃这套误读：他们靠扫导航学习产品边界。被藏掉的能力永远进不了他们的心智模型，以后即便开通了，也不知道该去哪找——开通事件若不同时把项变出来并点名，模型不会自己长出来。
怎么研究
给被试一项在材料或同事话语里出现过、但导航里被藏掉的能力，问「这个产品有没有 X」以及「若有，在哪」。自变量是隐藏还是禁用加原因。因变量是判定为不存在的比例、去设置/客服寻找的比例、以及开通后能否不经指点找到入口。
真实工单里「有没有某某功能」与权限相关的那一截，是这条机制的现场证据。
边界
对该角色确实不应知道的能力（未发布、安全隔离、考试中的管理端），让人以为不存在是目标，不是代价。从未在外部话语里出现过、也永远不会对该角色开通的项，隐藏不会造成这种误读。禁用加原因会暴露名称，名称本身敏感时不能用这条机制来反对隐藏。开通流程若发生在导航之外（邮件里的链接直接落地），存在性由那条链接承担，导航隐藏的误读会小一些。
怎么落地
- 凡是会在培训、合同、跨角色协作里被叫到名字的能力，不要对将要开通或正在协作的人完全隐藏；用禁用加原因保住存在性。
- 开通成功后不仅要出现入口，还要当面指出「刚才开通的就是这一项」，补上被隐藏期间没长出来的模型。
- 客服话术把「有没有」和「你的角色能不能」分开问，避免双方在存在性上空转。
- 验证：找一个听说过该能力的无权用户，只给导航、不给旁白，问产品有没有它。答「没有」即误读成立。换成禁用加原因后再问，答案应变成「有，但需要开通/某角色」。