原文:Julia Evans - 2024.09.27
在过去的几周里,我花了很多时间在用 Go 开发一个网站,虽然不知道它最终会不会发布,但在这个过程中我学到了一些东西,想记录下来。以下是我的一些收获:
Go 1.22 现在有了更好的路由支持
我一直没有动力去学习任何 Go 的路由库(比如 gorilla/mux
、chi
等),所以我一直是手动处理路由的,像这样:
// DELETE /records:
case r.Method == "DELETE" && n == 1 && p[0] == "records":
if !requireLogin(username, r.URL.Path, r, w) {
return
}
deleteAllRecords(ctx, username, rs, w, r)
// POST /records/<ID>
case r.Method == "POST" && n == 2 && p[0] == "records" && len(p[1]) > 0:
if !requireLogin(username, r.URL.Path, r, w) {
return
}
updateRecord(ctx, username, p[1], rs, w, r)
但显然从 Go 1.22 开始,Go 的标准库现在有了更好的路由支持,因此代码可以像这样重写:
mux.HandleFunc("DELETE /records/", app.deleteAllRecords)
mux.HandleFunc("POST /records/{record_id}", app.updateRecord)
不过它也需要一个登录中间件,所以可能更像这样,使用 requireLogin
作为中间件:
mux.Handle("DELETE /records/", requireLogin(http.HandlerFunc(app.deleteAllRecords)))
内置路由的一个坑:带斜杠的重定向
我遇到了一个烦人的问题:如果我为 /records/
创建了一个路由,那么对 /records
的请求会被重定向到 /records/
。
遇到的问题是,当我向 /records
发送 POST 请求时,它会被重定向到对 /records/
的 GET 请求,这导致 POST 请求的请求体被移除,从而破坏了请求。幸运的是,Xe Iaso 写了一篇关于同样问题的博文,这让我更容易调试这个问题。
我认为解决方案就是使用像 POST /records
这样的 API 端点,而不是 POST /records/
,这看起来本身也是一个更常见的设计。
sqlc 自动为我的数据库查询生成代码
我有点厌倦了为我的 SQL 查询写那么多样板代码,但并不想学习 ORM,因为我知道自己想写什么 SQL 查询,也不太想了解 ORM 如何将它们转换为 SQL 查询的规则。
但后来我发现了 sqlc,它可以将像这样的查询:
-- name: GetVariant :one
SELECT *
FROM variants
WHERE id = ?;
编译成这样的 Go 代码:
const getVariant = `-- name: GetVariant :one
SELECT id, created_at, updated_at, disabled, product_name, variant_name
FROM variants
WHERE id = ?
`
func (q *Queries) GetVariant(ctx context.Context, id int64) (Variant, error) {
row := q.db.QueryRowContext(ctx, getVariant, id)
var i Variant
err := row.Scan(
&i.ID,
&i.CreatedAt,
&i.UpdatedAt,
&i.Disabled,
&i.ProductName,
&i.VariantName,
)
return i, err
}
我喜欢这种方式,因为如果我不确定该为某个 SQL 查询编写什么 Go 代码,我可以直接写出我想要的查询,然后读取生成的函数,它会准确告诉我如何调用它。对我来说,这比翻阅 ORM 文档去搞清楚如何构建我想要的 SQL 查询要容易得多。
阅读了 Brandur 的 2024 年 sqlc 笔记后,我对使用这种方式来处理我的小项目更有信心。那篇文章提供了一个非常有用的案例,展示了如何使用 CASE
语句有条件地更新表中的字段(例如,当你有一个包含 20 列的表并且只想更新其中 3 列时)。
sqlite 小贴士
有人在 Mastodon 上给我发了这篇文章:优化 sqlite 以用于服务器。我的项目很小,对性能没有太多顾虑,但我从中得出的主要结论是:
- 为数据库的写入操作准备一个专用的对象,并对它运行
db.SetMaxOpenConns(1)
。我通过惨痛的教训了解到,如果不这样做,两个线程同时尝试写入数据库时会出现SQLITE_BUSY
错误。 - 如果我想让读取速度更快,可以有两个单独的数据库对象,一个用于写入,一个用于读取。
那篇文章中还有更多看起来有用的建议(比如“COUNT
查询很慢”和“使用 STRICT 表”),不过我还没有尝试这些。
另外,有时如果我有两个表,并且知道永远不需要在它们之间进行 JOIN
,我就会把它们放在不同的数据库中,这样就可以独立连接它们。
Go 1.19 引入了一种设置 GC 内存限制的方法
我在内存相对较少的虚拟机(VM)上运行所有 Go 项目,比如 256MB 或 512MB。我遇到了一个问题:应用程序不断被 OOM(内存不足)终止,这让我很困惑——难道我有内存泄漏吗?到底怎么回事?
经过一些谷歌搜索,我意识到或许我并没有内存泄漏,只是需要重新配置垃圾收集器!默认情况下(根据Go 垃圾收集器指南),Go 的垃圾收集器允许应用程序分配的内存达到当前堆大小的 2 倍。
Mess With DNS 的基本堆大小大约是 170MB,而 VM 上的可用内存大约只有 160MB,如果内存翻倍,它就会被 OOM 终止。
在 Go 1.19 中,添加了一种方法,可以告诉 Go “嘿,如果应用程序开始使用这么多内存,运行一次 GC”。于是我将 GC 内存限制设置为 250MB,似乎这样做后应用程序被 OOM 终止的次数减少了:
export GOMEMLIMIT=250MiB
我喜欢用 Go 做网站的几个原因
过去 4 年里,我断断续续地用 Go 做一些小网站(比如 nginx playground),这种方式对我来说很适用。我喜欢它的原因是:
- 只有一个静态二进制文件,部署时只需复制这个二进制文件。如果有静态文件,我可以用 embed 把它们嵌入到二进制文件里。
- 内置了一个可以在生产环境中使用的 web 服务器,所以我不需要配置 WSGI 等东西来让它工作。我可以把它放在 Caddy 后面,或者直接在 fly.io 上运行。
- Go 的工具链非常容易安装,我只需
apt-get install golang-go
之类的命令,然后go build
就能构建我的项目。 - 开始发送 HTTP 响应所需记住的东西非常少——基本上就是一些像
Serve(w http.ResponseWriter, r *http.Request)
这样的函数,读取请求并发送响应。如果我需要记住某个具体细节,只需要查看这个函数就可以了! - 而且
net/http
是标准库的一部分,所以你不需要安装任何库就可以开始创建网站。我真的很喜欢这一点。 - Go 是一个比较系统层面的语言,所以如果我需要运行像
ioctl
之类的操作,也很容易做到。
总的来说,它给我的感觉是,Go 让项目变得容易上手,你可以用 5 天时间开发一个项目,放下 2 年,然后再捡起来写代码也不会有太多问题。
相比之下,我尝试学习 Rails 几次了,我真的想喜欢 Rails——我用 Rails 做过几个小型网站,每次都觉得非常神奇。但最终每次我回到这些项目时,我都不记得任何东西是如何工作的,最后只能放弃。相比之下,虽然我的 Go 项目里充满了很多重复的样板代码,但至少我可以读懂代码,搞清楚它是怎么工作的。
我还没有搞明白的事情
一些我在 Go 中还没有做过的事情:
- 渲染 HTML 模板:通常我的 Go 服务器只是 API,我会用 Vue 做前端单页应用。我在 Hugo 中大量使用过
html/template
(过去 8 年我一直用 Hugo 写这个博客),但我还不确定对它的感觉。 - 我从没做过真正的登录系统,通常我的服务器根本不需要用户。
- 我从没尝试过实现 CSRF(跨站请求伪造)。
总的来说,我不确定如何实现安全敏感的功能,所以我不会启动那些需要登录/CSRF 等功能的项目。我猜这可能是框架派上用场的地方。
很高兴看到 Go 添加的新功能
我在这篇文章中提到的两个 Go 功能(GOMEMLIMIT
和路由)都是过去几年里添加的,而我在它们发布时没有注意到。这让我觉得应该更密切关注 Go 新版本的发布说明。