htmx 4.0 发布：改用 Fetch API 重写，内置 DOM Morphing Swap，并明确属性继承规则

专注AI 大模型与前沿科技深度解析习惯从工程师视角拆解技术热点让我们一起在技术浪潮中保持清醒与好奇 htmx 4.0 发布改用 Fetch API 重写内置 DOM Morphing Swap并明确属性继承规则30 秒结论htmx 4.0 是一次彻底的重写底层从XMLHttpRequest切换到Fetch API网络层代码几乎全部重写同时引入hx-swapmorph的内置 DOM Morphing 能力并首次以正式文档形式明确属性继承规则。适合谁正在用 htmx 3.x 做服务端渲染项目、希望减少手写 JavaScript 的开发者想以超文本驱动思路构建交互页面、又不想引入 React/Vue 全套工具链的学生与转行者。不适合谁重度依赖前端状态管理、需要复杂客户端路由或离线优先的 SPA 项目团队已经深度绑定 Vue/React 生态且没有迁移动力的情况。迁移成本官方提供了upgrade-check工具扫描模板文件但属性继承规则的调整可能影响依赖隐式继承的旧代码升级前需逐条核对。关键证据证据一网络层从 XHR 换成 Fetch。htmx 4.0 的请求发送、超时、取消、错误处理全部基于Fetch API和AbortController重新实现。这意味着hx-on::before-request这类钩子拿到的底层对象变了过去直接操作xhr的扩展代码需要改写。证据二hx-swapmorph成为内置能力。在 3.x 时代DOM Morphing 需要引入 idiomorph 扩展4.0 把它做进了核心hx-swap可以直接指定morph用于在替换 HTML 片段时保留焦点、滚动位置和表单输入状态。证据三属性继承规则被正式写进文档。过去hx-target、hx-swap、hx-confirm等属性的继承行为靠约定俗成4.0 明确了哪些属性会从祖先元素继承、哪些不会并给出了覆盖方式。证据四官方提供升级检查工具。发布说明中给出了npx htmx.org4.0.0 upgrade-check -- ./templates这样的命令可扫描.html、.php、.jinja、.erb、.hbs等模板文件提示需要手动处理的写法。展开说明为什么要把 XHR 换成 Fetchhtmx 的核心模型是用 HTML 属性描述请求。在 3.x 中这套模型跑在XMLHttpRequest上。XHR 的问题是取消请求要靠xhr.abort()超时要自己计时Promise 化还要手写包装。Fetch 天然返回 Promise配合AbortController可以干净地取消请求。对一个属性即请求的库来说网络层越薄越好——这是 4.0 重写的直接动机。一个最小的请求示例写法几乎没变buttonhx-get/api/timehx-target#clockhx-swapinnerHTML刷新时间/buttondividclock--:--:--/div服务端返回一段 HTML 片段htmx 把它塞进#clock。整个过程中你没有写一行fetch但底层已经是 Fetch 在工作。DOM Morphing Swap 解决什么问题普通innerHTML替换是推倒重建新 HTML 一进来旧节点全被销毁。副作用是焦点丢失、输入框内容清空、滚动位置跳回顶部。Morphing 的思路是对比新旧 DOM只改不同的部分。这在你有一个表单、局部刷新列表时特别有用——用户正在输入的内容不会被冲掉。formhx-post/todoshx-target#listhx-swapmorph:innerHTMLinputnametitleplaceholder新任务button添加/button/formulidlistli已有任务/li/ulmorph:innerHTML表示在#list内部做形态替换而不是整体重建。对于边填表边刷新的场景这是 4.0 最实用的变化之一。属性继承规则为什么重要htmx 的属性默认会从祖先元素往下传。比如你在body hx-target#main上写一次内部所有按钮不写hx-target也会指向#main。这很方便但也容易踩坑某个子元素想覆盖却忘了写或者以为没继承结果行为出乎意料。4.0 把规则明确化哪些属性继承、继承的优先级、如何用hx-disinherit阻断。对团队协作来说这比靠记忆和口口相传可靠得多。面试/作业常被追问的点htmx 的属性继承和 CSS 继承有什么相似与不同——相似在于都是自上而下、可覆盖不同在于 htmx 继承的是行为配置且部分属性如hx-trigger默认不继承需要显式声明。落地建议今天就能做的 3 件事跑一次升级检查。在你的模板目录执行npx htmx.org4.0.0 upgrade-check -- ./templates先看清有多少处需要改再决定是否立刻升级。不要盲目替换 CDN 链接。把一处innerHTML换成morph。找一个表单 列表的页面把hx-swapinnerHTML改成hx-swapmorph:innerHTML亲手体验焦点和输入内容是否被保留。这是理解 Morphing 价值最快的方式。显式写出关键属性。即使依赖继承也在关键元素上把hx-target、hx-swap写清楚。这样别人读代码时不用向上追溯祖先也方便未来升级时不被继承规则变化影响。写进作品集的小能力你可以做一个无框架的任务清单——服务端返回 HTML 片段前端只用 htmx 属性配合morph实现局部刷新。这个小项目能同时展示你对 HTTP、HTML 语义和服务端渲染的理解比再写一个 TodoMVC 更有辨识度。风险与反例如果你的项目重度依赖客户端状态htmx 的模型是服务端返回 HTML客户端状态很少。需要复杂本地状态、乐观更新、离线缓存时它并不合适。如果团队没有服务端渲染能力htmx 的价值建立在后端能返回 HTML 片段之上。纯静态站点或纯 API 后端用它会很别扭。如果扩展代码直接操作了 XHR 对象4.0 换成 Fetch 后这类扩展需要重写升级前务必检查第三方扩展的兼容性。Morphing 不是银弹它解决的是局部替换时的状态保留不解决两个完全不同的页面之间切换。用错场景反而增加调试成本。htmx 4.0 的方向很清晰把网络层交给浏览器原生能力把 DOM 替换做得更聪明把过去模糊的规则写清楚。对学习者来说它是一个很好的HTTP HTML 能走多远的实验场——但前提是你要清楚它的边界在哪里。