订单状态最稳妥用<span>包裹文本并配语义化class；卡片用Flexbox响应式布局；状态需图标+文字双重提示且禁用click；大数据量时禁用过渡、用textContent更新、加虚拟滚动或分页。
订单状态用什么 HTML 结构最稳妥？
直接用 <span> 包裹状态文本，配合语义化 class 名，比如 order-status--pending、order-status--shipped。别用 <div> 套状态文字——它默认块级，会破坏行内对齐；也别为了“语义”硬套 <progress> 或 <meter>，它们有特定含义和 ARIA 要求，订单状态不是进度值。
- 状态文案必须可读、不可省略（如“待支付”不能只写“待”）
- 每个状态对应唯一
class，方便 CSS 控制背景色、边框和文字颜色
- 避免在
class 里塞动态值（如 status-{{item.status}}），CSS 难维护，也增加 SSR 渲染负担
怎么让订单卡片在不同屏幕下保持可用性？
用 Flexbox 布局主容器，flex-direction: column 用于移动端，flex-direction: row 用于桌面端，靠媒体查询切换。别依赖 CSS Grid 做基础流式布局——IE11 兼容性差，且简单列表用 Grid 反而增加复杂度。
- 关键信息列（订单号、时间、金额）设固定最小宽度，防小屏下文字挤成一团
- 状态标签始终放在右上角或操作栏右侧，用
margin-left: auto 或 justify-content: flex-end 对齐
- 点击区域（如“查看订单”按钮）高度至少 44px，满足移动端触控最小尺寸
状态颜色和交互反馈怎么避免踩坑？
颜色不能仅靠色值区分状态（比如只用红/绿），必须叠加图标或文字样式。色弱用户可能无法分辨 #e74c3c 和 #27ae60 的差异。同时，悬停态（:hover）和焦点态（:focus）要一致，尤其当用户用键盘 Tab 导航时。
- 每个状态加统一前缀图标，如 ⏳ 表示“待支付”，? 表示“已发货”，用
<span aria-hidden="true"> 包裹，再配 aria-label 说明
- 禁用状态（如“已取消”）用
pointer-events: none + opacity: 0.6，别只靠灰度色——用户仍可能误点
- 不要在状态标签上绑
click 事件，它不是操作入口；操作按钮单独放，位置稳定、命名明确（如 btn-order-detail）
数据量大时 DOM 怎么不卡？
纯静态 HTML 列表没问题，但若订单数超 50 条且含图片、状态动画，得做两件事：一是状态标签禁用 CSS 过渡（transition: none），二是用 will-change: transform 换掉 transform 动画——后者在低端 Android 上易触发重绘卡顿。
- 状态变化频繁时（如轮询更新），用
textContent 替代 innerHTML 更新标签内容，避免重新解析 HTML
- 列表滚动区域加
overflow-y: auto 和 max-height，防止页面被撑爆
- 真要渲染几百条？上虚拟滚动，但先确认是否真需要——多数场景分页更简单可靠
状态样式看似简单，但字体大小、行高、图标对齐、禁用态的可访问性提示，每项都容易漏测。特别是多语言环境下，“已发货”变成“Shipped”后，图标位置和容器宽度可能偏移——别只在中文版验证。
class，方便 CSS 控制背景色、边框和文字颜色class 里塞动态值（如 status-{{item.status}}），CSS 难维护，也增加 SSR 渲染负担flex-direction: column 用于移动端，flex-direction: row 用于桌面端，靠媒体查询切换。别依赖 CSS Grid 做基础流式布局——IE11 兼容性差，且简单列表用 Grid 反而增加复杂度。
- 关键信息列（订单号、时间、金额）设固定最小宽度，防小屏下文字挤成一团
- 状态标签始终放在右上角或操作栏右侧，用
margin-left: auto或justify-content: flex-end对齐 - 点击区域（如“查看订单”按钮）高度至少 44px，满足移动端触控最小尺寸
状态颜色和交互反馈怎么避免踩坑？
颜色不能仅靠色值区分状态（比如只用红/绿），必须叠加图标或文字样式。色弱用户可能无法分辨 #e74c3c 和 #27ae60 的差异。同时，悬停态（:hover）和焦点态（:focus）要一致，尤其当用户用键盘 Tab 导航时。
- 每个状态加统一前缀图标，如 ⏳ 表示“待支付”，? 表示“已发货”，用
<span aria-hidden="true"> 包裹，再配 aria-label 说明
- 禁用状态（如“已取消”）用
pointer-events: none + opacity: 0.6，别只靠灰度色——用户仍可能误点
- 不要在状态标签上绑
click 事件，它不是操作入口；操作按钮单独放，位置稳定、命名明确（如 btn-order-detail）
数据量大时 DOM 怎么不卡？
纯静态 HTML 列表没问题，但若订单数超 50 条且含图片、状态动画，得做两件事：一是状态标签禁用 CSS 过渡（transition: none），二是用 will-change: transform 换掉 transform 动画——后者在低端 Android 上易触发重绘卡顿。
- 状态变化频繁时（如轮询更新），用
textContent 替代 innerHTML 更新标签内容，避免重新解析 HTML
- 列表滚动区域加
overflow-y: auto 和 max-height，防止页面被撑爆
- 真要渲染几百条？上虚拟滚动，但先确认是否真需要——多数场景分页更简单可靠
状态样式看似简单，但字体大小、行高、图标对齐、禁用态的可访问性提示，每项都容易漏测。特别是多语言环境下，“已发货”变成“Shipped”后，图标位置和容器宽度可能偏移——别只在中文版验证。
<span aria-hidden="true"> 包裹，再配 aria-label 说明pointer-events: none + opacity: 0.6，别只靠灰度色——用户仍可能误点click 事件，它不是操作入口；操作按钮单独放，位置稳定、命名明确（如 btn-order-detail）transition: none），二是用 will-change: transform 换掉 transform 动画——后者在低端 Android 上易触发重绘卡顿。
- 状态变化频繁时（如轮询更新），用
textContent替代innerHTML更新标签内容，避免重新解析 HTML - 列表滚动区域加
overflow-y: auto和max-height，防止页面被撑爆 - 真要渲染几百条？上虚拟滚动，但先确认是否真需要——多数场景分页更简单可靠
