原生表单验证在自定义元素中失效，是因为未正确接入Constraint Validation API；需设置static formAssociated = true、调用this.attachInternals()，并在setValidity()中传入可聚焦的内部DOM节点作为第三个参数以激活验证流程。
为什么原生表单验证在自定义元素里直接失效
当你把 input 封装进自定义元素（比如 <my-input>），浏览器默认不把它当“表单控件”——checkValidity() 返回 true，reportValidity() 不弹提示，提交时也完全跳过它。根本原因是：它没接入 Constraint Validation API。常见报错 “An invalid form control with name='xxx' is not focusable” 就是这个信号。
关键不是“写了个 custom element”，而是它得被浏览器识别为可参与验证的表单关联元素（FACE）。只加 static formAssociated = true 和 this.attachInternals() 还不够，漏掉 validity anchor 就会卡死整个流程。
- 必须在
setValidity()调用时传入第三个参数：一个可聚焦的内部 DOM 元素（如this.input） -
internals.setValidity({ valueMissing: true }, '字段不能为空', this.input)—— 第三个参数不能省 - 这个内部元素要能接收焦点（
tabindex="-1"或本身是input/textarea）
怎么让 reportValidity() 正常弹出并滚动到错误位置
很多 FACE 实现调了 reportValidity() 却没反应，或者 Firefox 下不自动滚动，问题往往出在 validity anchor 绑定失败或未触发 invalid 事件。
- 确保每次调用
internals.setValidity()时，第三个参数（anchor）是当前实例中真实存在的、可聚焦的节点 - 不要在 disconnectedCallback 里还调
setValidity()，否则 anchor 可能已移除，导致静默失败 - 如果用了 shadow DOM，anchor 必须在 light DOM 或显式
exportparts暴露，否则浏览器找不到聚焦目标 - 测试时用
form.reportValidity()触发全表单校验，比单独调某个元素的reportValidity()更可靠
setCustomValidity() 在 FACE 里怎么用才不翻车
原生 input 上用 setCustomValidity() 是直接挂载在元素上，但 FACE 必须通过 internals.setValidity() + 自定义 message 配合实现等效效果，且不能混用。
立即学习“前端免费学习笔记（深入）”；
- 别在 FACE 内部再调
this.input.setCustomValidity()—— 它和 internals 的状态不同步，会导致验证逻辑混乱 - 自定义错误文案要写进
setValidity()的第二个参数：internals.setValidity({ customError: true }, '用户名已被占用') - 清空错误必须显式调用：
internals.setValidity({})或internals.setValidity({}, '')，不能只设空字符串 - 若需响应用户输入实时清空旧错误，要在
input或blur事件里先setValidity({})，再跑新校验逻辑
如何避免验证状态残留导致“输对了还报错”
这是 FACE 表单中最隐蔽的坑：用户修改后明明符合规则，但 reportValidity() 仍弹旧提示。本质是 validity 状态没及时重置，尤其在异步校验（如用户名查重）场景下更明显。
- 每次开始新校验前，先调
internals.setValidity({})清空所有 validity flags - 异步校验（如 fetch）返回后，检查元素是否还在 DOM 中（
this.isConnected），避免回调执行时组件已销毁 - 不要依赖
invalid事件来清理状态 —— 它只在浏览器判定无效时触发，而你可能手动设了 customError，它不会自动触发 - 调试时可用
console.log(this.internals().validity)直接看当前 validity 对象，比猜更准
FACE 的验证逻辑看似封装了一层，实则把约束验证的每个环节都暴露给了你。锚点缺失、状态未清、同步/异步混用——这些细节一旦漏掉，验证就变成“看起来能跑，实际总掉链子”。最稳的做法是：每一步 validity 操作都对应一个明确的 DOM anchor，每一次校验都以 setValidity({}) 开头，而不是靠“应该没问题”去赌。
