应将details标签置于.invalid-feedback内部或之后，而非包裹验证提示元素；否则会破坏Bootstrap兄弟选择器规则并导致验证状态丢失，需手动控制open属性且微信环境需降级处理。
details标签不能直接包裹表单验证提示元素
把 .invalid-feedback 或 .error 塞进 <details> 里，会导致提示不显示或点击折叠后验证状态丢失。原因很直接：Bootstrap 的反馈样式依赖控件与提示是同级兄弟节点，而 <details> 会插入一层 DOM 包裹，破坏这个紧邻关系；同时，<details> 的 open 属性切换会触发重排，可能让 JS 判断的 nextElementSibling 指向错误节点。
常见错误写法：
<input class="form-control is-invalid"> <details> <summary>错误详情</summary> <div class="invalid-feedback">邮箱格式不对</div> </details>
这种结构下，.invalid-feedback 不再是 input 的直接下一个兄弟，Bootstrap 的 CSS 规则（如 .is-invalid ~ .invalid-feedback）完全失效。
想用details展开错误详情，得把summary和反馈内容拆开
真正可行的做法是：保持 input 和 .invalid-feedback 的兄弟关系不变，只把“详情说明”部分用 <details> 单独包起来，并放在 .invalid-feedback 内部或之后——这样既不破坏验证结构，又能提供可展开的补充信息。
立即学习“前端免费学习笔记（深入）”；
推荐结构：
<input type="email" id="email" class="form-control">
<div class="invalid-feedback">
邮箱格式不对
<details class="mt-2">
<summary>为什么报错？</summary>
<p class="mb-0">必须包含 @ 符号，且域名部分不能以点结尾。</p>
</details>
</div>
-
.invalid-feedback仍能被 JS 正确定位并显隐控制 -
<details>仅承载解释性文字，不参与验证逻辑 - 移动端 Safari、微信 X5 内核对单层
<details>支持良好，无需降级
表单提交失败时自动展开details需手动触发
原生 <details> 不响应表单验证失败事件，也不会在 JS 调用 reportValidity() 或设置 is-invalid 类时自动打开。你得在验证逻辑里显式控制。
例如，在提交失败后展开第一个含错误的 <details>：
form.addEventListener('submit', e => {
if (!form.checkValidity()) {
e.preventDefault();
const firstInvalid = form.querySelector(':invalid');
if (firstInvalid) {
const details = firstInvalid.nextElementSibling?.querySelector('details');
if (details) details.open = true;
}
}
});
- 别用
details.toggle()，它会翻转当前状态，而我们需要的是“确保展开” - 检查
nextElementSibling是否存在，避免querySelector报错 - 如果多个字段出错，只展开第一个即可——用户修复后，其他错误通常会消失或重新校验
iOS Safari 和微信内置浏览器对details+表单混合使用的限制
虽然单层 <details> 在 iOS 17.4+ 和新版微信中已基本可用，但一旦和表单验证联动，仍有两个隐藏雷区：
- 在 iOS Safari 中，
<details>内部的<input>或<select>会失去焦点管理能力，Tab 键跳过、VoiceOver 无法读出选项 - 微信 Android X5 内核（尤其 v8.0.4x 及更早）仍会忽略
<details>标签，整块内容直接不渲染——哪怕它只是放在.invalid-feedback里
所以，如果你的表单要覆盖微信用户，最稳妥的方式是：用 UA 检测，对微信环境直接渲染静态 <div class="details-fallback"> 替代 <details>，并用 aria-expanded 和 button 模拟交互语义。这点容易被忽略，但线上真实埋点数据显示，微信内表单错误展开率在未降级时低于 12%。
