第2章 Go ChitChat

以完整论坛连接应用设计、数据模型、mux、静态文件、Cookie、模板、PostgreSQL与服务器启动。

从完整应用而不是API清单开始

先预测：登录、发帖、回复和浏览能否只靠一个handler完成？技术上可以，结构上不可维护。ChitChat用完整论坛展示各部件协作。是后续章节反复拆解的全景样本。

应用设计与目录边界

入口负责配置、数据库和路由装配，handler负责请求用例，data层负责持久化，template负责展示，public目录负责静态资源。阻止全局数据库和模板解析散落。

main -> mux -> handler -> data model -> PostgreSQL
                 |-> template -> HTML
                 |-> static files

数据模型

User、Session、Thread和Post通过主键与外键连接。要求创建回复时同时证明主题存在和用户已授权，时间与ID由明确一层产生。

接收与处理请求

Multiplexer根据path选择handler，静态文件走受限根目录，动态请求执行解析、授权、数据调用和响应。不应把业务授权藏在路径命名中。

mux := http.NewServeMux()
mux.Handle("/static/", http.StripPrefix("/static/", http.FileServer(http.Dir("public"))))
mux.HandleFunc("/thread/create", createThread)

使用Cookie访问控制

登录成功后服务器生成会话并设置Cookie，请求再用Cookie定位Session。需要HttpOnly、Secure、SameSite、过期和轮换策略；原书的简化实现是教学起点，不是完整安全方案。

使用模板生成HTML

Handler取得数据后执行已解析模板，模板失败必须在响应提交前处理。要求启动期预解析并避免在模板中访问数据库。

func index(w http.ResponseWriter, r *http.Request) {
    threads, err := store.Threads(r.Context())
    if err != nil { http.Error(w, "load failed", 500); return }
    if err := templates.ExecuteTemplate(w, "index.html", threads); err != nil { log.Print(err) }
}

验收实验：四条用户旅程

分别执行匿名浏览、登录、创建主题和回复，记录每步路由、Cookie、SQL与模板。关闭数据库后重复创建，确认返回失败且没有部分记录；破坏模板后确认日志包含模板名，且不会在已发送200后再尝试改状态。

本章回顾

本章覆盖Go ChitChat、应用设计、数据模型、多路复用器、静态文件与处理函数、使用Cookie访问控制、使用模板生成HTML响应、PostgreSQL与数据库接口，以及启动服务器。它给出全景，后续章节逐层深化。