WordPress原生搜索性能差源于MySQL的LIKE模糊匹配，CI4仅作中转桥梁；推荐WP导出→CI4同步→Elasticsearch/Meilisearch架构，兼顾中文分词、实时性与可维护性。

WordPress 原生搜索性能差，本质是 MySQL 的 LIKE '%keyword%' 全表模糊匹配导致的。尤其当文章量超 5000 篇、分类/标签术语繁多时，搜索响应常超 2 秒，且无法支持中文分词、同义词、权重排序等需求。CI4（CodeIgniter 4）本身不内置全文检索能力，但可作为桥梁，将 WordPress 内容导出并接入专业检索引擎——这才是真正可行的“重构”路径，而非在 WP 内硬改 SQL。

为什么不能只靠 WP + CI4 自建全文索引

CI4 的 Query Builder 和原生数据库驱动仍依赖 MySQL 或 PostgreSQL 的全文检索功能（如 MATCH ... AGAINST），而 WordPress 默认使用的 MySQL 引擎（InnoDB）对中文支持极弱：不支持中文分词，需手动配置 ngram parser 且效果有限；同时，WP 多表关联（posts + postmeta + term_relationships + terms）使复合检索难以建有效联合索引，强行优化易引发锁表或查询超时。

推荐架构：WP 内容导出 → CI4 中转 → Elasticsearch / Meilisearch

这是 2026 年生产环境验证过的高效方案，兼顾实时性、中文支持与可维护性：

• 数据同步层：用 WP REST API 或自定义 endpoint 输出结构化内容（标题、摘要、正文、分类名、标签、自定义字段），通过 CI4 的 HTTP\Client 定时拉取或监听 save_post 钩子触发推送
• 检索引擎层：部署轻量级 Meilisearch（Docker 一键启动，中文分词开箱即用）或 Elasticsearch + IK 分词器；建立索引时为不同字段设置 searchable 属性（如 title: true, content: true, category_name: true）
• 查询服务层：CI4 构建统一搜索接口（如 /api/search?q=草莓&filters=product），调用 Meilisearch 的 HTTP API，返回 JSON 结果；前端用 AJAX 替换原 WP 搜索表单提交

关键细节处理

避免常见落地陷阱：

• WP 导出内容需过滤 shortcodes、清理 HTML 标签（用 wp_strip_all_tags()）、截断过长正文（防索引膨胀）
• 同步失败需有重试队列（CI4 的 Queue Library + Redis），失败日志写入 wp_options 表或独立日志文件
• 搜索结果页仍走 WordPress 主题渲染（search.php），仅把 CI4 接口返回的数据注入模板变量，保持主题兼容性
• 权限控制需复用 WP 用户体系：CI4 接口校验 wp_users 表或 JWT Token（由 WP 插件生成）

替代轻量方案（无服务器运维能力时）

若无法部署外部引擎，可退而求其次：

• 启用 MySQL 8.0+ 的 ngram parser，并为 wp_posts.post_title 和 wp_posts.post_content 单独建 FULLTEXT 索引（需修改表字符集为 utf8mb4_0900_as_cs）
• 用 WP_Query + posts_search 钩子，但只扩展到分类名称（terms.name），放弃 post_content 模糊匹配，改用 post_excerpt 或自定义字段存储精简关键词
• 前端加 Algolia DocSearch（免费版支持公开站点），无需后端改造，但数据托管在第三方