简介：一套面向64位Windows与Visual Studio 2012的C#调用SQLite示例源码，演示了如何通过System.Data.SQLite完成数据库创建、建表、参数化增删改查，以及利用连接字符串设置密码保护等关键操作，无论是学习SQLite编程还是为小应用快速增加数据持久化能力，都能找到可直接运行的代码。源码包共42个文件，含9个C#源文件、解决方案与工程配置（.sln/.csproj）、编译生成的exe和依赖dll、窗体设计资源resx等，压缩后约2.48MB，组织清晰，便于按模块检索。已有850人浏览，适合正在为桌面工具、进销存或数据采集类程序集成轻量级数据库的开发者参考。通过对Form1.cs、App.config等核心代码的分析，可快速掌握SQLiteConnection连接、SQLiteCommand执行SQL、SQLiteDataReader读取结果的标准写法，理解带Password参数的连接串与常见加密思路，避开64位SQLite编译和授权陷阱。同时，窗体界面示例和工程配置让读者既能学习逻辑又能直接运行调试，方便将这套轻量级存储方案应用到实际项目中。
1. 64位 C# 2012 调 SQLite：为什么加密这一步会卡住大多数人
做上位机或者桌面工具的朋友，大概率遇到过这个场景：手头一台 Win7/10 的 64 位机器，工程还是 VS2012 时代留下来的一套 C#，数据量不大但客户要求“数据库文件必须带密码”。64 位 C# 2012 调用 SQLite 数据库源码看起来遍地都是，真到了要交付 exe 的时候，卡人的基本就两件事：一是 64 位与 SQLite 原生库的位数匹配，二是设置密码后文件能不能真正锁住。这套方案适合谁？写 C# 上位机、内部工具、离线小系统的开发者，数据库文件要随程序分发，又不想让拿到文件的人直接拖进 DB 工具里看数据。先说结论：用 System.Data.SQLite 的 x64 版本，连接串里带 Password，就能在 VS2012 工程里把加密和调用一次做通。
2. 位数匹配是第一步：混合程序集与 VS2012 工程配置
2.1 为什么 System.Data.SQLite 必须按位数选版本
SQLite 底层是 C 写的原生库，System.Data.SQLite 这个封装不是一个纯托管 DLL，而是“托管代码 + 原生代码”混合在一起。这意味着进程跑在什么位数上，就得加载什么位数的原生部分。你在 64 位系统上跑一个 AnyCPU 的程序，进程默认是 64 位，却引用了 x86 版 System.Data.SQLite，最常见的结果就是抛 BadImageFormatException，或者程序启动时报错后直接退出，诡异的是有时候错误发生在你根本想不到的深层调用里，异常信息还甩锅给别的程序集。
VS2012 里的“平台目标”默认是 AnyCPU，而 .NET 4.5 对 AnyCPU 有一套自己的处理规则，核心就是“运行时才决定用 x86 还是 x64”。这就造成一个很反直觉的现象：同一份代码，在你本机 Debug 跑得好好的，拷到另一台机器或者切 Release 就崩。原因多半是编译目标或者引用的 DLL 位数变了。所以我对用 VS2012 的同事只有一个建议：凡是工程里出现 SQLite、Access、或者其他带原生 DLL 的库，直接把平台目标锁死，不要赌 AnyCPU。
2.2 工程里需要锁定的三处配置
第一处是“项目属性 → 生成 → 平台目标”，选 x64，不要选 AnyCPU。第二处是如果项目里还有“首选 32 位”（Prefer 32-bit）这个勾选框，务必要取消。VS2012 默认模板基本不会自动勾上，但如果你从 VS2015 之后的工程迁过来，这个选项会被带进来，一旦勾着，程序就算编译成 x64 也会以 32 位身份跑，SQLite 原生库立刻翻脸。第三处是引用的 System.Data.SQLite.dll 属性里的“复制本地”设为 True，同时保证 SQLite.Interop.dll 也能跟着输出到生成目录。
这里要多说一句 SQLite.Interop.dll。它是真正的原生核心，按 x86 和 x64 分目录存放。你手动添加引用时经常只引了托管 DLL，忘了输出目录里的 Interop 文件，程序一跑就报“无法加载 DLL‘SQLite.Interop.dll’”。这个文件必须在 exe 旁边，x64 版就放在 x64 子目录下，新版驱动会自动按架构找，前提是你别手动改它的位置。
2.3 用 NuGet 还原和手工拷贝两条路
VS2012 自带 NuGet，包管理器控制台里执行 Install-Package System.Data.SQLite 是最常见的做法。注意包名别看错，有的是 Core 版，有的是带 LINQ 的完整版，如果只是要基本的 ADO.NET 访问，装标准版就够。安装完成后，去 packages 目录确认一下有没有把 x64 的 Interop 文件带进输出目录，这一步很多人做完就不看了，实际上一大半运行时错误都出在这。
如果项目环境不允许联网，常见做法是手工下载安装版或二进制包，把 System.Data.SQLite.dll 和对应位数的 SQLite.Interop.dll 拷进工程目录，引用时选“浏览”，然后按 2.2 节配置复制本地。这种方式反而比 NuGet 更可控，因为你能明确知道拷进来的是 x64 还是 x86。装完之后用一个最简单的方式验证：写一行代码输出 SQLiteConnection 的版本和当前进程位数，能跑通再往后写业务。
3. 最小可跑源码：带密码的建库、读写与换密码
3.1 首次建库并设置密码的最短路径
先把一个能跑的整段贴出来，这是我在新工程里验证环境的第一块代码，小于这个规模不要往业务里写：
using System; using System.Data.SQLite; using System.IO; class Program { static void Main() { string dbPath = @"D:\demo\app.db"; // Password 写在连接串里，文件不存在时驱动会新建并直接生成加密库 string connStr = $"Data Source={dbPath};Password=MyP@ss2024;"; using (var conn = new SQLiteConnection(connStr)) { conn.Open(); using (var cmd = conn.CreateCommand()) { cmd.CommandText = "CREATE TABLE IF NOT EXISTS sensor(" + "data_id INTEGER PRIMARY KEY," + "value REAL NOT NULL," + "ts TEXT NOT NULL);"; cmd.ExecuteNonQuery(); cmd.CommandText = "INSERT INTO sensor(value, ts) VALUES" + "(1.5, '2024-01-01 10:00:00')," + "(2.5, '2024-01-01 10:01:00')," + "(3.5, '2024-01-01 10:02:00');"; cmd.ExecuteNonQuery(); } } Console.WriteLine("database created, size = " + new FileInfo(dbPath).Length); } }这段代码做的事情是：连接串里带 Password 打开一个不存在的库，System.Data.SQLite 会先创建一个空库，再把加密头写进去，之后所有写入都是加密状态。也就是说，带密码打开这个动作本身就是在“建一个加密库”，不是在普通库上后补密码。执行完，D 盘上这个 .db 示例文件已经不能用普通 SQLite 工具直接读了。
参数上最需要注意的是 Data Source 的路径，相对路径会跟着当前工作目录走，Windows 服务里启动的工作目录经常不是你以为的 exe 目录，所以正式程序一律用绝对路径，或者用 Path.Combine 拼出确定的目录。Password 里如果出现分号，整个连接串解析会出问题，我一般会避免在密码里用特殊符号，或者用 SQLiteConnectionStringBuilder 构造连接串，它能正确转义特殊字符，写法见下一节。
3.2 SQLiteConnectionStringBuilder 与连接串参数说明
直接用字符串拼连接串容易踩转义坑，尤其是密码。推荐用 SQLiteConnectionStringBuilder，代码可读性也好很多：
var builder = new SQLiteConnectionStringBuilder { DataSource = @"D:\demo\app.db", Password = "p@ss;word", FailIfMissing = false, // 库不存在时允许自动创建 Pooling = true, // 开启连接池，默认就是 true DateTimeFormat = SQLiteDateFormats.ISO8601, Version = 3 }; using (var conn = new SQLiteConnection(builder.ConnectionString)) { conn.Open(); // 打开后执行任意一条语句，确认读写通道正常 using (var cmd = conn.CreateCommand()) { cmd.CommandText = "SELECT count(*) FROM sqlite_master;"; Console.WriteLine("object count = " + cmd.ExecuteScalar()); } }常用参数各有各的坑，挑重点说：
| 参数 | 默认行为 | 我一般怎么设 |
|---|---|---|
| Password | 无密码 | 需要加密时必填，空密码等于没加密 |
| FailIfMissing | false | 正式环境建议改 true，库文件被误删时直接报错，而不是静默重建一个空库 |
| Pooling | true | 保持默认，加密库的密钥会被缓存在连接池里，后面会专门讲 ClearPool 的坑 |
| DateTimeFormat | ISO8601 | 按你存的日期格式选，别在程序里统一转字符串反而更省事 |
| Version | 3 | 老项目如果是 SQLite 2 才需要改，现代项目不用动 |
这段代码在 ExecuteScalar 里会触发 SQLite 内部的 sqlite3_exec 回调机制。C# 层不直接暴露 sqlite3_exec，但驱动的 Command 对象在遍历结果时，内部走的正是那套回调分发流程。你只需要知道一件事：C# 里不需要自己注册回调，所有行数据通过 DataReader 或 DataAdapter 拿就行。
3.3 修改密码与清除密码
建库之后要改密码，用 ChangePassword 方法。这个方法必须在一个已经打开的加密连接上调用，调用之后文件里的密钥会被重写：
using (var conn = new SQLiteConnection(@"Data Source=D:\demo\app.db;Password=MyP@ss2024;")) { conn.Open(); conn.ChangePassword("NewP@ss2025"); SQLiteConnection.ClearAllPools(); // 立即使旧连接池中的连接失效 }清除密码的写法是 ChangePassword 传空字符串或 null，按你所用版本的 XML 注释确认。我习惯传空字符串，语义更清楚。注意清除密码之后这个库就变成明文了，文件直接拖进 db browser for sqlite 就能看，交付前要想清楚这一步要不要暴露。
还有一个细节：ChangePassword 之后，先前已经打开的连接还能继续用一段时间。原因是连接池把旧连接缓存了，池里的连接用的还是旧密钥。所以改完密码立刻 ClearAllPools，不然程序里其他地方复用的连接打开的就是旧库结构，错误信息还特别难猜。这一段属于能跑通但最容易留下隐患的地方。
4. 内置 Password 与 SQLCipher：加密方案怎么选
4.1 内置 Password 的实际保护边界
System.Data.SQLite 连接串里的 Password 并不是 SQLite 官方开源内核自带的，它依赖驱动编译时内置的加密扩展。效果上，整个数据库文件被加密，文件头不再是明文的 “SQLite format 3”，用文本编辑器打开是乱码，普通工具直接报错。对大多数上位机场景，这个强度已经够用：客户拷走文件后没法直接看业务数据，也不会有专职安全人员盯着你的库做字典攻击。
但必须说清楚边界。第一，同样的驱动版本才有同样的加密算法，换一个版本的 System.Data.SQLite，原来设的密码可能打不开老库，升级驱动前要备份测试。第二，加密只保护文件本身，程序一旦运行起来，解密后的页面在内存里是明文的，这没什么可做的，别指望文件加密能挡住调试器。第三，内置 Password 对 DBA 工具不友好，日常维护数据库时，db browser 这类工具大概率认不出加密格式，你得专门留一把明文备份给自己调试用。
另外要注意，加密不是“数据库的权限系统”。SQLite 本身没有用户和角色，拿到密码的人就是全部权限。有人想用 Password 做多用户权限隔离，那是方向性错误，密码加密文件顶多算一道门锁，不是门禁系统。
4.2 SQLCipher 在什么场景替换内置方案
如果交付对象是银行、医疗这类对加密算法有明确要求的项目，内置 Password 就不够看了，因为它对外的算法名、密钥派生方式比较模糊，合规审计很难写。这种情况我会换成 SQLCipher 编译版。SQLCipher 是对 SQLite 内核加了 AES 加密层的实现，社区和商业项目用得都多，密钥可以通过 PRAGMA key 传入，也支持 rekey 换密钥。
替换的做法有两种。一种是直接把 System.Data.SQLite 换成 SQLCipher 的编译版本，老代码改动最小，连接串里 Password 的写法不变，但底层算法已经换成 AES；另一种是用新版生态里的 Microsoft.Data.Sqlite 配合 SQLitePCLRaw 的 e_sqlcipher 包，这个方案在 .NET 6+ 上很顺，但在 VS2012 的 .NET 4.5 工程里引入起来很别扭，我一般是新项目才这么搭。老工程还在 VS2012 上维护的话，第一种替换更实际：找对应的 x64 SQLCipher 版本，替换 DLL，跑一遍全部读写用例，重点验证换库文件后旧密码是否还能打开现场数据。
4.3 内置 Password 与 SQLCipher 的差异对比
选型时先看一个表，再对照自己的项目情况做决定：
| 对比点 | 内置 Password | SQLCipher |
|---|---|---|
| 算法可见性 | 依赖驱动内置实现，对外不透明 | AES 加密，算法和参数公开 |
| 第三方工具支持 | 多数工具不认；DB Browser 对它的识别依赖版本 | DB Browser for SQLite 选择 SQLCipher 加密后可直接输密码打开 |
| 换驱动版本的风险 | 较高，老库可能打不开 | 相对低，加密头格式稳定 |
| 合规审计 | 困难，拿不出算法说明 | 容易，业界认知度高 |
| 部署复杂度 | 一个官方包搞定 | 需要替换或额外引入相关 DLL |
| 性能开销 | 较小 | 略高，写入性能约降 2 到 3 成，实测为准 |
我的选型标准很简单：没有合规要求、内部工具、客户只要求“文件打不开”，用内置 Password，省事；有第三方数据交换、有安全审计、或者要把库文件交给客户自己在 DB 工具里查数据，上 SQLCipher。千万不要两个方案混用，加密头不兼容会让两边都打不开同一个文件，现场救数据很狼狈。
5. 加密和位数相关的五个常见坑：现象与定位
5.1 运行抛 BadImageFormatException
现象：程序启动后某个连接打开语句直接抛 System.BadImageFormatException，异常消息指向 System.Data.SQLite.dll，或者指向某个不相关的程序集。
原因：进程位数和 SQLite 原生部分位数不匹配。最常见的组合是程序跑在 64 位下，引用的却是 x86 版 DLL；或者平台目标改成了 x64，但输出目录里的 SQLite.Interop.dll 是 x86 子目录里带出来的。
解决：先看任务管理器确认进程是 32 位还是 64 位，再看输出目录里的 SQLite.Interop.dll 是哪个架构。两个都对上号再继续。我习惯在代码入口打印一行 Environment.Is64BitProcess，不是给自己看，是方便现场排查的人一眼判断位数。
5.2 报错找不到 SQLite.Interop.dll
现象：异常信息是 Unable to load DLL 'SQLite.Interop.dll' 或者 The specified module could not be found，有时候还会带 0x8007007E 这种十六进制错误码。
原因：你只引用了托管的 System.Data.SQLite.dll，原生 DLL 没有被复制到输出目录。这个文件按 x86/x64 分文件夹存放，如果工程配了自定义生成事件或者手动拷贝脚本，很容易漏掉其中一个架构的文件夹。
解决：输出目录完整结构应该是 exe 旁边有 System.Data.SQLite.dll，下面有 x64 和 x86 两个子目录，各自放 SQLite.Interop.dll。注意这个命名规则不能改，改了驱动找不到。手工部署时把整个 x64 文件夹原样拷走，不要只拷贝里面的 DLL 文件。
5.3 加密文件用第三方工具打不开
现象：数据库是程序正常建的，密码也是对的，但用 db browser for sqlite 打开时提示 file is not a database，或者另一个工具直接显示乱码。
原因：第三方工具默认按普通 SQLite 文件解析。加密文件有自定义文件头，普通解析必然失败。这不代表你的库坏了，反而是加密生效的证明。
解决：区分两种情况。内置 Password 加密的库，找支持对应加密格式的工具或版本；SQLCipher 加密的库，在 db browser for sqlite 打开时选择 SQLCipher 加密类型，再输入密码才能进。验证库是否损坏，用程序自己打开跑 count 才是准的，不要因为工具打不开就去恢复数据，我见过不少人把好库折腾坏了。
5.4 ChangePassword 之后旧连接还能用
现象：程序跑着的时候改了一次密码，旧连接后续读写居然没报错，但新启动的连接用新密码也正常，过一段时间旧连接又突然连不上了。
原因：连接池缓存了旧密钥连接。SQLite 连接池默认开启，改密码不会去清除池里已经建立的连接，池里的连接还在用旧密钥操作文件，直到被回收。
解决：ChangePassword 之后立刻调用 SQLiteConnection.ClearAllPools()。如果程序是多线程的，改密码前要停掉其他线程的数据库访问，不然有的线程用旧密码打开新连接会被池直接复用，出现读写互相锁死。这也是老项目里改加密库密码必须先发公告再停服的原因。
5.5 十万条数据写入加密库慢得离谱
现象：明文库批量插入一万条不到一秒，加密库跑同样的插入要几十秒，甚至越插越慢。
原因：加密库每次写入都要做加密计算和页写回，事务没开启时每条 INSERT 都是独立事务，fsync 加加密，开销完全叠加上去。十万条这个规模如果一条条提交，耗时能让人以为程序死锁了。
解决：批量写入包一个事务，或者用事务包裹一万条一批提交。代码里就是 conn.BeginTransaction() 然后 ExecuteNonQuery，最后 commit。顺带把 journal_mode 调成 WAL，读多写少的场景下收益明显。但注意，加密库搭配 WAL 时，要确认你用的加密组件对 WAL 支持正常，先拿小库压一遍再上生产。
6. 验证加密文件是否生效，加两个实用调参
验证这一步很多人跳过，但我建议每交付一个加密库，至少做一次文件头检查。普通 SQLite 文件的前 16 字节是明文字符串 “SQLite format 3”，加密后这个头会变掉，用一段小代码就能自检：
byte[] head = new byte[16]; using (var fs = File.OpenRead(dbPath)) { fs.Read(head, 0, head.Length); } string header = Encoding.ASCII.GetString(head); Console.WriteLine(header.StartsWith("SQLite format 3") ? "未加密" : "已加密或非SQLite文件");命令行也一样，在 Linux 或 Windows 的 Git Bash 下可以跑：
head -c 16 app.db | od -c看到最前面不是 “S Q L i t e f o r m a t 3”，就说明文件已经被改写。配合 db browser for sqlite 手动输密码打开一次，确认能正常看到表结构，这套加密链路才算闭环。我见过太多人写完代码不验这一步，最后交付的库其实是明文，因为连接串里的 Password 在某些驱动版本里根本没生效。
调参方面，有两个实用设置值得固化到模板里。第一个是连接超时，SQLite 在文件被其他进程锁住时会报 database is locked，默认等待时间可能不够，我会在打开连接前设置 SQLiteConnection.DefaultTimeout = 10，让驱动在锁冲突时多等一会儿而不是立刻抛异常。第二个是初始化脚本：
using (var conn = new SQLiteConnection(builder.ConnectionString)) { conn.Open(); using (var cmd = conn.CreateCommand()) { cmd.CommandText = "PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL; PRAGMA cache_size=12000;"; cmd.ExecuteNonQuery(); } }这段代码把 WAL 打开、同步降为 NORMAL、缓存加大，配合前面说的批量事务，十万条数据写入速度能回到明文库的七八成。注意加密库第一次执行 PRAGMA journal_mode=WAL 时，如果驱动不支持，会返回 wal 之外的值，检查返回值再决定保留还是回退到 DELETE 模式，别默认硬开。
做这一行时间久了，我养成了一个习惯：每个工程新建第一天就把位数、加密、文件头自检这三件事固化到项目模板里，后面所有业务代码都建立在这个地基上。数据库加密不是很高深的事，但很讲究“验证过再说”，尤其在这种老 VS2012 工程里，每一步都可能被环境坑一次，走到最后你会发现，真正值钱的不是那几行连库代码，而是一套能稳定交付、现场不出幺蛾子的纪律。希望帮到你。
本文还有配套的精品资源，点击获取
