chore: automated publish

github-actions[bot] · github-actions[bot] · commit dbb4a65138c4 · 2025-04-10T12:34:40.000Z
diff --git a/public/blog/2025-04-01/index.pdf b/public/blog/2025-04-01/index.pdf
diff --git a/public/blog/2025-04-01/index.tex b/public/blog/2025-04-01/index.tex
@@ -1,5 +1,5 @@
-\title{"Zig 语言中的拓扑排序及其在并行处理中的应用 "}
-\author{" 杨其臻 "}
+\title{"Zig 语言中的拓扑排序及其在并行处理中的应用"}
+\author{"杨其臻"}
 \date{"Apr 01, 2025"}
 \maketitle
 在系统编程领域，Zig 语言凭借其独特的显式内存管理、零成本抽象和强调确定性的设计理念，正在成为构建高性能应用的利器。本文聚焦于拓扑排序算法在 Zig 语言中的实现，并深入探讨其在并行任务调度中的创新应用。通过将传统的图论算法与现代并发模型相结合，我们能够构建出既保证执行顺序正确性，又充分挖掘硬件并行潜力的任务调度系统。\par
diff --git a/public/blog/2025-04-01/sha256 b/public/blog/2025-04-01/sha256
@@ -1 +1 @@
-7e4cd491629da2c176d8f6f58c39c7c4bd923481b768bf1c61e1db220d3e42c4
+41ad0fe14ece36affb97ea7d889ad6e3184dd579d90f36bccc9eff8be8afb7e7
diff --git a/public/blog/2025-04-02/index.pdf b/public/blog/2025-04-02/index.pdf
diff --git a/public/blog/2025-04-02/index.tex b/public/blog/2025-04-02/index.tex
@@ -1,5 +1,5 @@
-\title{" 理解并实现基本的拓扑排序算法 "}
-\author{" 杨其臻 "}
+\title{"理解并实现基本的拓扑排序算法"}
+\author{"杨其臻"}
 \date{"Apr 02, 2025"}
 \maketitle
 在计算机科学中，拓扑排序是一种解决依赖关系问题的关键算法。想象这样一个场景：大学选课时，某些课程需要先修课程。例如，学习「数据结构」前必须先修「程序设计基础」，这种依赖关系构成一个有向无环图（DAG）。拓扑排序的作用正是为这类依赖关系找到一种合理的执行顺序。本文将深入解析拓扑排序的核心原理，并通过 Python 代码实现两种经典算法。\par
diff --git a/public/blog/2025-04-02/sha256 b/public/blog/2025-04-02/sha256
@@ -1 +1 @@
-68cff51db1987cd8cd0066da78dd04e88c0658b99d7080006b608fa19a7be706
+f134741f8d0cb6e3084fbac87732b1f2f3701b470dcb7b1eb5b72878fea181eb
diff --git a/public/blog/2025-04-03/index.pdf b/public/blog/2025-04-03/index.pdf
diff --git a/public/blog/2025-04-03/index.tex b/public/blog/2025-04-03/index.tex
@@ -1,5 +1,5 @@
-\title{" 用 Mermaid.js 提升技术文档的可视化能力 "}
-\author{" 杨其臻 "}
+\title{"用 Mermaid.js 提升技术文档的可视化能力"}
+\author{"杨其臻"}
 \date{"Apr 03, 2025"}
 \maketitle
 在软件开发领域，技术文档的可读性直接影响团队协作效率与知识传递效果。传统绘图工具如 Visio 或 Draw.io 虽然功能强大，但其二进制文件格式与代码仓库的文本特性存在天然隔阂。Mermaid.js 作为一款基于文本的图表生成库，通过将图表定义为可版本控制的代码，完美解决了文档与图表同步更新的难题。其 \verb!9.4KB! 的轻量化体积与 Markdown 原生支持特性，使其成为技术写作领域的颠覆性工具。\par
@@ -56,7 +56,7 @@ \chapter{第三部分：架构图的绘制与优化}
 \begin{lstlisting}[language=mermaid]
 flowchart LR
   A[[用户终端]] --> B{{认证中心}}
-  click B "https://auth.example.com" _blank
+  click B"https://auth.example.com"_blank
 \end{lstlisting}
 \verb!click! 指令为节点添加了超链接，\verb!_blank! 参数指定在新标签页打开。导出为 SVG 时需调用 \verb!mermaid.initialize()! 并设置 \verb!securityLevel: 'loose'! 以保留交互特性。\par
 \chapter{第四部分：与其他工具的集成与自动化}
diff --git a/public/blog/2025-04-03/sha256 b/public/blog/2025-04-03/sha256
@@ -1 +1 @@
-221db7bc32884cf12d75100a0603b8842322c0aa9279b0086880926eeb72bd06
+0cc44d14dd96c5130698cd403c37fb6f1e7650805a8b471ee3eb7ddc4b2caeda
diff --git a/public/blog/2025-04-04/index.pdf b/public/blog/2025-04-04/index.pdf
diff --git a/public/blog/2025-04-04/index.tex b/public/blog/2025-04-04/index.tex
@@ -1,5 +1,5 @@
-\title{"JavaScript 中的事件循环机制 "}
-\author{" 叶家炜 "}
+\title{"JavaScript 中的事件循环机制"}
+\author{"叶家炜"}
 \date{"Apr 04, 2025"}
 \maketitle
 JavaScript 的单线程特性决定了它在处理异步任务时必须依赖事件循环机制。这一机制通过协调调用栈、内存堆和任务队列，实现了非阻塞的异步编程模型。例如，当发起一个网络请求时，浏览器不会等待响应返回，而是继续执行后续代码，待数据就绪后再通过回调函数处理结果。这种设计避免了主线程的阻塞，但也带来了执行顺序的复杂性。本文将深入剖析事件循环的核心原理，并探讨其在浏览器与 Node.js 中的差异及实践中的优化技巧。\par
diff --git a/public/blog/2025-04-04/sha256 b/public/blog/2025-04-04/sha256
@@ -1 +1 @@
-3716e993162bbc4e7be9323802bc04f3f519b8ce9aafea1b0759f76d3d63de80
+9163b0148420c198d3c07e1a553d1f5e4df5d0473590af5b89122fd583b4f304
diff --git a/public/blog/2025-04-05/index.pdf b/public/blog/2025-04-05/index.pdf
diff --git a/public/blog/2025-04-05/index.tex b/public/blog/2025-04-05/index.tex
@@ -1,5 +1,5 @@
-\title{"Python 生成器原理与应用深度解析 "}
-\author{" 黄京 "}
+\title{"Python 生成器原理与应用深度解析"}
+\author{"黄京"}
 \date{"Apr 05, 2025"}
 \maketitle
 在编程领域中，惰性计算（Lazy Evaluation）是一种延迟执行运算直到真正需要结果的核心技术。Python 通过「生成器」（Generator）实现了这一范式，使得处理海量数据流、构建无限序列等场景变得高效且优雅。本文将深入探讨生成器的工作原理，并通过典型代码示例揭示其在实际开发中的应用价值。\par
@@ -86,7 +86,7 @@ \section{协程与双向通信}
 
 co = coroutine()
 next(co)  # 启动生成器
-co.send("Hello")  # 输出 "Received: Hello"
+co.send("Hello")  # 输出"Received: Hello"
 \end{lstlisting}
 这种机制在异步编程中被广泛应用，直到 Python 3.5 引入 \verb!async/await! 语法后，生成器协程逐渐被原生协程替代，但其设计思想仍值得研究。\par
 \chapter{性能分析与实践建议}
diff --git a/public/blog/2025-04-05/sha256 b/public/blog/2025-04-05/sha256
@@ -1 +1 @@
-df4141015bdbd7737938c42b366fd4bd5eacc620ef54626fc00b29e1ac8295d7
+cd5dee95062f311b26bd1cd36be3888f8471ac18458aacee8db5a798644dbd94
diff --git a/public/blog/2025-04-06/index.pdf b/public/blog/2025-04-06/index.pdf
diff --git a/public/blog/2025-04-06/index.tex b/public/blog/2025-04-06/index.tex
@@ -1,5 +1,5 @@
-\title{"Rust 中的安全与不安全代码边界实践 "}
-\author{" 叶家炜 "}
+\title{"Rust 中的安全与不安全代码边界实践"}
+\author{"叶家炜"}
 \date{"Apr 06, 2025"}
 \maketitle
 Rust 语言以「内存安全」与「零成本抽象」著称，但这一承诺的实现依赖于开发者对安全（safe）与不安全（unsafe）代码边界的清晰认知。当我们需要操作硬件、进行极端性能优化或与 C 语言交互时，\verb!unsafe! 代码就成为必须的工具。本文将通过具体代码示例，探讨如何在实践中构建可靠的安全抽象层。\par
@@ -158,7 +158,7 @@ \chapter{进阶场景：FFI 安全封装}
         handle: *mut std::ffi::c_void,
     }
 
-    extern "C" {
+    extern"C"{
         pub fn create_context() -> *mut CContext;
         pub fn free_context(ctx: *mut CContext);
     }
diff --git a/public/blog/2025-04-06/sha256 b/public/blog/2025-04-06/sha256
@@ -1 +1 @@
-6b75ae53506ec0e029836997dfdad3b077bfc382fd7b70b4635e5d1b36b0f35c
+41813bc3fa71f8e31b0538a8e270bc927768bdbc560c0258883d1de024c94e20
diff --git a/public/blog/2025-04-07/index.pdf b/public/blog/2025-04-07/index.pdf
diff --git a/public/blog/2025-04-07/index.tex b/public/blog/2025-04-07/index.tex
@@ -1,12 +1,12 @@
-\title{" 使用 IndexedDB 进行浏览器端数据存储的最佳实践 "}
-\author{" 杨子凡 "}
+\title{"使用 IndexedDB 进行浏览器端数据存储的最佳实践"}
+\author{"杨子凡"}
 \date{"Apr 07, 2025"}
 \maketitle
 随着离线优先应用（如 PWA）的兴起，开发者面临的核心挑战之一是如何在浏览器端高效管理复杂数据。传统方案如 Cookies 和 LocalStorage 存在存储容量限制（通常为 5MB）和仅支持字符串存储的缺陷。例如，当需要缓存包含嵌套结构的 API 响应或存储二进制文件时，LocalStorage 显然力不从心。\par
 IndexedDB 作为浏览器原生 NoSQL 数据库，提供了异步事务机制、支持索引查询、存储容量可达硬盘空间的 50\%{} 等特性。其非阻塞设计意味着在写入 10MB 数据时，主线程仍能保持流畅响应——这是同步存储 API 无法企及的优势。\par
 \chapter{核心概念速览}
 \section{架构体系解析}
-每个 IndexedDB 实例由若干数据库（Database）构成，每个数据库包含多个对象存储（Object Store）。对象存储相当于传统数据库中的表，但支持直接存储 JavaScript 对象。例如，用户数据存储可以包含 \verb!{id: 1, name: "John", tags: ["vip", "developer"]}! 这样的复杂结构。\par
+每个 IndexedDB 实例由若干数据库（Database）构成，每个数据库包含多个对象存储（Object Store）。对象存储相当于传统数据库中的表，但支持直接存储 JavaScript 对象。例如，用户数据存储可以包含 \verb!{id: 1, name: "John", tags: ["vip","developer"]}! 这样的复杂结构。\par
 索引（Index）机制允许在非主键字段上建立快速查询通道。假设在 \verb!users! 存储中为 \verb!name! 字段创建索引，即可实现近似 SQL 的 \verb!WHERE name = 'John'! 查询。事务（Transaction）则确保操作的原子性——要么全部成功，要么回滚到操作前状态。\par
 \section{技术选型对比}
 与 Web SQL 相比，IndexedDB 避免了 SQL 注入风险且符合现代 NoSQL 发展趋势。相较于新兴的 OPFS（Origin Private File System），IndexedDB 更适合结构化数据存储，而 OPFS 更擅长处理文件系统类操作。当数据量超过 500MB 时，建议优先考虑 IndexedDB 的索引查询能力。\par
diff --git a/public/blog/2025-04-07/sha256 b/public/blog/2025-04-07/sha256
@@ -1 +1 @@
-d2704b8be61f40343da73a051c207d4be37204d9a0d5931b79dc907fb9e38d20
+3a891be9e112800e6551be7339ba24280e363285a20311fd742700eea684f509
diff --git a/public/blog/2025-04-08/index.pdf b/public/blog/2025-04-08/index.pdf
diff --git a/public/blog/2025-04-08/index.tex b/public/blog/2025-04-08/index.tex
@@ -1,5 +1,5 @@
-\title{" 使用 HNSW 算法优化向量相似性搜索 "}
-\author{" 叶家炜 "}
+\title{"使用 HNSW 算法优化向量相似性搜索"}
+\author{"叶家炜"}
 \date{"Apr 08, 2025"}
 \maketitle
 在大数据时代，向量相似性搜索已成为推荐系统、图像检索和自然语言处理等场景的核心技术。传统方法如暴力搜索（Brute-force）虽能保证 100\%{} 召回率，但其 $O(N)$ 的时间复杂度难以应对百万级以上数据规模；KD-Tree 和 LSH（Locality-Sensitive Hashing）虽提升了效率，却在高维空间中面临「维度灾难」的挑战。而 \textbf{HNSW（Hierarchical Navigable Small World）} 算法通过分层可导航小世界网络结构，在精度与效率之间实现了突破性平衡，成为当前近似最近邻搜索（ANN）领域的热门选择。\par
diff --git a/public/blog/2025-04-08/sha256 b/public/blog/2025-04-08/sha256
@@ -1 +1 @@
-7a6fd81895b9fde41b63c9df60d55210e9aa55ac326041e1093edcbd77e11496
+054c4a6d53da717e5e37bcbe39ac5ded8d5e2577b3853ed43721e1e0d6f31829
diff --git a/public/blog/2025-04-09/index.pdf b/public/blog/2025-04-09/index.pdf
diff --git a/public/blog/2025-04-09/index.tex b/public/blog/2025-04-09/index.tex
@@ -1,5 +1,5 @@
-\title{" 使用 PipeWire 优化 Linux 音频系统的配置与实践 "}
-\author{" 黄京 "}
+\title{"使用 PipeWire 优化 Linux 音频系统的配置与实践"}
+\author{"黄京"}
 \date{"Apr 09, 2025"}
 \maketitle
 在 Linux 生态系统中，音频子系统长期面临着架构碎片化与性能瓶颈的双重挑战。传统解决方案如 ALSA、PulseAudio 和 Jack 各自为政，导致用户在\textbf{低延迟音频处理}、\textbf{多设备动态路由}和\textbf{蓝牙编解码支持}等场景中频繁遭遇技术壁垒。2021 年正式发布的 PipeWire 凭借其\textbf{统一媒体处理架构}和\textbf{API 兼容层}，正在重塑 Linux 音频的底层格局。\par
@@ -19,7 +19,7 @@ \chapter{PipeWire 的安装与基础配置}
 \end{lstlisting}
 此过程关键步骤在于\textbf{禁用 PulseAudio 服务}，避免资源竞争。安装后需验证音频服务状态：\par
 \begin{lstlisting}[language=bash]
-pw-top | grep "Driver Rate Quantum"
+pw-top | grep"Driver Rate Quantum"
 # 预期输出示例：48000 Hz | 256 samples (5.33 ms)
 \end{lstlisting}
 配置文件 \verb!~/.config/pipewire/pipewire.conf! 中，建议优先调整时钟源参数：\par
@@ -76,10 +76,10 @@ \chapter{配套工具与插件生态}
 \begin{lstlisting}[language=lua]
 rule = {
     matches = {
-        { { "device.name", "equals", "bluez_card.XX_XX_XX_XX_XX_XX" } }
+        { {"device.name","equals","bluez_card.XX_XX_XX_XX_XX_XX"} }
     },
     apply_properties = {
-        ["device.profile"] = "a2dp-sink-ldac"
+        ["device.profile"] ="a2dp-sink-ldac"
     }
 }
 table.insert(alsa_monitor.rules, rule)
@@ -88,19 +88,19 @@ \chapter{配套工具与插件生态}
 \chapter{典型场景实战案例}
 在\textbf{游戏音频优化}场景中，可通过环境变量动态调整量子值：\par
 \begin{lstlisting}[language=bash]
-env PIPEWIRE_LATENCY="64/48000" %command%
+env PIPEWIRE_LATENCY="64/48000"%command%
 \end{lstlisting}
 该命令将量子锁定为 64 样本，应用于 Steam 启动参数时可显著降低《CS2》等游戏的输入到输出延迟。同时配合 \verb!easyeffects! 加载预置均衡器，可增强脚步声等关键音效。\par
 \chapter{常见问题与调试技巧}
 当遭遇\textbf{设备无声}故障时，建议按以下流程排查：\par
 \begin{itemize}
 \item 检查 WirePlumber 设备状态：\begin{lstlisting}[language=bash]
-wpctl status | grep -A 10 "Audio"
+wpctl status | grep -A 10"Audio"
 # 确认目标设备处于 available 状态
 \end{lstlisting}
 
 \item 验证节点连接：\begin{lstlisting}[language=bash]
-pw-dump | jq '.[] | select(.type == "PipeWire:Interface:Node")'
+pw-dump | jq '.[] | select(.type =="PipeWire:Interface:Node")'
 # 检查 input/output 端口是否建立链接
 \end{lstlisting}
 
diff --git a/public/blog/2025-04-09/sha256 b/public/blog/2025-04-09/sha256
@@ -1 +1 @@
-afb456073c27db424c3d3537ecde50dacea7141a785ad09380fca7adbe786848
+565dc757d176d3fcac0aa637e5ca0c6ae5455900b9efd791b4c55a9a693426de

Original file line number	Diff line number	Diff line change
`@@ -1 +1 @@`
`1`		`-7e4cd491629da2c176d8f6f58c39c7c4bd923481b768bf1c61e1db220d3e42c4`
	`1`	`+41ad0fe14ece36affb97ea7d889ad6e3184dd579d90f36bccc9eff8be8afb7e7`
Original file line number	Diff line number	Diff line change
`@@ -1 +1 @@`
`1`		`-68cff51db1987cd8cd0066da78dd04e88c0658b99d7080006b608fa19a7be706`
	`1`	`+f134741f8d0cb6e3084fbac87732b1f2f3701b470dcb7b1eb5b72878fea181eb`
Original file line number	Diff line number	Diff line change
`@@ -1 +1 @@`
`1`		`-221db7bc32884cf12d75100a0603b8842322c0aa9279b0086880926eeb72bd06`
	`1`	`+0cc44d14dd96c5130698cd403c37fb6f1e7650805a8b471ee3eb7ddc4b2caeda`