会，但仅限于路径合法且有写入权限。调用 new sqliteconnection("data source=app.db") 并执行 open() 时，sqlite ado.net 提供程序会静默创建空数据库文件；若路径无效或无权限，则抛出 sqlite error 14。
SQLite文件不存在时，SqliteConnection会自动创建吗？
会，但仅限于路径合法且有写入权限。调用 new SqliteConnection("Data Source=app.db") 并执行 Open() 时，如果 app.db 不存在，SQLite ADO.NET 提供程序会静默创建空数据库文件。但注意：Data Source 路径不能是只读目录（如 Program Files 某些子目录）、网络路径或权限受限的系统路径，否则抛出 SQLite Error 14: unable to open database file。
实操建议：
- 用
Path.GetDirectoryName()检查目标目录是否存在，不存在则提前Directory.CreateDirectory() - 避免硬编码绝对路径；推荐用
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)存放用户数据 - 连接字符串中不要加
Journal Mode=WAL或Synchronous=Off等参数来“加速创建”——这些对空库创建无影响，反而可能在后续写入时引发一致性问题
用 CREATE TABLE 建表前，需要先检查表是否存在吗？
不需要强制检查，但必须处理重复建表错误。SQLite 不支持 CREATE TABLE IF NOT EXISTS 的语法错误（它支持），但 C# 中执行该语句时若表已存在，SqliteCommand.ExecuteNonQuery() 仍会成功返回，不会抛异常——这是 SQLite 的设计行为，不是 bug。
所以更稳妥的做法是：直接执行 CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)，无需先 SELECT name FROM sqlite_master 查询。但如果业务逻辑依赖“首次初始化”，可改用以下方式判断：
SELECT count(*) FROM sqlite_master WHERE type='table' AND name='users'
返回 0 表示表不存在，可安全建表或执行迁移逻辑。
INSERT 和 UPDATE 为什么总提示“no such table”？
常见原因不是 SQL 写错，而是连接了错误的数据库文件。比如代码里写的是 "Data Source=app.db"，但实际运行时当前工作目录（Environment.CurrentDirectory）不是你预期的位置，导致打开了另一个同名空文件，自然没有表。
Android文件存取与数据库编程知识，文件操作主要是读文件、写文件、读取静态文件等，同时还介绍了创建添加文件内容并保存，打开文件并显示内容；数据库编程方面主要介绍了SQLite数据库的使用、包括创建、删除、打开数据库、非查询SQL操作指令、查询SQL指令-游标Cursors等知识。
排查步骤：
- 打印完整路径：
Path.GetFullPath("app.db")，确认是否指向你期望的文件 - 用
File.Exists()验证该路径下文件是否存在、大小是否 > 0 - 用 DB Browser for SQLite 打开该文件，手动确认表结构
- 确保没在多个地方用不同连接字符串操作“同名但不同路径”的文件（例如一个用相对路径，一个用
AppContext.BaseDirectory拼接）
读写性能差？别忘了 PRAGMA synchronous 和事务
默认 SQLite 启用 synchronous = FULL，每次写入都等磁盘落盘，适合数据安全优先场景；但批量插入时会明显变慢。若能接受短暂断电丢几条记录，可设为 NORMAL：
PRAGMA synchronous = NORMAL
更有效的是用显式事务包裹多条操作：
using var tx = conn.BeginTransaction(); using var cmd = conn.CreateCommand(); cmd.Transaction = tx; cmd.CommandText = "INSERT INTO users VALUES (@id, @name)"; // ... 设置参数并 ExecuteNonQuery 多次 tx.Commit(); // 或 Rollback()
注意：不要在循环内反复 BeginTransaction —— 那比不用还慢；也不要省略 Commit()，否则数据不持久。
真正容易被忽略的是：SQLite 文件本身是单文件，但它会生成 -journal 或 -wal 临时文件。如果程序异常退出而没正确关闭连接，这些文件可能残留，下次打开时触发回滚或阻塞——务必确保 SqliteConnection 被 using 或显式 Dispose()。
