工单页面设计核心在于状态可视化、操作可达性与列表密度控制；应使用语义化HTML（如<article>）、CSS Grid布局、清除list-style、合理焦点管理，避免滥用<div>嵌套和<table>整体布局。
直接说结论：工单页面不是“堆完
用 + 而不是一堆 套嵌套工单本质是“可独立存在、带状态、需操作”的内容单元，<article> 比 <div> 更贴切——它自带语义，支持无障碍阅读器聚焦，也方便后续用 prefers-reduced-motion 或 dark-mode 做条件样式切换。
常见错误是把整个工单列表包在 <div class="list"> 里，再给每条工单加 <div class="item">，结果 JS 批量操作时找不到语义锚点。
推荐结构：
<section aria-label="工单列表">
<header><h2>待处理工单（12）</h2></header>
<article data-id="1001" data-status="pending">
<header><h3>[P1] 登录页验证码不显示</h3></header>
<p>用户反馈 iOS 17.5 下无法加载验证码图片</p>
<footer><button data-action="assign">指派</button></footer>
</article>
<article data-id="1002" data-status="in-progress">
...
</article>
</section>表格布局只用于字段对齐，别用
做整体页面结构工单详情字段（如“创建时间”“负责人”“优先级”）适合用 <dl> 或 <table> 展示，但整页用 <table> 布局会带来三个硬伤：
• 屏幕阅读器会逐行读出空 <tr> 和占位 <td>，信息噪音大
• colspan/rowspan 在响应式断点下极易错格，尤其当某列内容超长换行时
• 无法用 grid-template-areas 实现“左侧筛选栏 + 右侧工单流”的现代看板布局
正确做法是：用 <table> 仅包裹字段表格（且必须加 <thead> 和 <tbody>），其余区域交由 CSS Grid 或 Flex 控制。
列表项水平排列用 display: flex，但必须关掉 list-style
工单筛选标签（如“全部”“待处理”“已关闭”）或状态徽章（<span class="status-badge">已解决</span>）常需横向紧凑排列，此时若直接对 <ul> 设 display: flex，默认的圆点 list-style 会挤到文字左侧甚至被裁切。
必须显式清除：
立即学习“前端免费学习笔记（深入）”；
ul.status-filter {
display: flex;
gap: 8px;
padding: 0;
margin: 0;
}
ul.status-filter li {
list-style: none; /* 关键！否则圆点残留 */
margin: 0;
}另外注意：
• 不要用 float: left 模拟横向排列，父容器不设 clear 会导致后续元素上浮
• gap 比 margin 更可靠，避免最后一项多出右侧外边距
• 移动端小屏下建议改用 flex-direction: column，并加大点击区域（padding: 10px 16px）
响应式工单流的关键是 grid-template-rows 而非 width 百分比
工单列表在桌面端常需“左筛选栏（240px）+ 主内容区（剩余）”，但硬写 width: 20% / width: 80% 会失效——因为工单卡片高度不一，Flex 容器无法自动对齐行尾。
CSS Grid 是更稳的选择，重点不是列宽，而是行高分配逻辑：
.ticket-container {
display: grid;
grid-template-areas:
"filter main"
"filter main"
"filter main";
grid-template-rows: minmax(0, 1fr) minmax(0, 1fr) minmax(0, 1fr); /* 三行等高，内容自适应 */
grid-template-columns: 240px 1fr;
}
.sidebar { grid-area: filter; }
.main-list { grid-area: main; }这样即使某张工单内容很长撑开第一行，第二、三行仍能保持高度一致，滚动时视觉节奏稳定。如果用 flex-wrap: wrap，高度差异大会导致卡片错位，用户容易漏看。
工单页面最易被忽略的其实是焦点管理——比如批量操作后，键盘用户按 Tab 键该落到哪？不是所有团队都记得给 <article> 加 tabindex="0"，也不是所有状态变更都触发 aria-live 提示。这些细节不处理，页面就只是“能看”，不是“可用”。
工单本质是“可独立存在、带状态、需操作”的内容单元，<article> 比 <div> 更贴切——它自带语义，支持无障碍阅读器聚焦，也方便后续用 prefers-reduced-motion 或 dark-mode 做条件样式切换。
常见错误是把整个工单列表包在 <div class="list"> 里，再给每条工单加 <div class="item">，结果 JS 批量操作时找不到语义锚点。
推荐结构：
<section aria-label="工单列表">
<header><h2>待处理工单（12）</h2></header>
<article data-id="1001" data-status="pending">
<header><h3>[P1] 登录页验证码不显示</h3></header>
<p>用户反馈 iOS 17.5 下无法加载验证码图片</p>
<footer><button data-action="assign">指派</button></footer>
</article>
<article data-id="1002" data-status="in-progress">
...
</article>
</section>
