<details>标签默认不支持嵌套表单和实时交互，因<summary>是唯一可点击区域且事件敏感；需将表单控件置于<summary>外、用toggle事件+requestAnimationFrame实现平滑滚动；移动端需延迟聚焦textarea并禁用viewport缩放；SSR中须正确输出open属性并避免hydration覆盖。
details 标签默认不支持嵌套表单和实时交互
<details> 本身只是语义化折叠容器，它不会自动处理评论提交、加载更多、输入框聚焦或键盘事件（比如回车提交）。如果你直接把 <form>、<textarea> 塞进 <summary> 或 <details> 内部，会遇到两个典型问题：点击 <summary> 时表单意外收起，或者输入框失焦。根本原因是 <summary> 是唯一可点击触发展开/折叠的区域，且浏览器对它的事件捕获很敏感。
解决思路是：把交互控件（如输入框、按钮）放在 <details> 内部但**避开 <summary>**；用 CSS 隐藏原生箭头并自定义样式；必要时用 JS 拦截 <summary> 的默认行为再手动控制 open 属性。
- 不要在
<summary>里放<input>或<button> - 把评论输入区、提交按钮、列表区域统一放在
<details>开始标签之后、</details>之前，但**在<summary>外部** - 如果需点击任意区域展开，加
onclick="this.parentElement.open = !this.parentElement.open"到自定义触发元素上（注意避免重复触发）
如何让 details 展开时平滑滚动到新评论
用户提交评论后，常希望页面自动滚动到底部显示最新内容。但 <details> 自身没有内置滚动逻辑，且 scrollIntoView() 在 open 属性变更的异步时机上容易失效——DOM 还没重排完成就调用了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
<details>的toggle事件（不是click），它在展开/折叠状态稳定后触发 - 在事件回调中用
requestAnimationFrame()延迟一次渲染周期再执行scrollIntoView() - 如果评论区内容动态加载，确保滚动目标元素已插入 DOM（比如在
fetch().then(() => { ... })里调用）
示例关键代码：
<details id="comments">
<summary>查看 12 条评论</summary>
<div id="comment-list"></div>
<form id="comment-form">...</form>
</details>
<script>
document.getElementById('comments').addEventListener('toggle', () => {
if (this.open) {
requestAnimationFrame(() => {
document.getElementById('comment-list').scrollIntoView({ behavior: 'smooth', block: 'nearest' });
});
}
});
</script>
移动端点击 summary 后键盘弹出导致布局抖动
iOS Safari 和部分安卓浏览器中，当 <summary> 包含文本且页面有 <textarea> 时，点击 summary 展开后若焦点落在 textarea 上，软键盘弹出会强制缩放 viewport、触发 body 重排，造成视觉跳动甚至 summary 错位。
这不是 <details> 的 bug，而是 viewport 缩放策略与 focus 行为叠加的结果。缓解方式优先级如下：
- 给
<textarea>加autofocus属性时，改用 JS 在toggle事件后setTimeout(() => el.focus(), 300)延迟聚焦（绕过键盘抢跑） - 在 meta viewport 中禁用缩放：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"> - CSS 强制固定高度：
details[open] { height: 500px; overflow-y: auto; }，避免内容撑开引发重排
服务端渲染时 details 的 open 状态同步问题
如果评论区初始有数据且希望默认展开，仅靠服务端输出 <details open> 不够稳妥——某些 SSR 框架（如 Next.js、Nuxt）会在 hydration 阶段覆盖 DOM 状态，导致闪屏（先展开后突然收起）。
关键点在于：客户端 JS 执行前，HTML 必须真实反映预期状态；hydration 时不能重置 open 属性。
- 服务端输出时，确保
open属性存在且值为空（<details open>），而非<details open="true">（后者会被视为字符串值，部分框架解析异常） - 客户端不主动设置
el.open = true，除非检测到服务端未正确输出（可用el.hasAttribute('open')判断） - 避免在 React/Vue 组件的
mounted或useEffect中无条件操作open，应加条件守卫
这个细节在首屏体验上非常关键：用户看到的不是“加载中”，而是“已经展开的评论”，但背后要扛住 hydration 的干扰。
