部分功能因需要持久身份而无法在游客模式下提供
别名: 游客功能限制 · guest feature gating · 未登录不可用
概念解释
有的动作在机制上绑定「这个人明天还是同一个人」：跨设备续聊、向他人授予权限、付费权益、法律责任、被举报后的追责。无法在游客模式下提供指这些动作在未持久身份时保持关闭，并在入口说明缺的是身份而不是功能坏了。这条划功能边界，不鼓励用游客去假装完成它们，也不把边界当成把所有核心体验都锁掉的借口——核心体验属于游客模式那一条。
机制
持久身份提供稳定主键、可追责的联系通道、可恢复的凭证。缺这三项时，分享链接会在设备清除后失效却仍被他人持有、退款找不到合同主体、恶意内容无法处置。产品若在游客下「先做了」这些动作，后续无法兑现承诺，体验债务会在注册或投诉时爆发。边界应该画在身份语义上，而不是画在商业转化上：需要持久身份的是「把这篇的编辑权给同事」，不是「把滤镜用完」。把后者也锁掉，游客模式名存实亡；把前者放开，系统会留下无法治理的对象。
怎么研究
把功能清单分成「必须持久身份」与「游客可做」，让人在游客态尝试两类入口，看关闭是否被理解，以及有没有漏网的高风险动作。
自变量：关闭的呈现（禁用并说明、点击后才要注册、假装可做做到一半失败）、分类是否公开。 因变量：人对「为什么不能做」的归因、把关闭当成故障的比例、游客态实际完成了本该关闭动作的漏洞。
不要用「游客转化」当分类质量。安全与信任研究应专门试图在游客态完成分享授权、支付、举报，看系统是否真的挡住。分类争议用书面标准（有无稳定主键、有无追责通道）仲裁，避免各部门按增长指标私自打开。
边界
支付若法规允许游客结账、用一次性联系方式履约，结算可以不建完整账号，但那是一次性合同身份，仍不是可回来的持久账号——界面不要写成「已注册」。只读消费公共内容几乎从不需要持久身份，把它锁进登录是注册墙，不是这条的边界。企业单点登录环境没有游客，整张卡不适用。功能会随版本改变类别，关闭列表要跟代码里的能力开关同源。
怎么落地
- 用书面标准把功能标成游客可写 / 游客只读 / 需持久身份；需身份的入口在游客态可见但关闭，文案说「需要账号因为要记住接收人或责任」，并提供此刻开户。
- 禁止游客态走完支付改权、跨设备授权、对他人内容的管理；技术上在服务端拒绝，而不是只藏按钮。
- 不要把滤镜、阅读、一次计算等无持久语义的动作标成需身份。
- 验证：列一份需身份功能，用游客令牌直接调对应接口，应全部被拒。界面上点这些入口应看到身份原因而不是通用错误。再列一份核心体验清单，确认它们仍可在游客态完成，边界没有吞掉整块产品。