WP旧接口无法复用到CI4 RESTful API，因二者架构、路由、权限、数据处理机制完全不同；需重写控制器、映射数据结构、独立实现认证与CORS配置。
WP旧接口不能直接复用到CodeIgniter 4的RESTful API开发中，根本原因在于二者架构模型、请求处理机制和资源抽象方式完全不同——不是“改个URL”或“套个包装”就能迁移的事。
核心差异：WP REST API 和 CI4 RESTful 不是同一套语言
WordPress REST API 是一个运行在 WordPress 运行时环境中的完整服务层，自带路由注册、权限钩子（如rest_api_init）、数据序列化逻辑、用户认证集成（JWT/OAuth）以及对 post、user、taxonomy 等内置对象的深度封装。它本质是 CMS 内置的“数据出口”，所有端点都基于 WP_REST_Controller，响应结构固定，且大量依赖全局函数和 WP 对象（如 $wpdb、get_posts()）。
而 CI4 的 RESTful 实现是轻量、显式、控制器驱动的：
- 路由必须在
app/Config/Routes.php中按 HTTP 动词显式绑定，例如$routes->post('api/users', 'Users::create'); - 控制器继承
CodeIgniter\Controller，不兼容 WP 的WP_REST_Controller - 请求体解析、验证、响应格式（含状态码、头信息）全部由
HTTP\Request和HTTP\Response统一控制，没有 WP 那套 filter/action 钩子链 - 无默认资源映射，
/wp-json/wp/v2/posts这类路径在 CI4 中不存在，需完全重定义
不能“复用”的典型场景
以下 WP 接口常见写法，在 CI4 中无法原样搬用：
-
register_rest_route('myplugin/v1', '/products', [...])→ CI4 没有register_rest_route函数，也不支持动态注册；所有路由必须静态声明 - 使用
WP_Query或get_posts()获取数据 → CI4 模型默认用$this->db，需手动构造查询或使用 Query Builder，且不识别 WP 的参数别名（如post_status、meta_query） - 依赖
rest_ensure_response()或rest_ensure_request()→ CI4 无对应函数，响应统一用return $this->response->setStatusCode(200)->setJSON([...]); - 通过
current_user_can()控制权限 → CI4 需自行实现鉴权逻辑（如检查 Bearer Token + 查询用户角色表），不接入 WP 用户会话
可行的重构路径：不是复用，而是映射与重实现
若需将 WP 旧接口能力迁移到 CI4，应视为一次“协议对齐”而非代码搬运：
- 保留原有 URL 路径语义（如
/api/v1/products），但内部逻辑全部重写为 CI4 风格控制器 + 模型 - 将 WP 的数据结构（如 post 对象字段）映射为 CI4 的 DTO 或数组结构，注意字段命名差异（如 WP 的
post_title→ CI4 的title） - 认证方案需独立设计：WP 的 JWT 插件生成的 token 不能直接被 CI4 解析，需在 CI4 中集成相同算法（如使用
firebase/php-jwt验证签名）并同步用户表 - 分页、排序、过滤等查询参数（
page、per_page、orderby）可保留命名，但在 CI4 中需手动解析并转为 Query Builder 条件
特别注意 CORS 和响应头配置
WP 默认允许跨域（尤其在本地开发时），而 CI4 默认关闭。若前端仍调用相同域名下的旧 WP 前端，但后端已切到 CI4，必须在 app/Config/Filters.php 中启用 CORS，并确保响应头包含：
-
Access-Control-Allow-Origin: *（或指定域名） Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONSAccess-Control-Allow-Headers: Authorization, Content-Type, X-Requested-With-
Access-Control-Allow-Credentials: true（如需带 Cookie 认证）
漏配会导致浏览器预检失败，接口看似“没反应”。
