原文：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)
- mux.HandleFunc("DELETE /records/", app.deleteAllRecords)
- mux.HandleFunc("POST /records/{record_id}", app.updateRecord)
- 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 = ?;
- 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
- }
阅读了 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 终止的次数淘汰了：
我喜好用 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 新版本的发布阐明。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
