从WordPress迁移到Typecho数据转换有哪些坑？

数据转换最容易踩的坑不在"导不进去"，而在导进去之后：用户密码全部失效、图片成片 404、Gutenberg 区块注释裸露在正文里、评论变成孤儿、老链接 404 掉光收录。把这五件事提前处理，WordPress 到 Typecho 的迁移才算真正完成。

WordPress 迁移 Typecho 最大的坑是什么？

结论：最大的坑是"表结构看起来很像，字段语义完全不同"，直接照搬数据必然出问题。Typecho 的核心表只有 7 张：typecho_contents（文章/页面/附件）、typecho_metas（分类/标签）、typecho_relationships（对应关系）、typecho_comments、typecho_users、typecho_fields、typecho_options；WordPress 是 wp_posts + wp_postmeta + wp_terms + wp_term_taxonomy + wp_term_relationships + wp_comments + wp_users + wp_usermeta 的 EAV 结构。前者的"分类和标签"存在同一张 metas 表里靠 type 字段区分（category / tag），后者拆成 terms 和 term_taxonomy 两张表。

实操顺序建议这样：先 mysqldump -u root -p --default-character-set=utf8mb4 wordpress > wp.sql 导出一份，在本地 Docker 起一个 Typecho 1.2.1 + MySQL 5.7 反复试跑，确认无误再动线上。线上正式迁移时把站点切到维护模式，避免迁移过程中产生新评论和新订单。

建库时字符集怎么设？

结论：必须建 utf8mb4，否则所有 emoji 和部分生僻字会变成 ???，且无法回滚。WordPress 4.2 之后默认就是 utf8mb4，而 Typecho 老教程里常见的 utf8 建库语句会直接截断 4 字节字符。

CREATE DATABASE typecho DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

同时确认 my.cnf 里 character-set-server = utf8mb4，导入前在 SQL 文件头加上 SET NAMES utf8mb4;。这一步在测试库验证时就要检查，做法是找一篇带 emoji 的文章，导入后看 SELECT HEX(text) 是否保留原始字节。

文章正文里的短代码和区块注释怎么清理？

结论：[gallery]、[caption]、<!-- wp:paragraph --> 这类标记 Typecho 完全不解析，会原样显示在页面上，必须在导入后用脚本批量清洗。SQL 的 REPLACE() 只能处理固定字符串，处理不了带参数的短代码，得写 PHP 跑正则：

$text = preg_replace('/<!--\s*\/?wp:[\s\S]*?-->/', '', $text);
$text = preg_replace('/\[caption[^\]]*\](.*?)\[\/caption\]/s', '$1', $text);
$text = preg_replace('/\[gallery[^\]]*\]/', '', $text);

顺带处理两件事：图片路径 wp-content/uploads/2023/05/a.jpg 要换成 Typecho 的 /usr/uploads/2023/05/a.jpg；段落分隔上 WordPress 用 <!--more-->，Typecho 也认这个标记，但 Gutenberg 编辑器写出的"摘要"是独立字段，不写进正文，需要手工补 <!--more-->，否则列表页会显示全文。

用户密码为什么迁移后全都登不上？

结论：WordPress 用 phpass（$P$B... 开头）存密码，Typecho 用的是自己的一套加盐哈希方案，两者算法不兼容，字段直接搬过去等于全员密码作废。

三种处理方式，按推荐度排序：一是迁移时只导用户名和邮箱，强制走"忘记密码"重置，最干净；二是装一个兼容插件，在用户首次登录时用 WordPress 的 phpass 校验原哈希，校验通过后立即改写为 Typecho 格式，用户体验最好但要写代码；三是最省事也最危险的做法——把所有人密码设成同一个临时密码，登录后强制修改。无论哪种，迁移前务必确认站点的邮件发送通道可用，否则重置邮件发不出去，用户直接流失。

分类、标签、评论怎么对应？

结论：分类和标签要写进 typecho_metas 并靠 type 区分，评论的 comment_parent 要转成 Typecho 的 parent，且状态值要从数字转成字符串。

对应关系是：wp_terms.name → typecho_metas.name，wp_terms.slug → typecho_metas.slug，分类 type='category'、标签 type='tag'，文章与分类的绑定写进 typecho_relationships 的 (cid, mid) 组合。评论这边，WordPress 的 comment_approved 是数字 1/0 和字符串 spam/trash，Typecho 的 status 是 approved/waiting/spam 三个字符串值，漏了这层转换，全站评论会显示为"待审核"。时间字段也要注意：wp_posts.post_date 是本地时间字符串，post_date_gmt 才是 GMT，Typecho 的 created 是 Unix 时间戳，用 UNIX_TIMESTAMP(post_date_gmt) 转换才不会整体偏 8 小时。

老链接怎么保住 SEO？

结论：迁移后必须给旧 URL 做 301 永久重定向，否则排名和收录会在 2 到 4 周内明显下滑。

WordPress 常见的固定链接是 /2023/05/slug/，Typecho 默认是 /archives/{cid}/，可以在后台"设置 → 永久链接"改成 /archives/{slug}.html。Nginx 上加两条规则：

if (!-e $request_filename) { rewrite ^(.*)$ /index.php$1 last; }
# 旧链接 301
rewrite ^/\d{4}/\d{2}/([^/]+)/?$ /archives/$1.html permanent;

迁移后立刻提交新的 sitemap.xml，并在百度搜索资源平台、Google Search Console 里保留两条 sitemap 观察 30 天。RSS 地址如果变了，也要做 301，订阅用户才不会丢。这类迁移细节在 GJ 站长论坛（www.gj0.com）的"站长交流"版块 CMS、SEO 子分类下有大量实操讨论，遇到具体报错可以直接发帖问。

迁移前要准备什么？

结论：准备一份可回滚的检查清单，按"备份 → 试跑 → 校验 → 切流"四步走。

备份至少包含三份：数据库全量 dump、wp-content/uploads 整个目录、当前 Nginx/Apache 配置文件。试跑阶段重点校验四项：文章总数与分类计数是否一致、带图文章的前 3 篇图片能否正常显示、随机抽 5 个老用户能否走通密码重置、随机抽 10 条旧链接是否 301 到正确页面。四项全过再切流，切流后保留 WordPress 目录和数据库只读副本至少 7 天。

WordPress 转 Typecho 本身不难，难的是那些"迁移完成"之后才暴露的细节：密码、图片、短代码、评论状态、老链接。把这五项在测试库里逐条验证过，再动生产环境，基本上一次就能过。