K1.07.2custom share list omission设计
自建分享列表会遗漏用户常用目标
别名: 自建分享 · 分享图标墙 · hardcoded share targets
概念解释
自建分享列表指产品自己画一排目标图标（某即时通讯、某微博、邮件……），用这份名单替代系统面板。名单来自发版时的合作关系与市场假设，不是这台设备上此人真正在用的接收方。漏掉的往往是最常用的那些：公司内部应用、地区性通讯工具、刚装的阅读器、系统「存储到文件」和隔空投送。这条只谈「谁出现在列表里」，不谈系统面板作为出口的机制，也不谈交出去的内容能不能被对方打开。
机制
沙盒不允许发送方读取完整的已装应用图，自建列表只能写成编译期常量或远程配置的白名单。白名单按市场平均喜好排序，对单台设备是错的：用户置顶的目标不在名单里，名单里的目标可能根本没装，点了跳到商店。自建行与系统面板还会重复且分叉：系统里已经钉过同一通讯应用，自建图标却走应用内分享组件，会话列表、能否带文件、是否要二次登录都不一样，人无法把两次「分享到同一应用」当成同一操作。名单还有时效：新出现的接收方要等发版才能加进去，而系统面板在对方安装并登记接收的当刻就能列出它。
边界
监管或品牌要求必须走指定渠道（政务报送、版权内容只能发到认证平台）时，目标集合本来就是封闭的，自建列表不是疏漏，是约束。尚未接入系统分享扩展的接收方，只能先用应用内协议，但这不能论证「所以全部目标都自建」。预装量极大、且系统面板里同名目标打不开完整能力（只能收纯文本到对话框，不能收订单卡片）时，可以在系统面板之外额外提供一条应用内深链，而不是用自建墙换掉面板。
怎么落地
- 默认调用系统面板；若必须突出一两个合作目标，把它们做成面板之外的快捷项，而不是替换整个目标集合。
- 不要在无该应用时仍展示其图标并在点击后才跳商店——空图标是在用产品的猜测覆盖设备的真实状态。
- 验证：找一名不在目标市场画像里的同事，列出其主屏幕上实际用来收文件的三个应用，打开产品的分享入口，看这三项有几项能直接到达；缺的每一项都是自建名单的漏报。