Please address the comments from this code review:

## Overall Comments
- The switch to std::fs::File::create inside an async function introduces a blocking syscall on the async runtime thread; consider moving file creation into the spawn_blocking section (or another blocking task) to keep the download path fully non-blocking.
- The use of chunk.to_vec() in the send loop doubles memory copies for each chunk; consider changing the channel type to something like Bytes or Box<[u8]> so you can transfer ownership without an extra allocation and copy.

## Individual Comments

### Comment 1
<location path="src-tauri/src/commands/download.rs" line_range="385-394" />
<code_context>
-        .get_ref()
-        .sync_all()
+    // 等待写入线程完成，确保文件句柄关闭后再进行重命名等后续操作
+    let write_thread_result = write_handle
         .await
-        .map_err(|e| format!("同步文件失败: {}", e))?;
+        .map_err(|e| format!("写入任务异常: {}", e))?;

-    // 显式关闭文件句柄，避免 Windows 上 rename 失败
-    drop(writer);
+    if let Some(err) = download_err {
+        if is_cancelled {
+            // 取消路径：cancel_download() 已处理临时文件清理，新下载会用 File::create 覆盖。
+            // 此处 disarm 避免 guard 在 write_handle.await 之后才触发，误删新任务的临时文件。
+            temp_guard.disarm();
+        }
+        return Err(err);
+    }
+    write_thread_result?;

     // 发送最终进度
</code_context>
<issue_to_address>
**suggestion:** Error reporting from the writer thread is slightly inconsistent between network-error and disk-error paths.

In the disk-error path, `write_handle` likely returns a detailed `Err("写入文件失败: …")`, but the current logic always returns the generic `download_err` whenever it is `Some`, ignoring `write_thread_result`. This loses useful detail for disk failures. Consider preferring the writer thread’s error (if present) over the generic channel-close message, or combining them so disk errors surface with maximum detail.
</issue_to_address>

### Comment 2
<location path="src-tauri/src/commands/download.rs" line_range="389-395" />
<code_context>

-    // 显式关闭文件句柄，避免 Windows 上 rename 失败
-    drop(writer);
+    if let Some(err) = download_err {
+        if is_cancelled {
+            // 取消路径：cancel_download() 已处理临时文件清理，新下载会用 File::create 覆盖。
+            // 此处 disarm 避免 guard 在 write_handle.await 之后才触发，误删新任务的临时文件。
+            temp_guard.disarm();
+        }
+        return Err(err);
+    }
+    write_thread_result?;
</code_context>
<issue_to_address>
**question (bug_risk):** The cancellation path now relies on external cleanup and disarms the temp-file guard, which may change the previous cleanup behavior.

On cancel, this now (1) flushes remaining chunks, (2) awaits the writer, then (3) disarms `temp_guard` assuming `cancel_download()` has already deleted the temp file and that future downloads will reuse/overwrite that path. This moves ownership of cleanup from the guard to `cancel_download()`, so if that external cleanup ever fails or is skipped, the temp file could be leaked. Please confirm this change is intentional and consistent at all call sites, or consider keeping the guard active and coordinating so only the latest guard for a given path is allowed to delete.
</issue_to_address>

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="src-tauri/src/commands/download.rs" line_range="262" />
<code_context>
+            .map_err(|e| format!("无法创建文件: {}", e))?;
+        let mut writer = std::io::BufWriter::with_capacity(512 * 1024, file);
+        let mut write_rx = write_rx;
+        while let Some(chunk) = write_rx.blocking_recv() {
+            writer
+                .write_all(&chunk)
</code_context>
<issue_to_address>
**issue (bug_risk):** Using `blocking_recv` on `tokio::sync::mpsc::Receiver` requires the `sync` feature on tokio, which is not enabled here.

In `Cargo.toml` this crate only enables `tokio` with `features = ["rt"]`, so this call will fail to compile unless `sync` is explicitly added here (we can’t rely on it being pulled in transitively). Please either enable the `sync` feature for `tokio` in this crate, or refactor to avoid `blocking_recv` (e.g., use `std::sync::mpsc`, crossbeam, or another non-blocking pattern).
</issue_to_address>