语义上必须用 ，因其能被屏幕阅读器正确识别评论顺序、数量和嵌套层级，支持无障碍访问与seo；会导致体验断裂。
评论列表用 <ol></ol> 还是 <div>？<p>语义上必须用 <code><ol></ol>，不是为了“好看”，而是让屏幕阅读器能正确识别评论顺序、数量和层级。用 <div> 套一堆 <code><section></section> 会导致无障碍体验断裂，且不利于 SEO 抓取时间线。
嵌套回复要靠 <ol></ol> 的递归能力，每层回复都是子 <ol></ol>，对应父级的 <li> —— 这是唯一被 HTML 规范明确认可的评论嵌套方式。
容易踩的坑：
- 把整个评论区包在
<ul></ul>里：无序列表无法表达“第1条、第2条”的时序含义 - 用
<article></article>替代<li>：破坏列表项语义，<article></article>应该出现在<li>内部，而非替代它 - 给
<ol></ol>加reversed属性倒序显示：会干扰辅助技术对序号的理解，应靠 CSSflex-direction: column-reverse或 JS 控制渲染顺序
aria-label 和 aria-describedby 怎么配着用？
单纯写 aria-label="评论：张三，2小时前" 是错的——动态内容（如时间、用户名）不该硬编码进属性值，否则更新不及时，屏幕阅读器不会重读。
正确做法是分离静态语义和动态内容：
- 每个
<li>加role="comment"（HTML5.2 已支持，比article更精准） - 用户名用
<span id="user-123">张三</span>，时间用<time datetime="2024-05-20T14:30">2小时前</time> - 在
<li>上写aria-labelledby="user-123"+aria-describedby="time-456"，让阅读器自动拼读
这样 JS 更新时间文案时，只要保持 datetime 属性不变，<time></time> 文本刷新后，阅读器下次聚焦会自动读新值。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
回复框放哪？怎么关联到目标评论？
回复框不能悬浮或全局固定，必须作为被回复评论的直接子元素出现，即放在该 <li> 内部、紧贴末尾的位置。否则键盘用户 Tab 到回复框时，无法感知“这是在回复谁”。
关键在于两个属性联动：
- 回复框
<textarea></textarea>加aria-label="回复张三的评论"（JS 动态写入） - 同时加
aria-controls="comment-789"，指向目标评论的id - 如果该评论有展开的子回复列表，还要加
aria-expanded="false"并同步控制其hidden状态
别用 data-* 属性存目标 ID 后靠 JS 绑定——ARIA 属性是浏览器原生识别的桥梁，少了它，辅助工具根本不知道这个输入框和哪条评论有关。
CSS 布局避不开的三个真实限制
Flex/Grid 能搞定样式，但有三个底层限制常被忽略：
-
<ol></ol>默认从 1 开始计数，想按发布时间倒序显示最新在顶？不能删<li>再插到开头，得用counter-reset+counter-increment重定义计数逻辑 - 嵌套层级深了，缩进靠
padding-left易失控，推荐用::marker { transform: translateX(...) }控制序号位置，不影响内容流 - 移动端小屏下，深度嵌套（>3 层）会让文字过窄难读，CSS 中必须设
min-width: 0配合word-break: break-word，否则长链接或邮箱会撑破容器
这些不是“锦上添花”的优化，而是影响基础可用性的硬约束。没处理好，键盘用户可能卡在某层缩进里出不来，或者屏幕阅读器把嵌套回复全读成同一级。
