chore: automated publish

Author: github-actions[bot]

public/blog/2025-05-04/index.pdf

@@ -0,0 +1,49 @@
+\title{"浏览器中的文件系统 API 原理与应用实践"}
+\author{"黄京"}
+\date{"May 04, 2025"}
+\maketitle
+随着 Web 应用复杂度的提升，浏览器逐渐从简单的交互平台演变为支持本地化操作的强大工具。传统的前端存储方案如 LocalStorage 和 IndexedDB 虽然能处理键值对或结构化数据，但在文件系统级别的管理上显得力不从心。文件系统 API 的诞生填补了这一空白，使得 Web 应用能够以更接近原生应用的方式管理文件，为在线编辑器、多媒体处理等场景提供了技术基础。\par
+\chapter{文件系统 API 基础}
+浏览器文件系统 API 是一套提供虚拟文件系统访问能力的接口。它允许开发者在沙盒环境中创建、读写文件，并支持将数据持久化存储。与本地文件系统不同，其所有操作都受限于同源策略和用户授权机制，确保安全性。例如，用户必须通过点击等主动行为授权后，页面才能访问文件系统。\par
+该 API 的演进经历了多个阶段。早期的 Origin Private File System (OPFS) 仅提供临时存储，而 File System Access API 的加入使得直接读写本地文件成为可能。目前 Chrome 和 Edge 浏览器已提供较完整的支持，但 Firefox 和 Safari 的兼容性仍待完善。\par
+\chapter{技术原理剖析}
+文件系统 API 的底层实现基于浏览器的 Storage Foundation 层。它通过虚拟文件系统抽象，将物理存储介质映射为逻辑目录结构。每个源的存储空间独立分配，且受配额限制。开发者可通过 \verb!navigator.storage.estimate()! 查询当前使用情况：\par
+\begin{lstlisting}[language=javascript]
+const { usage, quota } = await navigator.storage.estimate();
+console.log(` 已使用 ${usage} 字节，配额为 ${quota} 字节 `);
+\end{lstlisting}
+这段代码通过异步调用获取存储使用量和总配额。浏览器根据设备存储容量动态调整配额，通常遵循公式 $Q = \min(D \times r, S_{\max})$，其中 $D$ 为设备容量，$r$ 为分配比例，$S_{\max}$ 为系统设定的上限。\par
+安全机制方面，API 采用双重防护策略。首先，任何文件操作必须由用户主动触发（如点击事件），防止恶意脚本自动运行。其次，沙盒环境隔离不同源的数据，即使同一物理设备上的不同网站也无法互相访问文件。\par
+\chapter{应用实践指南}
+在实现基础文件操作时，核心流程包含权限请求、文件创建和内容写入三个步骤。以下示例演示如何创建并保存文件：\par
+\begin{lstlisting}[language=javascript]
+// 请求目录访问权限
+const dirHandle = await window.showDirectoryPicker();
+// 获取或创建文件句柄
+const fileHandle = await dirHandle.getFileHandle('demo.txt', { create: true });
+// 创建可写流
+const writer = await fileHandle.createWritable();
+// 写入内容
+await writer.write('Hello, File System API!');
+// 关闭流以保存
+await writer.close();
+\end{lstlisting}
+代码首先通过 \verb!showDirectoryPicker()! 触发浏览器权限弹窗。用户授权后返回目录句柄 \verb!dirHandle!。\verb!getFileHandle! 方法接收文件名和创建标志，若文件不存在则新建。\verb!createWritable()! 返回的可写流对象支持分块写入，这对处理大文件至关重要。最后必须显式关闭流以确保数据持久化。\par
+在处理复杂场景时，递归遍历目录是常见需求。以下函数展示如何深度扫描目录结构：\par
+\begin{lstlisting}[language=javascript]
+async function scanDirectory(dirHandle, indent = 0) {
+  for await (const entry of dirHandle.values()) {
+    console.log(' '.repeat(indent) + entry.name);
+    if (entry.kind === 'directory') {
+      await scanDirectory(entry, indent + 2);
+    }
+  }
+}
+\end{lstlisting}
+该函数利用异步迭代器遍历目录项，通过 \verb!entry.kind! 判断类型，递归处理子目录。这种方式避免了同步 API 可能导致的性能问题，符合浏览器的事件循环模型。\par
+\chapter{注意事项与局限性}
+尽管文件系统 API 功能强大，开发者仍需注意其边界条件。存储配额在不同浏览器中存在差异，Chrome 通常允许源占用至少 60\%{} 的磁盘空间。当写入超过配额时，会抛出 \verb!QuotaExceededError!，此时需要引导用户清理存储或申请更多空间。\par
+兼容性方面，iOS 设备目前仅支持 OPFS 的临时存储，且文件在页面刷新后可能被清除。对于需要长期保存的数据，建议结合 Service Worker 实现离线缓存。此外，直接访问系统全局路径仍受限制，文件的导入导出必须通过用户显式操作完成。\par
+\chapter{未来展望}
+W3C 正在推进文件系统 API 的标准化进程，未来可能与 WebAssembly 深度结合，实现更高效的文件处理。在 WASM 模块中直接操作文件句柄，可以绕过 JavaScript 的类型转换开销，这对视频编辑等计算密集型场景意义重大。同时，与 IPFS 等去中心化协议的集成，可能催生出新型的分布式 Web 应用架构。\par
+浏览器文件系统 API 正在重塑 Web 应用的疆界，使原本依赖客户端的复杂应用能够迁移到云端。随着标准的完善和生态工具的成熟，开发者将获得更接近操作系统级别的能力，这预示着 Web 平台新时代的到来。\par

public/blog/2025-05-04/index.tex

@@ -0,0 +1 @@
+4598d826571496b2db46c942bd4a7a748b9c20956e9b5fde08f9fe01771e3ae1