Azure Linux部署EF Core 6.0+SQLite遇写入锁定，Windows正常

需排查的关键点 #

• 存储介质锁兼容性：Linux下SQLite依赖fcntl系统调用实现文件锁，若数据库文件放在Azure Files这类网络共享存储上，可能出现锁延迟或失效。建议将数据库迁移到Azure Linux Web App的本地目录（如/home/site/wwwroot/data）测试。
• DbContext生命周期管理：检查EF Core上下文的DI配置是否正确（ASP.NET Core中应为Scoped）。Linux进程模型与Windows不同，若上下文未及时释放，会导致数据库连接未关闭、长期持有锁。可临时在操作后手动调用context.Dispose()验证。
• SQLite日志模式配置：默认情况下，Windows环境可能自动启用WAL模式减少锁竞争，但Linux下需显式配置。可在连接字符串添加Journal Mode=WAL;Cache=Shared，或执行PRAGMA journal_mode=WAL;开启该模式。
• Linux权限隐性限制：除文件写入权限外，需确保数据库所在父目录拥有执行权限（Linux访问文件依赖目录的x权限）。同时检查Azure Linux Web App的安全策略（如AppArmor）是否限制了文件锁操作，可通过Kudu控制台用sqlite3命令手动执行DELETE操作，排除应用层面问题。
• 并发进程/线程冲突：Azure Linux Web App的进程数、线程数配置可能与Windows不同，多进程同时访问SQLite会加剧锁竞争。可暂时将应用设置为单进程运行，验证是否解决问题。

EF Core跨平台行为差异 #

• 文件锁实现逻辑：SQLite的锁机制依赖系统API，Windows用Win32文件锁，Linux用fcntl，网络存储场景下Linux的锁可靠性低于Windows。
• 默认配置差异：EF Core在Windows与Linux上对SQLite的默认配置有细微区别，比如WAL模式的启用时机、缓存策略，Linux下需显式配置才能获得与Windows一致的锁优化。
• 进程模型影响：Windows Web App基于IIS进程模型，Linux下采用Kestrel或容器化部署，进程隔离与资源调度逻辑不同，可能导致DbContext释放时机延迟，进而引发连接未关闭、锁持有问题。

内容的提问来源于stack exchange，提问作者Pedro Soares