可用的群组列表须用语义化标签（如<ul>+<li>+<button>）实现可聚焦、可键盘操作、屏幕阅读器友好的点击交互，配合aria-selected控制选中态，并确保移动端点击区域≥44×44px。
怎么用 HTML + CSS 实现可点击的群组列表项
纯 HTML 无法“响应点击”或“高亮选中”，必须配合 click 事件和 CSS 状态控制。常见错误是只写 <div> 列表，结果点击没反馈、键盘不可聚焦、屏幕阅读器无法识别——这不算真正可用的群组列表。
推荐用语义化标签起步：<ul> 包裹 <li>，每个 <li> 内部用 <button> 或带 role="button" 的 <div>。按钮天然支持空格/回车触发、焦点管理、:focus 样式。
- 避免直接给
<li>绑定onclick：它默认不可聚焦，键盘用户无法操作 - 如果必须用
<div>，务必加tabindex="0"和role="button" - 选中态建议用 JS 切换
aria-selected="true"属性，再用 CSS 的[aria-selected="true"]匹配样式，比纯 class 更利于辅助技术
群头像 + 名称 + 成员数的三段式布局怎么对齐不崩
头像尺寸不一致、文字行数不同、成员数动态变化，都会导致列表项高度参差。CSS Grid 比 Flexbox 更稳，尤其在多行文本场景下。
关键不是“怎么居中”，而是“如何让三段内容各自独立撑开又保持基线对齐”。推荐结构：
立即学习“前端免费学习笔记（深入）”；
<li>
<button type="button">
<img src="group1.jpg" alt="技术讨论组" width="40" height="40">
<span class="group-info">
<span class="group-name">技术讨论组</span>
<span class="member-count">24人</span>
</span>
</button>
</li>
-
<img>加width/height属性（非 CSS），防止加载时布局抖动 -
.group-info设为display: grid; grid-template-columns: 1fr max-content;，让名称占满、人数右对齐 -
.group-name加line-clamp: 1防止超长换行撑高整行 - 避免用
vertical-align: middle配合inline-block：在字体渲染差异下容易错位
点击切换群组时，如何避免重复渲染整个列表
如果每次点击都重绘全部 <li>，滚动位置会丢失、动画卡顿、DOM 节点频繁销毁重建——特别是群组数超过 50 个时明显。
正确做法是只更新状态属性和局部样式，不替换 HTML 结构：
- 用
document.querySelector('[aria-selected="true"]')找到当前选中项，移除其aria-selected - 给新点击项设置
aria-selected="true"，CSS 自动生效 - 如需异步加载群聊消息，应在点击后仅更新右侧聊天区，不要 touch 左侧列表 DOM
- 真要批量更新（比如群成员变动），用
DocumentFragment批量操作，而非循环innerHTML += ...
移动端点击区域太小，iOS 上经常点不中怎么办
iOS Safari 默认忽略小于 44×44px 的可点击区域，哪怕你写了 onclick 也没用。这不是 bug，是 WCAG 可访问性强制要求。
- 确保每个群组项的可点击容器（如
<button>）最小尺寸 ≥ 44×44px - 不要靠 padding 勉强撑开：iOS 对
padding不敏感，优先用min-width/min-height - 如果头像只有 32px，就把点击热区扩大到包裹它的
<button>，而不是只围住头像 - 测试时用 iOS 真机开启“缩放文字”和“粗体文本”，看是否仍能稳定点击
群组列表看着简单，但跨端一致性、可访问性、性能边界全藏在细节里。最容易被跳过的其实是 aria-selected 的同步时机和移动端最小点击尺寸——这两个点一漏，PC 上好好的，发到微信内置浏览器就点不动了。
