邮件向导的桌面假设

【踩坑实录】邮件向导的桌面假设

▍现象
邮件客户端工程的账户配置向导：向导流程本身能启动，但走不完全——完成按钮要弹授权窗（OAuth2 登录页），这个窗是独立顶层窗，单表面环境下是死窗（点完成无反应）；高级配置窗、验证方式下拉面板同族全死。用户卡在向导半程，账户配不完。

▍定位过程
向导的窗口依赖普查：向导主体（主窗内的内容区，能活）、完成按钮的授权窗（独立窗，死）、高级配置（独立窗，死）、验证方式选择（弹出面板，死）。死因统一：独立顶层窗口家族。工程没有笼统标记向导不支持，而是逐个登记逐个选型（撰写窗标签化、向导绕过、弹窗替代三条改道路径的家族处置）。

▍对策
向导的核心价值是引导用户完成配置（服务器地址、认证方式、账户参数）。工程的改道：配置种子直注——把向导要引导产生的配置结果，做成配置文件种子直接注入（用户在应用界面填关键字段，种子补全技术性配置项），向导流程整体绕过。向导标签保留自动打开（表单填写、探测与手动配置的前半流程可用——能用的部分继续用），死窗部分的功能由种子通道承接。

▍根因抽象
向导类功能的移植三问：向导的产出是什么（配置数据）、引导是否必须（用户能不能直接给结果）、哪些环节有独立窗依赖。产出导向的改道（直注产出）比流程复刻（硬搬向导）更稳。

▍方法论沉淀
桌面流程类功能（向导、设置旅程、首次引导）的移植优先考虑产出等价：用户最终得到什么配置与状态，用移动形态的最短路径送达——流程的仪式感不是必须品。

向导改道的完整登记在邮件工程实录（含三条改道路径的家族表），apps 板块 56 篇欢迎对照。