用Go写前端：一种反直觉的"复古"技术栈

2024年了，还有人用服务端渲染写后台？不是Vue/React不够香，是有一群开发者发现：全用Go也能搭出像样的电商管理后台。

这套组合叫Fiber + HTMX + Templ UI + GORM。没有前端构建工具链，没有npm install的等待，模板文件生成后就是普通Go代码，直接编译进二进制。

一张图看懂：这套技术栈怎么运转

原文作者用一张架构图概括了核心思路：浏览器请求→Fiber路由→Templ模板渲染→HTMX处理交互→GORM操作数据库。整个流程在服务端完成，返回的是HTML片段而非JSON。

这和现代前后端分离的玩法完全相反。但作者认为，对于内部管理后台这类场景，"Go优先"的工作流反而更干净——一个人能搞定全栈，部署只有一个可执行文件。

第一步：最小的Fiber服务器

启动代码短到离谱：

func main() {
app := fiber.New()
app.Static("/assets", "./assets")
app.Get("/", RenderTempl(LandingPage))
app.Listen(":3000")
}

三行核心逻辑：静态文件服务、首页路由、端口监听。作者说这是"第一个成功点"——如果/路径能正常渲染，说明服务器、模板引擎、静态文件三者已连通。

没有webpack配置，没有热更新中间件，保存即编译。

Templ UI：把组件"编译"进项目

关键设计在Templ UI的生成式思路。不是运行时拉取远程组件库，而是执行命令把组件源码生成到本地项目里：

go install github.com/templui/templui/cmd/templui@latest
templui init
templui add "*"

教程里用通配符生成全部组件，方便折腾。生产环境可以只添加需要的，避免冗余。

生成后的组件就是普通.templ文件，改起来和手写没区别。作者特意提醒：示例代码故意简化，接近伪代码，重点看结构而非复制粘贴。

落地页验证：从0到能点

作者用落地页当第一个里程碑——证明布局系统能跑，同时给导航按钮找个地方。

代码片段里有个细节：hx-boost="true"和hx-indicator="#gprogress"。这是HTMX的魔法，让普通链接变成AJAX请求，加载时显示进度条。不需要写一行JavaScript。

按钮组件这样调用：

@button.Button(button.Props{Href: "/login"}) {
Login
}

变体样式通过Props控制，比如outline变体给注册按钮。这种写法对习惯React JSX的人需要适应，但类型安全是编译期保证的。

为什么选这条"非主流"路

原文没展开比较，但从技术选型能反推几个假设：

管理后台的用户是内部员工，对首屏加载秒级优化不敏感；功能迭代快，一个人维护比团队协作更高效；部署环境简单，单二进制文件丢到服务器就能跑。

这些条件满足时，砍掉前端工具链的复杂度是合理 trade-off。代价是交互丰富度天花板明显——复杂表单联动、实时协作编辑这类场景，HTMX的声明式语法会吃力。

作者把这套方案定位在"电商管理后台"，而非面向消费者的C端产品，边界感很清晰。

数据收束：一个待观察的指标

原文是系列第一篇，只覆盖UI基础。完整实现需要看后续：数据库模型设计、权限系统、HTMX的局部更新策略。

值得跟踪的是Templ UI的组件生态成熟度。目前需要手动生成和编辑，如果社区贡献的预制模板足够丰富，"Go全栈"的门槛还能再降。反之，如果每个项目都要大量自定义组件，省下的构建工具时间可能花在写模板里。