密码字段必须是<input type="password">且有非空语义化name属性，表单需含账号字段与密码字段组合、method="post"，并由原生submit触发，否则浏览器密码保存弹窗不会出现。
密码字段必须是 <input type="password"> 且有 name 属性
浏览器密码保存弹窗（如 Chrome 的“是否保存密码？”）不会仅因 type="password" 就触发。它要求该输入框同时具备 name 属性，且值不能为空或纯空格。没有 name 的密码框，哪怕类型正确、用户输过内容，提交后也大概率被忽略。
-
name值建议语义化，比如name="password"或name="user_password"；name="pwd"也可识别，但name="p"或随机字符串（如name="abc123"）可能失效 - 若用框架动态生成（如 React/Vue），确保
name在 DOM 渲染后真实存在，而非仅在 JS 对象里 - 注意：Chrome 117+ 对
name的语义匹配更严格——name="confirm_password"可能被当作二次确认字段，不触发保存；主密码字段应避免带confirm、repeat等前缀
表单需包含可识别的用户名/邮箱字段 + 密码字段组合
单个 <input type="password"> 提交不会唤起保存弹窗。浏览器需要至少两个字段：一个文本类（type="text" / type="email" / type="username"）用于账号标识，一个 type="password" 字段用于凭证。两者需在同一个 <form> 内，且提交方式为 method="post"（get 通常被忽略）。
- 账号字段推荐使用
type="email"或明确标注autocomplete="username"；type="text"时，name建议为"username"、"email"、"login"等常见值 - 如果账号字段是隐藏的（如通过 JWT token 自动填充），浏览器无法感知登录凭据组合，保存弹窗不会出现
- 注意：某些浏览器（如 Safari）对
autocomplete属性依赖更强——即使name合规，缺失autocomplete="current-password"（密码字段）或autocomplete="username"（账号字段）也可能降低识别率
提交行为必须由原生表单 submit 触发，而非 JS 拦截后手动 fetch
浏览器只监听原生 submit 事件。如果用了 event.preventDefault() + fetch() 或 axios 提交，即使 DOM 结构完全合规，密码保存弹窗也不会弹出——这是设计使然，不是 bug。
- 折中方案：保留原生
<form>提交逻辑，用submit事件监听做前置校验；校验失败再preventDefault()，成功则放行 - 若必须用 fetch，可尝试在请求完成后手动触发一次不可见的原生提交（不推荐，兼容性差且易被误判为恶意行为）
- 注意：Chrome 会检查响应状态码——返回 4xx/5xx 的提交，即使结构正确，也可能跳过保存提示
密码字段不能被 JavaScript 动态修改 type 属性
初始渲染时是 type="password"，但后续被 JS 改成 type="text"（如“显示密码”功能），再改回 type="password"，会导致浏览器丢失对该字段的密码上下文识别。部分版本 Chrome 会直接放弃保存逻辑。
- 正确做法：用
inputmode="text"+ CSS 遮罩控制可见性，而非切换type；或始终维持type="password"，仅通过visibility或opacity控制文字显示 - 避免在
DOMContentLoaded后用 JS 设置type——必须保证 HTML 初始解析时就是type="password" - Vue/React 中注意：不要在
v-model或value绑定过程中意外重写type属性
type="password" 就能稳保生效。最常被忽略的是 name 属性缺失、表单被 JS 完全接管、以及账号字段语义模糊这三点。 
