factory、builder、composite 三类设计模式可落地纯静态html项目：builder用于动态生成结构稳定的内容片段，composite对应html天然嵌套关系，factory适用于多变体组件的统一创建；其余依赖运行时状态的模式基本无效。
HTML组件化里哪些设计模式真能落地
纯静态HTML项目中，Factory、Builder、Composite 这三类模式有明确对应点；Singleton 或 Observer 等依赖运行时状态的模式，在无JS或仅轻量JS场景下基本无效。
用 Builder 模式生成 HTML 片段，而不是写死结构
当你需要动态拼接卡片、表单或邮件模板这类结构稳定但内容可变的 HTML 时，Builder 比字符串拼接更可控、易测试。它不依赖框架，手写几行 JS 就能实现。
-
Builder类只定义方法骨架（如addTitle()、addImage()），不关心最终怎么渲染 -
Director控制组装顺序，比如先标题、再图、再描述——这个逻辑可复用于不同主题的卡片 - 具体实现类（如
LightCardBuilder/DarkCardBuilder）决定每个部件的 class 名、属性值或内联样式 - 避免直接拼
"<div class="card">...</div>"：一旦 class 名变更或结构微调，所有拼接点都要改；而 Builder 只需改一个实现类
Composite 模式对应 HTML 的嵌套容器关系
div、section、article 天然构成树形结构，Composite 不是让你重写 DOM API，而是帮你理清“谁该管子节点”“谁不该支持 add/remove”。
- 叶子节点（如
img、input）不实现addChild()，强行调用应抛UnsupportedOperationException（JS 中 throw new Error()） - 组合节点（如自定义
<nav-menu></nav-menu>）必须提供addItem()和render()，且内部递归调用子项的render() - 常见错误：把
aside当作通用容器往里塞导航、广告、联系表单——它不是Composite，而是语义上可剥离的附属内容，不该承载管理逻辑 - 实际判断标准：如果删掉某个元素，其子元素在页面中失去上下文或无法独立存在，那它大概率不该是组合节点
Factory 模式用于组件实例化，但别滥用
当同一类组件有多个视觉变体（如 btn--primary、btn--outline、btn--icon），且创建逻辑分散在多处时，Factory 才值得引入。
- 工厂函数接收配置对象（如
{ type: 'icon', icon: 'download' }），返回已设置好 class 和 data- 属性的HTMLElement - 禁止让工厂返回字符串 HTML——那样无法绑定事件、无法访问实例方法、无法做无障碍属性注入
- 如果只有两三种固定变体，且都在同一模块内创建，直接用 switch +
document.createElement()更轻量 - 真正需要抽象的是“创建后要立即初始化”的场景，比如按钮要自动绑定点击统计、输入框要挂载验证逻辑
组件化不是堆设计模式，而是用最简契约约束 HTML 结构的可替换性。class 前缀、data- 属性、语义标签边界——这些才是每天要检查的东西；模式只是帮你在复杂度上升时守住边界。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
