Please address the comments from this code review:

## Overall Comments
- In HttpCacheRepository, methods like _InsertDatabase and _UpdateTable create a SqliteConnection in a using block and then return a SqliteCommand that holds a disposed connection; the connection lifetime should outlive the command usage (e.g., return an open connection+command pair or avoid disposing the connection before the caller uses the command).
- In Initialize, destLocation is treated as a directory but in the IOException handler File.Delete(destLocation) is called; this will fail or be misleading when destLocation is a directory and should be handled with Directory.Delete or a safe cleanup of existing directory contents.
- HttpCacheHandler overrides Send to call SendAsync(...).GetAwaiter().GetResult(), which can deadlock on certain synchronization contexts and blocks threads; consider either not overriding Send or making the handler fully async-only and letting the framework handle sync calls.

## Individual Comments

### Comment 1
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="260-269" />
<code_context>
+    #region "SQL 执行函数"
+
+    
+    private SqliteCommand _InsertDatabase(HttpCacheDetails details)
+    {
+        using var conn = _connectionFactory.Invoke();
+        var cmd = conn.CreateCommand();
+        cmd.CommandText = InsertTable;
+        cmd.Parameters.AddWithValue("@Uri", details.RequestUri);
+        cmd.Parameters.AddWithValue("@Tag", details.Tag);
+        cmd.Parameters.AddWithValue("@LastModify", details.LastModify);
+        cmd.Parameters.AddWithValue("@ExpiredAt", details.ExpiredAt);
+        cmd.Parameters.AddWithValue("@EnsureValidate", details.EnsureValidate);
+        cmd.Parameters.AddWithValue("@Status", (int)details.Status);
+        cmd.Parameters.AddWithValue("@Hash", details.Hash);
+        return cmd;
+    }
+
</code_context>
<issue_to_address>
**issue (bug_risk):** Returning a SqliteCommand built on a disposed connection will cause runtime failures.

In `_InsertDatabase`, `conn` is disposed at method exit due to `using var conn = _connectionFactory.Invoke();`, but the returned `SqliteCommand` still references this disposed connection, so any later `ExecuteNonQuery()` will throw `ObjectDisposedException`.

Align `_InsertDatabase` with `_DeleteTable` and `_FindTableWithUri`: don’t `using` the connection here; instead, keep it alive and dispose it when the command is disposed (e.g., by attaching a disposal handler to the command).
</issue_to_address>

### Comment 2
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheHandler.cs" line_range="50" />
<code_context>
+        newDetails?.RequestUri = request.RequestUri.ToString();
+        newDetails?.LastUpdate = DateTimeOffset.Now;
+        newDetails?.EnsureValidate = response.Headers.CacheControl?.NoCache ?? false;
+        newDetails?.LastModify = response.Content.Headers.LastModified.ToString();
+        newDetails?.Tag = response.Headers.ETag?.Tag;
+        if (handle is not null)
</code_context>
<issue_to_address>
**issue (bug_risk):** Using ToString() on LastModified without null checks can throw or produce culture-dependent values.

`LastModified` is a `DateTimeOffset?`; when it's null, `.ToString()` returns an empty string, which will later cause `DateTimeOffset.Parse` to throw.

Recommend:
- Preserve nulls instead of empty strings: `newDetails.LastModify = response.Content.Headers.LastModified?.ToString("O");`
- Use an invariant, round-trip format (e.g. `"O"`) so parsing is culture-independent.
</issue_to_address>

### Comment 3
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="89" />
<code_context>
        cmd.CommandText = CreateTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 4
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="264" />
<code_context>
        cmd.CommandText = InsertTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 5
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="279" />
<code_context>
        cmd.CommandText = DeleteTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 6
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="289" />
<code_context>
        queryCmd.CommandText = FindTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- The SQLite schema and access code in HttpCacheRepository are inconsistent: InsertTable expects 8 columns but _InsertDatabase only binds 7 parameters (missing LastUpdate and misaligned with ExpiredAt/Status), and TryGetCacheData uses result.GetInt16(6) as Status even though column 6 is LastUpdate, which will cause runtime errors and incorrect cache status handling.
- HttpCacheRepository._UpdateTable builds an UPDATE statement by prepending "SET" for each changed column (e.g., "UPDATE HttpCache SET RequestUri=..., SET Tag=..."), and directly calling GetString/GetInt32 on potentially nullable columns, which can generate invalid SQL and throw on NULL values; consider building a single SET clause with comma-separated assignments and handling DBNull safely.
- The cache validation logic in HttpCacheHandler.SendAsync appears inverted: in the ExpiredAt check, it serves the cached response when LastUpdate + ExpiredAt is in the past (i.e., when the entry is expired), whereas typically you want to serve cache only when it is still fresh and otherwise revalidate or fetch a new response.

## Individual Comments

### Comment 1
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="77-83" />
<code_context>
+    /// </summary>
+    public void Initialize()
+    {
+        try
+        {
+            if (!Directory.Exists(destLocation)) Directory.CreateDirectory(destLocation);
+        }
+        catch (IOException)
+        {
+            File.Delete(destLocation);
+            Directory.CreateDirectory(destLocation);
+        }
</code_context>
<issue_to_address>
**issue (bug_risk):** Using File.Delete on a directory path is error-prone

In the catch block, `destLocation` is assumed to be a file and passed to `File.Delete`, but elsewhere it’s treated as a directory. Calling `File.Delete` on a directory will itself throw (e.g., `UnauthorizedAccessException`), which isn’t handled. Consider checking `File.Exists(destLocation)` vs `Directory.Exists(destLocation)` and deleting/creating accordingly, so you only delete files and only create directories at this path.
</issue_to_address>

### Comment 2
<location path="PCL.Core/IO/Net/Http/Cache/Models/CacheStream.cs" line_range="61-65" />
<code_context>
+        _lock.Release();
+    }
+
+    protected override void Dispose(bool disposing)
+    {
+        _lock.Dispose();
+        base.Dispose(disposing);
+    }
+}
</code_context>
<issue_to_address>
**suggestion (bug_risk):** CacheStream does not dispose the wrapped response stream

`Dispose(bool)` only disposes `_lock` (and base), but not the wrapped response stream. If that stream owns network/file resources (e.g., `HttpContent`), they may never be released. Either dispose `_responseStream` here as well, or make its ownership contract explicit and avoid wrapping streams you don’t own.

Suggested implementation:

```csharp
    public override void Flush() { }

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            _responseStream?.Dispose();
            _lock?.Dispose();
        }

        base.Dispose(disposing);
    }

```

This assumes that `CacheStream` fully owns `_responseStream` and is responsible for its lifetime. If that’s not true for all call sites, you may need to:
1. Add a constructor parameter (e.g., `bool leaveResponseStreamOpen = false`) and store it in a field.
2. Conditionally dispose the response stream only when ownership is indicated: `if (disposing && !_leaveResponseStreamOpen) _responseStream?.Dispose();`.
3. Update all `CacheStream` instantiations accordingly to explicitly signal ownership.
</issue_to_address>

### Comment 3
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheHandler.cs" line_range="24-26" />
<code_context>
+        _repository = repo;
+    }
+
+    protected override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken)
+    {
+        return SendAsync(request, cancellationToken).GetAwaiter().GetResult();
+    }
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Blocking on SendAsync in Send risks deadlocks and thread-pool starvation

Using `SendAsync(...).GetAwaiter().GetResult()` in `Send` can deadlock under a synchronization context and contribute to thread-pool starvation under load. Prefer delegating the sync path to `InnerHandler.Send` (if available) or removing the sync override and relying on the async pipeline instead.

Suggested implementation:

```csharp

```

By removing this synchronous override, `HttpCacheHandler` will rely on the base `DelegatingHandler`/`HttpMessageHandler` implementation for synchronous calls, avoiding the explicit `SendAsync(...).GetAwaiter().GetResult()` and its deadlock/thread-pool starvation risks. No further changes are required unless other code depends directly on this override’s specific behavior.
</issue_to_address>

### Comment 4
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="89" />
<code_context>
        cmd.CommandText = CreateTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 5
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="268" />
<code_context>
        cmd.CommandText = InsertTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 6
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="282" />
<code_context>
        cmd.CommandText = DeleteTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 7
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="290" />
<code_context>
        queryCmd.CommandText = FindTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- In `HttpCacheRepository._UpdateTable`, the generated SQL is invalid because each changed column appends a separate `SET` clause (e.g., `SET RequestUri = ... SET Tag = ...`); instead, build a single `SET` with comma‑separated assignments and be careful to handle nullable columns via `IsDBNull` rather than using `GetString` on potentially null values.
- In `HttpCacheRepository.Initialize`, `destLocation` is treated as a directory but the IOException handler calls `File.Delete(destLocation)`, which will fail for an existing directory; consider ensuring you distinguish between directories and files and avoid deleting the whole cache directory on a transient IO error.
- In `HttpCacheHandler`, the sync `Send` implementation calls `SendAsync().GetAwaiter().GetResult()` which can deadlock in certain environments, and the expiration logic (`LastUpdate.AddSeconds(ExpiredAt) < Now`) currently returns the cached response when it is already expired; consider using only `SendAsync` and inverting the expiry condition so fresh entries are served from cache and stale ones trigger a revalidation/fetch.

## Individual Comments

### Comment 1
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="75-81" />
<code_context>
+    /// <summary>
+    /// 初始化数据库
+    /// </summary>
+    public void Initialize()
+    {
+        try
+        {
+            if (!Directory.Exists(destLocation)) Directory.CreateDirectory(destLocation);
+        }
+        catch (IOException)
+        {
+            File.Delete(destLocation);
</code_context>
<issue_to_address>
**issue (bug_risk):** Deleting a directory path with File.Delete is incorrect and can throw.

Here destLocation is a directory, but the catch uses File.Delete(destLocation) after Directory.Exists/CreateDirectory. File.Delete on a directory path will throw. If you need to clean up a bad directory, use Directory.Delete(destLocation, recursive: true) or adjust the exception handling to treat directory failures differently.
</issue_to_address>

### Comment 2
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheHandler.cs" line_range="24" />
<code_context>
+        _repository = repo;
+    }
+
+    protected override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken)
+    {
+        return SendAsync(request, cancellationToken).GetAwaiter().GetResult();
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Using sync-over-async in Send can cause deadlocks and thread pool starvation.

Calling `SendAsync(...).GetAwaiter().GetResult()` from `Send` is a sync-over-async pattern that can deadlock with a synchronization context and unnecessarily block thread-pool threads. Prefer a truly synchronous path or, if possible, only override `SendAsync` and rely on the base implementation for sync calls instead of blocking on the async method.

Suggested implementation:

```csharp
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

```

By removing the `Send` override, synchronous callers will use the base `HttpMessageHandler.Send` implementation, which in turn calls this overridden `SendAsync`. This avoids introducing an additional sync-over-async layer in your handler while preserving existing behavior for both sync and async flows.
</issue_to_address>

### Comment 3
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="89" />
<code_context>
        cmd.CommandText = CreateTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 4
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="268" />
<code_context>
        cmd.CommandText = InsertTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 5
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="282" />
<code_context>
        cmd.CommandText = DeleteTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>

### Comment 6
<location path="PCL.Core/IO/Net/Http/Cache/HttpCacheRepository.cs" line_range="290" />
<code_context>
        queryCmd.CommandText = FindTable;
</code_context>
<issue_to_address>
**security (csharp.lang.security.sqli.csharp-sqli):** Detected a formatted string in a SQL statement. This could lead to SQL injection if variables in the SQL statement are not properly sanitized. Use a prepared statements instead. You can obtain a PreparedStatement using 'SqlCommand' and 'SqlParameter'.

*Source: opengrep*
</issue_to_address>