Go不自带ORM，推荐用database/sql配合驱动或sqlx提升开发效率；注意DSN格式、连接池配置、SQL注入防护、事务正确提交及复杂业务逻辑在Go层实现。
Go 本身不自带 ORM，直接用 database/sql 配合 lib/pq（PostgreSQL）或 go-sql-driver/mysql（MySQL）做查询最稳妥，也最贴近实际生产环境的写法。
建表与连接数据库前先确认驱动和 DSN 格式
不同数据库的连接字符串（DSN）格式差异大，填错一个字符就会报 dial tcp: lookup xxx: no such host 或 failed to parse address 这类模糊错误。
- PostgreSQL 推荐用 URL 形式：
postgres://user:pass@localhost:5432/libdb?sslmode=disable - MySQL 要注意
parseTime=true&loc=Local，否则time.Time字段会解析失败或时区错乱 - 连接池设置别漏掉：
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(10)，否则高并发下容易卡在waiting for connection
用 sqlx 替代原生 database/sql 提升结构体映射效率
原生 Scan 要按字段顺序一一匹配，字段一多就容易错位；sqlx 支持结构体字段名自动映射，且语法几乎兼容。
- 定义结构体时加
dbtag：type Book struct { ID int `db:"id"` Title string `db:"title"` } - 查单条用
Get，查多条用Select，比手写rows.Scan()少一半胶水代码 - 注意：所有字段必须是导出的（首字母大写），否则
sqlx无法反射赋值
WHERE 条件拼接别用字符串格式化，改用 NamedQuery 或参数占位符
用户输入直接拼进 SQL 是典型 SQL 注入漏洞。图书馆系统里搜索书名、作者、ISBN 都是高危入口。
立即学习“go语言免费学习笔记（深入）”；
- 简单查询用问号占位符：
SELECT * FROM books WHERE title LIKE ?，然后传参%《设计模式》% - 复杂动态条件（比如“只搜作者”或“作者+年份”组合）推荐
sqlx.NamedExec+ map 参数，避免 if-else 拼 SQL 字符串 - 切忌：
"WHERE title LIKE '%" + userInput + "%'"—— 这种写法在任何审查中都会被标红
事务处理要显式 Commit/Rollback，且注意 defer 的执行时机
借书、还书、扣库存这类操作必须原子执行，但 Go 的 defer tx.Rollback() 如果没配合 if err != nil 提前 return，会导致成功时也回滚。
- 标准写法是：
tx, _ := db.Begin(); defer func() { if r := recover(); r != nil { tx.Rollback() } }()，再加手动if err != nil { tx.Rollback(); return } - 更稳妥的是用函数封装：
err := db.Transaction(func(tx *sqlx.Tx) error { ... })（需自行实现或用github.com/jmoiron/sqlx的扩展） - 注意：事务内不能用
db.Query，必须用tx.Query，混用会导致连接泄漏或死锁
真正麻烦的不是写 CRUD，而是处理“同一本书多个副本”“借阅记录状态流转”“超期未还自动冻结账户”这类业务规则——它们往往需要跨表更新+条件判断+时间计算，纯 SQL 很难覆盖全部分支，得靠 Go 层逻辑兜底。
