简介这是一套面向WinForm桌面开发者的SQLite集成示例工程基于.NET Framework 4.8演示如何借助EntityFramework ORM框架完成SQLite数据库的读取、新增与删除操作。工程内置主窗口列表展示数据并封装了EF数据访问层适合初学ORM映射或需要在WinForm中快速接入SQLite的开发者参考。资源共183个文件压缩包约35.51MB主体包含Visual Studio解决方案文件sln/csproj、C#源码cs、数据库文件db3、DLL依赖库及NuGet包等文件类型多样且目录结构完整便于直接打开调试与对比学习。已有601人学习下载说明该示例贴近常见需求。通过源码可掌握App.config中配置ConnectionStrings、SQLite Expert Personal查看db3文件、首次访问前利用GetItemCollection暖机减少延迟等实用技巧还能了解EF6相关SQLite适配包的引入方式是一份能落地运行的工程级参考。1. 先讲结论WinForm SQLite EF 这套组合是给内部工具续命的你大概率是接手了这么个活一个没人愿意碰的 WinForm 老程序数据要从 Access 或者 Excel 迁出来又不想回到手写 SQL 和 DataSet 那种“一处拼错全线崩”的状态。WinForm 负责界面SQLite 数据库负责单机存储EntityFramework ORM 框架负责把表和实体对象之间那层胶水代码省掉——这三样凑在一起就是一套能让你在两三天内把内部工具重写一遍、并且敢交给别人继续改的方案。它解决的核心问题是桌面程序要落地、要离线、要能打包给别人装还不能把大量时间耗在数据访问层的重复劳动上。适合的人很明确做企业内工具、工单系统、小型进销存、设备管理这类单机或局域网小应用的开发者。2. 为什么是这三个每层选型理由与边界2.1 SQLite 凭什么进桌面项目嵌入式数据库的三条硬边界把 SQLite 数据库放进 WinForm 项目很多人第一反应是“这不就是个文件型数据库吗能扛住什么”。这句话对了一半。它确实是个单文件数据库但恰恰是这个单文件特性让它在桌面软件里比 SQL Server 和 MySQL 都顺手。部署层面你的安装程序只需要带上一个 .db 文件和一个 dll不需要装服务、不需要配账号、不需要管端口用户拿到就能跑。这对“给别人装工具”的场景来说是决定性的。它的硬边界也很清楚。第一写入并发很弱两个进程同时写同一张表其中一个大概率拿到database is locked。第二它没有完整的用户权限体系谁拿到文件谁就能拷走数据敏感数据需要自己在应用层做加密。第三它不适合做“服务器”数据库如果你要支撑二十个以上客户端同时高频写入SQLite 会先顶不住。我的判断标准很简单单机、偶尔多线程读、每小时写入量在几百到几千条这种量级SQLite 绰绰有余一旦出现多客户端高并发写直接换 SQL Server Express 或者 PostgreSQL别在 SQLite 上硬扛。2.2 EF 在这里解决什么从 DataTable 到强类型WinForm 老项目里最常见的访问方式是这样SqlConnection拼 SQL 字符串SqlDataAdapter塞进DataTable再把DataTable绑到DataGridView。这套路子的痛点在字段一多就出来了——改一个字段名SQL 字符串里的、DataTable 列名里的、界面绑定的三处都可能漏编译期还不报错运行到那一行才炸。EntityFramework ORM 框架就是来消灭这块胶水代码的。你把表映射成 C# 类把数据库操作抽象成对DbContext的操作增删改查变成db.Users.Add()、db.SaveChanges()这种强类型调用。字段名拼错了编译直接报错连运行的机会都没有。这个价值在 WinForm 场景里被放大了因为 WinForm 项目往往没有专门的 DBA写数据访问的就是界面开发的人强类型意味着心智负担大幅降低。2.3 ORM 框架怎么选EF6 还是 EF Core这是动手前必须定的事而且经常有人选错。EF6 是跑在 .NET Framework 上的老牌版本全球无数 WinForm 项目用着它资料最多坑基本都被踩平了EF Core 是跨平台重写版跑在 .NET Core / .NET 5 上。怎么选取决于你的项目框架。VS2015 时代的 WinForm 项目几乎都是 .NET Framework 4.5 或 4.6这种项目用 EF6 是最稳妥的升级成本低第三方控件兼容性也好。如果你的 WinForm 已经是 .NET 6/8 的新项目那就直接 EF Core。具体到 SQLite 搭档EF6 需要配合System.Data.SQLite这个官方包版本线锁定在 1.1.x它自带了对 EF6 的 provider 支持EF Core 则用Microsoft.EntityFrameworkCore.Sqlite。这里常见的翻车点是把 EF Core 的 SQLite 包装进 .NET Framework 项目编译能过一跑就报 provider 不匹配后面避坑章节我会详细说。下表是我实际接项目时的选型参考场景推荐组合原因VS2015 老项目、.NET Framework 4.xEF6 System.Data.SQLite兼容性好、资料多、升级风险低新项目、.NET 6/8、打算跨平台EF Core Microsoft.EntityFrameworkCore.Sqlite可持续维护、能迁移到其他数据库局域网多客户端、高并发写不用 SQLite换 SQL ServerSQLite 锁机制撑不住3. 从空项目到跑通增删改查最小可复现搭建流程3.1 建项目和装包需要哪几个 NuGet 包版本怎么锁我用 VS2015 加 .NET Framework 4.5 举例这是存量 WinForm 项目最常见的底座。新建一个 WinForm 项目后打开 NuGet 包管理器搜索并安装两个包System.Data.SQLite勾选包括依赖项以及System.Data.SQLite.EF6。前者是 SQLite 的 ADO.NET 驱动后者是把它接入 EF6 的 provider。注意System.Data.SQLite的版本号当前主流是 1.1.x 线装的时候锁定在这个大版本内不要随手升级到 2.x——那不是这个老生态的延续是另一个体系。用包管理器命令行安装的话命令是这样的Install-Package System.Data.SQLite -Version 1.1.6 Install-Package System.Data.SQLite.EF6 -Version 1.1.6这里锁版本号是刻意为之。SQLite 官方包的版本和 EF6 provider 的版本必须严格一致差一个小版本都可能出现The provider is not compatible with the version of Entity Framework。我见过太多人在这里翻车所以第一条经验就是两个包一起装版本号手动锁死不要用“最新稳定版”的默认选项。3.2 连接串怎么写路径、密码与 db4s 验证SQLite 的连接串比其他数据库简单得多核心就一个Data Source指向数据库文件路径。但路径这事有个经典坑很多人写相对路径Data Sourcemydb.db程序一跑发现文件生成在了bin\Debug目录下而不是你预期的项目根目录。这是因为 WinForm 的工作目录默认是 exe 所在目录。我的习惯是连接串里直接写绝对路径用AppDomain.CurrentDomain.BaseDirectory拼出来这样无论调试还是发布后都稳定。在App.config里注册 EF 的连接串标准写法是connectionStrings add nameAppDbContext providerNameSystem.Data.SQLite.EF6 connectionStringData Source|DataDirectory|appdata.db;Version3;PoolingTrue;Journal ModeWAL; / /connectionStrings参数说明|DataDirectory|是 .NET 里的一个可选占位符WinForm 项目默认指向bin\Debug可以通过AppDomain.CurrentDomain.SetData(DataDirectory, ...)重定向我用它确保调试和发布后的路径行为一致。Version3是 SQLite 文件格式版本必填不要动。PoolingTrue建议开着EF 频繁开连接时能省下不少时间。Journal ModeWAL是让 SQLite 走 WAL 日志模式读写并发会好很多后面性能章节会展开。配置完成后用 DB Browser for SQLite也就是 db4s 这个开源跨平台工具先把空的数据库文件建好建一张测试表再让程序去连。这样做的好处是把「EF 映射的问题」和「SQLite 本身的问题」分开排查不要一上来就让 EF 自动建库出了问题你根本分不清是哪一层在报错。3.3 DbContext 与实体映射Code First 的底线写法EF6 在 SQLite 上做 Code First 是可行的但远没有 SQL Server 上那么顺滑所以我采用的是“半手工”方式自己写实体类自己写映射配置不让 EF 去自动迁移建库。数据库表结构用 db4s 手工建好EF 只负责访问。这套做法的好处是省掉了初始化迁移那套脆弱机制对 WinForm 这种项目来说表结构稳定后手动改 SQLite 文件比跑 migration 靠谱得多。实体类写起来就是普通的 POCOpublic class Device { public int Id { get; set; } public string DeviceName { get; set; } public string Location { get; set; } public DateTime InstallDate { get; set; } public bool IsActive { get; set; } }DbContext 这边要指定表名和字段映射避免 EF 默认的复数表名规则和 SQLite 里的实际表名对不上public class AppDbContext : DbContext { public AppDbContext() : base(nameAppDbContext) { } public DbSetDevice Devices { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.EntityDevice() .ToTable(device) .Property(e e.DeviceName) .HasColumnName(device_name) .IsRequired() .HasMaxLength(64); } }参数说明构造函数里的nameAppDbContext告诉 EF 去连接串配置里找名字为AppDbContext的那条记录这就是 3.2 节里那个连接串的 name。ToTable(device)是显式指定表名因为 EF6 默认会把Device复数化成Devices而 SQLite 里你建的可能是device。HasColumnName和HasMaxLength这种配置属于可选的底线配置字段少可以不用但一旦你的表结构里有缩写列名或非空约束就别省。3.4 最小增删改查跑通第一行 EF 代码这四段代码是整套方案的骨架我基本上所有项目都是从这四段改出来的。查询最简单using (var db new AppDbContext()) { var activeDevices db.Devices .Where(d d.IsActive) .OrderBy(d d.InstallDate) .ToList(); dataGridView1.DataSource activeDevices; }逻辑说明这就是 EF 的核心价值Where和OrderBy会翻译成 SQL 里的WHERE和ORDER BYToList()才真正执行查询。这里有个容易误用的小细节IQueryable的查询是延迟执行的如果你不调ToList()dataGridView1.DataSource绑定的是查询对象而不是数据运行时才开始执行排查问题时会觉得“数据怎么时有时无”。我的习惯是到 UI 层之前一律显式物化。新增和更新using (var db new AppDbContext()) { var device new Device { DeviceName PLC-01, Location A车间, InstallDate DateTime.Now, IsActive true }; db.Devices.Add(device); db.SaveChanges(); }逻辑说明Add是把实体加入跟踪状态SaveChanges()才真正执行 INSERT。EF6 默认会自动开事务包裹 SaveChanges所以一次 SaveChanges 里的多个写操作要么全成要么全不成。这里要记住一个原则做界面程序时一个用户动作对应一次 SaveChanges不要在循环里反复调用性能问题后面再讲。删除using (var db new AppDbContext()) { var device db.Devices.FirstOrDefault(d d.Id targetId); if (device ! null) { db.Devices.Remove(device); db.SaveChanges(); } }逻辑说明删除前必须先查询出来再删除这看起来多此一举其实是 EF 的事务型删除标准姿势。直接db.Devices.Remove(new Device { Id targetId })偶尔能省一步但一旦实体类里有关联配置或者删除触发器这种“构造假实体”的方式会失效而且代码可读性差。除非你对数据关系把握得非常清楚否则别玩这个技巧。跑通这四段后把 db4s 打开刷新表数据看变化——库里能看到刚才插入和删除的记录。到这一步WinForm SQLite EF 的最小链路就通了接下来才是真正决定这个项目能不能扛住真实数据量的部分。4. 十万条数据下SQLite 与 EF 的性能真相4.1 十万条数据查询需要多久SQLite 的真实读取优势很多人的第一反应是“SQLite 不就一个文件吗十万条数据不得卡死”。实际不是这样SQLite 的查询性能在单机场景下被严重低估。纯读场景下十万行级别的SELECT * FROM device WHERE location A车间加上合适的索引响应时间在几十毫秒量级用户几乎感知不到卡顿。这个结论我拿真实项目验证过多次设备记录、操作日志这类表三年攒下来二十万行的体量SQLite 一点压力没有。但有个前提你要把查询条件建立在索引字段上。SQLite 用的是 B-Tree 索引结构走索引和全表扫描是两个数量级的差距。十万行没有索引时查询可能要几百毫秒甚至更久具体取决于WHERE条件的复杂度和字段数据量加了索引以后基本稳定在几十毫秒而全表扫描随着数据量线性增长。所以结论简单SQLite 读性能够用前提是索引建对。索引建起来也简单用 db4s 打开数据库执行CREATE INDEX idx_device_location ON device(location); CREATE INDEX idx_device_install_date ON device(install_date);逻辑说明第一条索引服务WHERE location ...这种精确匹配查询第二条服务ORDER BY install_date或时间范围查询。建索引的成本是牺牲一点写入速度但 WinForm 场景下写入量小可以忽略。这里我要特别提醒一个常见的错误索引不是建得越多越好把每个字段都建上索引会让插入和更新变得很慢而且 SQLite 文件体积增大——找三个最频繁出现在 WHERE 里的字段建索引就够用。4.2 EF 的三个性能杀手N1、追踪、全表映射SQLite 本身能扛住但 EF 的默认行为会拖后腿这三个坑几乎每个项目都会踩。第一个是 N1 查询。当你查询一堆实体然后访问每个实体的导航属性时EF 默认是每访问一个就发一条 SQLusing (var db new AppDbContext()) { var devices db.Devices.ToList(); // 1条SQL foreach (var device in devices) { var repairs device.Repairs.ToList(); // 每个设备再发1条SQL } }逻辑说明Repairs是导航属性这段代码会执行1 N条查询N 是设备数。当 N 是五百时数据库要接五百零一条查询。解决办法是预先加载var devices db.Devices .Include(d d.Repairs) .ToList();Include会生成一条LEFT JOIN查询把关联数据一次性取出来。这就是把 N1 压成 1 的关键。注意Include不能滥用比如你只关心设备列表本身根本不看维修记录那就别加——加了反而会让查询变慢因为 JOIN 的数据量远大于你需要的。第二个是默认的实体追踪。EF6 默认把查询出来的每个实体都放进状态管理器里为的是后续 SaveChanges 时能检测变化。这在查几条绑到界面上没问题但在“查两千条、展示完就不改了”的场景追踪全是白费功夫var devices db.Devices .AsNoTracking() .Where(d d.IsActive) .ToList();加了AsNoTracking()后查询跳过状态追踪速度明显提升。判断标准我一般这样掌握只要这段数据用于展示、不需要回写这个实体的一律加。第三个是Select只取需要的字段坚决不整表查询var deviceNames db.Devices .Where(d d.Location A车间) .Select(d new { d.DeviceName, d.InstallDate }) .ToList();逻辑说明Select投影会让 EF 生成的 SQL 只查两个字段而不是SELECT *。当你的表有一二十列、里面还存着大文本备注时这个差距会非常明显。做表格展示时优先在查询里做投影不要指望 DataGridView 会自动帮你裁剪。4.3 索引与 WAL不用改代码就能拿到的性能前面连接串里提过Journal ModeWAL这是 SQLite 的一个运行模式不是索引那种结构性的东西。WALWrite-Ahead Logging, 预写日志模式把写操作先写进一个 wal 临时文件再周期性合并回主库文件好处是读操作不被写操作阻塞写操作也不用等读操作完成。对 WinForm 来说最直观的影响是你在后台线程往库里写日志界面线程同时查数据不会因为锁等待卡界面。WAL 模式的开启有两种方式。一种是连接串里加参数已经在配置里做过了另一种是想动态切换的话执行PRAGMA journal_modeWAL;验证是否生效用 db4s 执行PRAGMA journal_mode;返回wal说明开启成功。这里要提醒一个 WinForm 特色坑如果你把程序放在 U 盘或者网络共享盘上跑WAL 模式反而可能出问题——它依赖 wal 文件写入某些网络文件系统不支持这种模式会报错disk I/O error。所以WAL 是给本机硬盘用的放在共享盘或者移动介质上的程序保持默认的 delete 模式更安全。5. 避坑清单7 个让 WinForm SQLite EF 翻车的常见问题5.1 连接串路径“玄学”bin 目录、绝对路径与打包安装程序现象程序在自己的开发机上跑得好好的打到另一台机器上安装后一登录就报SQLite error: unable to open database file。原因连接串里写的是相对路径安装程序把程序装在C:\Program Files\xxx\但工作目录是C:\Windows\System32找不着数据库文件。就算你在开发机用了绝对路径换一台机器路径也不一样。解决不要写死路径。我的写法是连接串里保留|DataDirectory|占位符然后在程序启动的 Main 方法里统一设置string dataDir Path.Combine(AppDomain.CurrentDomain.BaseDirectory, data); Directory.CreateDirectory(dataDir); AppDomain.CurrentDomain.SetData(DataDirectory, dataDir);逻辑说明DataDirectory是 .NET 提供的一个逻辑路径连接串里的|DataDirectory|appdata.db会把它替换成实际路径。这段代码把DataDirectory指向 exe 同级的data目录发布时把数据库文件放在那里无论程序装到哪个目录都能稳定找到。打包成安装程序时把这个 data 目录一并装上问题就彻底根治了。顺带说一句想设计成“程序首次运行自动建空库”也可以此时data目录的写权限要确认安装在Program Files下的程序可能没有写权限那就要考虑%LocalAppData%。5.2 database is locked并发写入与 EF 重试现象程序运行个把小时某次写入操作突然抛异常异常信息里带database is locked。更诡异的是重启程序后一切正常过一段时间又出现。原因SQLite 是库级写锁同一时刻只允许一个连接写。WinForm 里最容易触发的是你开了多个窗口或多个线程各自拿着一个 DbContext 链接一个线程正在写另一个线程也来写就撞上了。还有一种是忘了 Dispose 的 DbContext 或者连接没释放干净、事务没提交锁被长时间持有。解决第一所有 DbContext 一律用using包裹这是底线第二EF 本身不提供 SQLite 的重试机制所以要在业务层做一个简单的重试封装。我一般会写一个通用的执行方法public void ExecuteWithRetry(Action action, int retryCount 3, int delayMs 100) { for (int attempt 1; ; attempt) { try { action(); return; } catch (SQLiteException ex) when (ex.ResultCode SQLiteErrorCode.Busy) { if (attempt retryCount) throw; Thread.Sleep(delayMs * attempt); } } }参数说明SQLiteErrorCode.Busy就是database is locked的底层错误码只对这类锁错误重试其他异常直接抛出。retryCount3是重试次数上限delayMs*attempt是递增等待时长第一次等 100 毫秒、第二次等 200 毫秒给前面的写入留出完成时间。这套方案对付偶然的写撞车足够但如果你发现database is locked高频出现那就不是重试能解决的属于架构问题——排查是不是有长事务或者查询没关闭。5.3 类型映射差异DateTime、Decimal、Boolean 的坑现象用 EF 往 SQLite 里写DateTime.Now再读出来发现比原来大了 8 个小时或者查某个bool字段返回的结果和自己预期相反。原因SQLite 没有原生 DateTime、Decimal、Boolean 类型。DateTime 实际以 TEXT 存储System.Data.SQLite存的是字符串中间有格式转换存储的时区和读出来的 Kind 可能不一致Decimal 没有精度语义存进去是一个字符串读出来如果按 float 处理会损失精度Boolean 存成 INTEGER 0 或 1如果你在库里手工把值改成别的数字EF 读取时只认 0/1 或者非零行为和你理解的“真/假”会不一样。解决第一DateTime 一律存 UTC 时间取出来展示时再转本地时间这样至少在跨时区、跨机器上有确定的行为第二涉及金额、计量这类精度敏感的字段数据库层面用 TEXT 存实体用decimal属性EF 映射上在 OnModelCreating 里显式配置modelBuilder.EntityDevice() .Property(e e.Price) .HasPrecision(18, 2);逻辑说明HasPrecision(18, 2)在 EF6 里对 SQLite 的实际效果是让 SQL 生成时带上精度上下文避免被默认映射成 double。虽然 SQLite 底层不强制精度但 EF 这层配置能确保你不用在 C# 里到处写强转。第三Boolean 字段在库里保持 INTEGER 值只填 0 或 1不要为了让数据“好看”去存true或false字符串EF 读那种值会直接抛转换异常。5.4 32位/64位 DLL 冲突何时改平台目标现象项目在自己的 64 位开发机上一切正常同事用 32 位系统跑启动就报BadImageFormatException或者反过来32 位机器上编译的程序在 64 位机器上报错。原因SQLite 的底层是一个原生 C/C 写的 SQLite 内核System.Data.SQLite包里同时提供了 x86 和 x64 两套原生 DLL。如果项目编译目标是“AnyCPU”在 64 位系统上会以 64 位加载它找的是 x64 的 DLL在 32 位系统上会以 32 位加载找 x86 的 DLL。一旦项目里某一个引用的第三方控件是强制 32 位的整个进程被拽到 32 位就可能和 x64 的 SQLite 原生库冲突。解决最省心的做法是手动把项目平台目标设为 x86这是 WinForm 项目最常见的稳定配置。道理很直接所有第三方控件几乎都兼容 x86SQLite 的 x86 原生 dll 是完整可用的而 x64 的坑在于“AnyCPU 下加载行为不可控”。设置路径是项目属性 - 生成 - 平台目标 - 选 x86同时把Prefer 32-bit勾选去掉。如果你非要跑 x64那就把整个方案包括所有引用的第三方库统一设 x64但这需要你把每个引用的 dll 的位数都排查一遍投入产出比不高。5.5 EF 版本与 provider 不匹配老项目最容易踩的包版本坑现象Add-Migration或程序启动时报错No Entity Framework provider found for the ADO.NET provider with invariant name System.Data.SQLite或者直接提示找不到System.Data.SQLite.EF6程序集。原因System.Data.SQLite和System.Data.SQLite.EF6版本不一致或者装好了 EF6 provider 但项目实际引用的是 EF Core 的程序集。VS2015 老项目尤其容易踩因为 NuGet 会自动更新小版本两个包在某一方被更新后版本错开。解决检查两个包的版本号是否一致最简单的方法是在 NuGet 包管理控制台执行Update-Package System.Data.SQLite -Version 1.1.6 Update-Package System.Data.SQLite.EF6 -Version 1.1.6另外确认项目引用里没有混入Microsoft.EntityFrameworkCore而不是EntityFramework——这两个东西长得像但是完全不同程序集名都不同。我遇到过一个项目就是因为有人顺手装了一个 EF Core 的包两个 ORM 的配置互相打架折腾了半天。5.6 数据库文件被外部工具改坏后的两难现象用 db4s 手工改数据、加了字段、改了类型之后EF 查询报SQLiteException: no such column: ...或者干脆打不开数据库。原因SQLite 的文件结构很宽容但不代表改不坏。最常见的是db4s 里把一个字段的类型改了又改了回来底层存储格式变了或者删了一张表但另一个表的约束还引用着它SQLite 某些配置下不会立刻报错EF 一访问关联实体就炸。解决第一步不要急着删库重来先把原文件备份一份用 db4s 的Database - Integrity Check跑一遍完整性检查能看到具体是哪个 page、哪个索引出问题第二步如果是简单的 schema 问题用 db4s 把 EF 涉及的视图和索引重建一下第三步如果你发现模型和表结构只是微小的不一致干脆直接在OnModelCreating里补映射不要靠手工改库去凑。说到底用了 EF 之后库结构的变更收敛到代码里配置db4s 只做检查用这是最不容易出问题的分工。5.7 发布后启动找不到数据库安装目录权限的另一面现象开发机正常安装到客户机器上启动后程序能打开但一操作数据就报unable to open database file或者提示attempt to write a readonly database。原因程序安装在C:\Program Files (x86)\xxx普通用户对这个目录只有读取权限写入和创建文件都要管理员权限。WinForm 默认以普通用户运行于是数据库文件的创建和写入全部失败。解决不要把数据文件放安装目录。正确做法是把数据库放到%LocalAppData%\你的程序名\data\下模板代码string localAppData Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); string dataDir Path.Combine(localAppData, YourAppName, data); Directory.CreateDirectory(dataDir); AppDomain.CurrentDomain.SetData(DataDirectory, dataDir);这和 5.1 的区别在于5.1 是同盘相对路径问题这个是系统目录权限问题。我把两种情况的判断口径一起说一下——如果安装目录是Program Files直接走 LocalAppData如果安装目录是自定义的比如D:\Apps\可以继续用BaseDirectory但要注意磁盘空间和备份路径的可达性。这个坑在打包成安装程序后暴露得最多开发机上永远是bin\Debug根本碰不到权限问题属于典型的“发布才翻车”。6. 进阶批量导入与性能验证的常用技巧6.1 一个 30 秒跑完的读写性能测试脚本“SQLite 到底快不快”这种事别听人说必须自己拿数据说话。我用一个简单的测试方法放到 WinForm 的按钮事件里跑一遍就能对当前机器、当前表结构下的真实性能有个底var sw Stopwatch.StartNew(); using (var db new AppDbContext()) { for (int i 0; i 100000; i) { db.Devices.Add(new Device { DeviceName 测试设备 i, Location 车间 (i % 10), InstallDate DateTime.Now, IsActive true }); if (i % 500 0) db.SaveChanges(); } } sw.Stop(); MessageBox.Show($插入10万条耗时{sw.ElapsedMilliseconds} ms);参数说明i % 500是每 500 条批量提交一次避免一条条提交和一次性提交十万条的两种极端。EF 在事务中批量SaveChanges是 WinForm 里批量导入最常用的写法。注意第一次跑这个测试时EF 首次会做模型预热耗时偏高所以正确做法是先跑一次预热查询再计时。只测写不测读是偏的。查询的测试方法更简单索引建好之后执行一个带 WHERE 条件的查询用Stopwatch记录耗时。我给自己定的标准是十万行数据里做带索引的等值查询25 毫秒内算及格无索引时超过一秒优先补索引而不是骂 EF 慢。这套验证流程 30 秒跑完比听任何人的“经验”都可靠。6.2 批量插入的正确姿势与回滚写法生产环境里真正用到的批量插入日志记录、采集数据入库数据量常常一次来几千甚至几万条。EF 在这种场景下如果还是一条条SaveChanges()性能会极差因为每次 SaveChanges 都做一次事务和数据库往返。常见做法是上面那种分批提交模式但还有更讲究的技巧。把Configuration.AutoDetectChangesEnabled关掉可以显著减少 EF 在跟踪大量实体时的开销using (var db new AppDbContext()) { db.Configuration.AutoDetectChangesEnabled false; db.Configuration.ValidateOnSaveEnabled false; for (int i 0; i 50000; i) { db.Logs.Add(new LogEntry { ... }); if (i % 500 0) { db.SaveChanges(); db.Dispose(); db new AppDbContext(); } } db.SaveChanges(); }逻辑说明AutoDetectChangesEnabledfalse是让 EF 不再自动扫描实体状态代价是状态的正确性要靠你自己保证。这种场景下实体只增不改所以完全没问题。ValidateOnSaveEnabledfalse跳过保存前的实体校验这要求前面已经做过数据合法性检查不然脏数据直接进库。回滚的写法靠 EF 的事务天然支持但有个容易误用的点SaveChanges是自动包事务的如果一次 SaveChanges 中途抛异常EF 会回滚这一批但如果你的代码是循环中多次SaveChanges某一次失败后之前批次已提交是没法整体回滚的。要做整体回滚手动开事务using (var tx db.Database.BeginTransaction()) { try { // 批次1SaveChanges // 批次2SaveChanges tx.Commit(); } catch { tx.Rollback(); // 或者不写Dispose时自动回滚 throw; } }这块我这几年带下来的经验是先想清楚“这一批数据是不是一个原子操作”是的话才手动开事务不是的话分多条批次提交反而更安全——失败的批次重跑就行不影响已成功的部分。别一上来就开大事务事务越大 SQLite 的锁持有时间越长越容易触发 5.2 里的database is locked。最后说一个我自己的习惯每逢接手别人的 WinForm 数据库程序我会先在开发环境把它当前的查询性能测一遍、建立基线再开始动代码。这样优化完才知道是真变快了还是只是感觉变快了。SQLite 配合 EF 这种组合性能问题九成是索引和 EF 用法问题只有一成是数据库本身扛不住。把前面那些边界判断清楚、包版本锁牢、路径权限处理好这套组合在内部工具这个领域是个能让你踏踏实实交付、长期少返工的选择。希望帮到你。本文还有配套的精品资源点击获取