关键在于引导浏览器正确填充而非阻止，应通过语义化autocomplete属性、分离sso与本地字段、隐藏干扰输入及服务端严格校验来协同sso与autofill。
在 H5 页面中支持企业单点登录（SSO）的同时，又要兼容浏览器自动填充（Autofill），关键不是“阻止填充”，而是“引导填充到正确字段、避免错填干扰 SSO 流程”。现代浏览器（Chrome 80+、Edge 105+、Safari 15.4+）会主动忽略 autocomplete="off"，尤其对密码字段——它不认为这是安全需求，而视为 UX 障碍。所以硬拦没用，得用语义化 + 上下文控制来协同 SSO。
明确区分 SSO 凭据与本地表单字段
企业 SSO 登录页通常有两种模式：一种是跳转至统一认证中心（如 CAS、OAuth2 授权页）；另一种是嵌入式 SSO 表单（如 OIDC Implicit Flow 或 JWT 预填充）。无论哪种，H5 页面本身不应直接暴露 type="password" 字段用于 SSO 凭据输入——因为那会触发浏览器错误填充（比如把个人 Gmail 密码塞进企业 SSO 框）。
- 若走重定向 SSO（推荐），H5 页面只保留一个「登录」按钮，点击后跳转至 IDP（Identity Provider），全程不渲染用户名/密码输入框，自然规避 Autofill 干扰
- 若必须内嵌表单（如某些 legacy SSO 协议要求预填域账号），则该表单应由 IDP 动态下发，且字段 name/id 使用无语义值（如
name="sso_u_7x2"、name="sso_p_q9f"），避免浏览器匹配历史记录 - 禁止在同一个 DOM 中混用 SSO 字段和本地系统登录字段——例如不要在 SSO 登录页下方再放一个“管理员后台登录”入口，否则浏览器极易填串
用 autocomplete 语义值精准声明字段用途
浏览器填充逻辑依赖 autocomplete 属性的语义值，而非仅靠 type="password"。对 SSO 场景，应放弃模糊的 off，改用标准语义：
-
autocomplete="username"：仅用于真实需要用户手动输入的账号（如邮箱前缀、工号），且确保该字段不参与 SSO 凭据提交 -
autocomplete="current-password"：仅用于已登录状态下修改当前账号密码的场景，不可用于 SSO 初始登录 -
autocomplete="one-time-code"：适用于短信验证码、TOTP 等一次性口令字段，SSO 的 MFA 步骤可放心使用 - SSO 认证令牌（如
id_token、access_token）绝不通过<input>暴露，应由 JS 从 URL hash、postMessage 或 localStorage（配合 SameSite 限制）安全读取
干扰策略要服务于 SSO 上下文，而非对抗浏览器
如果 H5 页面需同时支持 SSO 和本地账号登录（如混合身份源），可用轻量干扰手段引导浏览器识别主次：
- 在真实 SSO 触发按钮前，插入一个隐藏但合法的干扰字段：
<input type="password" autocomplete="new-password" style="position: absolute; left: -9999px;">（注意不用display:none或disabled，部分国产浏览器会跳过） - SSO 表单中的密码类字段（如 OTP 输入框）初始设为
type="text"，获得焦点后再切换为type="password"（需兼容 Safari，它对动态 type 切换有延迟限制） - 所有敏感字段（包括 SSO 回调参数 input）都绑定一次性 CSRF Token，并由后端严格校验——防止 Autofill 错填后被恶意利用提交
后端必须切断“填充即成功”的误解链
浏览器填了，不等于认证通过。H5 页面只是载体，真正的 SSO 校验一定发生在服务端：
- 前端提交的任何字段（包括被 Autofill 填入的 username/password）都不能直接用于身份核验，只能作为 SSO 请求参数转发给 IDP
- IDP 返回的 assertion 或 token 必须由后端解密、验签、检查 issuer/audience/exp，再生成本地 session
- 禁止前端 JavaScript 解析或存储原始 SSO 凭据（如明文 id_token 放在 localStorage）——这会让 Autofill 变成安全隐患放大器
