将 WordPress 主题迁移到 Astro 与 EmDash
实用的主题迁移思路：把 WordPress 主题视为前端与内容模型翻译项目，而非逐文件代码搬运。
将 WordPress 主题迁到 EmDash，不应从「找一一对应的模板」开始。
这种做法往往会把过多旧耦合一并带过去。WordPress 主题常常把展示、CMS 假设、辅助逻辑与副作用混在一起——在历史上说得通，但在现代前端栈里会变得别扭。
更好的做法是先把主题实际在做什么拆开来看。
从主题的真实职责入手
在写任何 Astro 代码之前，先用平实语言盘点当前主题。
需要识别：
- 页面类型
- 共用布局
- 导航模式
- 归档行为
- 可复用 UI 组件
- 主题特有的数据需求
这样你就有一张「哪些必须重建、哪些可以简化」的地图。
翻译的是行为，不是文件
在 EmDash 里，有意义的单位不是某个 WordPress 主题文件，而是最终呈现出来的体验。
在 Astro 与 EmDash 中，典型主题会变成：
- 各页面类型的路由
- 共用结构的布局
- 可复用 UI 的组件
- 视觉体系的样式
- 主题所依赖内容模型的 schema 定义
这比传统的「往主题里塞逻辑直到能跑」要健康得多。
在追逐视觉一致之前，先重建内容模型
很多团队还没弄清目标内容结构，就想保留旧 HTML 输出，主题迁移往往会因此失败。
若 WordPress 主题依赖自定义文章类型、文章元数据、短代码或区块特有假设，必须先翻译成 EmDash 原生的内容类型与字段。
否则 Astro 层会一直在为薄弱的 schema 打补丁。
若站点仍处于内容迁移阶段，可先从 WordPress 迁移至 EmDash 指南 入手。
保留旧设计中值得保留的部分
WordPress 主题并非都要扔掉。通常更稳妥的做法是：
- 保留信息架构
- 保留品牌体系
- 保留已验证的页面模式
- 去掉遗留实现包袱
这样编辑与读者仍感到熟悉，又不必让 Astro 去模仿 PHP 时代的主题结构。
建议刻意重写的内容
迁移时，以下几类几乎都应重新设计：
- 与
functions.php强绑定的部分 - 藏在主题辅助函数里的逻辑
- 脆弱的短代码驱动渲染
- 依赖插件的视觉组件
这些地方往往是「忠实迁移」变成技术债搬运的重灾区。
可操作的「成功」标准
成功的主题迁移，不是保留每一处实现细节，而是：
- 保留读者真正在乎的内容体验
- 给编辑更清晰的内容结构
- 让前台更易维护
- 降低安全与运行时的耦合
这正是 Astro 与 EmDash 的强项：把展示层按现代前端项目重建，而不是把主题代码当圣物供奉。