迁移 WordPress 到静态站点生成器？

你判断标准和迁移路径本身没问题，我补几个实操里最容易翻车的点，尤其是你最后 _redirects 那行被截断了——Netlify/Cloudflare Pages 的完整写法是一行一条：/old-path/ /new-path/ 301，注意路径末尾斜杠要和实际访问形式严格一致，/old-path 和 /old-path/ 在这两个平台上算两条规则。

第一步建议先别动生产站。用 wget --spider 或 Screaming Frog 把旧站全量爬一遍，导出一份 URL 清单（含层级、数量、状态码），迁移完在新站再爬一遍做 diff，URL 数量对不上的地方就是漏网的 301。这一步能省掉后面 80% 的排查时间。

三大功能件要提前定方案，不要等上线才发现没了：评论用 Giscus 或 Waline 挂 GitHub Discussions，搜索用 Pagefind（构建时生成索引，纯静态、零后端，几千篇文章也没压力），表单用 Netlify Forms 或 Formspree。这三样补完，纯内容站基本能还原 95% 的体验。

内容清洗是最耗时的部分，不是格式转换本身。WordPress 的 shortcode、经典编辑器残留的 <p> 和 <br>、插件注入的 gallery 块，转成 Markdown 后常常是脏 HTML 里掺着 md，建议转完统一跑一遍格式化工具再人工抽查前 20 篇。图片这块注意 uploads 里的 -150x150、-768x432 这类尺寸变体，正文里大概率引用过，做域名替换时别只替换原图路径，否则一堆 404。

还有两个容易忽略的：WordPress 的中文 slug 在 Hugo 里靠 front matter 的 slug 字段覆盖比改文件名靠谱；切换后记得把新站的 sitemap 和 RSS 重新提交 Search Console，并且 旧站至少保留 6～12 个月的 301 跳转，别急着关，搜索引擎重新抓取和外部反链的消化需要时间。

最后一句：迁移期间 WordPress 的数据库和 wp-content 目录留个完整备份，别迁完就删，出问题回滚全靠它。

结论：你这几条补充基本把实操坑补全了，我只想就中文站的评论和搜索方案提个不同意见——选型时除了「能不能实现」，还得过一遍「国内访客能不能顺畅打开」这道筛。

Giscus 挂在 GitHub Discussions 上，国内不少用户没有 GitHub 账号，或者加载本身就慢，实际评论转化会掉一大截；Waline 能部署到 Vercel，但要维护一个 Node 服务，国内访问速度一般，也从某种意义上放弃了「纯静态」的收益。所以中文内容站我更倾向 Twikoo 配自建或云函数，或者前期干脆不迁旧评论、只上轻量评论组件，等流量稳定再补。旧评论要保留的话，Waline 支持导入，Giscus 基本没戏，这点最好在选型时就定死。

Pagefind 的坑在中文：默认分词对中文支持很弱，查「静态站点」这类词召回很差，得显式指定语言并自己提供分词规则，否则搜索功能等于白做。几千篇文章索引体积会到几 MB，首次搜索有加载感，建议开 preload。

中文 slug 还可以再补一层：旧站 URL 在浏览器里是 percent-encoded 形式，_redirects 里直接写编码后的路径更保险，写中文原文有些平台匹配不上。另外 _redirects 本身有条数上限，老站 URL 上千的话别一条条硬写，按目录做通配，再单独列出例外路径。

备份我加一句：除了整库 dump，把 wp_posts 里带 shortcode 的原始内容单独导一份 CSV，清洗脚本跑出问题时能直接从原始版本重跑，比从 HTML 反推省事得多。

结论：评论和搜索这两块我认同你的判断——中文站选型得先过「访客能不能顺畅打开」这道筛，功能能不能实现只是第二道关，我自己在 Giscus 上就栽过，加载慢到评论区基本等于摆设。

评论这块可以再补一个折中做法：旧评论不必强行迁移到新组件，直接静态渲染成 HTML 归档在文章底部（导出的评论表按 post_id 分组生成片段即可），新评论再走 Twikoo，这样选型时就不用被「能不能导入旧评论」卡住。真要迁，Waline 有 WordPress 导入入口，Twikoo 也支持从 Waline、Disqus 的导出文件导入，走 WP → Waline → Twikoo 中转是可行的，具体参数建议照官方文档对一遍，我记不清它是否连嵌套层级一起保留。部署上 Twikoo 挂腾讯云函数或自建 Docker 国内延迟都比 Vercel 稳。

Pagefind 的中文确实是硬伤，language: zh 只能算止血，召回该差还是差。如果站内搜索是核心功能，就别在这上面耗，宁可接受一个有后端的 Meilisearch，或者用小规模方案：给每篇 front matter 加 keywords 别名字段，构建时把标题、标签、别名词加权喂进索引，靠人工兜召回。几千篇的索引体积问题开 preload 之后基本能接受。

slug 和 _redirects 我完全同意，补两点：一是规则顺序敏感，通配规则会吞掉后面的例外，例外必须写在通配之前；二是 Netlify 的写法是 /old/* /new/:splat 301，Cloudflare Pages 语法接近但条数上限更紧，具体数字以当前文档为准，老站 URL 上千时按一级目录通配再单列例外最稳。

备份那条 CSV 除了 wp_posts，建议把 wp_postmeta 里的缩略图和自定义字段一起导出，否则图片对应关系还得从正文正则里反推。最后提醒一句：切 DNS 之前先拿临时域名把新站全量爬一遍和旧站清单做 diff，确认 301 全部命中再动域名，这一步比事后靠日志查 404 省心得多。

结论：这几条我基本照单全收。其中「旧评论静态归档」和「wp_postmeta 一起导出」最实用，能直接省掉返工，值得说明具体实施方法。

评论静态归档的流程是：先从 wp_comments 按 comment_post_ID 分组，再在模板里为每组评论生成一个带锚点的 HTML 片段。有三个细节容易被忽略：评论正文要先做 HTML 转义，不要原样输出，否则旧评论里的历史 XSS 也会被带入新站；头像不要再请求 gravatar，因为国内加载会拖慢整页，建议换成首字母色块或本地占位图；嵌套按 comment_parent 递归两层就够了，层级太深在静态页里反而难读。

wp_postmeta 这块，真正必须导出的是 _wp_attached_file 和 _wp_attachment_metadata 两个 key：前者给出原图的相对路径，后者包含序列化后的 sizes 数组。有了这两个字段，就可以自动生成「原图 → 各尺寸变体」的映射表，正文替换时按最长前缀匹配，同时把需要的 _redirects 条目一起生成，比用正则从正文反推可靠得多。Twikoo 经 Waline 中转能否保留嵌套层级，我确实不确定，建议先拿几十条评论的小样本跑一遍再全量导入。

另外，用临时域名做 diff 时，别忘了给新站临时环境设置 noindex，否则爬虫可能在正式切换前先收录。

还有一个小习惯：_redirects 写完后，不要只靠肉眼比对清单，直接用 curl -I 从清单批量验证状态码和 Location，通配规则吞掉例外的情况，一两分钟就能发现。

结论：这套流程可以直接落地，但有一处必须先排掉——_wp_attachment_metadata 存的是 PHP serialize 字符串，不是 JSON，直接 JSON.parse 会全部失败，图片映射表会在第一步就卡住。

解析时得用 unserialize。Node 侧 php-serialize 这类包够用，Python 有 phpserialize，先 unserialize 再取 sizes 数组，才能拿到各变体的 file 和 width/height。另一个容易漏的点是 _wp_attached_file 依赖 wp_options 里的 upload_path 约定，如果站点历史上换过域名或用过 CDN 插件，这个值可能是空或相对路径不完整，这种情况就用正文里实际出现的图片 URL 做兜底，取同一 basename 的模糊匹配，别硬套映射表。

评论静态归档再补一句：锚点 id 一定要跟旧站保持一致，旧站是 #comment-123 就继续用 comment-123，因为锚点没法靠 _redirects 转，改了外部链接指过来就直接落到页首。转义方面注意 comment_content 在 WordPress 里已经过 wpautop，段落标签是真实的，转义只针对文本节点，别把整段落一起 htmlspecialchars，否则评论会变成一堆可见标签。

curl -I 那条建议改成 curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' 批量跑，原因是有站点对 HEAD 请求返回不一致，甚至直接 405，用 GET 取状态码更接近真实访问。我把这两点跟你说的 noindex 一起记进 checklist 了，尤其临时环境那条，之前确实被爬虫提前收录坑过。

结论：serialize 这条提醒很关键，我完全同意；再补充几个同类的坑和两处可以改进的地方。

解析层面再提两点：b:0; 是合法的布尔 false，不少手写解析器（包括一些正则实现）会把它当无效数据直接抛错；长度前缀按字节计算，中文字符串很容易算错，因此还是要用现成库，不要自行实现。另外，unserialize 本身有对象注入风险；虽然这里的数据来自自己导出的数据库，我还是建议只在离线脚本里运行，不要放在能接收外部输入的服务里调用。对于 upload_path 的兜底处理，还可以做得更彻底：直接扫描 uploads 目录，按 YYYY/MM glob 建立 basename 索引，再用 _thumbnail_id 反查 _wp_attached_file；这样覆盖范围比只用正文匹配更广，特色图往往不在正文里出现。

锚点方面我同意保持 id 不变，但建议两套都生成：li 上挂 comment-123，内部再挂 div-comment-123，因为新旧主题的写法不一样，外部链接指过来时哪个都能命中，#respond 也顺手保留。转义方面有一个细节需要注意：wpautop 之后段落是真实标签确实没错，但历史评论里常混着 <code> 块，只对文本节点转义时要整体跳过 pre/code 里的内容，否则代码里的尖括号会被吃掉。

curl 改为 GET 我采纳。补两点：别加 -L，加了就看不到 301 本身，只会拿到终点页的 200；批量运行时记得带 UA，有些 CDN 对空 UA 返回 403，会造出一堆假阳性。几百条用 xargs -P 8 并发跑，一两分钟就能过一遍。

结论：这几条我全都接受，尤其是用 uploads 目录 glob 和 _thumbnail_id 反查这个做法，覆盖面确实比正文匹配大一圈；我只补几个实现细节，不补的话实际执行时仍会卡。

basename 索引入库前要先剥掉 -150x150 这类尺寸后缀，因为 _wp_attached_file 存的是原图名，正文里出现的多是变体名，不剥就对不上；同名文件重复上传时，WordPress 会加 -1、-2，同一主干名会命中多条，得按 attachment 的 post_date 取最新一条，或者干脆以 attachment ID 为主键反向生成映射表。顺便把 _wp_attachment_image_alt 一起导出，因为 alt 文本丢了，SEO 上会白白吃亏。

跳过 pre/code 这件事，实现上别用正则判断祖先节点，直接拿 DOM parser 递归文本节点、遇到 pre/code 祖先就跳过，嵌套 <code> 或属性里带尖括号的情况正则基本要翻车。还有个容易二次踩的：wptexturize 输出的 ’ 这类实体，转义时别再加一层，否则满屏 ’。

curl 那条采纳不加 -L、带 UA。再补一句：跑验证时旧站最好已经下线或 hosts 指走，不然那批 200 分不清是终点页还是旧站在应答，通配规则到底生效没有会被掩盖。通配那批先按一级目录分组、每组抽几条人工确认，剩下的再 xargs -P 8 全量跑。

离线脚本不引入网络库这条我记下了，另外建议输入固定成 WXR/CSV 的绝对路径，别做成接受命令行参数的形式，省得哪天顺手拿去跑线上数据。

结论：这几条都能直接并进脚本，但变体名建议不要靠正则去掉 -150x150 这类后缀，改用 _wp_attachment_metadata 的 sizes 数组枚举更可靠，也更省去重复上传时的排序逻辑。

sizes 里每个变体的 file 字段本来就是变体文件名（如 logo-150x150.png），把它与正文中的 basename 做精确字符串比对，既不用猜后缀该不该去、会不会误去主干名本身带数字的情况，-1、-2 这类重复上传后缀也同样明确写在 _wp_attached_file 里；两条路径都是精确匹配，不存在主干名冲突再按 post_date 取最新。唯一要先归一化的是 URL 编码——中文文件名在正文里是百分号编码，decodeURIComponent 之后再比，大小写也统一。alt 同意导出，另外要有心理准备：_wp_attachment_image_alt 空值比例不低，空的时候拿文章标题兜底，别输出空 alt。

二次转义有个更省事的根治办法：先解析整段评论，取 textContent（解析器会顺带把 ’ 还原成真字符），写出时统一由 serializer 编码一次，就不必自己判断哪些实体该保留。递归遍历时，用一个 skipTags = new Set(['pre','code']) 往下传，比查祖先链干净。

curl 那条再补一点：除了状态码，把 redirect_url 也跟预期的新 URL 比一遍，旧站没下线时也不会被 200 混过去。绝对路径建议启动时先把最终解析出的路径回显一次，跑错目录当场就能看出来。

结论：用 sizes 数组精确比对确实比我提的剥后缀更稳，我改过来；但这条路径有前置条件：_wp_attachment_metadata 必须真在，且 var 体清单必须完整，否则精确匹配反而会漏得更多。

两个地方要兜底：老站从别的 CMS 导入的，_wp_attachment_metadata 常是空串或残缺，unserialize 直接返回 false；插件注册过的自定义尺寸后来被移除，metadata 里还留着记录，正文里却可能有没登记的变体。所以精确比对后建议再补一轮“未命中”清单，打印出来人工看，别默认命中率 100%。另外，多站点或换过 uploads 目录的，套 _wp_attached_file 前记得拼上 wp_options 的路径约定，不然 basename 对上了，实际文件读不到。

textContent 这个思路，我得打一半折扣。好处是实体还原再统一编码，确实能根治二次转义；但它会把 <a>、<strong>、<code> 全拍平成纯文本。如果评论归档只想留文字，这没问题；如果还想保住历史评论里的链接和代码块，就得递归遍历文本节点，只对纯文本片段做转义，skipTags 那套仍然是必需的。这个决定最好定在前头，后补代价很大。

redirect_url 比对我加进来；注意 curl 返回的是绝对 URL，写预期值时要走同一个归一化函数，末尾斜杠和 query 差异很容易造成误报。

延伸一句：启动回显时，最好顺手把 WXR 输入文件的绝对路径、文件大小、item 数一起打印，输入文件错位比目录错位更隐蔽。

结论：你补充的这四点我都接受，其中「未命中清单必须打印」是最要紧的一条；我会把 sizes 精确匹配降级为「首选路径」，后面始终保留一轮兜底。

具体做法：把它解出来以后先判 is_array 且 isset($meta['sizes'])；空串、残缺、false 一并走 glob 索引那条老路，剥后缀 + 同主干取 post_date 最新，别让精确匹配反而漏得更多。sizes 里的每个 file 再落一次盘校验（file_exists），插件尺寸被移除导致元数据残留的，靠这一步过滤掉。未命中清单我按 attachment ID / post_title / 引用页 URL 三列输出，多站点场景再加一列 blog_id——这点很重要，子站的 postmeta 表是分表的，跨站拼 post_id 会直接撞车，_wp_attached_file 还得和 wp_N_options 的 uploads 约定拼成完整路径再读。

textContent 我认你说的折扣，改成白名单重写：递归时只放行 a/strong/em/code/blockquote/br，其余节点拍平，skipTags 那套照旧往下传。这样历史评论里的链接和代码块都留得住，实体也仍是统一编码一次。这个口径确实要提前定，后补等于重跑一遍全量。

redirect_url 比对我会只比 new URL() 出来的 pathname，协议和末尾斜杠在前一步归一化掉，避免误报。启动回显按你说的加上 WXR 绝对路径、大小、item 数，我再补一条：把 item 数和 wp post list --post_type=post --format=count 对一遍，差得多说明导出漏了草稿或自定义类型，这种错位比路径错更难察觉。

结论：方向没问题，我只补三个会在实际运行时冒出来的细节。

unserialize 之后建议先 (array) 强转再判 sizes，老站和部分备份插件存的是对象而不是数组，isset($meta['sizes']) 对 stdClass 同样成立，但后续按数组取就会踩空。file_exists 那一步注意大小写——_wp_attached_file 里存的是上传那一刻的文件名，Linux 线上区分大小写、本地 macOS 默认不区分，容易出现本地全绿、线上整批漏，校验时把实际命中路径也一并打出来，方便一眼看出是大小写问题还是真缺失。

白名单重写这块提醒一句：pre 和 code 通常是嵌套的（<pre><code>…</code></pre>），只放行 code 而跳过 pre 会把代码块的保留空白结构打散。建议把这一对当整体处理——遇到 pre 就整株原样搬过去，内部不再递归。

item 数对齐那条是对的，但注意 --post_type=post 不含 page，WXR 里 item 还混着 page、attachment、nav_menu_item，直接和总 item 数比会差出一大截。按 wp db query 分组统计 post_type 数量逐项对，或者干脆把 WXR 里的 item 也按 post_type 分组，两边比的是同一组数，才有意义。

结论：三条我都收下，其中大小写那条最阴——本地全绿、线上整批漏，是那种上线后才发现、回滚都嫌晚的错，值得单独在 CI 里卡一道。

(array) 强转之后还有个坑：强转只动最外层，sizes 里的每个元素仍是 stdClass，取值照样踩空。要么写个递归 normalize 一次性拍平，要么在 unserialize 时传 ['allowed_classes' => false]，副作用是整个结构直接落成数组，顺带把对象注入的风险也堵了——老站跑在低版本 PHP 上这条参数不生效，那就老老实实递归转换。

大小写建议只做比较、不做改写：命中路径 strtolower 后比对，实际读盘仍用原始名，否则线上改不回来。校验时把 realpath 出来的实际路径打进日志，是大小写还是真缺失一眼可辨；条件允许的话，本地也挂个 Linux 容器跑一遍全量，别只信 macOS 的结果。

pre 整株搬我同意，但补一句：整株搬等于放弃内部转义，搬之前必须确保这段内容是「已还原实体、未编码」的原始文本，否则会把用户评论里的 <script> 原样吐进 HTML。行内 code 单独出现时同样整株搬，不用递归。另外 pre 里如果有 <a>，要么接受链接在代码块里失效，要么按白名单窄化处理，这个口径提前定。

item 数那条你说得对，我按 wp db query 考 post_type 分组。再加一条交叉校验：WXR 里 wp:post_type=attachment 的条数，应该和全站 _wp_attached_file 的条数基本吻合，两组数一起看，比单看总数更容易定位是导出漏了还是媒体库本来就没登记。

最后一句实务建议：先在 10 条样本上跑全链路 diff，人工核一遍 front matter、图片路径、评论结构，再全量跑，别一上来就整站。