用户列表应使用语义化而非，必须包含和，操作按钮须为，小屏需响应式转卡片布局，确保可访问性与结构完整性。
用户列表页面不是表格的堆砌现场，而是结构、语义和交互的交汇点。用 <table> 展示用户数据本身没问题，但把它当布局工具、忽略可访问性、漏掉关键属性，页面就只剩“能看”，而没有“能用”“能搜”“能读”。
<h3>为什么不能直接用 <code><div> 套列表项做用户列表
<p>很多人图省事写一串 <code><div class="user-item">，视觉上整齐，但问题藏在底层：
<ul>
<li>屏幕阅读器无法识别这是“用户列表”，会把每条当作孤立段落朗读，丢失上下文</li>
<li>搜索引擎抓不到“这是 27 个用户”，<code>class 名对爬虫毫无意义
<div> 没有行/列/头/体概念，JS 处理成本翻倍
<li>键盘导航（Tab 键）会把每个子 <code><div> 当作独立焦点，体验碎片化
<h3><code><table> 的正确打开方式：必须带 <code><thead> 和 <code><tbody><p>用户列表本质是二维结构化数据（姓名、邮箱、状态、操作），<code><table> 是语义最匹配的标签。但只写 <code><tr><td> 是半残废——缺了 <code><thead> 和 <code><tbody>，就等于没告诉浏览器“哪些是标题、哪些是数据”。
<ul><li><code><thead> 必须包裹表头行（<code><tr>），里面用 <code><th> 而非 <code><td>；它让辅助工具知道“这列叫‘注册时间’”
<li><code><tbody> 包裹所有用户数据行，是 JS 批量操作（如删除、选中）的天然作用域
<li>别用 <code>border="1" 这种过时属性，用 CSS 控制边框；但 border-collapse: collapse 要保留，避免单元格缝隙错位<th> 加 <code>scope="col"，明确它是列标题，方便屏幕阅读器关联数据行
操作列按钮必须是 <button></button> 或带 role="button" 的元素
“编辑”“禁用”“删除”这类操作不是装饰文字，是可触发行为的控件。写成 <span class="btn">删除</span> + JS 绑定，等于主动放弃可访问性：
- 键盘用户按 Tab 键跳不过去，无法聚焦
- 屏幕阅读器不会提示“这是一个按钮”，只会读“删除”两个字，缺少动词语境
- 移动端触摸目标太小，
<span></span>默认无padding，易误触
正确写法是：<button type="button" data-user-id="123">删除</button>。注意 type="button" 防止表单意外提交；data-user-id 存 ID 比从文本里 parse 更可靠。
响应式断点下，<table> 别硬撑，该转卡片就转卡片
<p>小屏上强行横向滚动 <code><table> 是反人类设计。CSS Grid 或 Flex 可以优雅降级：
<ul><li>桌面端保持 <code><table>，用媒体查询在 <code>max-width: 768px 下隐藏 <thead> 并设 <code>display: block 于 <tbody><li>每行 <code><tr> 改为 <code>display: flex; flex-direction: column，内部 <td> 变成带标签的块：<code><div class="field">
<span class="label">邮箱：</span><span class="value">user@x.com</span>
</div>
display: grid 配 grid-template-areas，让每条用户数据自成一个区域（"name email status action"），不依赖表格 DOMoverflow-x: auto 包裹整个 <table>，那只是把问题藏起来，不是解决
<p>真正难的不是怎么让列表“显示出来”，而是让每一条用户数据，在任何设备、任何辅助工具、任何网络条件下，都保有它本该有的含义和操作能力。标签选错，后面补 JS、加 ARIA、调样式，都是在修漏水的桶。</p>
</table>
