之前在搞一个游戏内的运营数据统计模块需要本地存一批战斗记录和玩家行为数据还要按条件查询、做聚合统计。刚开始图省事直接用 PlayerPrefs 存键值对数据量一大、字段一复杂读写和解析都让人头疼。后来切换到了 SQLite才发现“单 DB 文件、SQL 查询、跨平台支持”这三个特性简直是为 Unity 本地数据存储量身定做的。这篇文章我就完整记录一下从零开始把 SQLite 集成进 Unity再把数据库里的数据做成可视化图表的全过程包括插件选型、代码封装、移动端适配和一堆实战中踩过的坑。如果你也有类似需求——不管是做单机游戏存档、玩家战绩统计、关卡编辑器配置读取还是搞一个本地数据可视化看板这篇文章应该能帮你少走不少弯路。我会把每一步为什么这么做、参数怎么选、坑在哪里都说清楚直接照着抄作业即可。1. 项目概述与整体设计思路先说清楚这个项目到底要干什么。我的目标是做一个 Unity 客户端本地数据库模块能够把业务数据写入 SQLite 数据库文件并通过 SQL 查询把数据取出来最终在 Unity 的 UGUI 界面上以柱状图、折线图等可视化形式呈现。说白了就是一套“本地数据采集 → 入库 → 查询统计 → 图表展示”的完整链路。1.1 为什么 Unity 项目需要 SQLite很多刚接触 Unity 的人都会有疑问Unity 不是自带 PlayerPrefs 吗实在不行存 JSON 文件也可以为什么非要引一个数据库进来我实际用下来的感受是这样PlayerPrefs 本质是一个键值对存储适合存音量设置、上次登录时间这种零散数据。一旦遇到“玩家的 1000 条战斗记录每条记录有 10 个字段还要按时间区间查总和、平均值”这种需求PlayerPrefs 基本就废了。JSON 文件方案能存结构化数据但所有数据都得一次性加载进内存数据量大了之后查找、筛选、排序全得自己写算法效率低还容易出 bug。SQLite 是嵌入式关系型数据库服务端和客户端通用程度极高支持标准的 SQL 语法数据量几万条以内查询都是毫秒级而且整个数据库就是一个独立文件备份、迁移、清除都非常方便。很多人对数据库有心理门槛觉得那是后端工程师才需要碰的东西。但实际上 SQLite 不需要安装服务端没有独立的进程它是以库文件的形式嵌入到程序里的Unity 项目里就是放几个 DLL 和原生库然后通过 C# 调用。理解成“一个可以直接用 SQL 读写的结构化和本地文件”就行跟“读写 JSON”相比只是换了个操作方式但能力完全不在一个量级。1.2 整体架构与模块划分这个项目我分了三个层次来处理避免把所有代码堆在一个类里后续扩展和维护也省心数据持久化层负责数据库文件的创建、连接管理、表结构初始化对外提供 Insert、Query、Update、Delete 等基础方法。业务逻辑层负责把从数据库查出来的裸数据转换成 C# 对象比如战斗记录 BattleRecord、统计数据 StatItem这一层只跟集合和对象打交道。可视化表现层负责把业务层整理好的数据渲染成 UI 图表包含柱状图、折线图组件以及一个数据看板的布局。这样的分层方式是标准的“数据 → 逻辑 → 展示”三段式。这样做最大的好处是后续如果想把本地 SQLite 换掉直接对接网络接口只需要替换第一层的实现业务逻辑和图表代码都不用动。哪怕只做一个小项目我也建议保持这个结构因为你在开发过程中一定会频繁调整数据库字段和 UI 样式分层能让你改动局部而不牵连全局。2. 环境准备与工具链选型动手之前先把环境搭对。这一节我用文字列出我自己的工程配置和工具并且把每个选择的理由说明白。特别是插件选型这一步要是选错了后面会出现一堆莫名其妙的报错。2.1 Unity 版本与脚本运行时配置Unity 版本我使用的是 2021.3 LTS这是一个长期支持版本稳定性和插件兼容性都很好。如果你用的是 2019 或 2020过程也完全一样但建议至少保持在 2019.4 LTS 以上。打开 Unity 后先到 Project Settings → Player → Other Settings 里确认两处关键配置Scripting Backend 选择 Mono。如果选择 IL2CPP 或者需要支持某些 Android 平台时SQLite 的原生库需要额外的处理后面我会专门讲。API Compatibility Level 选择 .NET Standard 2.0 或者 .NET Framework。重点说明一下如果选了 .NET Standard 2.0可能有些老版本 SQLite 插件会报“找不到 System.Data.dll”之类的错误这时候可以切到 .NET Framework或者干脆用依赖更少的 sqlite-net。我在第一个测试项目里就踩过这个坑插件已经引进来代码编译也通过一运行就报 FileNotFoundException查了很久才发现是 API Compatibility Level 的问题。所以开局先把这项配置确定好能省掉大量排查时间。2.2 SQLite 插件选型对比Unity 里面用 SQLite主流的方案有下面几种我整理成表格方便大家对照方案底层实现优点缺点适用场景Mono.Data.Sqlite通过 C# 调用引擎内置 SQLite老牌方案资料多Window 平台稳更新慢不同 Unity 版本兼容性有差异本地工具、快速原型sqlite-net纯 C# P/Invoke 封装轻量、安装简单支持 ORMSQL 能力受限复杂查询不如原生 SQL存档系统、中小型数据SQLite4Unity在 sqlite-net 基础上整合原生库支持 Android/iOS/Windows社区常用需要自己处理原生库分发发布移动端游戏官方原生 sqlite3直接引入官方源码或预编译库功能最完整可定制工作量大桥接代码要自己写对 SQL 功能有极高要求我个人最终选了 SQLite4Unity 这个方案。原因很简单它既有 sqlite-net 的 ORM 便利性又帮你把 Android、iOS、Windows 各个平台的 sqlite3 原生库都打好了包引入工程后直接就能跑。不过要注意sqlite4unity 仓库版本网上挺多尽量选更新活跃、star 数量高的分支避免拿到一个几年没更新的残缺版。如果你只是在 Windows 编辑器里做工具类开发不想碰移动端用 Mono.Data.Sqlite 也完全够用。但如果是要发布到 Android 或 iOS 真机强烈建议直接用 SQLite4Unity或者深入理解底层后自己整合原生库否则数据库打不开、读不了文件的情况会非常频繁。2.3 外部数据库管理工具数据可视化不只是把数据画在 Unity 里开发过程中你还需要直接查看数据库文件的内容。这里推荐三款外部工具都是我实际用过的DB Browser for SQLite免费开源最推荐查看表结构、执行 SQL、导出 CSV 都很方便日常调试够用了。SQLiteStudio同样是免费工具界面比 DB Browser 稍微现代一点支持数据导入导出和简单图表。DBeaver全平台数据库管理工具支持的数据库类型非常多如果你同时在搞 Web 后端或数据分析工作装这一个就够了。这些工具的作用是让你能直接打开 App 生成的 .db 文件用 SQL 语句验证数据是否正确。我通常的工作流是Unity 里跑一次写入操作然后把数据库文件拉出来用 DB Browser 打开执行几条查询语句确认数据结构和内容符合预期再回 Unity 里做可视化。3. 核心实现Unity 集成 SQLite 从零搭建这一节是整篇文章的重头戏。我会按照“导入插件 → 封装数据库访问类 → 建表与增删改查 → 处理数据库文件路径”的顺序把每一步操作讲透。3.1 插件导入与工程结构我这里以 SQLite4Unity 为例说下目录结构。下载插件后把核心文件放到 Assets/Plugins/SQLite 目录下sqlite3.dllWindows 版本libsqlite3.soAndroid 版本libsqlite3.dylibiOS/macOS 版本SQLite.csC# 层面的操作封装也就是 sqlite-net 的源码放到 Plugins 目录下是 Unity 的约定这个目录里的 DLL 和原生库会被自动识别并按平台打包。每个平台的子文件Unity 会根据文件扩展名自动分发到对应平台不需要你写额外的构建脚本。但要注意一点iOS 平台原生的库会被编译进 Xcode 工程必须确认它包含 arm64 架构Android 平台要看 .so 的 CPU 架构arm64-v8a 还是 armeabi-v7a如果你的安卓设备比较新建议只保留 arm64-v8a 以减小包体但老的 32 位机器可能就跑不了。导入完成后在 Unity 里先做个最简单的连接测试写一段代码尝试打开一个内存数据库执行 SELECT 1如果返回值正常说明插件和底层库都通了。这一步能尽早暴露 DLL 版本问题。3.2 数据库连接管理类封装我不建议每个业务类都直接去 new SQLiteConnection那样连接对象满天飞资源管理迟早出问题。实际项目中我封装了一个数据库服务类 DBService用单例来持有唯一的数据库连接。public class DBService { private static DBService _instance; public static DBService Instance _instance ?? (_instance new DBService()); private SQLiteConnection _connection; private string _dbPath; public void Init(string dbName) { _dbPath Path.Combine(Application.persistentDataPath, dbName); _connection new SQLiteConnection(_dbPath); _connection.CreateTableBattleRecord(); // 其他建表操作... } public SQLiteConnection GetConnection() { return _connection; } }这里把数据库文件路径定在 Application.persistentDataPath而不是 StreamingAssets。原因是 StreamingAssets 目录在 Android 上是只读的你没法往里面写数据而且从 Android 的 APK 包内读取 StreamingAssets 里的文件还需要用 UnityWebRequest 去走特殊协议没法直接用 File 类。所以常规做法是App 第一次启动时把打包在 StreamingAssets 里的数据库模板如果存在的话复制到 persistentDataPath之后所有读写操作都在这个持久化路径上执行。3.3 建表、增删改查与自增 ID 获取sqlite-net 这个库支持直接用类定义来建表非常方便。比如我要存战斗记录就定义一个 BattleRecord 类public class BattleRecord { [PrimaryKey, AutoIncrement] public int Id { get; set; } public string PlayerName { get; set; } public int Score { get; set; } public int KillCount { get; set; } public int DeathCount { get; set; } public string MapName { get; set; } public long Timestamp { get; set; } }第一次调用 CreateTableBattleRecord() 的时候库里会自动创建一张名字为 BattleRecord 的表字段名和类型会自动映射。对于不熟悉 ORM 的读者我解释一下PrimaryKey 是主键AutoIncrement 是自增也就是每条记录插入后会自动分配一个唯一数字 ID这个 ID 就是我们在数据可视化时用来定位单条记录的依据。插入数据并拿回自增 ID这块就是热词里提到的“sqlite insert into 后获取自动序号”。sqlite-net 的做法是var record new BattleRecord { PlayerName Player001, Score 1200, KillCount 5, DeathCount 2, MapName Map01, Timestamp DateTimeOffset.Now.ToUnixTimeSeconds() }; _connection.Insert(record); int newId record.Id; // 插入之后sqlite-net 会自动把自增Id写回这个对象如果你用的是原生 ADO.NET 的写法那就要在 Insert 之后执行一句 SELECT last_insert_rowid()cmd.CommandText SELECT last_insert_rowid(); object result cmd.ExecuteScalar(); int newId Convert.ToInt32(result);这两种方式都能拿到自增 ID。我建议在项目里只统一使用其中一种不要混着用。刚入门的时候混着用很容易出现“刚才插入的明明是 A拿到的 ID 却是 B”这种诡异问题。原因是 last_insert_rowid() 只对当前数据库连接内的上一次 INSERT 有效如果中间穿插了其他连接的操作结果就会错乱。查询操作是可视化模块的基础。比如我要统计每张地图的玩家平均分和总击杀数SQL 可以直接写var rows _connection.QueryStatItem( SELECT MapName, COUNT(*) as PlayerCount, AVG(Score) as AvgScore, SUM(KillCount) as TotalKills FROM BattleRecord GROUP BY MapName);对应的 StatItem 类public class StatItem { public string MapName { get; set; } public int PlayerCount { get; set; } public float AvgScore { get; set; } public int TotalKills { get; set; } }这里 SQL 语句里的 AVG、SUM、GROUP BY 都是数据库基本功不用全部记住但常用的这几个聚合函数值得花十分钟过一遍。因为数据可视化的本质就是“把原始数据按维度聚合后用图形方式展示”。没有 GROUP BY你只能画出一堆散点有了 GROUP BY你才能画柱状图按分类汇总和折线图按时间序列汇总。更新和删除相对简单_connection.Execute(UPDATE BattleRecord SET Score ? WHERE Id ?, newScore, id); _connection.Execute(DELETE FROM BattleRecord WHERE Id ?, id);注意 sqlite-net 的参数占位符用的是问号不要把 MySQL 的 参数格式套进来。关于事务我再多说一句。如果你需要一次性插入几千条数据逐条 Insert 会非常慢因为每条插入默认都开启一个隐式事务磁盘 IO 开销很大。正确做法是用事务包住批量操作_connection.BeginTransaction(); try { foreach (var record in records) { _connection.Insert(record); } _connection.Commit(); } catch { _connection.Rollback(); throw; }用事务包住后几千条数据一秒内就能插入完性能差距非常明显。这也是新手最容易忽略的点数据很小的时候看不出问题数据量上来了才临时补事务不如一开始就留好封装。3.4 数据库文件路径与跨平台适配前面说过数据库文件本体建议放 persistentDataPath。但这个路径在不同平台位置不同而且它是应用沙盒路径用户在设备上是找不到的调试的时候要么通过 Debug.Log 打印路径要么用工具把数据库文件导出来。如果你的项目需要在首次启动时预制一些基础数据比如初始配置表、地图列表那就把 ans 填充好的 sqlite 数据库文件放在 Assets/StreamingAssets 下然后首次启动时判断持久化路径有没有这个文件没有才复制过去string sourcePath Path.Combine(Application.streamingAssetsPath, game.db); string targetPath Path.Combine(Application.persistentDataPath, game.db); if (!File.Exists(targetPath)) { // Android 平台要用 UnityWebRequest 读取 StreamingAssets #if UNITY_ANDROID UnityWebRequest request UnityWebRequest.Get(sourcePath); request.SendWebRequest(); while (!request.isDone) { } File.WriteAllBytes(targetPath, request.downloadHandler.data); #else File.Copy(sourcePath, targetPath); #endif }这里有一个非常经典的坑Android 上 Application.streamingAssetsPath 指向的是 APK 包内的 jar 路径用 File.Copy 直接读会报 DirectoryNotFoundException 或 FileNotFoundException。必须用 UnityWebRequest 拿到 Byte 数组后再写文件。iOS 上没有这个问题但 iOS 的持久化路径受 iCloud 备份策略影响如果数据库里有用户隐私数据需要在 Infoplist 里设置开启或关闭备份属性不过大多数游戏项目不涉及先了解即可。4. 数据可视化从查询结果到图表数据库集成好了数据也查出来了接下来就是把数据变成图表。Unity 里没有现成的图表控件这和 Web 前端里面有 ECharts、D3.js 不一样一切图表都得自己画或者引第三方库。4.1 可视化方案选型我实际对比过几种方案自绘 UGUI 图表用 Image、RectTransform 来拼柱状图用 LineRenderer 或 RawImage 来画折线图。适合数据量不大、图表样式要求定制化高的场景。优点是完全可控缺点是一切要自己造轮子。开源图表库 XCharts基于 UGUI 的开源图表库GitHub 上有柱状图、折线图、饼图都有现成组件配置项也很丰富。如果你只想快速出效果直接导入 XCharts 是最省事的。第三方插件如 Graph MakerAsset Store 上有一些商业图表插件功能全面但对滨版本依赖强升级 Unity 版本后可能失效。Web 可视化方案把数据提交到本地 Web 页面用 ECharts 渲染Unity 内嵌 WebView 展示。技术路线复杂一般不推荐在纯本地项目里用。我这次没有引入外部图表库因为需要展示的图表只有柱状图和折线图两种自绘成本不高而且能更好地控制颜色、坐标轴和交互。如果你有更复杂的图表需求比如雷达图、热力图或者时间紧迫建议直接用 XCharts。4.2 从数据库查询结果到内存模型拉取数据后先转成 UI 能直接消费的内存集合。比如我做一个“每张地图的平均分柱状图”就需要得到一组“地图名 平均分”的数据public class ChartDataItem { public string Label { get; set; } public float Value { get; set; } } var chartDataList _database.QueryChartDataItem( SELECT MapName AS Label, AVG(Score) AS Value FROM BattleRecord GROUP BY MapName);把 SQL 的查询列用 AS 重命名成和类属性一致的名字sqlite-net 才能正确映射。这个环节需要注意的是SQL 返回的字段名如果和类属性名不一致映射会失败结果集是空的或者全是 0。我自己就踩过一次因为把别名写错了调试时查了半小时。4.3 柱状图与折线图的 UGUI 实现思路柱状图的原理其实很简单每个柱子是一个 UGUI Image通过控制它的 height 和 y 轴位置来表现数值大小。画一个图表容器容器底部是 x 轴每个 Image 的锚点设置在底部运行时动态设置 sizeDeltafloat maxValue 0f; foreach (var item in chartDataList) { if (item.Value maxValue) maxValue item.Value; } float barWidth 80f; float chartHeight 400f; for (int i 0; i chartDataList.Count; i) { var bar Instantiate(barPrefab, chartRoot); RectTransform barRect bar.GetComponentRectTransform(); float normalizedValue chartDataList[i].Value / maxValue; float barVisualHeight chartHeight * normalizedValue; barRect.sizeDelta new Vector2(barWidth, barVisualHeight); barRect.anchoredPosition new Vector2(i * (barWidth gap), barVisualHeight / 2f); }这里关键的细节是把柱子的 pivot 设在底部0, 0这样才能让柱子从底部向上生长。如果 pivot 是默认的 (0.5, 0.5)那么柱子会以中心点为基准向两边扩展看起来就是从中间长出来的非常怪。设置锚点这块对新手来说容易踩坑建议画图前先把 UGUI 的 anchor、pivot、anchoredPosition 这三个概念过一遍。折线图我选择用 LineRenderer 来实现。把数据点转成世界坐标然后把相邻点连起来LineRenderer lineRenderer lineObject.GetComponentLineRenderer(); lineRenderer.positionCount chartDataList.Count; for (int i 0; i chartDataList.Count; i) { float normalizedValue chartDataList[i].Value / maxValue; float x i * (barWidth gap); float y normalizedValue * chartHeight; lineRenderer.SetPosition(i, new Vector3(x, y, 0f)); }LineRenderer 用的坐标是 Unity 世界坐标所以需要先把它挂在一个合适的 GameObject 下确保坐标和柱状图的坐标能对上坐标原点和缩放。线条粗细和材质球要提前设置好否则画出来很模糊或者看不见。如果数据点很多折线图最好开启抗锯齿或者用更高分辨率纹理。性能方面几百个点的折线图完全无压力但如果上万个点我建议先做降采样只绘制每 N 个点中的一个否则 UI 的 Grid 布局和刷新会变卡。4.4 可视化看板布局与交互细节图表组件做好后我在一个独立的 Scene 里搭了整个数据看板。看板布局我用了 Canvas 下嵌套若干 Panel 的方式上半部分是标题区和大数字摘要比如总战斗场次、总击杀数、平均分数下半部分左侧是柱状图右侧是折线图。底部分页按钮可以切换维度按地图、按时间、按玩家。摘要数字这部分可以从 SQL 里直接查var summary _connection.ExecuteScalarlong(SELECT COUNT(*) FROM BattleRecord);大数字文本的更新放在数据加载完成之后不要放在 Update 里逐帧刷新否则性能会被浪费。另外图表的数据刷新我加了一个“刷新”按钮点击后重新从数据库查询并重建图表。这是为了防止 UI 图表和数据库内容不同步。交互层面我给柱状图的每个柱子加了 Button 组件点击后弹出详情面板显示该柱子对应维度的明细数据。这种下钻交互是最基础的数据可视化操作却能让看板一下子专业起来毕竟“能看”和“能查”是两个层次的体验。5. 常见问题与排查技巧实录这一章我集中整理一下集成过程中遇到的典型问题按“现象 → 原因 → 解决”的格式整理成速查表再补充一些独家经验。5.1 DLL 加载失败与 .NET 版本冲突现象一编译报错 CS0246找不到 Mono.Data.Sqlite。原因插件没有正确放在 Assets/Plugins 目录下或者 .dll 文件没有勾选正确的平台兼容选项。解决在 Project 面板里选中插件文件在 Inspector 的 Select Platforms 中勾选需要的平台最常见的是勾上 Any Platform 或 Standalone Android iOS。现象二运行时报 DllNotFoundException: sqlite3。原因sqlite3 原生库没有随构建被打包或者 Unity 在运行时没能在正确的目录下找到对应的动态库。Windows 平台的 sqlite3.dll 要放在 Plugins 根目录Android 的 .so 要放在 Plugins/Android 目录下对应 ABI 文件夹里iOS 的 .a 静态库也要放在 Plugins/iOS 目录。发布前务必开启 Development Build在真机上跑一遍连接测试。5.2 Android 上数据库文件找不到或无法写入现象PC 编辑器上一切正常一部署到 Android 就报“no such table”或者“could not open database file”。原因90% 的情况是路径问题。开发时用了 Application.dataPath它指向 APK 包内部在 Android 沙盒限制下你没法写文件。解决统一用 Application.persistentDataPath并在首次运行时从 StreamingAssets 复制数据文件。另一个容易忽略的点如果你的 App 已经跑过一次数据库文件已经被创建后续代码改了表结构比如新增了字段旧库不会自动加列。排查思路是用 DB Browser 打开旧库手动对比表结构和代码里的类定义。如果差异很大最简单的方法是删掉旧库重跑一次但这会导致用户本地数据丢失所以正式项目要做数据库版本迁移简单做法是维护一个版本号表启动时比对版本执行对应的 ALTER TABLE 语句。5.3 中文乱码与编码问题Unity 的字符串默认是 UTF-8SQLite 存储文本本身不强制编码但如果你在 SQL 语句里硬编码中文比如WHERE MapName 地图01代码文件和编译产物的编码如果没有统一可能出现乱码。解决所有 C# 脚本统一保存为 UTF-8 with BOMSQL 语句里尽量用参数化查询不要拼接字符串。参数化写法_connection.Execute(UPDATE BattleRecord SET Score ? WHERE PlayerName ?, score, playerName);这不止是编码问题还能防止 SQL 注入。虽然本地数据库的注入风险很低但养成参数化的习惯总是好的。5.4 性能优化查询慢、UI 卡顿数据量不大的本地数据库查询慢基本不会是 SQLite 的问题而是你每帧都在查。新手常见写法是在 Update 里执行查询然后赋值给 Text这是性能杀手。正确做法是数据变化时才查询或者至少间隔几秒刷新一次查询结果缓存到内存列表。另一个性能隐患是把整个表查出来再在 C# 里做聚合。其实 SQL 的聚合能力非常强能查 AVG、SUM、COUNT、GROUP BY、ORDER BY就尽量在数据库层完成不要每次都把几千条原始记录全部 Load 到内存里再手动循环计算。除非你在做需要精细控制场景的特殊分析否则“能下推给 SQL 的就下推给 SQL”。UI 卡顿还可能是图表对象过度创建导致的。每次刷新都 Instantiate 几百个 Image再销毁会产生大量 GC。解决办法是对象池一开始按最大柱子数量生成 Image刷新时只改 Image 的 height 和颜色不重复创建销毁。我实测下来用对象池之后图表刷新耗时从数百毫秒降到了几十毫秒画面流畅度提升明显。5.5 自增 ID 获取与并发写入的坑自增 ID 的问题前面提到过这里再补一个并发场景。Unity 的单线程主线程模型下数据库操作基本都在主线程一般不会遇到并发冲突。但如果你用了异步任务Task.Run或者多线程插件去写数据库就要小心两个线程同时 Insert 时拿到的 last_insert_rowid 不是自己的数据。解决思路尽量把数据库写操作集中到主线程调度通过队列把子线程的写入任务串行化。如果必须跨线程每个线程持有独立的 SQLiteConnection避免共享连接。SQLite 本身支持多连接读但同一连接同时读写会出现 busy 错误。还有个小技巧如果表结构里有唯一约束插入之前可以先 SELECT 一次判断是否存在避免重复数据。可视化统计中最常见的问题就是“数据被重复插入图表翻倍”本质上是没有对业务 ID 做唯一性处理。6. 扩展思路与个人心得这套“Unity SQLite 可视化”的组合成型之后能干的事情比最初想象的要多。比如我可以把战斗录像的关键帧数据存进数据库然后结合 Timeline 做回放也可以把玩家在关卡内的路径点数据存下来利用 SQLite 的 JSON 扩展或者单独的表结构在编辑器里直接画出热力路径图。如果你有 3D 数据可视化的需求甚至可以把 SolidWorks 等建模软件导出的模型放进 Unity再用数据库驱动模型的位置、旋转、颜色这比单纯的 UI 图表更直观。最后分享一个很实际的经验数据库字段设计阶段一定要预留 create_time 和 update_time 两个字段别嫌浪费。我吃了不少没预留时间字段的亏后面想按时间维度画折线图结果发现原始表里根本没有可用的时间戳只能改表结构、写迁移脚本绕了一大圈。如果一开始就带上时间字段后面所有的按时间聚合查询都是顺手的事。从插件选型到路径适配从建表插数到图表自绘这套流程我跑通之后后续再做同类项目基本就是复用封装好的模块省下来的时间足够把更多精力放在数据分析和交互体验上。希望这篇实战记录能帮你顺利把 SQLite 集成进你的 Unity 项目少踩几个我已经替你踩过的坑。