纯HTML模板不支持状态管理，必须由JavaScript类或函数接管生命周期与DOM更新；原生HTML无法解析{{}}等逻辑语法，需依赖模板引擎或框架，而服务端与前端状态应严格分离。
纯 HTML 模板本身不支持状态管理，想让它承载复杂逻辑，必须靠 JavaScript 主动接管——不是“把 JS 塞进模板”，而是让模板退为纯结构容器，由 JS 类或函数控制生命周期、数据流与 DOM 更新。
为什么不能直接在 HTML 模板里写状态逻辑
HTML 是声明式标记语言，th:if、{{ count }} 这类语法依赖模板引擎（如 Thymeleaf、Handlebars）或框架（如 Vue）的运行时解析。原生浏览器加载 index.html 时，所有双大括号、指令标签都会被当作文本原样显示，根本不会执行逻辑。
- 常见错误现象：
{{ user.name }}直接出现在页面上，而不是渲染成 “张三” - 服务端模板（如 Thymeleaf）需后端参与编译，无法脱离 Spring Boot 环境单独调试
- 前端模板引擎（如 Handlebars）虽可纯前端运行，但缺乏响应式更新能力：数据变了，DOM 不自动同步
- 手动 DOM 操作易漏更新、难追踪副作用，尤其在表单联动、列表排序等多状态交织场景下
用 Class 封装组件 + 原生 <template> 做结构载体
这是轻量但可控的集成路径：HTML 提供语义化骨架，JS 类负责状态、事件与渲染闭环。
-
<template id="todo-item"><li class="todo-item"><span class="text"></span><button class="delete">×</button></li></template>—— 只定义结构，不参与初始渲染 - 定义
TodoItem类，内部维护this.state = { text: '', completed: false } - 提供
render()方法：克隆template.content，填充文本、绑定事件监听器，并返回DocumentFragment - 关键点：所有事件监听必须在
render()中重新绑定（因为每次克隆都是新节点），且销毁时要手动removeEventListener
Redux 驱动 HTML 视图更新的最小可行链路
适合已有全局状态诉求、又不想引入框架的项目。核心是切断“DOM → JS → DOM”的手动映射，改用单向数据流。
立即学习“前端免费学习笔记（深入）”；
- 初始化 store 时，
createStore(reducer, initialState)必须传入完整初始状态对象，不能留空 - 在
store.subscribe(() => render(store.getState()))中调用render，但render函数不能粗暴innerHTML = ''全量重绘——应只更新变化字段，例如：document.getElementById('count').textContent = state.count - 避免在 reducer 里操作 DOM 或调用异步 API；所有副作用（如保存到 localStorage）应在
dispatch后由监听器处理 - 若多个元素共用同一状态字段（如 5 个按钮都显示
state.loading），别重复查getElementById，缓存节点引用更高效
Thymeleaf 片段嵌套中状态逻辑的边界划分
服务端渲染场景下，“状态”实际分两层：后端 Model 是静态快照，前端 JS 是动态行为。混淆二者会导致刷新丢失状态或服务端/客户端渲染不一致。
- Thymeleaf 的
th:fragment只负责结构复用，不传递运行时状态；th:each渲染出的每个<tr>是独立 DOM 节点，JS 事件委托必须基于父容器（如tbody）绑定 - 不要在
th:fragment内写onclick="updateCount()"这类内联 JS —— 它会随每次片段插入重复注册，造成多次触发 - 后端传来的布尔值（如
user.active）可用于服务端条件渲染（th:if="${user.active}"），但用户点击切换激活态这类操作，必须由前端 JS 发起 API 请求并局部更新 DOM - 若用
th:attr="data-id=${user.id}"向 DOM 注入后端 ID，前端 JS 取值时统一用dataset.id，避免手动解析getAttribute('data-id')
真正难的不是“怎么把状态塞进 HTML”，而是决定哪部分状态该由谁管：后端 Model 控制初始数据和权限态，前端 JS 管理交互反馈与临时 UI 状态（如表单校验错误、折叠展开）。混用两者，迟早遇到服务端渲染和客户端 hydration 对不上号的问题。
