.NET MAUI运行出现A resource failed to call close报错排查

• [System] A resource failed to call close是Android平台StrictMode抛出的原生资源泄漏告警，不是功能级报错：只要实现了Closeable接口的原生对象（文件流、数据库句柄、Parcel描述符等）被GC回收前没主动调用close()，就会触发该日志，长期运行确实会导致文件句柄耗尽、内存占用持续升高的问题。
• 90%以上同技术栈（sqlite-net-pcl + SQLitePCLRaw.provider.dynamic.cdecl）的该告警，问题源不在手动处理的JSON文件流上——手动关流没效果是正常的，泄漏点在SQLite封装层：低版本SQLitePCLRaw动态提供器存在原生预编译语句句柄、临时库加载流未主动释放的已知bug，加上sqlite-net-pcl默认开启的语句缓存会持有句柄不释放，刚好匹配导入数据后反复出日志的场景。
• 剩余常见触发点是FilePicker返回的文件流未做全分支释放：如果只在正常逻辑末尾手动调Close()，读取/反序列化抛出异常时就会跳过关闭逻辑，触发告警。

1. 修正文件流释放逻辑 #

所有FilePicker相关的流操作，全程用using声明包裹，不要手动调用Close()，保证异常分支也能自动释放资源：

// 错误写法：异常分支会漏释放
// var stream = await pickResult.OpenReadAsync();
// var data = await JsonSerializer.DeserializeAsync<List<ImportModel>>(stream);
// stream.Close();

// 正确写法：作用域结束自动释放，无遗漏
await using var readStream = await pickResult.OpenReadAsync();
var importData = await JsonSerializer.DeserializeAsync<List<ImportModel>>(readStream);

注意：Android平台上FilePicker返回的流本质封装了原生ParcelFileDescriptor，只要被using包裹，离开作用域时会自动调用原生close方法，不会触发泄漏告警。

2. 修正SQLite连接的资源释放 #

• 先把sqlite-net-pcl、SQLitePCLRaw.provider.dynamic.cdecl两个NuGet包升级到2.1.7以上稳定版，修复动态提供器本身的临时流泄漏bug。
• 调整单例数据库连接的初始化配置，关闭不必要的语句缓存，显式指定连接标记：

// 数据库单例初始化修正
public static SQLiteAsyncConnection Instance { get; } = new SQLiteAsyncConnection(
    dbPath,
    // 关键配置：共享缓存模式下连接释放会同步回收所有句柄
    SQLiteOpenFlags.ReadWrite | SQLiteOpenFlags.Create | SQLiteOpenFlags.SharedCache
);
// 初始化时关闭WAL模式的长持句柄，单实例场景无性能影响
await Instance.ExecuteAsync("PRAGMA journal_mode=DELETE;");

• 批量导入数据完成后，主动调用一次连接关闭方法，释放当前持有的所有原生句柄：

await Instance.RunInTransactionAsync(tran =>
{
    tran.InsertAll(importData);
});
// 单例连接调用CloseAsync不会销毁实例，下次操作会自动重连
await Instance.CloseAsync();

3. Visual Studio下精准定位泄漏源 #

不需要额外工具，直接用Android原生StrictMode打印泄漏栈：

1. 打开安卓平台项目的MainActivity.cs，在OnCreate方法开头加入调试专用的StrictMode配置：

protected override void OnCreate(Bundle savedInstanceState)
{
    if (BuildConfig.Debug)
    {
        StrictMode.SetVmPolicy(new StrictMode.VmPolicy.Builder()
            .DetectLeakedClosableObjects()
            .PenaltyLog()
            .PenaltyDeath() // 泄漏时直接崩溃，打印完整调用栈
            .Build());
    }
    base.OnCreate(savedInstanceState);
}

2. 调试运行触发JSON导入操作，一旦存在未关闭资源，应用会直接抛出异常，异常栈信息会明确标注持有资源的类名、代码行号，直接定位到具体泄漏点即可。

连续执行10次以上JSON导入操作，查看Visual Studio的Android设备日志面板，不再输出A resource failed to call close提示即为修复完成，不存在内存泄漏隐患。

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