优先用 <ul>，除非公告有严格发布时间顺序且必须视觉编号；标题用 <a> 或 <button> 保证可访问性；时间用 <time> 标签提供机器可解析的 datetime；滚动卡顿优先优化 CSS 而非过早引入虚拟列表。
公告列表用 <ul> 还是 <ol>？
优先用 <ul>，除非公告有严格发布时间顺序且必须视觉编号（比如“第1期公告”“第2期公告”）。实际业务中，公告通常按时间倒序排列，但编号只是辅助，<ul> 语义更准确、样式更自由。用 <ol> 反而容易被屏幕阅读器读成“1. … 2. …”，造成干扰，尤其当后端动态插入/删除条目时，序号会错位。
常见错误：直接套用教程里的 <ol> + reversed 属性，结果 Chrome 支持但 Safari 不渲染反向序号，且无法控制起始值为当前最大 ID。
- 动态加载场景下，用
<ul>+ CSScounter-reset/counter-increment控制自定义序号更可靠 - 如果真要编号，建议后端返回
seq字段，前端用data-seq属性存值，CSS 或 JS 渲染，不依赖 HTML 列表类型 - 无障碍要求高时，加
role="list"和每个项的role="listitem"，比强行用<ol>更可控
怎么让公告标题可点击又保持语义正确？
别用 <div onclick="..."> 包标题——这既不是链接也不是按钮，键盘用户无法聚焦，屏幕阅读器不会识别为可交互元素。正确做法是：标题本身是 <a>，href 指向详情页；若无跳转（比如只展开摘要），则用 <button>，并加 type="button" 防止表单提交。
常见错误：给 <h3> 加 onclick，或把整个 <li> 设为 cursor: pointer 却没配 ARIA 属性，导致键盘 Tab 键跳过、Enter 键无响应。
立即学习“前端免费学习笔记（深入）”；
-
<a href="/notice/123">系统维护通知</a>—— 有详情页时首选，天然支持新标签页、书签、SEO -
<button type="button" aria-expanded="false" aria-controls="notice-123-body">系统维护通知</button>—— 纯前端展开时必须加aria-expanded和aria-controls，否则视障用户不知道状态变化 - 避免在标题里塞图标
<i class="icon-arrow"></i>而不加aria-hidden="true"，否则读屏会念“arrow”
公告时间显示用 <time> 标签有什么实际好处？
不只是“语义化”这么虚——<time datetime="2024-05-20T09:30">5月20日 上午9:30</time> 能让浏览器、日历 App、邮件客户端自动识别时间戳，部分安卓设备长按还能弹出“添加到日历”。更重要的是，它让 JS 处理时间格式时有唯一可信源：new Date(el.dateTime) 比从中文文本里正则提取靠谱得多。
常见错误：写成 <span class="date">5月20日 上午9:30</span>，后续想加“距今 X 小时”功能时，得写一堆兼容性 hack 来解析中文时间；或者 datetime 值写成 "2024-05-20" 缺少时分秒，导致时区转换出错。
-
datetime必须是机器可解析格式（ISO 8601），推荐后端直接输出带时区的完整时间，如"2024-05-20T09:30:00+08:00" - 显示文本可以本地化（如“昨天 14:22”），但
datetime属性不能变，它是数据锚点 - 配合
title属性可 hover 查看原始时间：<time datetime="2024-05-20T09:30" title="2024-05-20 09:30:00">5月20日</time>
移动端公告列表滚动卡顿，是不是该上虚拟列表？
不到 50 条不用。真实瓶颈往往在 CSS：比如每条公告用了 box-shadow + border-radius + background-image，或者父容器设置了 overflow: hidden 但子元素有动画。先检查是否触发了全层重绘（paint）——用 Chrome DevTools 的 Rendering 面板勾选 “Paint flashing”，滚动时大片绿色闪动就是问题。
常见错误：一卡就以为是 DOM 太多，急着引入虚拟列表库，结果发现是某条公告里嵌了个未设宽高的 <img>，导致 layout 波动；或者用了 position: sticky 但没加 will-change: transform，iOS Safari 直接掉帧。
- 优先优化 CSS：移除不必要的
filter、用transform: translateZ(0)提升合成层（慎用，别滥用）、图片加loading="lazy" - 超过 100 条再考虑虚拟列表，但注意：服务端分页比前端虚拟化更省资源，用户拉到底再请求下一页即可
- 如果必须前端虚拟化，别手写，用
react-window或vue-virtual-scroller，自己算scrollTop和offsetTop容易在 iOS 上因缩放失准
最常被忽略的点：公告列表里混入了第三方统计脚本的 <script> 标签，或内联了未压缩的 JSON-LD 结构化数据，这些都会阻塞解析和渲染，比 DOM 数量影响更大。
