details + summary 可原生实现无 js 折叠评论：details 管理开合状态且语义清晰，summary 必为首个子元素；需递归渲染每个评论为独立 details 块，用 css margin-left 和 --depth 控制缩进，扩展 summary 点击区域并添加 aria-label 提升可访问性。
用 details + summary 实现无 JS 折叠回复
原生 HTML 就能做带折叠的嵌套评论，不用 JS 也能响应点击展开/收起——关键在 details 元素。它天然支持开合状态、语义清晰、无障碍友好，且默认可被 CSS 定制样式。
注意：details 的开合状态由浏览器维护，不依赖 JS；但若需「默认展开」，得加 open 属性，不能靠 CSS 模拟（否则会破坏可访问性）。
-
summary必须是details的第一个子元素，否则无法触发折叠逻辑 - 嵌套时，每个子级
details都要独立包裹自己的评论内容，不能共用父级details的 body 区域 - Chrome/Firefox/Safari 均支持，IE 完全不支持（需降级为纯平铺或引入 polyfill）
递归渲染时避免 DOM 结构断裂
服务端模板（如 Jinja2、EJS）或前端框架（如 React/Vue）递归渲染嵌套评论时，最常见错误是把子评论直接塞进父 details 的末尾，导致结构变成：<details><summary>...</summary>...<details>子</details></details>——这看似嵌套，实则子 details 在父的「展开区」内，而非语义上的子节点。
正确做法是：每个评论项（含其子树）都应是一个完整、自包含的 details 块；子评论列表作为当前项的展开内容，而非新一层的兄弟节点。
- 递归函数返回值必须是完整 HTML 片段：
<details><summary>...</summary><div class="replies">[递归调用结果]</div></details> - 若用 React，确保组件返回的是单个根元素（如用
<details></details>包裹，不要 return [] 或多个并列details） - 避免在
summary内写交互控件（如「回复」按钮），部分屏幕阅读器可能将其误读为折叠开关的一部分
CSS 控制缩进与视觉层级
仅靠 HTML 无法自动缩进子评论，必须用 CSS 模拟嵌套层级。推荐用 margin-left 配合自定义属性（--depth）实现可扩展缩进，比硬编码多层 class 更可控。
details {
margin-left: calc(var(--depth, 0) * 24px);
}
details > summary::marker {
content: "▶ ";
}
details[open] > summary::marker {
content: "▼ ";
}
-
--depth应由模板或组件在渲染时注入，例如 Vue 中用:style="{ '--depth': depth }" - 不要用
padding-left替代margin-left，否则会影响summary点击热区范围 - 若需限制最大嵌套深度（如最多 5 层），可在 CSS 中加
details:nth-of-type(5n) { margin-left: 96px; }截断，但语义上仍保持完整结构
移动端点击区域与可访问性陷阱
在小屏设备上，summary 默认点击区域太窄，用户容易点空；同时，屏幕阅读器对嵌套 details 的朗读顺序可能混乱，尤其当子评论数量多时。
- 给
summary加display: block; padding: 8px 12px;扩展可点击区域，别只靠伪元素撑开 - 为每个
summary添加aria-label，例如aria-label="展开 3 条回复"，数值从数据中动态读取 - 禁止用
pointer-events: none或visibility: hidden隐藏子details，这会让屏幕阅读器跳过整个子树——要用display: none配合open属性控制显隐 - 若后端返回的嵌套深度超过 6 层，建议在第 6 层后截断并显示「更多深层回复…」链接，避免页面卡顿和语义过载
实际部署时，最易被忽略的是 summary 的语义完整性——它不该只是「回复」二字，而应携带上下文（如作者名、时间、回复数），否则折叠状态下用户无法判断是否值得点开。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
