HTML、Angular中，用户选文件后关浏览器，返回能否免操作或确认后上传？

Great question—this is a super common scenario for file upload apps, but there are key web platform constraints and practical workarounds you need to know about. Let’s break this down step by step:

Why storing file paths won’t work #

First off, you can’t rely on saving local file paths to resume uploads. Browsers enforce strict security rules that block websites from accessing local files directly via file system paths. The path you get from a file input is only valid for the current browser session—once the browser closes, that path becomes useless, and you won’t be able to read the file using it.

Storing large files for later upload #

LocalStorage is indeed too limited (usually ~5MB) for large images or files, so you’ll need better storage options:

1. IndexedDB (widely supported) #

IndexedDB is a browser-built asynchronous storage API that lets you store Blob objects (you can use a user-selected File directly, since File inherits from Blob). It has no hard size limit (only constrained by the user’s available disk space), making it perfect for large files.

Here’s a quick workflow for this approach:

• When the user selects a file, save it to IndexedDB along with metadata (like file name, upload progress state)
• When the user reopens the app, check IndexedDB for any unfinished upload records
• If found, retrieve the Blob, create a FormData object, and initiate the upload once the user confirms

2. File System Access API (modern browsers only) #

For newer browsers (Chrome, Edge, Firefox 118+), the File System Access API lets you request permission to get a FileSystemFileHandle for the user’s file. You can save this handle to IndexedDB, and when the user returns, you can use the handle to re-access the file without them having to re-select it.

A few caveats here:

• Users have to grant explicit permission for your app to access their files this way
• If the user moves or deletes the file locally, the handle will become invalid
• This API isn’t supported in Safari yet, so you’ll need an IndexedDB fallback for those users

Auto-upload vs. user confirmation #

Important rule: Browsers block automatic file uploads that don’t come from a direct user interaction (like a button click). Even if you have the file stored, you can’t start the upload without the user explicitly confirming it (e.g., a dialog that says "Resume uploading your 15MB image?"). This is a security and user experience safeguard to prevent unwanted data transfers.

Recommended workflow #

Putting it all together, here’s a solid approach:

• When the user selects a file, save it (as a Blob or FileSystemFileHandle) to IndexedDB, along with upload state (e.g., "not started", "in progress")
• On app load, check IndexedDB for any pending uploads
• If a pending upload exists, show a clear confirmation prompt to the user
• Once the user confirms, retrieve the file from storage, build your upload request, and send it to your server
• After a successful upload, delete the stored file/handle from IndexedDB to free up space

Key considerations #

• Privacy: Always tell users you’re storing their files locally, and give them an option to delete stored data (to comply with regulations like GDPR)
• Storage limits: Even though IndexedDB has no hard limit, users can clear browser storage at any time—don’t rely on it as permanent storage
• Error handling: Account for cases where the stored file/handle is no longer valid (e.g., user deleted the file) and show a friendly error message

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