table 更稳妥——语义正确、兼容性好、打印开箱即用；仅当数据具行列关系时使用，并严格遵循 thead/tbody/th/scope 规范。
用户列表用 table 还是 div + CSS Grid？
纯静态 HTML 管理系统里，table 是更稳妥的选择——不是因为它“过时”，而是它天然语义正确、浏览器兼容性极好、打印样式开箱即用，且在无 JS 渲染的场景下不会塌陷。用 div + display: grid 虽然灵活，但 IE11 及更早版本不支持，而很多内部管理系统仍需兼容这类环境。
常见错误是把 table 当成“布局工具”滥用，结果导致响应式断点失效或屏幕阅读器识别混乱。正确做法是：仅当数据具备行列关系（如姓名、学号、班级、状态）时才用 table，并严格使用 thead、tbody、th 和 scope 属性。
-
th必须放在thead内，且带scope="col" - 每行
tr中的单元格用td，不要混用th - 避免嵌套
table实现“复杂布局”，那会破坏可访问性
人员信息字段怎么组织才清晰？
静态系统没有后端校验，字段顺序直接影响用户操作效率。姓名、工号/学号这类唯一标识必须前置；状态（如“在职”“休学”）建议用带颜色的 span 包裹，而不是纯文字；联系方式等次要字段可折叠或放最后列。
容易踩的坑是把所有字段平铺一排，导致小屏设备横向滚动严重。解决方法是：在桌面端保持 5–6 列，移动端用 @media 隐藏非关键列（如“创建时间”），或改用卡片式堆叠（div 块每行只显一条记录）。
立即学习“前端免费学习笔记（深入）”；
- 必显字段：姓名、编号、状态、操作（编辑/删除按钮）
- 可选隐藏字段：入职日期、部门、备注
- 电话/邮箱等长文本字段加
text-overflow: ellipsis防溢出
“操作”列里的按钮怎么写才不翻车？
静态页面没有路由，所以“编辑”按钮不能写成 <a href="edit.html?id=123"></a> 这种硬跳转——ID 无法透传，且缺乏上下文。更实际的做法是用 data- 属性携带信息，配合内联 JS 绑定行为：
<button class="btn-edit" data-id="123" data-name="张三">编辑</button>
这样后续哪怕加 JS 逻辑（比如弹出表单预填值），也不用改 HTML 结构。注意别用 onclick 行内事件，它会让代码难以维护，也违反渐进增强原则。
- 所有按钮统一加
type="button"，防止意外提交表单 - 删除按钮建议加二次确认，用
confirm()就够用，别强求模态框 - 禁用状态用
disabled属性，别只靠 CSS 灰掉
为什么表格排序和搜索功能总卡住？
静态页面做前端排序，本质是 DOM 操作。直接对 tbody 的 tr 排序没问题，但常见错误是没重置 data- 属性或忽略表头点击区域的 th 是否可点击。另外，中文排序默认按 Unicode 码点，会导致“张三”排在“李四”前面——得用 localeCompare('zh-CN')。
搜索功能若用 indexOf() 匹配，记得先转小写（toLowerCase()），否则“张三”搜“张三”能匹配，“张三”搜“zhangsan”就失败。性能上，百条以内数据无需防抖，但超过 300 条建议加节流。
- 排序时保留原始 DOM 顺序，只移动
tr，别重建整张表 - 搜索建议高亮关键词，用
innerHTML替换时注意 XSS，简单场景可用textContent+span包裹 - 空结果状态必须显式提示，比如插入一个
<tr><td colspan="6">未找到匹配项</td></tr>
真正麻烦的从来不是怎么画出一张表，而是当客户说“这个字段要加个下拉筛选”“导出 Excel”“支持 Ctrl+F 全局搜姓名”时，你得在零后端、零构建工具的前提下，用原生 JS 控制好边界条件——比如导出功能，blob + URL.createObjectURL 在 iOS Safari 上不支持，就得降级为手动复制 CSV 字符串。
