html步骤条仅为视觉容器，无流程引导能力；是否需要js控制取决于业务逻辑需求，如多步表单必须校验、同步状态、维护aria属性并处理前后导航逻辑。

HTML 步骤条本身不自带流程引导能力，它只是视觉容器；是否需要流程引导，取决于你是否要控制用户操作顺序、校验状态或同步 UI 与业务逻辑。

步骤条不等于流程控制

用 <ol></ol> 或 <div class="step"> 渲染的步骤条，本质是静态结构。点击第 3 步不会自动跳转、不会阻止未完成第 2 步就提交、也不会高亮“已完成”状态——这些都得靠 JS 主动实现。 <ul> <li>纯 HTML/CSS 步骤条只负责展示，<code>aria-current 和 aria-disabled 等属性需手动维护

浏览器不会因步骤条存在而限制表单提交或路由跳转

无障碍支持（如屏幕阅读器播报进度）必须配合语义化标签 + 动态 aria-valuenow 更新

什么时候必须加流程引导

当步骤之间有强依赖关系时，比如注册多步表单、安装向导、支付流程，就必须用 JS 控制步骤流转逻辑，否则用户可能跳过必填项或触发非法状态。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 用户点击未完成步骤时，应 preventDefault() 并提示“请先完成上一步”
• 每步离开前需调用校验函数（如 validateStep2()），仅当返回 true 才允许进入下一步
• URL 路径（如 /setup/step3）和步骤条高亮状态需双向同步，避免刷新后丢失上下文

aria- 属性不是摆设，但不能替代逻辑

aria-disabled="true" 可让屏幕阅读器知道某步不可点，但它不会禁用 DOM 事件——你仍需在 click 处理中判断并拦截。

• 错误写法：<button aria-disabled="true">下一步</button> 却没绑定 onclick 拦截
• 正确做法：用 disabled 属性（对原生按钮生效）或 pointer-events: none + aria-disabled 双保险
• aria-label 建议包含当前步骤状态，例如 "步骤2：填写信息，已完成"，而非静态文本

最常被忽略的是「后退」逻辑：用户点上一步时，是否该清空后续步骤数据？是否要重新校验？这些细节不写进 JS，步骤条再好看也只是个装饰画。