HTML用data-status属性标记状态（如data-status="pending"），配合CSS类视觉区分，需由服务端或JS驱动更新，不可写死，须避免误用progress等语义不符标签。
HTML里怎么表示“审核中→已处理”这种状态流转
纯HTML本身不负责状态逻辑，它只负责呈现。所谓“审核中→已处理”，本质是服务端或JS控制的视图更新，HTML只提供语义化容器和可读标记。别试图用HTML属性自动驱动状态变化——data-status可以存值，但不会自己变。
- 用
data-status属性标记当前状态，比如<div data-status="pending">或<span data-status="processed"> - 配合CSS类做视觉区分：
status-pending显示黄色圆点，status-processed显示绿色对勾 - 禁止用
disabled、readonly这类表单属性表达业务状态——它们只对交互控件有效，且语义不符 - 如果状态要被屏幕阅读器感知，加
aria-live="polite"在状态容器上，再用JS动态更新文本内容
为什么不能只靠CSS类切换状态（比如 .status-pending → .status-processed）
CSS类切换只是样式层面的响应，用户看不到“流转”过程，也缺乏可访问性和数据绑定能力。真实场景中，“审核中”变成“已处理”往往伴随接口返回、时间戳更新、操作按钮显隐等联动，光靠CSS做不到。
- 类名切换无法传递结构化信息给JS或后端，比如缺少时间、操作人、失败原因等上下文
- 多个组件共用同一状态时，仅靠类名容易冲突（例如两个
.status-processed但含义不同） - 服务端渲染页面时，若直接输出
class="status-processed"，前端JS再想“回退”到中间态会丢失原始状态值 - 推荐组合：
data-status="processed"+data-timestamp="2024-06-12T14:23:00Z"+data-operator-id="u789"
常见错误：把状态写死在HTML里还号称“动态”
比如静态页面里硬编码<span class="status" data-status="processed">已处理</span>，但实际该条目还在队列里没被人工审核。这种“假状态”会导致用户误判、运营查数偏差、甚至引发客诉。
- 状态必须由可信数据源驱动：要么服务端模板渲染时注入（如PHP/Node.js模板），要么前端发起
fetch后解析JSON更新DOM - 避免“先渲染占位，再异步覆盖”导致的闪动或不一致，尤其在列表页中多个条目状态不同步时
- 注意缓存问题：CDN或浏览器缓存了旧HTML，
data-status可能长期不变，需配合ETag或版本号强制刷新 - 调试时直接查看元素的
data-status值，比看文字内容更可靠——文字可能被CSS隐藏或翻译插件改写
用progress标签不合适，别被名字误导
<progress>是为百分比进度设计的（如文件上传0%→100%），不是为离散业务状态（pending/processing/processed/rejected）准备的。强行用它表达“审核中→已处理”，既不符合语义，也会让辅助技术误读为数值型任务。
立即学习“前端免费学习笔记（深入）”；
-
<progress value="1" max="3">这种写法看似能映射三阶段，但value只能是数字，无法携带状态名、时间、原因等关键信息 - 屏幕阅读器会读成“进度 33%”，而不是“审核中”，完全丢失业务含义
- 真正需要可视化进度条的场景极少——举报处理通常是原子操作，没有中间百分比，只有明确的状态跃迁
- 替代方案：用带图标和文字的
<span>+ CSS伪元素，或SVG状态流程图（仅作示意，不参与逻辑）
