---
title: 用了 10 年 WordPress，我为什么决定为外贸网站自研技术栈
slug: farewell-wordpress
date: 2026-01-26
author: Frankie 徐
category: wordpress
tags: ['wordpress', 'static-site', 'automation', 'multilingual', 'architecture']
description: 用了 10 年 WordPress，最终决定为外贸网站自研一套技术栈。不是因为 WP 不好，而是我想做点不一样的事情。
permalink: https://www.210k.cc/farewell-wordpress
---

## 不是 WordPress 不够好，是我想做点不一样的

### 缘起

用了 10 年 WordPress。

从 2015 年第一次搭建博客，到后来做外贸网站、企业官网、产品展示站，WordPress 一直是我的首选。

直到最近，我做了一个决定：放弃 WordPress，自己造一套东西。

为什么？

**不是因为 WordPress 不好，而是我想知道：如果从零开始，我会怎么设计一个外贸网站系统？**

---

### 起点：重新定义"网站"

某个周末，我决定重构用了 8 年的 WordPress 网站。

不是因为它有问题，而是我突然意识到：**我可能从来没有真正思考过"我需要什么"。**

我的外贸网站：
- 多语言（目前 7 种，随时可扩展到 20+）
- 每周更新 2-3 次内容
- 主要流量来自 Google 自然搜索
- 没有用户系统、没有评论、没有复杂交互

**这样一个网站，真的需要 PHP + MySQL + 插件生态吗？**

我开始问自己一个问题：

**如果让我用代码，从头定义一个"内容网站"，我会怎么做？**

---

### 思考：我到底想要什么？

#### 1. 内容应该是文件，不是数据库记录

WordPress 把内容存在数据库里。这很合理，但不适合我。

我想要的是：
```sh
content/
├── about.md
├── products/
│   ├── product-a.md
│   └── product-b.md
└── blog/
    ├── 2025-01-20-post.md
    └── 2025-01-25-post.md
```

- 每个文件就是一个页面
- 支持版本控制（Git）
- 可以用任何编辑器打开
- 可以批量处理（脚本、AI）

**内容即代码。**

#### 2. 多语言应该是自动化的，不是手工复制粘贴

WordPress 的多语言插件让我每次更新都要重复 7 遍。

我想要的是：
```bash
# 写好英文版
echo "New product launched" > product-new.en.md

# 运行脚本
./translate.sh product-new.en.md

# 1 分钟后，所有语言全部生成（想加多少语言就加多少）
✓ product-new.es.md
✓ product-new.fr.md
✓ product-new.de.md
✓ product-new.ja.md
✓ product-new.ko.md
✓ product-new.pt.md
✓ product-new.zh.md
✓ product-new.ar.md  # 需要阿拉伯语？改个配置就行
```

**翻译不应该是体力活。语言数量也不应该是限制。**

#### 3. 构建应该是确定性的，不是每次都可能出问题

WordPress 每次访问都要执行一遍渲染逻辑。这意味着：
- 插件冲突可能随时发生
- 数据库查询可能随时变慢
- 某个环节出错，整站挂掉

我想要的是：
```bash
# 构建一次
bun run build

# 生成所有页面（HTML + CSS + 资源）
dist/
├── en/
│   ├── index.html
│   ├── about/index.html
│   └── products/...
├── es/
│   ├── index.html
│   └── ...
└── ...

# 部署到 CDN
# 之后每次访问，都是直接返回这些文件
# 没有运行时，没有变数
```

**构建时确定一切，运行时零意外。**

#### 4. 速度应该是物理极限，不是"还能接受"

WordPress 的 TTFB（Time to First Byte）通常在 1-3 秒。

我想要的是：
- 访客请求 → CDN 边缘节点直接返回 HTML
- 没有数据库查询
- 没有服务端计算
- TTFB < 100ms（物理延迟）

**速度不应该被软件拖累。**

---

### 实现：我做了什么？

我没有用现成的框架直接替换 WordPress。

我基于一些开源工具，搭建了一套**适合我自己的系统**。

#### 核心架构

**内容层**：
- Markdown 文件 + Frontmatter（元数据）
- Git 版本控制
- 本地编辑器（VSCode + Vim）

**构建层**：
- 静态站点生成器（SSG）
- 自定义构建脚本（Bun + TypeScript）
- AI 翻译流水线（多模型策略：不同语言用不同 LLM）

**部署层**：
- Cloudflare 边缘网络（全球 300+ 节点）
- 自动化构建（Git Push → Auto Deploy）
- 零运维（没有服务器可以挂）

#### 翻译自动化

这是最关键的部分。

我写了一套翻译系统：

```javascript
// translate.ts（简化版）
async function translateContent(file: string) {
  const content = readFile(file);
  const languages = ['es', 'fr', 'de', 'ja', 'ko', 'pt', 'zh'];

  for (const lang of languages) {
    // 检查是否已翻译过（缓存）
    if (cacheExists(file, lang)) {
      console.log(`✓ ${lang} (cached)`);
      continue;
    }

    // 调用 AI 翻译（不同语言用不同模型）
    const translated = await aiTranslate(content, {
      targetLang: lang,
      preserveFormat: true, // 保留 Markdown 格式
      context: 'B2B SaaS product page' // 给 AI 上下文
    });

    // 保存翻译结果
    writeFile(`${file}.${lang}.md`, translated);
    console.log(`✓ ${lang} (translated)`);
  }
}
```

**工作流**：
1. 用 Markdown 写英文内容
2. 运行 `bun run translate`
3. 脚本智能选择模型翻译成所有目标语言（日语用 Claude、西语用 GPT-4o...）
4. 人工校对关键页面（首页、产品页）
5. Git Push → 自动部署

**语言扩展**：
- 想加新语言？配置文件里加一行，重新翻译即可
- 不同语言可以用不同的模型（质量 + 成本平衡）
- 整个架构完全灵活，没有硬编码限制

**效率**：
- 之前：2 小时手动复制粘贴
- 现在：1 分钟自动完成

#### 构建流程

```bash
# 1. 读取所有 Markdown 文件
# 2. 解析 Frontmatter 和内容
# 3. 按语言分组
# 4. 生成 HTML（每种语言独立站点）
# 5. 优化资源（压缩、缓存策略）
# 6. 输出到 dist/

bun run build

# 输出结构：
dist/
├── en/
│   ├── index.html
│   ├── products/product-a/index.html
│   └── ...
├── es/
├── fr/
└── ...
```

**特点**：
- 每次构建输出完全一致（确定性）
- 所有页面预渲染（零运行时）
- 支持增量构建（只重新生成变更的页面）

#### 部署

```bash
# Git Push 后，Cloudflare 边缘网络自动：
# 1. 拉取代码
# 2. 运行 bun run build
# 3. 分发到全球 300+ 边缘节点
# 4. 更新路由（零停机）

# 整个过程 2 分钟，感谢赛博活佛的慷慨
```

---

### 结果：能做什么？

#### 1. 内容管理

- 用 Markdown 写内容（比 WordPress 编辑器更快）
- 所有内容版本化（Git 历史）
- 支持批量修改（脚本 + 正则）

#### 2. 多语言

- 写一份英文，自动生成任意数量语言（配置即可扩展）
- 每种语言独立 URL（SEO 友好）
- 支持手动覆盖（AI 翻译不准时）
- 不同语言智能选择最适合的模型

#### 3. 性能

- Lighthouse 评分 98/100
- TTFB < 100ms（全球任意位置）
- LCP < 0.5s（首屏渲染）

#### 4. 开发体验

- 本地修改 → 热重载（< 100ms）
- 构建速度快（10,000 页面 < 30 秒）
- 零配置（一个配置文件搞定）

---

### 代价：失去了什么？

公平起见，说说这套系统的局限：

#### 1. 不适合高频更新

如果你每小时都要发布新内容，静态生成可能不够灵活。

但对于外贸网站、企业官网、产品展示站？完全够用。

#### 2. 需要一点技术能力

不是点点鼠标就能搞定。

你需要：
- 会用 Git（至少会 `git add / commit / push`）
- 会写 Markdown（5 分钟学会）
- 会运行脚本（复制粘贴命令）

但如果你是工程师，这些应该是基础技能。

#### 3. 动态功能需要外接

- 评论系统？用 Giscus（基于 GitHub Discussions）
- 搜索功能？用 Pagefind（静态索引）
- 表单提交？用 Cloudflare Workers

但这恰恰是我想要的：**用专业的服务做专业的事，而不是把所有功能塞进一个系统里。**

---

### 反思：为什么要造轮子？

有人可能会问：**市面上有那么多静态站点生成器（Astro、Next.js、Hugo），为什么要自己造轮子？**

答案很简单：

**因为我想知道"如果是我"会怎么做。**

我不是说现有工具不好，而是：
- 我想要完全理解每一层的工作原理
- 我想要完全控制构建和部署流程
- 我想要为我的场景（外贸网站 + 多语言）定制优化

**更重要的是：现在的时机刚刚好。**

最近 vibe coding（AI 辅助编程）特别火。

以前造轮子需要几个月，现在可能只要几个周末：
- 不会写构建脚本？问 Claude / GPT
- 不懂某个 API？AI 直接给你写好示例
- 遇到 bug？AI 帮你 debug

**AI 让"实现自己的想法"变得前所未有的容易。**

你不再需要成为每个领域的专家，你只需要：
- 知道自己想要什么
- 会描述清楚需求
- 能理解和调试代码

**这就是为什么我选择现在动手的原因。**

**造轮子不是为了"更好"，而是为了"学习"和"掌控"。而 AI 降低了这件事的门槛。**

---

### 适合谁？

这套系统适合：
- 工程师（至少会基本的命令行和 Git）
- 内容驱动型网站（博客、官网、文档站）
- 多语言需求（翻译自动化是核心优势）
- 追求极致性能和可靠性

不适合：
- 非技术用户（没有可视化界面）
- 高频更新内容（新闻站、社交平台）
- 复杂动态功能（会员系统、实时聊天）

---

### 写在最后

这不是一篇"教你怎么做"的文章。

因为我也不知道这套系统能用多久，或者未来会怎么演化。

但我知道一件事：

**有些事情，你只有自己做过，才会真正理解。**

WordPress 是一个伟大的项目，它让数百万人拥有了自己的网站。

但对于我来说，**现在是时候探索别的可能性了。**

---

### 技术细节

如果你对实现细节感兴趣：
- 翻译脚本：不同语言用不同的大模型（GPT-4o、Claude、Gemini 灵活切换）+ 缓存机制
- 构建工具：基于开源 SSG + 自定义插件
- 部署平台：Cloudflare 边缘计算，赛博活佛的慷慨免费额度