标签 静态网站 下的文章

首先在服务器管理器内安装 Web 服务器(IIS)

image
打开 IIS 管理器

image
在网站选项卡下右键添加网站

image
网站名称:自己随便写,这个只是显示在 IIS 中使用的
物理路径:本地网页文件的路径
绑定
类型:http 和 https
IP 地址:默认就全部未分配
端口:默认 80
主机名:如果只有一个网站可以不填,如果有多个网站那就在这里填域名

image
对着网站右键浏览即可打开资源管理器

image
将静态网页文件放入网站目录下

image
访问正常

如果主页文件不叫index.html,可以在默认文档处修改

image
选中网站,双击默认文档

image
添加你的文档,然后调整优先级即可

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 属性

属性说明
data-pagefind-body标记要索引的主要内容区域
data-pagefind-ignore排除该元素及其子元素
data-pagefind-meta添加自定义元数据
data-pagefind-filter定义可过滤的字段
data-pagefind-sort定义可排序的字段
data-pagefind-weight设置内容权重(1-10)

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 个

性能分析:

阶段耗时说明
用户输入 + 防抖300ms等待用户完成输入
分词 + 哈希计算<5ms纯计算,无 I/O
加载索引分片20-50ms取决于网络和缓存
索引查询 + 评分5-10ms纯内存操作
加载内容片段15-30ms取决于网络和缓存
摘要生成 + 渲染5-10msDOM 操作
总计(首次)~80ms不含防抖延迟
总计(缓存)~25ms索引和片段均已缓存

核心技术解析

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
缓存层级命中延迟容量适用场景
L1 内存缓存<1ms~10MB频繁访问的索引(LRU 淘汰)
L2 HTTP 缓存~5ms~100MB已访问的所有索引(Cache-Control)
L3 Service Worker~10ms~50MB离线访问(可选)
网络请求50-200ms-首次访问

性能提升

  • 首次搜索:~80ms
  • 后续搜索(缓存命中):~25ms
  • 离线模式:~25ms

服务器配置(Nginx):

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

性能对比

方案初次加载索引大小 (1000页)搜索速度离线支持
Pagefind~20KB~500KB<50ms
Algolia0 (CDN)N/A<10ms
Lunr.js~30KB~3MB~100ms

实际数据(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. 多语言分词:支持中英文等智能分词

相关资源

这里记录每周值得分享的科技内容,周五发布。

本杂志开源,欢迎投稿。另有《谁在招人》服务,发布程序员招聘信息。合作请邮件联系[email protected])。

封面图

巫山县城建在山坡上,为了方便居民和促进观光,在中轴线上建设了神女大扶梯,总长905米,高240余米,相当于80层楼,全程需要20分钟。(via

独立软件的黄昏

软件可以分成两种:一种是公司开发的,另一种是个人开发的。后者就称为"独立软件"(indie software)。

它的历史非常悠久,从古至今,很多程序员依靠出售独立软件谋生。

有一种东西"共享软件"(Shareware),年轻的朋友未必知道,二三十年前曾经非常流行。用户免费使用软件的试用版,如果满意,就向开发者购买一个注册码。

这就是一种独立软件,当年很多著名软件都是这个模式,比如国外的 WinZip 和 WinRAR,国内的网络蚂蚁(NetAnts)、网际快车(FlashGet)、豪杰解霸。

时至今日,大家看看目前流行的软件,还有多少属于独立软件?你每天使用的软件,又有多少是个人开发的?

很少很少了。

一位二十年的独立软件开发者哀叹现在的市场上,公司开发的比重越来越大,个人开发的比重越来越小,独立软件正在没落。

"我销售自己的软件20年了,2005年以后,互联网开始普及,独立软件迎来了黄金年代。而最近两三年,环境一直在快速变化,销售明显变难了,我感觉自己越来越难维持生计了。"

独立软件的大发展,是从2005年开始的。

  1. 互联网的普及,网民数量急剧增长。
  2. 智能手机创造了手机软件,一个全新的软件大市场。
  3. 在线支付的普及和简化。
  4. 互联网使软件分发变得容易且免费。
  5. 免费的高质量开发工具(编译器、IDE、版本控制系统、Web 服务器)不断涌现。

这些因素让程序员切切实实获利了,要是你再做一些 SEO、买一些付费广告,完全可能赚到大钱。很多人就是这样发展起来的,从独立软件变成了大公司。

但是,最近两三年情况变了,上面这些因素都到头了。

独立软件正在慢慢退潮,你能够想起名字的独立软件越来越少,更不要说掏钱购买了,即使有也是多年前的作品。根据我的观察,依靠出售自己软件维生的程序员似乎也在减少。

主要原因有下面几个。

(1)AI 改变了互联网流量,独立软件失去了推广渠道。网站的访问量显著减少,人们更多跟大模型交互,而不是浏览网页。通过搜索引擎和在线广告获取流量的策略,越来越没有效果。

视频是为数不多仍然有效的推广渠道之一,但制作视频非常耗时,而且竞争异常激烈。另外,AI 生成的劣质视频迟早会大量出现,推广效果也会变差。

(2)AI 使得软件开发变得容易。它加快了开发速度,降低了进入门槛,让更多人加入竞争。以前,用户可能购买某个功能,现在直接让 AI 生成即可。

(3)新软件汗牛充栋,越来越难脱颖而出。iPhone 应用商店有大约200万个应用,用户很难发现你。另一方面,应用商店更喜欢推广那些能帮它赚更多钱的大公司软件,而不是独立软件。

(4)人们越来越习惯使用基于网络的软件,独立软件属于需要下载安装的原生应用,它的市场在萎缩。

基于网络的软件与其说是产品,不如说是一种服务,全天候24小时可用的服务。越来越多的个人开发者顺应这种趋势,改为以提供 SaaS 服务为主。

(5)平台的风险。现在的很多独立软件,都依靠云服务商的平台或底层服务,而平台随时会改变规则(比如关闭 API),或者推出竞品,一大批应用随之死掉,这种事情屡见不鲜。

(6)用户期望软件是免费的,或者非常便宜。售价略微高一点,就会无人问津。因此,独立软件要想获得可观的回报,就需要巨大的销售规模,这根本做不到。别的不说,个人开发者完全无力提供满意的客服。

(7)以上这些因素将长期存在,只会加深,不会逆转。独立软件的时代可能真的要结束了,个人开发者以后大概很难靠销售自己的软件为生,而要改为销售自己维护的 SaaS 服务,尽管这也很难。

科技动态

1、VS Code 的定位

微软公司的 VS Code 是非常流行的代码编辑器,市场份额很高。

现在的官网上,它的产品定位是"开源 AI 代码编辑器"。

但是,2025年上半年,它的产品定位还是"你的代码编辑器,由 AI 重定义"。

更早的2024年,产品定位是"重新定义的代码编辑"。

令人感慨啊,这么成功的软件,AI 本来只是附属功能,现在也要蹭热点,把自己包装成 AI 主导的产品。

2、智能脖巾

英国科研人员发明了一种智能脖巾。它围在脖子上,可以感受到穿戴者的心跳和喉部肌肉运动。

它的用户主要是中风后丧失说话能力的人。这些人可以张嘴,做出说话的口型,但是无法正常发音。

他们佩戴这个脖巾后,颈部的运动数据就通过它传给电脑,经过模型训练,可以用电脑语音还原出用户想说的话。

3、雪宝机器人

人形机器人何必一定做成人形。

迪斯尼最近发布了一个机器人,样子就是电影《冰雪奇缘》的雪宝。

它用来在迪斯尼乐园,跟游客互动。

它启示我们,人形机器人做成卡通形状也很好。

另外,LG 公司在美国 CES 展会上,展示了他们最新的家务机器人

这个机器人的功能就是做家务,比如叠衣服和洗碗。我觉得,国内厂商可以借鉴,展示机器人功能时,不要展示跳舞打拳,而要展示如何做家务。

文章

1、别用 MySQL,改用 MariaDB(英文)

曾经的明星数据库 MySQL,最近几个月的代码提交数为0(上图)。作者认为,种种迹象表明甲骨文已经放弃了这个项目。

2、10秒获得 AI 代码评审结果(英文)

本文介绍一个技巧,让 AI 快速给出提交代码的评审结果,方法是不要提交整个代码库,只提交 diff 的部分。

3、使用 Pandoc 生成静态网站(英文)

文档格式转换工具 Pandoc 可以用来生成静态网站,作者介绍自己是怎么做的。

4、锚点元素<a>的一些鲜为人知的地方(英文)

锚点元素<a>用来生成链接,本文介绍如果链接到一些特殊字符的情况。

5、学习自定义元素(英文)

一篇 HTML 自定义元素的教程文章,写得简单清晰。

6、Go、Rust 和 Zig 的一些想法(英文)

作者是一个高级程序员,谈谈他对 Go、Rust、Zig 三种语言的感受。有趣的地方是,这三种语言都没有类,也不支持面向对象编程。

7、我的个人基础设施(英文)

作者介绍他自己的家庭实验室。比较有趣的是,他的个人网站是本地构建后,自动用 Syncthing 同步到服务器,这对小型静态网站确实简单。

工具

1、GoRead

开源的电子书阅读器应用,支持桌面与移动端(Android/iOS)。(@zhashut 投稿)

2、EasyPostman

用于 API 调试的跨平台桌面应用,对标 Postman + JMeter。(@lakernote 投稿)

3、Port Sentinel(端口哨兵)

Windows 桌面应用,查看端口占用情况。(@Sanjeever 投稿)

4、Building Sunlight Simulator

基于 Web 的楼盘采光 3D 日照模拟工具,帮助购房者评估小区采光。(@SeanWong17 投稿)

5、Office App

一个纯本地的 Office 网页应用,可以离线在网页创建/编辑 Word、Excel、PowerPoint 文件。(@baotlake 投稿)

6、ScreenshotSnap

免费的网站截屏在线工具,提供 API,可以直接将截图代码插入网页。(@phpiscute 投稿)

7、tsshd

SSH 服务器登录协议的全新实现,特点是连接不掉线,可以重连前一个对话。(@lonnywong 投稿)

8、AirScan-QR

一个开源网页应用,通过动态二维码发送/接收文件。(@topcss 投稿)

9、LuCI Bandix

开源路由器操作系统 OpenWRT 的一个插件,可以监控局域网各设备的实时流量和目的地。(@timsaya 投稿)

10、pure-genealogy

开源的网页族谱工具,用来生成家族族谱,基于 Next.js + Supabase。(@yunfengsa 投稿)

11、mdto.page

这个网站免费将 Markdown 文件转成 HTML 格式,发布成公开访问的网页。

AI 相关

1、ChatGPT 翻译

OpenAI 悄悄发布的翻译功能,只有在官网可用。

2、Mango Desk

一个跨平台的桌面应用,使用自然语言进行本地文件搜索。(@moyangzhan 投稿)

3、OpenWork

Claude 公司新产品 CoWork 的开源替代品,让普通用户不编程,就能完成文件操作,定位就是"Claude Code 的非编程版"。

另有一个类似项目 Open Claude Cowork。(@aiagentbuilder 投稿)

4、Wolfcha(猹杀)

开源的网页游戏 AI 狼人杀,除了玩家自己,其他所有角色(女巫、猎人、守卫、狼人等)都由 AI 扮演。(@oil-oil 投稿)

资源

1、维基百科25周年

维基百科是2001年1月13日上线的,今年是25周年纪念。这个网站是官方的纪念网站,以互动形式展示了发展历程。

另外,还有一篇文章,介绍互联网档案馆的历史(下图)。

2、HTTP:COLON

这个网页可以查看指定网站返回的 HTTP 标头,详细解释每个字段的含义。

3、现代 Java(Modern Java)

面向初学者的 Java 语言教程。

图片

1、中国新能源建设的惊人规模

90后摄影师储卫民拍摄的中国新能源建设。

他说:"从地面上很难体会这些发电厂的规模,但当你升到空中时,就能看到它们与山脉、沙漠和海洋之间的关系。"

青海冷湖镇

浙江象山县

青海塔拉滩

内蒙古阿拉善

"我一开始只是拍摄风景,但2022年我去贵州、云南、青海等地旅行时,不断看到风力发电场和太阳能发电厂出现在我的镜头里。我意识到这就是我们这个时代的故事----但几乎没有人系统地记录它。"

文摘

1、谷歌14年工作的教训

大约14年前,我加入谷歌,以为这份工作就是编写优秀的代码。

这个想法部分正确。但随着时间的推移,我越来越意识到,真正成功的工程师不一定是最优秀的程序员,而是懂得驾驭代码之外一切的人。

下面就是我得到的经验教训。有些教训是我走了几个月的弯路得到的,还有一些需要数年才完全领悟。它们都与具体的技术无关----技术变化太快,根本无关紧要。

(1)工程师想在大公司生存,必须学会沟通。

因为在大公司,团队是组织的基本单位,推进项目必须跟其他团队沟通。项目越大,你花在跟其他人、其他团队沟通的时间就越多,比编写代码的时间还多。大多数"慢"的团队实际上是不沟通的团队。

为了顺利沟通,清晰是第一位的要求。它不仅可以加快沟通,还能降低代码风险。最优秀的工程师都会用清晰易懂的代码来代替炫技。

为了提高表达的清晰性,你可以尝试写作和去教别人。如果你能用简单的语言解释某件事,你就是真的理解它了。

(2)想要得到晋升,必须有人为你说话。

职业生涯初期,我曾认为优秀的工作成果代表了一切,但我错了。代码默默地躺在代码库里,不会为你说话。

那些对你至关重要的会议,你本人很可能没有机会参加。你需要你的经理、同事在会上提到你、推荐你。他们可能这样做,也可能不会。

平时工作中,你尽量不要为自己增加阻力。如果开会的时候,你赢得每一场辩论,很可能就是在积累无声的阻力。你之所以"赢",不是因为你说服了别人,而是因为他们不再与你争论,放弃了,将会在其他场合表达这种不满。

(3)专注于你能控制的事情,忽略你无法控制的事情。

很多事情,你改变不了,不要为这种事情烦恼。这不是被动接受,而是策略性分配精力。如果你把精力浪费在无法改变的事情上,就等于放弃改变那些原本可以改变的事情。

(4)简化工作往往可以提高绩效。

当系统运行缓慢时,人们的第一反应是增加缓存层、并行处理和更智能的算法。有时这样做没错,但我发现,删除不必要的工作几乎总是更有效果。下次进行优化之前,你要先问问自己这项工作是否应该存在。

(5)时间比金钱更有价值,你要抓紧时间。

职业生涯初期,你用时间换取金钱,各种事情都做----这无可厚非。但到了某个阶段,情况就完全不同了,你会开始意识到,时间才是不可再生资源。你要专注于那些对你最重要的事情,放弃其他事情。

言论

1、

-- 一位程序员评论 OpenAI 宣布在 AI 对话中加入广告

2、

Netflix 的电影不追求视觉效果,因为大多数观众是在手机、平板和笔记本电脑上看,内容不需要为大银幕制作、而是为小屏幕制作的。

-- 马特·达蒙,美国著名演员

3、

我从未见过哪个群体比程序员更热衷于分享知识。其他行业都是严守知识、保守秘密,程序员则是免费提供源代码、书籍、博客文章、演示文稿、视频教程等等。

编程领域没有什么神圣不可侵犯的东西。如果你想学习,你可以找到免费书籍、完整的源代码、论坛、聊天室、邮件列表、线下聚会、博客文章、视频讲座、教程以及你可能需要的一切资源。尽管举手,总会有人乐于助人,倾囊相授。

-- 《我是如何学习所有编程知识的》

4、

今年的 iOS 26 中,一些 UI 元素利用 HDR 屏幕,采用高光,比纯白色更亮。如果你曾经在 iPhone(或其他任何支持 HDR 的屏幕)上看过 HDR 照片,然后再看看以 SDR 模式显示的 UI,你就会知道它看起来有多么灰暗黯淡。

-- 《亮模式的膨胀》,作者发现 iOS 每年都变得更亮,容易产生视觉疲劳,让他不得不使用暗模式

5、

如果你想批评大型组织的运作方式,首先要了解它们为何如此运作。否则,批评会显得尖锐,但却毫无意义。

-- 《关于大型软件公司的常见误解》

往年回顾

年底的未来已来(#335)

为什么 PPT 不如备忘录(#285)

青年失业率与选择创业(#235)

美国宪法拍卖,一个区块链案例(#185)

(完)

个人背景,
之前一直在大厂做项目,对于官网或者网站,停留在读书的时候 Dreamweaver 上了。
(从做产品的角度,我也是推动过一些项目落地的,,^_^)
最近琢磨说如果不用 WordPress 是不是可以给我弟的厂子整个官网,说干就干,
结果真的就在 gemini 的帮助下搓出来了。视觉还不错。

也没用什么复杂的框架,就为了快和省钱,直接手写 HTML/CSS ,部署在了 GitHub Pages 上,域名也是刚绑定的。(实名感谢 github-好用,再次感谢 gemini ,虽然我觉得我在 gemini 上还没真的玩出花来)

这是我的小站: https://wooohu.com 我弟是专门设计时尚女鞋的设计师。
(目前比较简陋,主要是图片展示)

想请教各位大佬几个问题:

  1. 在国内访问速度怎么样?图片加载会不会很慢?(我自己看好像还行)
  2. SEO 方面,除了 Search Console ,针对这种静态站还有什么优化的路子吗?
  3. 设计上有没有什么明显的硬伤?
  4. 如果从做官网的角度,还有什么更好用的方式搭建。
    第一次在这个节点发帖,纯粹是分享一下传统行业拥抱技术的乐趣,希望能得到大家的指点!

感谢!

把之前一直用的 ob 插件 webpage-html-export 魔改了一下,更适合作为个人知识库网站。
用的是 vercel 部署的
插件仓库地址:GitHub - Ryanu9/Obsidian_webpage_export_pro
示例库:
https://myblog-livid-iota.vercel.app/
https://c1trus.top/

感兴趣的佬友可以看看


📌 转载信息
原作者:
ryanu
转载时间:
2026/1/12 10:15:26