应监听input事件实时比对密码字段，trim后用===校验，结合setcustomvalidity触发原生验证，服务端必须二次校验并返回400及明确错误码，自动填充场景需animationstart等多事件兜底。

用 JavaScript 监听 input 事件实时比对两个密码字段

核心是监听 password 和 confirm_password 两个 <input> 的 input 事件，而非只在提交时校验——用户打完字就该立刻知道是否匹配，体验更直接。

常见错误是只监听 change 或 blur，导致用户输完没失焦就看不到反馈；或者把比对逻辑写在 submit 里，掩盖了输入过程中的问题。

• 必须用 input 事件（不是 keyup），它能捕获粘贴、自动填充、剪切板操作等所有输入方式
• 比对前先 trim() 去除首尾空格，避免因空格导致“明明一样却报错”
• 不要用 ==，统一用 === 防止类型隐式转换干扰判断
• 建议给确认框加 data-validate="confirm" 这类标记，便于后续统一绑定，而不是硬写 ID

表单提交前用 checkValidity() + 自定义 setCustomValidity()

光靠视觉提示不够，得让浏览器原生表单验证机制参与进来：否则用户按回车或点击提交，表单仍可能绕过校验直接发出去。

关键点是调用 confirmInput.setCustomValidity() ——传空字符串表示通过，传非空字符串则触发浏览器默认的 invalid 提示（且 form.checkValidity() 返回 false）。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 每次输入后都要调用 setCustomValidity()，哪怕只是清空错误信息
• 不能只在不匹配时设错误，匹配时不管——这会导致上次的错误残留
• confirmInput.reportValidity() 只在手动触发校验时用（比如点击按钮），日常监听中不需要调用
• 如果用了 required 属性，注意空值优先级高于自定义校验，要先确保两个字段都有值再比对

服务端必须重新校验，前端校验只是体验层

任何前端校验都可被绕过：禁用 JS、改 DOM、抓包重发……所以 password 和 confirm_password 必须在服务端再次比对，且应放在业务逻辑之前（比如创建用户前）。

典型疏漏是前端做了漂亮提示，服务端却只校验单个密码强度，完全没比对两次输入是否一致，结果用户以为成功，实际注册的是错误密码。

• 服务端比对前，同样要 trim() 两端字符串
• 返回错误时，HTTP 状态码别用 200 + 错误体，用 400 Bad Request 更规范
• 错误响应里明确指出是 "password_mismatch" 而不是笼统的 "validation_failed"，方便前端精准处理

兼容性与边界场景：自动填充、iOS 键盘、密码管理器

Safari 和 iOS 原生键盘常触发 input 事件延迟或缺失，尤其是密码管理器自动填入时。单纯依赖 input 会漏掉这部分校验。

稳妥做法是加一层兜底：监听 animationstart（Chrome/Firefox 自动填充会触发）、focusin 后延时检查、以及 DOMContentLoaded 后立即比对一次初始值。

• iOS 上 input 在自动填充后可能不触发，但 change 会，所以可组合监听两者
• 某些密码管理器填完后焦点不在确认框，需主动 confirmInput.dispatchEvent(new Event('input', {bubbles: true}))
• 不要用 setTimeout 等固定毫秒数，改用 requestAnimationFrame 或监听 load 事件后再检查初始状态

真正容易被忽略的，是自动填充场景下事件触发时机的不可靠性——它不像人工输入那样确定，得靠多事件组合+初始态检查来覆盖。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！