纯HTML无法实现工作流引擎，必须依赖JavaScript补足状态管理、条件跳转等能力；自定义元素仅负责渲染与属性响应，业务逻辑由外部JS控制。
纯 HTML 无法实现“工作流引擎”——它没有状态管理、条件跳转、节点依赖解析或运行时调度能力。所谓“HTML 工作流组件”，本质是静态结构渲染 + 有限交互，最多模拟流程图展示或线性步骤切换。真要驱动工作流逻辑，必须靠 JavaScript 补足。
用 customElements.define() 封装可配置的流程容器
你可以把整个工作流视图封装成一个自定义标签，比如 <workflow-steps>，但它只负责渲染和响应属性变化，不执行业务逻辑。
- 标签名必须含短横线（如
workflow-steps），否则浏览器拒绝注册 - 通过
static get observedAttributes()声明监听current、steps等属性，但注意：steps是字符串，需JSON.parse(this.getAttribute('steps'))转换，且不能传对象字面量 -
connectedCallback()中只做一次初始化渲染；后续步骤切换应由外部 JS 控制该元素的current属性，触发attributeChangedCallback() - 别在 Shadow DOM 里放
<script>标签——它不会执行
用 <template> + cloneNode(true) 实现步骤模板复用
每个步骤块结构一致（标题、描述、状态图标、操作按钮），适合抽成模板。直接写死在 HTML 里比 JS 拼字符串更安全、易维护。
- 模板内避免硬编码文字，改用
slot或data-*占位，例如<span data-role="step-title"></span> - 克隆后用
querySelectorAll('[data-role]')批量填充，比递归遍历快且可控 - 不要用
innerHTML = template.innerHTML—— 会丢失<style>和事件绑定，且可能执行脚本 - 如果步骤数超 20，建议加
document.createDocumentFragment()批量插入，避免频繁重排
用 dataset + 自定义事件驱动简单流转
真正的“引擎”行为（如点击「下一步」校验表单、调用 API、跳转到指定节点）必须由页面级 JS 控制，组件只暴露契约接口。
立即学习“前端免费学习笔记（深入）”；
- 组件内部触发
new CustomEvent('stepchange', { detail: { from: 1, to: 2 } })，外部监听并决定是否允许跳转 - 禁用按钮状态靠
button.disabled = true，别只靠 CSS 类——屏幕阅读器和键盘用户会失效 - 用
this.dataset.stepIndex存当前序号，比从 class 名里 parse 更可靠（class="step step--active"不具备机器可读性） - 错误提示不要塞进组件 shadowRoot 内部——外部 JS 难以注入内容，应预留
<slot name="error"></slot>
为什么不用 fetch() 动态加载步骤 HTML？
看似模块化，实则引入不可控变量：网络延迟、CORS、HTML 解析失败、无错误降级路径。对工作流这类强顺序场景风险过高。
- 若真要拆分，用 ES 模块导出 JSON 结构（非 HTML 字符串），再由主组件统一渲染
- 服务端 SSI 或构建时 HTML include 更稳妥，但失去运行时灵活性
- CodePen / StackBlitz 等在线环境不支持本地
fetch('./steps.html')，调试会卡死 - 所有动态加载的 HTML 片段，都得手动 re-init 里面的事件监听器和第三方库实例，极易漏掉
真正难的不是画出流程图，而是让每一步的“完成”有明确判定依据、每条“分支”有可测试的条件表达式、每次“回退”能还原真实状态。这些必须脱离 HTML 的声明式边界，在 JS 层建模。把 HTML 当画布，不是引擎。
