企业官网建设流程全解析

GRDB.swift 入门教程：4 步搞定 App 的本地 SQLite 数据库

【免费下载链接】GRDB.swiftA toolkit for SQLite databases, with a focus on application development项目地址: https://gitcode.com/GitHub_Trending/gr/GRDB.swift

给 iOS App 挑本地存储方案，是开发初期绕不开的第一个决定。GRDB.swift 是一款 Swift 的 SQLite 库：引擎是 SQLite，API 全是 Swift，从建表、类型安全查询到数据观察都帮你包办，也不用继承任何基类就能改造现有类型。下面先理清选型思路，再带你走一遍安装和常用技巧。

先用不惯 UserDefaults 的那一刻

当你的 App 数据从"几个配置项"长成"几百条记录，要筛选、要排序、甚至要离线缓存"时，键值存储就开始失灵了：没法按条件查、没法排序，每次读取还得把所有东西整包倒进内存。这时 iOS 数据持久化方案大致四条路线，差别很明显：

GRDB.swift 的位置落在第四格，但把"自己兜底"的部分接走了：引擎还是标准 SQLite，上面用 Swift 封装出类型安全查询、并发调度和数据观察。它轻量、SQL 可见，现有类型只要遵循对应协议就能接入。

GRDB 安装与初始化步骤：两条路任选

📦 安装很标准。SPM 路线：Xcode 里选 Add Package Dependencies，填入项目远程地址，把 GRDB 加进 target；CocoaPods 路线：Podfile 里写一行pod 'GRDB.swift'就完事。

初始化也只有一行：拿文件路径创建一个DatabaseQueue，数据库就就绪了，文件不存在时会自动创建。想快速找感觉，可以跑一下仓库里的 GRDBDemo 示例应用，是个能直接跑的玩家列表 Demo。

3 步写出第一个类型安全查询

第 1 步：让模型遵循两个协议

FetchableRecord 负责"从行里取出来"，MutablePersistableRecord 负责"写回数据库"。声明表名和字段，模型就齐了：

struct Player: Codable, FetchableRecord, MutablePersistableRecord { static let databaseTableName = "players" var id: Int64? var name: String var score: Int }

大白话：模型就是个普通 struct，不用继承谁，列名默认跟字段同名。

第 2 步：建表

在写操作里声明表结构：一个自增主键加两列，顺手把 notNull 之类的约束也加好。后续要升级表版本时，官方有专门的迁移机制，实现就放在 Migration 目录里，按版本号逐步演化，不会一上来就推倒重来。

第 3 步：把筛选、排序、取数串成链

let top = try Player.filter(Column("score") > 500) .order(Column("score").desc) .fetchAll(db)

filter 管"谁有资格"，order 管"怎么排队"，fetchAll 管"真的取出来"。想偷看生成的 SQL？把请求打印出来就能看到。

DatabaseQueue 还是 DatabasePool：按"流量"选

🚦 这是用 GRDB.swift 时第一个要想清楚的分支点，它决定数据库的并发行为。

• DatabaseQueue：读写都走同一条串行队列，简单可预期，多数 App 用这就够了。
• DatabasePool：读可以并行，写保持串行，适合信息流、后台处理这类多路并发读的场景。

选择逻辑一句话：默认上 Queue，等真的出现多个模块同时读数据、读成为瓶颈时，再换 Pool。

让界面跟着数据库走：ValueObservation

👀 列表页想随数据变化自动刷新？别自己写通知。用ValueObservation.tracking声明一份"我关心的数据"（比如取全部玩家），再挂一个回调。之后任何碰到被追踪区域的写入，都会自动重跑查询、把新值推给你；配合 async/await 或 Combine 就能直接驱动 SwiftUI 和 UIKit。

避坑与调优：三个低成本动作

🛠️ 这三条性价比最高：

• 批量操作进事务：一次插几百条，包在一个事务里统一提交，磁盘往返会明显减少。
• 给高频查询列建索引：常出现在 WHERE、ORDER BY 里的列，建一次索引受益很久。
• 别混用连接：Queue 和 Pool 选定一个就坚持下去，别自己跨线程传递 Database 对象。

选型前自检：该用 GRDB.swift 的三种情况，以及该放过的两种

✅ 对着下面两列打勾，结论就出来了：

适合接入手：

• 数据超过几百条，且要筛选、排序、聚合
• 想直接写 SQL，不被对象模型层绑住
• 读侧有并发，希望有可预期的并行读

适合放过：

• 只有寥寥几个配置项，UserDefaults 就够用
• 团队已重度投入 Core Data + CloudKit 同步生态，换掉的边际收益很小

如果"接手"一列勾中两条以上，就可以直接上。仓库 Documentation/ 目录里的主文档和示例是配套的，边跑边读最顺。

【免费下载链接】GRDB.swiftA toolkit for SQLite databases, with a focus on application development项目地址: https://gitcode.com/GitHub_Trending/gr/GRDB.swift