系统统一承接账号与支付改变了流程边界
别名: 宿主登录 · 微信支付 · 支付宝 · 系统收银台
概念解释
在微信、支付宝和鸿蒙上，登录和付钱常常不是应用漏斗里的两步，而是系统或超级应用拉起的宿主面板。应用把流程做到「请求身份」或「请求支付」就应交出去：宿主出示自己的账号选择、生物识别、收银台和结果页，再把令牌或支付结果交回。信任展示（这是不是我的微信、钱从哪扣）发生在宿主壳上，不发生在商户页的仿造表单里。流程边界因此前移——商户不再拥有从填手机号到看到支付成功的整段画面。
它处理的是「账号和资金步骤的主权落在哪一侧」，不是小程序胶囊怎么排，也不是桌面卡片怎么前置功能。继续在应用里做一套平行的账号密码和银行卡表，会被宿主拦截，也会让已经把身份交给微信/支付宝的用户觉得在重复证明自己。
机制
身份和资金账户住在宿主侧，应用只是请求使用一次。面板由宿主绘制，是为了让用户核对壳而不是核对商户：熟悉的头像、已绑定的卡、系统级生物识别，这些线索无法被商户页诚实复制，复制了反而是钓鱼信号。应用能加的，是请求之前的上下文（买的是什么、金额、商户名）和请求之后的业务结果（订单已生成、失败后怎么改）。中间那一段——选账号、确认、验证、看扣款渠道——应用既画不到，也不该画。
取消和失败也改了归属。用户在宿主面板上划掉，应用收到的是取消，不是「表单校验失败」；此时应回到请求前的商户页并保持购物车，而不是弹出自己的错误文案去解释宿主里发生的事。金额、币种和商品描述一旦交给收银台，就不能在宿主面板还开着的时候在底下偷偷改，否则用户核对的壳和实际扣款会对不上。授权范围同样由宿主列出：应用要的头像、手机号、地址必须在宿主的同意界面上可见，不能在回调之后再加一项静默采集。
边界
没有接入微信支付/支付宝、也没有系统账号的独立站点，登录和支付仍是自己的漏斗，宿主面板模型不适用。跨境收款、企业对公转账、现金和货到付款本来就不走这些面板，强行套用会让用户找不到本应存在的渠道。未成年人、企业账户和分账商户会在宿主侧被额外拦一道，应用看到的是失败码而不是「用户不想买」，需要把这类失败从「支付失败」里分出来。纯内容浏览、不涉及账号和资金的表面，不应为了「统一」而强制先拉登录面板。
怎么落地
- 把漏斗切成三段：请求前的上下文（商品、金额、商户名）由应用说清；身份与支付只调宿主面板；回调后只处理成功、取消、失败码对应的业务状态。
- 不要在应用内再做账号密码、短信码或银行卡表去平行承接同一笔登录或支付；需要的资料在宿主授权项里一次列清。
- 宿主面板打开期间冻结订单金额和描述；用户取消时回到请求前页面并保留已填内容。
- 验证：走一遍微信或支付宝登录与支付（或沙箱），录下应用画面在哪一帧把控制权交给宿主壳、哪一帧拿回。任何在宿主面板之上叠自己的加载、在面板未关时改价格、或取消后清空购物车的行为，都是边界画错了。再拒绝一项授权，确认应用没有在回调后静默补采。