浏览器自动填充与应用内智能预填的数据来源不同，需分别处理
别名: 自动填充 vs 预填 · autocomplete vs prefill · 两套填充
概念解释
浏览器自动填充（autofill / autocomplete）把浏览器或密码管理器里保存的姓名、地址、账号写进带有相应语义的字段，数据主人是用户的浏览器档案，应用事先不知道会填什么。应用内智能预填把应用自己的档案或订单写进字段，数据主人是这家产品。两套可以同时发生：页面打开时应用先写入上次地址，焦点进入时浏览器又用另一套地址盖上去。分别处理指：来源提示、覆盖规则、关闭开关、错误责任都不能共用一套文案或一套开关。字段命名错配、隐藏字段被填、用户覆盖权，是这组里另外三件事。
机制
自动填充在焦点进入或页面解析时由浏览器决定映射；应用预填在渲染时由服务端或脚本决定映射。人看见框里有字，分不清是「这家店记得我」还是「我的浏览器记得所有店」。第二层是冲突时谁赢：后写入的覆盖先写入的。应用若在 DOMContentLoaded 写完预填，浏览器在用户点进字段时再填，浏览器赢；应用若在 autocomplete 之后又用脚本刷一次档案，应用赢。人无法预测哪一次是自己要的那套地址。关掉「记住我」只能关应用预填，关不掉浏览器；关掉浏览器的自动填充关不掉应用档案。把两套当成同一功能来做设置页，开关会撒谎。支付、登录还多了密码管理器这第三套，同样不能和应用档案混在一个「智能填写」开关里。
怎么研究
构造「仅应用预填」「仅浏览器填充」「两者都开且地址不同」三种页。记录最终提交的是哪一套、人以为是哪一套。
自变量：两套是否同时启用、写入时序（渲染时 / 聚焦时 / 提交前脚本再写）、设置里是否分成两个开关。 因变量：提交值来源、来源判断正确率、关掉其中一个开关后另一套是否仍写入。
实验室机器若没开浏览器填充，会以为只有应用预填。要在真实开着密码管理器的浏览器上测。不要把错配到错误字段的案例算进「来源冲突」——那是命名问题。
边界
应用没有账号、从未写过预填时，只存在浏览器这一套，不必做应用侧开关。企业管控的浏览器禁用自动填充时，应用预填是唯一来源，责任完全在应用。WebView 内嵌页可能拿不到系统填充，表现得像「自动填充坏了」，其实是壳没把管理器接进来。原生系统自动填充（iOS Password AutoFill）与 HTML autocomplete 又不是同一管道，移动壳要单独测。
怎么落地
- 在字段旁把两套来源分开写：应用预填写「来自你在本产品的档案」，浏览器填充留给系统自己的钥匙或高亮，不要都叫「智能填写」。
- 规定冲突规则并执行一次：例如「用户焦点进入时的浏览器填充优先于渲染时的应用预填」，提交前禁止脚本再盖一层。
- 设置里两个开关：停止应用预填 ≠ 停止浏览器自动填充。
- 验证：档案地址与浏览器地址不同，打开表单后点进地址栏，看最终留下哪一套、文案是否说对。只关应用预填，确认浏览器仍能填。只关浏览器填充，确认应用档案仍在。提交前用脚本再写一次档案，作为必须禁止的对照。