Pagefind 是一个专为静态网站设计的开源搜索引擎，它能够自动索引你的网站并提供完全离线的搜索体验。

核心特性

• 按需加载：只下载搜索相关的内容片段，而不是整个索引
• 轻量级：核心 JS 仅约 20KB，索引文件高度压缩（相比 Lunr.js 减少 85%）
• 零配置：自动识别内容，开箱即用
• 多语言支持：内置中文、日文等多语言分词器
• 完全静态：无需服务器端支持，支持完全离线

快速上手

三步启用搜索

# 1. 构建你的静态网站
npm run build

# 2. 生成搜索索引
npx pagefind --source "dist"

# 3. 在 HTML 中添加搜索界面

<link href="/pagefind/pagefind-ui.css" rel="stylesheet">
<div id="search"></div>
<script src="/pagefind/pagefind-ui.js"></script>
<script>
    new PagefindUI({ element: "#search" });
</script>

Pagefind 会自动在 dist/pagefind/ 目录下生成索引文件。

核心用法

控制索引范围

使用 data-pagefind-body 标记要索引的内容：

<main data-pagefind-body>
    <h1>文章标题</h1>
    <p>这部分内容会被索引</p>
</main>

<!-- 使用 data-pagefind-ignore 排除特定内容 -->
<div data-pagefind-ignore>
    <h2>评论</h2>
    <div class="comments">...</div>
</div>

添加元数据和权重

<!-- 自定义元数据 -->
<article data-pagefind-body
         data-pagefind-meta="author:张三,date:2024-01-01">
    <h1 data-pagefind-weight="10">文章标题</h1>
    <p data-pagefind-weight="5">摘要内容...</p>
    <div>正文内容...</div>
</article>

配置文件

# pagefind.yml
source: "dist"
exclude_selectors:
  - "nav"
  - ".sidebar"
force_language: "zh-cn"

自定义搜索 UI

import * as pagefind from '/pagefind/pagefind.js';

const search = await pagefind.search("React");
const results = await Promise.all(
    search.results.map(r => r.data())
);

实战指南

集成到构建流程

{
  "scripts": {
    "build": "vite build",
    "postbuild": "pagefind --source dist"
  }
}

React 自定义搜索组件

import { useState } from 'react';

function Search() {
    const [results, setResults] = useState([]);

    const handleSearch = async (e) => {
        const { default: pagefind } = await import('/pagefind/pagefind.js');
        const search = await pagefind.search(e.target.value);
        const data = await Promise.all(
            search.results.slice(0, 5).map(r => r.data())
        );
        setResults(data);
    };

    return (
        <>
            <input type="search" onChange={handleSearch} />
            {results.map((r, i) => (
                <a key={i} href={r.url}>
                    <h3>{r.meta.title}</h3>
                    <p dangerouslySetInnerHTML={{ __html: r.excerpt }} />
                </a>
            ))}
        </>
    );
}

最佳实践

1. 只索引主要内容

<!-- ✅ 推荐 -->
<main data-pagefind-body>
    <article>...</article>
</main>

2. 使用权重优化结果

<h1 data-pagefind-weight="10">标题</h1>
<p data-pagefind-weight="5">摘要</p>

3. CLI 参数配置

# 排除选择器
pagefind --source "dist" --exclude-selectors "nav" --exclude-selectors "footer"

# 强制语言
pagefind --source "dist" --force-language "zh-cn"

配置参考

HTML 属性

JavaScript API

// 高级搜索
const search = await pagefind.search("React", {
  filters: { category: "tutorial" },
  sort: { date: "desc" },
  limit: 10
});

// 获取结果
const results = await Promise.all(
  search.results.map(r => r.data())
);

原理深度解析

整体架构

首先通过架构图了解 Pagefind 的整体设计：

graph TB
    subgraph "构建阶段 Build Time"
        A[HTML 文件] --> B[内容扫描器]
        B --> C[内容提取器]
        C --> D[多语言分词器]
        D --> E[倒排索引构建器]
        E --> F[索引分片器]
        F --> G[压缩引擎]
        G --> H[索引文件]
    end

    subgraph "运行阶段 Runtime"
        I[用户查询] --> J[查询分词]
        J --> K[哈希计算]
        K --> L[按需加载器]
        H --> L
        L --> M[索引查询]
        M --> N[TF-IDF 评分]
        N --> O[结果排序]
        O --> P[内容片段加载]
        P --> Q[摘要生成]
        Q --> R[搜索结果]
    end

    subgraph "缓存层 Cache Layer"
        S[浏览器缓存]
        T[内存缓存]
        L -.-> S
        L -.-> T
    end

    style A fill:#e1f5ff
    style H fill:#e1f5ff
    style I fill:#fff3e0
    style R fill:#fff3e0

索引构建过程

Pagefind 的工作流程可以分为两个阶段：构建时索引和运行时搜索。

1. 构建时索引（Build Time）

当你运行 pagefind --source "dist" 时，Pagefind 会执行以下步骤：

flowchart TD
    Start([开始构建]) --> Scan[扫描 HTML 文件]
    Scan --> Parse[解析 HTML DOM]
    Parse --> Extract[提取内容]

    Extract --> CheckBody{检查 data-pagefind-body}
    CheckBody -->|找到| UseBody[使用标记的内容]
    CheckBody -->|未找到| UseDefault[使用 body 全部内容]

    UseBody --> Filter[应用排除规则]
    UseDefault --> Filter

    Filter --> Meta[提取元数据]
    Meta --> Tokenize[文本分词]

    Tokenize --> CheckLang{检测语言}
    CheckLang -->|英文| EnTokenizer[英文分词器]
    CheckLang -->|中文| ZhTokenizer[中文分词器 n-gram]
    CheckLang -->|其他| OtherTokenizer[对应语言分词器]

    EnTokenizer --> BuildIndex[构建倒排索引]
    ZhTokenizer --> BuildIndex
    OtherTokenizer --> BuildIndex

    BuildIndex --> CalcWeight[计算词条权重]
    CalcWeight --> Shard[索引分片 256个桶]

    Shard --> Compress[压缩处理]
    Compress --> GenFragment[生成内容片段]
    GenFragment --> WriteFiles[写入文件]

    WriteFiles --> Output[输出到 pagefind/]
    Output --> End([构建完成])

    style Start fill:#90EE90
    style End fill:#FFB6C1
    style BuildIndex fill:#FFE4B5
    style Compress fill:#E0FFFF

关键技术点：

• 倒排索引：对于每个词条，记录它出现在哪些文档的哪些位置
• 分片存储：将索引拆分成小块，按需加载（使用一致性哈希算法分配到 256 个桶）
• 压缩算法：使用高效的压缩减少文件大小

索引结构详解：

pagefind/
├── pagefind.js           # 核心搜索引擎（~20KB）
│                         # - 包含哈希函数
│                         # - 索引加载器
│                         # - 搜索算法
│
├── pagefind-ui.js        # UI 组件（~15KB）
├── pagefind-ui.css       # 样式文件（~3KB）
│
├── index/                # 索引分片（256 个）
│   ├── index_00.pf       # 哈希值 0x00-0x00
│   ├── index_01.pf       # 哈希值 0x01-0x01
│   ├── ...
│   └── index_ff.pf       # 哈希值 0xFF-0xFF
│
├── fragment/             # 内容片段
│   ├── en_<hash>.pf      # 英文页面片段
│   ├── zh_<hash>.pf      # 中文页面片段
│   └── ...
│
└── filter/               # 过滤器数据（如果使用）
    ├── category.pf
    └── tags.pf

2. 运行时搜索（Runtime）

当用户输入搜索查询时的完整时序：

sequenceDiagram
    actor User as 用户
    participant UI as 搜索界面
    participant Core as Pagefind 核心
    participant Cache as 浏览器缓存
    participant Server as 静态服务器

    User->>UI: 输入 "React 教程"
    UI->>UI: 防抖延迟 (300ms)

    UI->>Core: search("React 教程")
    Core->>Core: 分词 ["React", "教程"]

    par 并行计算哈希
        Core->>Core: hash("React") = 0x42
        Core->>Core: hash("教程") = 0xA7
    end

    par 并行加载索引分片
        Core->>Cache: 检查 index_42.pf
        Cache-->>Core: 缓存未命中
        Core->>Server: GET /pagefind/index/index_42.pf
        Server-->>Core: 返回索引数据 (5KB)

        Core->>Cache: 检查 index_a7.pf
        Cache-->>Core: 缓存命中
        Cache-->>Core: 返回缓存数据
    end

    Core->>Core: 解析索引分片
    Core->>Core: 查找匹配文档<br/>"React": [1,5,23]<br/>"教程": [1,8,15]<br/>交集: [1]

    Core->>Core: 计算 TF-IDF 得分
    Core->>Core: 排序结果

    Core->>Cache: 检查 fragment_1.pf
    Cache-->>Core: 缓存未命中
    Core->>Server: GET /pagefind/fragment/zh_1.pf
    Server-->>Core: 返回内容片段 (12KB)

    Core->>Core: 提取摘要<br/>高亮关键词
    Core->>Core: 生成结果对象

    Core-->>UI: 返回搜索结果
    UI->>UI: 渲染结果列表
    UI-->>User: 显示搜索结果

    Note over Core,Server: 总耗时: ~80ms<br/>网络请求: 2 个 (17KB)<br/>缓存命中: 1 个

性能分析：

核心技术解析

1. 按需加载机制

Pagefind 最大的创新是渐进式加载。传统的客户端搜索（如 Lunr.js）需要加载完整索引：

// 传统方案：需要加载整个索引
// 假设网站有 1000 个页面，索引文件可能有 5MB
await loadFullIndex(); // 加载 5MB
search("React");

Pagefind 的方案：

// Pagefind：按需加载
search("React");
// 1. 根据 "React" 计算哈希 -> 只加载包含 "React" 的索引分片（可能只有 10KB）
// 2. 找到匹配的文档 ID
// 3. 只加载这些文档的内容片段（可能 20KB）
// 总共只需要下载 30KB，而不是 5MB

实现原理：

查询词 "React"
    ↓
计算哈希：hash("React") = 0x3A7F
    ↓
确定分片：0x3A7F % 256 = 127
    ↓
加载：GET /pagefind/index/index_127.pf
    ↓
解析分片，找到文档 ID: [5, 23, 87]
    ↓
加载内容：GET /pagefind/fragment/en_005.pf

2. 倒排索引结构

倒排索引是搜索引擎的核心数据结构：

正向索引（文档 → 词条）：
文档1: ["React", "教程", "入门"]
文档2: ["Vue", "教程", "进阶"]
文档3: ["React", "进阶", "Hooks"]

倒排索引（词条 → 文档）：
"React"  → [文档1, 文档3]
"Vue"    → [文档2]
"教程"   → [文档1, 文档2]
"入门"   → [文档1]
"进阶"   → [文档2, 文档3]
"Hooks"  → [文档3]

当搜索 "React 教程" 时：

1. 查找 "React" → [文档1, 文档3]
2. 查找 "教程" → [文档1, 文档2]
3. 取交集 → [文档1]

3. TF-IDF 相关性评分

Pagefind 使用 TF-IDF 算法计算搜索结果的相关性：

TF（词频）：词条在文档中出现的频率

TF(t, d) = 词条 t 在文档 d 中出现的次数 / 文档 d 的总词数

IDF（逆文档频率）：词条的稀有程度

IDF(t) = log(总文档数 / 包含词条 t 的文档数)

TF-IDF 得分：

TF-IDF(t, d) = TF(t, d) × IDF(t)

示例计算：

假设我们有 100 个文档，搜索 "React Hooks"：

文档A：
- "React" 出现 10 次，文档总词数 100
  TF("React", A) = 10/100 = 0.1
  包含 "React" 的文档有 30 个
  IDF("React") = log(100/30) = 0.52
  TF-IDF("React", A) = 0.1 × 0.52 = 0.052

- "Hooks" 出现 5 次
  TF("Hooks", A) = 5/100 = 0.05
  包含 "Hooks" 的文档有 5 个
  IDF("Hooks") = log(100/5) = 1.30
  TF-IDF("Hooks", A) = 0.05 × 1.30 = 0.065

文档A 总分 = 0.052 + 0.065 = 0.117

"Hooks" 更稀有，所以权重更高。

4. 多语言分词

Pagefind 内置了多种语言的分词器：

英文分词（基于空格和标点）：

"Hello, world!" → ["hello", "world"]

中文分词（基于字典和统计）：

"自然语言处理" → ["自然", "语言", "处理"]
或 → ["自然语言", "处理"]
或 → ["自然语言处理"]

Pagefind 使用 n-gram 技术处理 CJK 文本：

"搜索引擎" → ["搜索", "搜索引", "搜索引擎", "索引", "索引擎", "引擎"]

这样即使查询 "搜索" 或 "引擎"，也能匹配到 "搜索引擎"。

性能优化技术

Pagefind 通过多种技术实现高性能：

索引压缩（原始 10MB → 500KB，压缩率 95%）：

• 去除 HTML 标签和属性
• 词干提取（stemming）："running" → "run"
• 停用词过滤（去除 "the", "a", "is" 等常见词）
• 增量编码 + Gzip 压缩

并行加载：
支持 HTTP/2 多路复用，多个词条的索引分片并行加载，总耗时 = max(单个加载时间)。

技术内幕深度剖析

1. 核心算法实现

Pagefind 是用 Rust 编写并编译为 WASM，核心逻辑包括：

哈希计算（FNV-1a 算法）：

// 词条归一化（转小写、去除特殊字符）→ FNV-1a 哈希 → 映射到 0-255
hash("React") = 0x42 (66)
hash("react") = 0x42 (66)  // 大小写不敏感

索引加载器：

1. 计算词条哈希 → 确定分片编号
2. 检查内存缓存 → 未命中则加载对应的 .pf 文件
3. 解析二进制格式 → 存入缓存
4. 返回词条对应的文档 ID 列表

TF-IDF 评分器：

// 计算每个文档的相关性得分
score = Σ(TF × IDF × weight) × lengthNorm
// - TF: 词频
// - IDF: 逆文档频率（缓存优化）
// - weight: 自定义权重
// - lengthNorm: 长度归一化（防止长文档占优）

2. .pf 文件格式

Pagefind 使用自定义的 .pf（Pagefind Format）二进制格式：

索引文件（index_XX.pf）：

• Header：Magic Number (0x5046 'PF') + 版本 + 标志 + 条目数
• Entries：每个词条 → 文档 ID 列表（增量编码）

示例："React" → [1, 5, 23] 存储为 [1, +4, +18]

内容片段（fragment_XX.pf）：

• Header：Magic Number + 压缩类型 + 文档 ID + 长度
• Metadata：JSON 格式（title, url, excerpt 等）
• Content：原始文本 + 词条位置映射

3. 四层压缩策略

graph LR
    A[原始数据<br/>100KB] --> B[增量编码<br/>50KB]
    B --> C[VarInt 编码<br/>40KB]
    C --> D[词干提取<br/>30KB]
    D --> E[Gzip 压缩<br/>25KB]

    style E fill:#90EE90

Level 1: 增量编码（Delta Encoding）

• 文档 ID [1, 5, 23, 45] → [1, +4, +18, +22]
• 节省 50% 存储空间

Level 2: 变长整数编码（VarInt）

• 小数字用 1 字节，大数字自动扩展
• 1 → [0x01]，128 → [0x80, 0x01]

Level 3: 词干提取（Stemming）

• "running", "runs", "runner" → "run"
• 减少唯一词条数量 30-40%

Level 4: Gzip 压缩

• 文本压缩率 60-80%
• 最终实现 95% 总压缩率

4. 三层缓存架构

graph TD
    A[搜索请求] --> B{L1 内存缓存}
    B -->|命中| C[返回结果]
    B -->|未命中| D{L2 HTTP 缓存}
    D -->|命中| C
    D -->|未命中| E{L3 Service Worker}
    E -->|命中| C
    E -->|未命中| F[网络请求]
    F --> G[更新所有缓存]
    G --> C

    style B fill:#FFE4B5
    style D fill:#E0FFFF
    style E fill:#F0E68C

性能提升：

• 首次搜索：~80ms
• 后续搜索（缓存命中）：~25ms
• 离线模式：~25ms

服务器配置（Nginx）：

location /pagefind/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    gzip on;
}

性能对比

实际数据（500 页文档网站）：

• 首次搜索：下载 45KB，耗时 ~80ms
• 后续搜索：下载 10KB，耗时 ~25ms
• 对比 Lunr.js：减少 97% 的下载量

常见问题

Q: Pagefind 与 Algolia 如何选择？

• Pagefind：中小型网站（< 10,000 页）、免费、离线支持、重视隐私
• Algolia：大型网站、高级功能、极致速度、付费

Q: 支持哪些框架？
框架无关，支持 VitePress、Docusaurus、Hugo、Jekyll、Astro、Next.js（SSG）等任何生成 HTML 的工具。

Q: 是否影响 SEO？
不影响。Pagefind 的搜索 UI 是客户端渲染的，原始 HTML 内容完全不受影响。

Q: 如何更新索引？
每次构建时重新生成索引。在 CI/CD 中使用 postbuild 脚本自动化。

总结

Pagefind 为静态网站提供了轻量、高性能的搜索方案：

• ✅ 轻量级：核心 20KB，按需加载
• ✅ 高性能：搜索响应 < 50ms
• ✅ 零配置：开箱即用
• ✅ 完全静态：无需服务器，支持离线
• ✅ 多语言：内置 CJK 分词

核心原理

1. 倒排索引 + 分片：将索引拆分成 256 个小块
2. 按需加载：根据查询词哈希值只加载相关分片
3. TF-IDF 评分：计算相关性智能排序
4. 多语言分词：支持中英文等智能分词

相关资源

• 官方文档：https://pagefind.app/docs/
• GitHub：https://github.com/CloudCannon/pagefind

在过去一年中，我们见证了多起重大攻击事件，例如 Shai-Hulud 蠕虫攻击、Nx 构建系统被攻破，以及通过 tj-actions/changed-files 漏洞导致机密信息泄露到公开的 GitHub Actions 日志中。但仅仅是罗列各种攻击事件，就足以占据本文的全部篇幅，更不用说深入探讨了。

作为一个行业和生态系统，我们能感受到攻击频率的日益增加。仅在 2024 年，报告的恶意软件包数量就同比增长了 156%。鉴于 Mend 托管的 Renovate Cloud 平台受信于超过 130 万个代码仓库，我们在保护开源软件消费者方面处于非常有利的地位，同时也为自托管 Renovate 的用户提供了更强的安全默认设置。在一系列备受瞩目的 npm 供应链安全攻击之后，Mend Renovate 的维护者们决定，对于选择采纳“最佳实践”配置的用户，默认启用这项安全功能是最佳选择。

为了帮助客户更好地应对这些日益增多的攻击，维护团队正在 Mend Renovate 现有的“最佳实践”配置之上进行构建。该团队一直致力于提供更多“默认即安全”的配置，并首先从 npm 生态系统着手。

在最新的 Mend Renovate 42 版本中，使用“最佳实践”配置的用户将会发现，npm 生态系统中的依赖项更新现在需要通过一个“最短发布时间”的检查，即某个更新发布后必须经过 3 天的窗口期，Mend Renovate 才会提议进行更新。通过这种方法，组织可以确保只有经过验证的、稳定的和值得信赖的依赖项更新才能进入生产环境，从而在保持开发者效率的同时，最终降低供应链攻击的风险。

这有何帮助？
尽管影响广泛，但这些攻击通常利用了两种常见情况：

• 依赖项的精确版本未被锁定。
• 依赖项的精确版本已被锁定，但我们在其发布后极短时间内就尝试更新。

不锁定依赖项版本可能有其合理的原因。例如，在 npm 生态系统中，当你发布一个拥有若干依赖项且被许多其他包所依赖的包时。

如果每次你提升一个依赖版本都需要发布自己的包，那么所有依赖于你的包也同样需要提升版本并发布新版，从而在整个生态系统中引发连锁效应。

其中一些过程可以通过自动化来简化——自然是使用像 Mend Renovate 或 GitHub 的 Dependabot 这样的工具，但这仍然需要一定程度的人工审查。

与此同时，不锁定我们的依赖项可能会导致问题，用户可能会立即开始下载一个包的新版本。
在推荐锁定依赖版本后，下一个问题是我们应该多久更新一次。许多工具中现有的默认设置是“一旦有新版本就立即更新”，这可能导致一个恶意升级在其发布几分钟内就被创建为拉取请求 (Pull Request)。

尽管那个恶意的依赖项可能不会进入您开发人员的机器——但它有可能从您的自动化构建管道中窃取机密或其他特权信息——或者利用您 AI 驱动的代码审查工具中的提示注入漏洞。

如果我们增加软件包发布与它出现在您项目的拉取请求中的时间间隔，这就为安全研究人员和自动化安全工具提供了更多时间来发现软件包中的恶意意图，从而减少供应链攻击的可能性。
Mend Renovate 如何助力保障整个生态系统的安全

如上所述，在 Mend Renovate 的最新版本中，我们为所有使用“最佳实践”配置的用户启用了“最短发布时间”检查的强制执行。这适用于更新任何使用 npm 数据源的包，无论其使用的是何种 JavaScript/TypeScript 包管理器。

这项强制执行将：

• 确保给定的依赖项更新包含其发布时间的元数据（“发布时间戳”）。
• 确保在该版本发布后未满最少 3 天之前，不会创建任何分支。

如果发现不满足此要求的包更新，Mend Renovate 的依赖项仪表板中将包含一个“等待状态”的条目，并且需要人工明确请求才能更新——从而确保只有“安全”的包更新才会被提出。

（这里的一个告诫是，增加等待时间并不一定意味着所有问题都能被发现——由于针对性攻击或复杂的规避技术，所有问题可能无法都被捕获。）

通过将此功能直接添加到我们的“最佳实践”配置中，那些已经选择遵循行业最佳实践的用户将默认受到保护。而其他所有人也能够添加此功能，例如：
codeJSON

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["security:minimumReleaseAgeNpm"]
}

此外，还可以调整此行为——将等待窗口设置得任意长或短——或者对受信任的内部开发包绕过“最短发布时间”功能。

纵深防御
除了让 Mend Renovate 在满足特定条件（即经过一个给定的窗口期）前不发起更新之外，我们还建议建立多层防御：

在可能的情况下，在您的包管理器中启用此功能，以保护开发人员的机器；和/或在您的自动化构建管道中启用此功能，在发布窗口期过去之前使构建失败。

在撰写本文时，pnpm 10.6 和 yarn 4.2.0 已添加了对这些功能的支持，我们也看到其他包管理器正在考虑添加类似功能。

下一步计划？
继此版本的工作之后，维护团队将继续研究其他包生态系统，以便为我们的“最佳实践”配置启用相应功能，从而进一步保障面向消费者的产品和内部开发环境的安全！

在过去一年中，我们见证了多起重大攻击事件，例如 Shai-Hulud 蠕虫攻击、Nx 构建系统被攻破，以及通过 tj-actions/changed-files 漏洞导致机密信息泄露到公开的 GitHub Actions 日志中。但仅仅是罗列各种攻击事件，就足以占据本文的全部篇幅，更不用说深入探讨了。

作为一个行业和生态系统，我们能感受到攻击频率的日益增加。仅在 2024 年，报告的恶意软件包数量就同比增长了 156%。鉴于 Mend 托管的 Renovate Cloud 平台受信于超过 130 万个代码仓库，我们在保护开源软件消费者方面处于非常有利的地位，同时也为自托管 Renovate 的用户提供了更强的安全默认设置。在一系列备受瞩目的 npm 供应链安全攻击之后，Mend Renovate 的维护者们决定，对于选择采纳“最佳实践”配置的用户，默认启用这项安全功能是最佳选择。

为了帮助客户更好地应对这些日益增多的攻击，维护团队正在 Mend Renovate 现有的“最佳实践”配置之上进行构建。该团队一直致力于提供更多“默认即安全”的配置，并首先从 npm 生态系统着手。

在最新的 Mend Renovate 42 版本中，使用“最佳实践”配置的用户将会发现，npm 生态系统中的依赖项更新现在需要通过一个“最短发布时间”的检查，即某个更新发布后必须经过 3 天的窗口期，Mend Renovate 才会提议进行更新。通过这种方法，组织可以确保只有经过验证的、稳定的和值得信赖的依赖项更新才能进入生产环境，从而在保持开发者效率的同时，最终降低供应链攻击的风险。

这有何帮助？
尽管影响广泛，但这些攻击通常利用了两种常见情况：

• 依赖项的精确版本未被锁定。
• 依赖项的精确版本已被锁定，但我们在其发布后极短时间内就尝试更新。

不锁定依赖项版本可能有其合理的原因。例如，在 npm 生态系统中，当你发布一个拥有若干依赖项且被许多其他包所依赖的包时。

如果每次你提升一个依赖版本都需要发布自己的包，那么所有依赖于你的包也同样需要提升版本并发布新版，从而在整个生态系统中引发连锁效应。

其中一些过程可以通过自动化来简化——自然是使用像 Mend Renovate 或 GitHub 的 Dependabot 这样的工具，但这仍然需要一定程度的人工审查。

与此同时，不锁定我们的依赖项可能会导致问题，用户可能会立即开始下载一个包的新版本。
在推荐锁定依赖版本后，下一个问题是我们应该多久更新一次。许多工具中现有的默认设置是“一旦有新版本就立即更新”，这可能导致一个恶意升级在其发布几分钟内就被创建为拉取请求 (Pull Request)。

尽管那个恶意的依赖项可能不会进入您开发人员的机器——但它有可能从您的自动化构建管道中窃取机密或其他特权信息——或者利用您 AI 驱动的代码审查工具中的提示注入漏洞。

如果我们增加软件包发布与它出现在您项目的拉取请求中的时间间隔，这就为安全研究人员和自动化安全工具提供了更多时间来发现软件包中的恶意意图，从而减少供应链攻击的可能性。
Mend Renovate 如何助力保障整个生态系统的安全

如上所述，在 Mend Renovate 的最新版本中，我们为所有使用“最佳实践”配置的用户启用了“最短发布时间”检查的强制执行。这适用于更新任何使用 npm 数据源的包，无论其使用的是何种 JavaScript/TypeScript 包管理器。

这项强制执行将：

• 确保给定的依赖项更新包含其发布时间的元数据（“发布时间戳”）。
• 确保在该版本发布后未满最少 3 天之前，不会创建任何分支。

如果发现不满足此要求的包更新，Mend Renovate 的依赖项仪表板中将包含一个“等待状态”的条目，并且需要人工明确请求才能更新——从而确保只有“安全”的包更新才会被提出。

（这里的一个告诫是，增加等待时间并不一定意味着所有问题都能被发现——由于针对性攻击或复杂的规避技术，所有问题可能无法都被捕获。）

通过将此功能直接添加到我们的“最佳实践”配置中，那些已经选择遵循行业最佳实践的用户将默认受到保护。而其他所有人也能够添加此功能，例如：
codeJSON

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["security:minimumReleaseAgeNpm"]
}

此外，还可以调整此行为——将等待窗口设置得任意长或短——或者对受信任的内部开发包绕过“最短发布时间”功能。

纵深防御
除了让 Mend Renovate 在满足特定条件（即经过一个给定的窗口期）前不发起更新之外，我们还建议建立多层防御：

在可能的情况下，在您的包管理器中启用此功能，以保护开发人员的机器；和/或在您的自动化构建管道中启用此功能，在发布窗口期过去之前使构建失败。

在撰写本文时，pnpm 10.6 和 yarn 4.2.0 已添加了对这些功能的支持，我们也看到其他包管理器正在考虑添加类似功能。

下一步计划？
继此版本的工作之后，维护团队将继续研究其他包生态系统，以便为我们的“最佳实践”配置启用相应功能，从而进一步保障面向消费者的产品和内部开发环境的安全！

作为开发者，我们已经习惯了使用 Claude Code、Cursor、GitHub Copilot。但这些工具都有一个共同的局限——它们只能读写文件，不能真正控制你的电脑。

我开发了 xAgent CLI，因为我想拥有一个能帮我搞定一切的 AI 助手。

xAgent CLI 是什么？

xAgent CLI 是世界上首个结合顶尖 AI 模型与真·GUI 自动化的开源助手。它不只是会读写文件，而是能真正控制你的鼠标和键盘。

核心特性

🖱️ 真·GUI 自动化

与传统 AI 工具不同，xAgent CLI 能直接控制你的桌面：

xagent gui --url https://example.com/login
点击坐标 (500, 300) 的登录按钮
在用户名框输入 "myemail@example.com"
按 Tab 键切换到密码框
输入密码
点击提交按钮

这意味着：

• 浏览器自动化操作
• 网页表单自动填写
• UI 测试
• 跨应用操作
• 工作流自动化

🧠 顶尖模型免费用

开箱即用，免费访问世界顶级模型：

无需 API Key，无限使用。

💻 开发者友好

• 上下文感知的代码分析
• 自动识别项目架构
• SubAgent 系统处理复杂任务
• 中断后对话恢复

🏠 生活助手

整理我的桌面，按类型分类文件
设置每天自动备份到云盘
下载这个页面上所有 PDF
查找并删除重复文件

🔒 安全可控

提供 5 种执行模式，满足不同安全需求：

快速开始

npm i -g @xagent-ai/cli
xagent start

支持 Windows、macOS、Linux。

结语

xAgent CLI 代表了 AI 助手的新范式——从"读写文件"到"真正干活"。它是开源的、免费的，并且尊重你的隐私。

项目链接：

• GitHub: https://github.com/xAgent-AI/xagent
• NPM: https://npmjs.com/package/@xagent-ai/cli