页面空白或报模板错误的主因是路径错误、未显式Parse、嵌套名不匹配；数据库字段与Scan参数数量/顺序不符或struct缺少db tag；SQLite并发写入易锁库；URL参数须校验转换后再入库。
Go 的 html/template 渲染时为啥页面空白或报 template: ...: no such template
模板路径没对上、没显式 Parse 或嵌套模板名不匹配，是最常见的三连原因。Go 的模板系统不自动扫描目录，ParseFiles 传的路径是相对**当前工作目录**（不是 .go 文件所在目录），且必须包含后缀（如 "templates/index.html"）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Getwd()打印当前路径，确认模板文件是否真在那个位置 - 统一用
template.Must(template.ParseGlob("templates/*.html"))加载全部，避免漏文件 - 如果用了
{{template "header" .}}，确保对应{{define "header"}}存在且名字完全一致（区分大小写） - 渲染前检查
err：直接忽略tmpl.Execute(...)返回的 error 会导致静默失败
用 database/sql 查博客文章时，Scan 报 sql: expected 3 destination arguments, got 2
字段数和变量数不匹配，或者 struct 字段没加 db tag 导致反射跳过某些字段。Go 不会自动按列名映射，Scan 是严格按 SELECT 字段顺序和数量绑定变量的。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- SELECT 字段必须和
Scan参数一一对应：比如SELECT id, title, content FROM posts就得传三个变量，不能少也不能多 - 用 struct +
Rows.Scan(&post)时，确保每个字段都有db:"column_name"tag，且类型可被驱动转换（如int64接BIGINT，string接TEXT） - 别依赖
SELECT *—— 表结构一变，代码立刻崩；显式写字段更安全 - 遇到 NULL 值，用
sql.NullString等类型替代原生 string，否则 Scan 会报sql: Scan error on column index X
SQLite 作为博客数据库，在并发写入时出现 database is locked
SQLite 默认以独占方式打开，写操作会锁整库，而 Go 的 database/sql 连接池在高并发下容易撞上这个限制。这不是代码 bug，是 SQLite 的设计边界问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化
*sql.DB后立刻调db.SetMaxOpenConns(1)，强制串行写入（适合小流量个人博客） - 用
_ "github.com/mattn/go-sqlite3"驱动时，在 DSN 末尾加?_busy_timeout=5000，让写操作等 5 秒再报错 - 读操作尽量用
QueryRowContext而非QueryContext，减少连接占用时间 - 真要撑更高并发，别硬扛 —— 换 PostgreSQL 或加一层内存缓存（比如用
map[string]*Post缓存热文章），SQLite 就不是为这个场景造的
路由里怎么把文章 ID 从 URL（如 /post/123）安全传进 handler
别用字符串拼接 SQL，也别信任任何来自 URL 的原始输入。Go 的 http.ServeMux 不支持命名参数，得靠正则或第三方路由器，但核心原则就一条：所有外部输入进数据库前必须校验+转义。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
chi或gorilla/mux解析路径参数：r.Get("/post/{id}", postHandler)，然后在 handler 里用chi.URLParam(r, "id")取值 - 拿到字符串 ID 后，立刻用
strconv.ParseInt(idStr, 10, 64)转成 int64，失败就返回 404 —— 这比在 SQL 里用WHERE id = ?前还多一层防护 - 即使用了参数化查询，也别省略这步校验：攻击者可能传
/post/abc或超大数字触发整型溢出 - 如果坚持用默认 ServeMux，只能靠
strings.Split(r.URL.Path, "/")手撕路径，但要注意边界（比如/post//123或/post/123/edit）
模板嵌套层级深了容易漏 define，数据库字段改了不改 struct tag 就 panic，SQLite 的 lock 不是 error 而是 timeout 策略问题 —— 这些都不是“写完就能跑”的环节，而是每次 deploy 前得手动点一遍的地方。
