企业官网建设流程全解析

1. 为什么要在嵌入式设备上折腾 SQLite

做过嵌入式开发的人大概都有过这样的纠结：设备跑起来了，传感器数据也在源源不断地产生，但这些数据往哪儿放？用普通文件存吧，查询起来得自己写解析逻辑，数据量一大就慢得让人抓狂；上 MySQL 或者 PostgreSQL 吧，那资源占用对于一块只有几十兆内存的开发板来说简直是灾难。这时候 SQLite 就成了一个绕不开的选择。

SQLite 这个库最讨人喜欢的地方在于它的"轻"。整个数据库引擎编译出来可能就几百 KB，运行时几乎不占什么额外内存，而且它不需要独立的服务进程，直接以库的形式链接进你的应用程序里。你可以把它理解成一个"会 SQL 的文件系统"——数据还是存在本地文件里，但你能用标准 SQL 语句去增删改查，省去了手写文件解析的全部麻烦。对于嵌入式场景来说，这几乎是关系型数据库的唯一现实解。

不过话说回来，把 SQLite 移植到嵌入式平台上，跟你在 PC 上apt install sqlite3完全是两码事。PC 上你面对的是成熟的包管理器和完整的操作系统支持，而嵌入式环境里，你可能要面对交叉编译工具链、精简过的 C 库、没有标准文件系统、甚至没有操作系统的情况。移植过程中踩的坑，往往不是 SQLite 本身的问题，而是构建系统、文件系统、内存管理这些底层环节的配合问题。

这篇内容适合两类人看：一类是刚接触嵌入式、需要给设备加本地数据存储功能的开发者，另一类是已经用过 SQLite 但想搞清楚移植细节和性能调优的老手。我会从源码获取、交叉编译配置、文件系统适配、实际读写测试这几个环节，把整个流程拆开讲清楚，重点放在那些文档里不会写、但实际移植时一定会遇到的问题上。

2. 移植前的准备工作：源码、工具链与目标平台确认

2.1 获取 SQLite 源码的正确姿势

SQLite 的源码获取方式有好几种，但嵌入式移植场景下，我强烈建议用amalgamation（合并版）而不是完整的源码树。所谓 amalgamation，就是把 SQLite 所有分散的 C 源文件合并成一个大文件sqlite3.c加上一个头文件sqlite3.h。这样做的好处非常直接：你只需要把这两个文件加入你的工程，配置好编译选项就能用，完全不需要去处理它原本复杂的构建系统。

为什么不用完整源码树？因为完整源码树里包含了大量的构建脚本、测试代码、文档和工具，交叉编译时这些都会成为干扰项。而且完整源码树的构建依赖 TCL 环境，很多嵌入式开发机上根本没装 TCL，光配这个环境就够你折腾半天。amalgamation 版本直接绕过了这个问题。

下载地址在 SQLite 官网的下载页面，找sqlite-amalgamation-xxxxxxx.zip这种命名的包。版本选择上，不建议追最新版，选一个发布半年以上、社区反馈稳定的版本更稳妥。太新的版本可能引入了一些针对新平台优化的代码，反而在老旧工具链上编译不过。

拿到压缩包后解压，你会看到四个文件：sqlite3.c、sqlite3.h、sqlite3ext.h和shell.c。前两个是核心，shell.c是命令行工具，嵌入式场景一般用不上，可以不管。

2.2 交叉编译工具链的确认

在动手编译之前，先把工具链的信息摸清楚。你需要确认三件事：目标平台的架构（ARM、MIPS、RISC-V 还是别的）、工具链前缀（比如arm-linux-gnueabihf-）、以及目标平台的 C 库类型（glibc 还是 musl 还是 uClibc）。

这三件事为什么重要？因为 SQLite 在编译时会根据 C 库的特性决定启用哪些功能。比如 glibc 有完整的 POSIX 线程支持，而某些精简的 C 库可能连pthread都不完整，这直接影响你能不能开启 SQLite 的多线程模式。再比如，如果你的目标平台没有mmap系统调用，那 SQLite 默认的内存映射 I/O 就得关掉，否则运行时会直接报错。

确认工具链的方法很简单，直接跑一下：

arm-linux-gnueabihf-gcc -v

输出里会显示目标架构和配置信息。如果工具链是你自己用 Buildroot 或 Yocto 生成的，那在生成配置里也能查到 C 库类型。这一步花五分钟确认清楚，能省掉后面几个小时的排查时间。

2.3 目标平台文件系统的摸底

SQLite 归根结底是要在目标平台的文件系统上创建数据库文件的，所以你得先搞清楚目标平台用的是什么文件系统。常见的嵌入式文件系统有 jffs2、ubifs、yaffs2、ext4 这几种。它们对 SQLite 的影响主要体现在两个方面：文件锁和掉电安全。

文件锁方面，SQLite 默认使用 POSIX 的fcntl文件锁来实现并发控制。大部分文件系统都支持，但有些网络文件系统或者特殊设计的只读文件系统可能不支持，这时候你就得改用 SQLite 的 other 锁模式，或者干脆用单连接模式。

掉电安全方面，jffs2 和 yaffs2 这类日志型闪存文件系统在写入时如果突然断电，可能会出现数据不一致。SQLite 本身有事务机制，但它的默认日志模式（rollback journal）在某些闪存文件系统上表现并不理想。如果你的设备有频繁掉电的风险，建议考虑开启 SQLite 的 WAL 模式，或者调整同步级别。

提示：在正式移植前，先在目标平台上跑一个简单的文件读写测试程序，确认文件系统能正常创建、写入、删除文件，并且支持fsync调用。这一步能提前暴露文件系统层面的问题。

3. 交叉编译 SQLite 的完整配置与实操

3.1 最简编译命令与关键宏定义

假设你已经把sqlite3.c和sqlite3.h放到了工程目录下，最基础的编译命令大概是这样：

arm-linux-gnueabihf-gcc -c sqlite3.c -o sqlite3.o \ -DSQLITE_OS_UNIX=1 \ -DSQLITE_THREADSAFE=0 \ -DSQLITE_OMIT_LOAD_EXTENSION=1 \ -DSQLITE_OMIT_DEPRECATED=1 \ -O2

这几行命令里，每个宏定义都有它的用意。SQLITE_OS_UNIX=1告诉 SQLite 目标平台是类 Unix 系统，这样它会启用 POSIX 相关的系统调用接口。SQLITE_THREADSAFE=0是关闭线程安全支持，这是嵌入式场景下最常用的配置——单线程访问数据库，省掉了互斥锁的开销，代码体积和运行时开销都能降下来。SQLITE_OMIT_LOAD_EXTENSION=1是去掉动态加载扩展的功能，嵌入式平台一般不需要这个，去掉能省不少空间。SQLITE_OMIT_DEPRECATED=1是去掉废弃的 API，进一步精简。

编译完之后，你可以用size命令看一下生成的目标文件大小：

arm-linux-gnueabihf-size sqlite3.o

正常情况下，text 段大概在 300KB 到 500KB 之间，具体取决于你开启了哪些功能。如果超过 1MB，那说明有些该关的功能没关掉，需要回头检查配置。

3.2 功能裁剪：哪些能砍，哪些不能砍

嵌入式设备资源紧张，功能裁剪是必须的。但砍功能不能乱砍，有些功能砍了会导致数据库无法正常工作。下面这张表是我在实际项目中总结出来的裁剪建议：

这里重点说一下SQLITE_OMIT_WAL。WAL 是 Write-Ahead Logging 的缩写，是一种比传统回滚日志更高效的日志模式。它的核心优势是读写可以并发进行，而且掉电恢复速度更快。如果你的设备有掉电风险，或者对读写并发有要求，那这个功能不能砍。但如果你的设备是持续供电的，而且存储空间极其紧张，那砍掉 WAL 能省下几十 KB 的代码空间。

另一个需要注意的是SQLITE_OMIT_UTF16。SQLite 默认同时支持 UTF8 和 UTF16 两种编码。如果你的应用只需要处理 ASCII 或者 UTF8 文本，那砍掉 UTF16 支持能省不少空间。但要注意，一旦砍掉，数据库文件就不能用 UTF16 编码存储了，而且某些 API 的行为会发生变化。

3.3 编译选项的取舍：优化等级与调试信息

优化等级的选择上，-O2是大多数情况下的最佳选择。-O3虽然理论上更快，但在某些嵌入式平台上可能会因为代码膨胀导致指令缓存命中率下降，反而变慢。-Os是优化体积，如果你的 Flash 空间非常紧张，可以用这个，但性能会有一定损失。

调试信息方面，开发阶段建议加上-g，方便用 gdb 调试。但发布版本一定要去掉，因为调试信息会让二进制文件体积膨胀好几倍。我一般会在 Makefile 里用两个不同的 target 来区分开发版和发布版：

CFLAGS_DEBUG = -g -O0 -DSQLITE_DEBUG CFLAGS_RELEASE = -O2 -DNDEBUG sqlite3_debug.o: sqlite3.c $(CC) -c $< -o $@ $(CFLAGS_DEBUG) sqlite3_release.o: sqlite3.c $(CC) -c $< -o $@ $(CFLAGS_RELEASE)

SQLITE_DEBUG这个宏会开启 SQLite 内部的断言检查，能帮你提前发现一些逻辑错误。但它会显著增加代码体积和运行开销，所以只能用在开发阶段。

3.4 链接阶段的注意事项

编译成.o文件只是第一步，链接阶段还有几个坑要注意。首先是数学库的问题，SQLite 在某些配置下会用到log()、pow()这些数学函数，链接时需要加上-lm。其次是线程库，如果你开启了SQLITE_THREADSAFE=1，那就需要链接-lpthread。最后是动态链接和静态链接的选择，嵌入式场景一般用静态链接，避免目标平台上缺少对应的动态库。

一个典型的链接命令大概是这样：

arm-linux-gnueabihf-gcc main.o sqlite3.o -o myapp -lm -lpthread -static

如果链接时报undefined reference to 'dlopen'之类的错误，那说明你忘了加SQLITE_OMIT_LOAD_EXTENSION=1，或者需要额外链接-ldl。这类问题在交叉编译时特别常见，因为宿主机的库和目标平台的库不一定完全对应。

4. 文件系统适配与运行时配置的实战细节

4.1 数据库文件的存放位置选择

数据库文件放哪儿，这个问题看起来简单，实际上影响很大。放在根文件系统的/tmp下？那重启就没了。放在只读的 squashfs 上？那根本写不进去。放在数据分区上？那得先确认数据分区已经挂载并且可写。

我的建议是，在应用启动时先检查数据库文件所在目录是否存在且可写，如果不行就报错退出，而不是等到 SQLite 打开数据库时才失败。检查的代码大概是这样：

#include <sys/stat.h> #include <unistd.h> int check_db_dir(const char *path) { struct stat st; if (stat(path, &st) != 0) { return -1; // 目录不存在 } if (!S_ISDIR(st.st_mode)) { return -2; // 不是目录 } if (access(path, W_OK) != 0) { return -3; // 不可写 } return 0; }

这个检查看起来多余，但在实际项目中能帮你快速定位"数据库打开失败"的原因。我遇到过好几次，最后发现是数据分区根本没挂载成功，而不是 SQLite 的问题。

4.2 文件锁模式的适配

前面提到过，SQLite 默认用fcntl文件锁。但在某些嵌入式文件系统上，fcntl的行为可能不符合预期。这时候你可以通过sqlite3_vfs接口自定义文件锁的实现，或者改用其他锁模式。

SQLite 提供了几种锁模式，可以通过编译宏或者运行时配置来选择：

• POSIX 锁：默认模式，用fcntl实现，适用于大多数 Unix 文件系统。
• flock 锁：用flock系统调用实现，某些文件系统上比fcntl更可靠。
• 其他锁：适用于不支持文件锁的文件系统，需要应用层自己保证并发安全。

切换锁模式的方法是在编译时定义SQLITE_ENABLE_LOCKING_STYLE=0来关闭自动锁模式检测，或者运行时通过sqlite3_vfs注册自定义的 VFS。对于大多数嵌入式场景，如果文件系统支持fcntl，用默认的 POSIX 锁就行。如果发现并发访问时出现奇怪的错误，再考虑换锁模式。

4.3 内存配置与页缓存调优

SQLite 默认的页缓存大小是 2000 页，每页默认 4096 字节，算下来大概 8MB。对于内存紧张的嵌入式设备来说，这个默认值太大了。你需要根据设备的实际内存情况来调整。

调整的方法是在打开数据库之后，执行几条 PRAGMA 语句：

sqlite3_exec(db, "PRAGMA cache_size = 200;", NULL, NULL, NULL); sqlite3_exec(db, "PRAGMA page_size = 1024;", NULL, NULL, NULL); sqlite3_exec(db, "PRAGMA synchronous = NORMAL;", NULL, NULL, NULL);

cache_size设为 200 页，配合 1024 字节的页大小，页缓存总共只占 200KB 左右，对大多数嵌入式设备来说是可以接受的。synchronous设为 NORMAL 是在性能和数据安全之间取一个平衡点，它比 FULL 模式快，但比 OFF 模式安全。如果你的设备有掉电风险，那还是老老实实用 FULL。

注意：page_size的设置必须在数据库创建之前进行，如果数据库已经存在，修改页大小需要先执行VACUUM命令重建数据库。这个细节很容易被忽略，导致设置不生效。

4.4 临时文件目录的指定

SQLite 在执行某些操作（比如排序、创建索引）时会生成临时文件。默认情况下，这些临时文件会放在系统临时目录（通常是/tmp）下。但嵌入式设备的/tmp往往是内存文件系统，空间有限。如果临时文件太大，就会导致操作失败。

解决办法是通过PRAGMA temp_store_directory指定一个空间更大的目录，或者用PRAGMA temp_store = MEMORY让临时数据全部放在内存里。后者速度更快，但会消耗更多内存，需要根据实际情况权衡。

sqlite3_exec(db, "PRAGMA temp_store_directory = '/data/tmp';", NULL, NULL, NULL);

如果目标平台的/data分区空间充足，用这个配置比较稳妥。如果内存够大，那用temp_store = MEMORY性能更好。

5. 从零跑通第一个嵌入式数据库程序

5.1 最小可运行示例的编写

配置都弄好之后，写一个最小的测试程序来验证整个链路是否通畅。这个程序不需要复杂的功能，只要能创建数据库、建表、插入数据、查询数据就行。

#include <stdio.h> #include <sqlite3.h> static int callback(void *not_used, int argc, char **argv, char **col_name) { for (int i = 0; i < argc; i++) { printf("%s = %s\n", col_name[i], argv[i] ? argv[i] : "NULL"); } printf("---\n"); return 0; } int main(void) { sqlite3 *db; char *err_msg = NULL; int rc; rc = sqlite3_open("/data/test.db", &db); if (rc != SQLITE_OK) { printf("open failed: %s\n", sqlite3_errmsg(db)); return 1; } const char *create_sql = "CREATE TABLE IF NOT EXISTS sensor_data (" "id INTEGER PRIMARY KEY AUTOINCREMENT," "timestamp INTEGER," "value REAL);"; rc = sqlite3_exec(db, create_sql, NULL, NULL, &err_msg); if (rc != SQLITE_OK) { printf("create table failed: %s\n", err_msg); sqlite3_free(err_msg); sqlite3_close(db); return 1; } const char *insert_sql = "INSERT INTO sensor_data (timestamp, value) VALUES " "(1000, 23.5), (1001, 24.1), (1002, 22.8);"; rc = sqlite3_exec(db, insert_sql, NULL, NULL, &err_msg); if (rc != SQLITE_OK) { printf("insert failed: %s\n", err_msg); sqlite3_free(err_msg); sqlite3_close(db); return 1; } const char *select_sql = "SELECT * FROM sensor_data;"; rc = sqlite3_exec(db, select_sql, callback, NULL, &err_msg); if (rc != SQLITE_OK) { printf("select failed: %s\n", err_msg); sqlite3_free(err_msg); } sqlite3_close(db); return 0; }

这个程序虽然简单，但它覆盖了 SQLite 最核心的几个 API：sqlite3_open、sqlite3_exec、sqlite3_close。编译的时候记得把sqlite3.c一起编进去。

5.2 交叉编译与部署到目标平台

编译命令前面已经给过了，这里补充一下完整的 Makefile 写法：

CC = arm-linux-gnueabihf-gcc CFLAGS = -O2 -DSQLITE_THREADSAFE=0 -DSQLITE_OMIT_LOAD_EXTENSION=1 LDFLAGS = -lm TARGET = dbtest OBJS = main.o sqlite3.o $(TARGET): $(OBJS) $(CC) $(OBJS) -o $@ $(LDFLAGS) main.o: main.c sqlite3.h $(CC) $(CFLAGS) -c $< -o $@ sqlite3.o: sqlite3.c sqlite3.h $(CC) $(CFLAGS) -c $< -o $@ clean: rm -f $(OBJS) $(TARGET)

编译完成后，把生成的dbtest可执行文件拷贝到目标平台。拷贝方式取决于你的调试手段，可以用 scp、tftp、U 盘，或者直接打包进固件里。拷贝过去之后，记得给可执行权限：

chmod +x dbtest

然后运行：

./dbtest

如果一切正常，你应该能看到查询结果的输出。如果报错，根据错误信息逐步排查。

5.3 常见运行时错误与排查思路

第一次跑的时候，最常见的错误有这么几种：

错误一：unable to open database file。这个错误的原因可能是目录不存在、目录不可写、或者路径拼写错误。排查方法是先用ls -ld看一下目录权限，再用touch命令测试一下能否在该目录下创建文件。

错误二：disk I/O error。这个错误通常意味着文件系统层面出了问题，比如存储介质损坏、文件系统挂载异常、或者空间不足。排查方法是先用df -h看一下剩余空间，再用dmesg看一下内核日志里有没有存储相关的错误信息。

错误三：database is locked。这个错误说明有另一个连接正在写数据库，或者之前的连接没有正常关闭导致锁没释放。排查方法是确认没有其他进程在访问同一个数据库文件，如果有，等它释放锁；如果没有，那可能是文件锁机制有问题，需要检查文件系统的锁支持。

错误四：程序运行到一半直接崩溃。这种问题往往跟内存有关，可能是栈溢出、堆损坏，或者 SQLite 的配置跟目标平台不匹配。排查方法是先用ulimit -c unlimited开启 core dump，然后分析 core 文件。如果没有 core 文件，那就在代码里加日志，逐步缩小问题范围。

6. 性能调优与长期运行的经验总结

6.1 批量插入的性能优化

嵌入式设备上往数据库里写数据，如果一条一条地插入，性能会非常差。原因是每次插入都会触发一次事务提交，而事务提交涉及到磁盘同步操作，这是最耗时的环节。解决办法是把多条插入合并到一个事务里：

sqlite3_exec(db, "BEGIN TRANSACTION;", NULL, NULL, NULL); for (int i = 0; i < 1000; i++) { // 执行插入语句 } sqlite3_exec(db, "COMMIT;", NULL, NULL, NULL);

这样一千条插入只需要一次磁盘同步，性能能提升几十倍甚至上百倍。实测下来，在同样的硬件平台上，逐条插入一千条记录可能需要好几秒，而合并事务之后只需要几十毫秒。

另一个优化点是使用预编译语句（prepared statement）。如果你的插入语句结构相同，只是参数不同，那用sqlite3_prepare_v2编译一次，然后循环用sqlite3_bind_*绑定参数、sqlite3_step执行，能省掉每次解析 SQL 的开销。

6.2 查询性能的优化手段

查询优化主要靠索引。如果你的表数据量比较大，而且经常按某个字段查询，那给这个字段建索引能大幅提升查询速度。建索引的 SQL 很简单：

CREATE INDEX idx_timestamp ON sensor_data(timestamp);

但索引不是越多越好，因为索引本身也占空间，而且插入数据时维护索引会增加开销。一般来说，只在最常用的查询字段上建索引就行。

还有一个容易被忽略的点是EXPLAIN QUERY PLAN命令。它能告诉你 SQLite 执行一条查询时用了什么策略，是全表扫描还是走了索引。在优化查询之前，先用这个命令看一下执行计划，能帮你快速定位性能瓶颈。

EXPLAIN QUERY PLAN SELECT * FROM sensor_data WHERE timestamp > 1000;

如果输出里出现SCAN TABLE，说明是全表扫描，需要考虑加索引。如果出现SEARCH TABLE USING INDEX，说明走了索引，性能应该没问题。

6.3 长期运行的数据清理策略

嵌入式设备通常需要长期运行，数据会不断累积。如果不做清理，数据库文件会越来越大，最终可能撑爆存储空间。清理策略有几种：

第一种是定期删除旧数据。比如只保留最近七天的数据，每天凌晨执行一次删除操作：

DELETE FROM sensor_data WHERE timestamp < strftime('%s', 'now', '-7 days');

第二种是分表存储。按时间分表，比如每个月一张表，过期的表直接删除。这种方式的优点是删除操作很快，不需要逐条删除。缺点是查询跨表数据时比较麻烦。

第三种是限制数据库文件大小。当文件超过一定大小时，触发清理操作。这种方式实现起来稍微复杂一些，但能精确控制存储占用。

不管用哪种策略，删除数据之后记得执行VACUUM命令来回收空间。SQLite 删除数据后，文件大小不会自动缩小，需要VACUUM来重建数据库文件。但VACUUM操作比较耗时，而且执行期间需要额外的磁盘空间，所以最好在设备空闲时执行。

6.4 掉电保护与数据完整性

嵌入式设备经常面临意外掉电的情况，如果数据库正在写入时掉电，可能会导致数据损坏。SQLite 本身有事务机制来保证数据完整性，但前提是文件系统和存储介质能正确响应同步请求。

提高掉电安全性的方法有几个：一是把PRAGMA synchronous设为FULL，这样每次事务提交都会等待数据真正写入存储介质；二是开启 WAL 模式，WAL 模式下掉电恢复更快，而且不容易损坏数据库文件；三是定期备份数据库文件，万一损坏了还能恢复。

WAL 模式的开启方法很简单：

PRAGMA journal_mode = WAL;

执行之后，SQLite 会创建一个-wal后缀的日志文件。正常关闭数据库时，这个日志文件会被自动合并回主数据库文件。如果掉电了，下次打开数据库时 SQLite 会自动从 WAL 文件恢复数据。

提示：WAL 模式需要文件系统支持共享内存映射，某些嵌入式文件系统可能不支持。开启之前先在目标平台上测试一下，确认能正常工作。

6.5 我踩过的几个印象深刻的坑

第一个坑是文件系统空间不足导致的数据库损坏。有一次设备运行了几个月之后，数据库突然打不开了，报database disk image is malformed。排查了半天才发现是存储空间满了，SQLite 在写入时没有足够的空间完成事务，导致数据库文件处于不一致状态。后来加了空间监控，剩余空间低于 10% 就触发清理，再也没出现过这个问题。

第二个坑是多线程访问没有加锁。早期的一个项目里，我在两个线程里同时访问同一个数据库连接，结果偶尔会出现查询结果错乱。后来查文档才知道，SQLite 的连接对象不是线程安全的，多线程访问要么每个线程用自己的连接，要么在应用层加锁。改成每个线程独立连接之后问题就消失了。

第三个坑是页大小设置不生效。前面提到过，page_size必须在数据库创建之前设置。我一开始不知道这个规则，在已有数据库上执行PRAGMA page_size = 1024，结果怎么都不生效。后来查了文档才明白，需要先删掉数据库文件重新创建，或者执行VACUUM重建。

第四个坑是临时文件目录不可写。有个项目的目标平台把/tmp挂载成了只读，SQLite 在执行排序操作时无法创建临时文件，导致查询失败。后来通过PRAGMA temp_store_directory把临时目录改到了可写的分区，问题解决。

这些坑的共同特点是：它们都不是 SQLite 本身的 bug，而是嵌入式环境的特殊性导致的。理解了这一点，排查问题时就不会把时间浪费在怀疑 SQLite 上，而是去检查环境配置。

6.6 关于版本升级的务实建议

最后聊一下版本升级的问题。SQLite 的更新频率很高，几乎每个月都有新版本。但对于嵌入式项目来说，频繁升级并不是一个好主意。我的建议是：项目初期选一个稳定版本，整个开发周期内不要轻易升级。等到项目稳定了，再评估是否有必要升级到新版本。

升级之前一定要做完整的回归测试，特别是数据库文件的兼容性测试。虽然 SQLite 官方承诺向后兼容，但某些配置变化（比如页大小、编码方式）可能会导致旧数据库文件无法直接使用。升级前先备份数据库文件，升级后在测试环境验证通过再部署到生产设备。

另外，升级时要注意新版本可能引入了新的编译依赖或者改变了默认配置。比如某个版本开始默认开启了 WAL 模式，如果你的文件系统不支持，就会导致运行时错误。所以升级时不能只替换sqlite3.c和sqlite3.h，还要重新检查编译配置。

我在实际项目中的做法是，把 SQLite 的版本号和编译配置一起记录在项目的构建文档里，每次升级都更新这个文档。这样即使过了很久再回头看，也能快速搞清楚当时用的是什么配置，省去了重新摸索的时间。