React 太重、Svelte 太绕？Go + HTMX 全栈方案，连 LLM 都更容易看懂
内容提要
GopherCon UK 2026演讲分享：后端工程师用Go、HTMX、templ和sqlc完成副业项目。HTMX让服务端返回HTML片段，状态只保留在后端，消除前后端状态不同步问题，且无需构建链。演讲介绍防抖搜索、懒加载、OOB多区域更新、HX-Redirect等技巧，并强调移动端API与Web API应分开。作者指出重交互场景和前后端分离团队不宜用HTMX，它更适合后端主导的内部工具。
延伸解读
HTMX 的适用边界：不是银弹
演讲者反复强调 HTMX 并非万能。它适合后端工程师主导、缺少前端人力的场景，如内部管理后台、客服工具或个人副业项目。但若前端交互很重、团队前后端分离、或需要成熟设计系统（如 Storybook 生态），则 React、Svelte 更合适。强行使用 HTMX 可能带来维护困难，读者应根据团队结构和项目复杂度判断是否采用。
API 拆分：Web 与移动端不必强求一致
文章引用 HTMX 官方观点，将 API 分为数据 API 与应用 API。Web 端返回 HTML 片段可简化状态管理，而移动端可能需要不同形态的数据。强行复用同一接口会限制页面迭代，并可能引发多次请求和 N+1 问题。演讲者建议一事一议，拆分虽增加样板代码和测试，但能避免过度 DRY 带来的耦合。
开发体验：工具链降低全栈门槛
演讲者用 Task、Docker Compose、Air、templ/Tailwind watch、Nix 和 Playwright（Go 版）构建本地开发环境，实现一条命令拉起依赖、热重载和端到端测试。这些工具让后端工程师无需深入前端构建链即可完成全栈开发。现场观众补充 Air 可执行构建前置任务，演讲者表示此前不知，提示读者可自行验证优化空间。
对 LLM 友好：可审查性优于框架流行度
演讲者回应“LLM 写 React 更强”的质疑时指出，LLM 生成的 Go 代码他能判断好坏，而 React 代码只能看能否运行。HTMX 的数据流直白——请求发往哪个端点、返回什么 HTML 一目了然，没有分散的前端状态。这种可审查性不仅利于人类维护，也让 LLM 更容易理解和生成正确代码，降低协作成本。
Q&A
HTMX 是什么？它和传统前端框架有什么不同？
HTMX 是一个约 50KB（压缩后）的小型 JavaScript 库，允许你通过 HTML 属性直接向后端发送请求。与传统 SPA 框架不同，HTMX 不维护前端状态，服务端返回 HTML 片段并直接替换页面局部内容，从而消除前后端状态不同步的问题，且无需构建链。
用 Go + HTMX 做全栈开发，状态管理是怎么处理的？
在 Go + HTMX 方案中，状态只保留在后端。前端只是一个“哑”界面，通过 HTMX 属性告诉后端“该显示什么”，后端返回对应的 HTML 片段来更新页面。这样就不需要在前端维护一份状态，避免了两边状态不同步的一整类 Bug。
HTMX 有哪些进阶交互技巧？比如防抖搜索、懒加载、多区域更新？
HTMX 支持多种进阶技巧：1) 防抖搜索：用 hx-trigger 设置延迟（如 300ms）再请求，配合 hx-push-url 使搜索结果可分享；2) 懒加载：用 hx-trigger="load" 在页面加载后自动请求并替换占位内容；3) OOB 多区域更新：用 hx-swap-oob 让一次响应更新多个页面区域；4) 响应头控制：如 HX-Retarget 改更新目标、HX-Reswap 改替换策略；5) 登录重定向：识别 HX-Request 头并使用 HX-Redirect 响应头实现跳转。
HTMX 适合哪些场景？什么情况下不应该用 HTMX？
HTMX 适合后端工程师主导、缺少前端人力的场景，如内部管理后台、客服工具、个人副业项目。不适合的场景包括：前端交互很重（复杂客户端响应式逻辑）、团队前后端分离（不要抢前端同事的工具选择）、需要成熟的设计系统（如 Storybook 生态在 React/Svelte 侧更完善）。演讲者强调 HTMX 不是银弹。
使用 HTMX 时，API 应该返回 HTML 还是 JSON？移动端和 Web 端如何协调？
演讲者建议将 API 分为三类：移动端 API、Web 应用 API、数据 API，不要强行合并。Web 端返回 HTML 片段完全够用，数据 API 单独维护以保持稳定。强行复用数据 API 给 Web 前端会限制页面迭代，并可能导致多次请求和 N+1 问题。拆分的代价是更多样板代码和测试，需要自行权衡。
Go + HTMX 技术栈中，templ 和 sqlc 分别起什么作用？
templ 是专为 Go 设计的类型安全 HTML 模板工具，特别适合 HTMX 返回局部 HTML 的场景，它完全类型化并自带 LSP，能在生成时发现类型错误。sqlc 则让你手写 SQL 并自动生成强类型的 Go 代码，避免 ORM 的“魔法”，SQL 可审查。两者结合提供强类型保障，让人和 LLM 都更容易审查代码。
HTMX 对 LLM 辅助开发有什么优势？为什么说 LLM 更容易看懂？
演讲者指出，HTMX 的数据流非常直白：请求发到哪个端点、返回什么 HTML，一目了然，没有分散在前端各处的状态。因此人和 LLM 都容易理解和审查。相比之下，LLM 生成的 React 代码往往只能看它“能跑就行”，而 Go + HTMX 代码更容易判断好坏。
