提到移动端数据存储，大部分开发者第一反应是SQLite或者基于它的各种ORM框架。SQLite确实好用，轻量、零配置、单文件，几乎撑起了整个移动端的本地存储生态。但有一个问题经常被忽视：SQLite的数据库文件是明文的。只要拿到那个db文件，用任何SQLite工具都能直接打开，表结构、数据内容一览无余。如果App里存了用户的登录token、聊天记录、身份证号这类敏感信息，明文存储的风险就非常大了。设备越狱或root之后，攻击者可以直接读取沙盒里的数据文件；手机丢失后被人提取数据，也是同样的隐患。这篇文章就来聊聊怎么在移动端实现加密数据库，把本地数据真正保护起来。
为什么明文SQLite不够安全
很多团队对本地数据库的安全认知停留在“数据在沙盒里，别的App读不到”这个层面。沙盒机制确实挡住了普通应用之间的互访，但它挡不住几种常见场景。第一种是root和越狱设备，root之后的Android设备可以自由访问/data/data目录下的所有文件，越狱的iOS设备同样能通过工具读取沙盒内容。第二种是备份提取，iOS设备通过iTunes或爱思助手备份时，如果不开启加密备份，App沙盒数据会被完整导出。第三种是内部风险，测试包、日志文件意外流出时，数据库文件往往跟着一起泄露。
实际测试一下就明白了。把一个正常App的db文件用adb pull拉出来，然后用DB Browser for SQLite打开，用户表、订单表里的内容清清楚楚。即使是经过混淆的字段名，只要数据本身是明文，敏感信息照样能被读取和批量导出。所以对涉及个人隐私、金融、医疗类数据的App来说，数据库加密不是可选项，而是必须做的基础安全措施。
SQLCipher：最主流的移动端加密方案
SQLCipher是SQLite的开源加密扩展，原理是在SQLite的读写层插入了加解密逻辑，数据库每一页在写入磁盘前都会用AES-256-CBC算法加密，读取时再解密还原。对上层业务完全透明，SQL语句该怎么写还怎么写，性能损耗在多数场景下可以控制在10%以内。
Android接入SQLCipher的方式很简单，引入官方的android-database-sqlcipher依赖，然后把原来的SQLiteOpenHelper换成SupportFactory包装即可。
// build.gradle 引入依赖
// implementation 'net.zetetic:android-database-sqlcipher:4.5.4'
SQLiteDatabase.loadLibs(context); // 初始化native库
SupportOpenHelperFactory factory = new SupportOpenHelperFactory(passphraseBytes);
AppDatabase db = Room.databaseBuilder(context, AppDatabase.class, "secure.db")
.openHelperFactory(factory) // 关键：用SQLCipher的工厂替换默认工厂
.build();
iOS端同样有成熟的CocoaPods支持，pod 'SQLCipher'之后，在打开数据库时执行PRAGMA key语句即可。注意key必须在执行任何SQL之前设置，否则后续操作会报“file is not a database”错误。
// iOS端使用SQLCipher NSData *passphrase = [self databaseKey]; // 从安全存储获取密钥 sqlite3 *db; sqlite3_open([[dbPath UTF8String]], &db); sqlite3_key(db, [passphrase bytes], (int)[passphrase length]); // 设置加密密钥 // 之后的SQL操作与普通SQLite完全一致
SQLCipher的加密粒度是页级别的，默认每页4096字节，每页有独立的初始化向量，同时通过HMAC校验保证数据完整性，防止数据被篡改。密钥长度建议用256位，除非有性能极端敏感的场景才考虑降到128位。
其他方案对比：Realm加密与平台原生能力
除了SQLCipher，Realm数据库自带加密能力，打开Realm配置时传入64字节的encryptionKey就行，实现起来比SQLCipher更省事。但Realm在国内的使用基数远小于SQLite，团队学习成本和社区资料都要考虑。iOS端还有NSPersistentContainer配合Core Data的方案，Core Data本身不加密，但可以通过NSPersistentStoreFileProtectionKey设置文件级加密，利用的是iOS的硬件加密引擎，实现成本最低。
Android这边对应的是EncryptedSharedPreferences和官方的Security Crypto库，不过它们主要面向键值对存储。如果App已经用Room或GreenDAO做关系型存储，迁移到SQLCipher是改动最小的路径；如果是新项目且数据模型简单，也可以评估WCDB，它是微信团队开源的数据库组件，内置加密和损坏修复能力，在国内大型App里经过了海量验证。
密钥管理才是真正的难点
数据库加密之后，密钥就成了整个安全体系的命门。密钥硬编码在代码里等于没加密，反编译一下就能拿到。比较稳妥的做法是Android用Android Keystore系统生成密钥，密钥材料保存在硬件安全模块中，无法导出；iOS用Keychain存储密钥，配合设备的Secure Enclave更安全。
// Android Keystore生成不可导出的密钥
KeyGenerator keyGenerator = KeyGenerator.getInstance(
KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
keyGenerator.init(new KeyGenParameterSpec.Builder("db_master_key",
KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
.setBlockModes(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.setUserAuthenticationRequired(false)
.build());
keyGenerator.generateKey();
// 用主密钥加密数据库密钥后再存储，数据库密钥本身不落明文
另一个常见坑是密钥换了导致老数据打不开。设计时要考虑密钥轮换机制，比如在服务端下发换钥指令时，先解密旧库导出数据，再用新密钥重建。还有一点要注意：加密数据库文件必须配合代码混淆使用，否则攻击者拿到密钥生成逻辑的源码，逆向成本会大幅降低。ProGuard或R8混淆加上密钥动态生成，两道防线叠加才是完整的方案。
性能影响与落地建议
加密必然带来开销，实测SQLCipher在批量插入场景下比原生SQLite慢15%到30%，查询场景影响相对小一些。优化手段包括：把PRAGMA cipher_memory_security关闭（默认关闭状态性能更好）、开启WAL模式、避免在事务外做大量小写入。对绝大多数业务来说这点损耗完全可接受，千万不要因为性能顾虑放弃加密。
落地时建议分三步走：先盘点App里所有本地存储的敏感数据字段，明确加密范围；再选择与现有技术栈匹配的加密方案做技术验证；最后灰度上线，重点监控数据库打开失败率，因为密钥存储迁移出问题时用户会集体报“数据库打不开”，这种情况要有兜底的降级逻辑，比如清库重建加重新拉取数据。加密数据库不是一劳永逸的事情，配合定期的安全审计和密钥轮换，才能真正守住用户数据的第一道防线。