将搭载JS单页应用的Django后端迁移至WordPress的技术问询

嘿，作为经常折腾这类跨框架迁移的开发者，得跟你说——真不是只转换API接口那么简单。WP REST API确实能提供类似DRF的RESTful能力，但两者的生态、数据结构、权限模型差异不小，我给你拆解几个必须关注的要点：

1. 数据模型的映射是基础 #

Django里你可以自定义Model，但WordPress有一套固定的核心数据体系（文章、页面、自定义文章类型、分类、标签、用户等）：

• 如果你的Django数据刚好对应WP核心类型（比如博客文章→WP Post），那迁移数据时可以用WP自带的导入工具，或者写个简单脚本把Django数据转成WP数据库的结构（比如wp_posts、wp_postmeta表）
• 如果是自定义业务模型（比如订单、会员专属数据），你得在WP里创建自定义文章类型（CPT），或者用ACF这类自定义字段插件来对应，这部分得重新设计数据存储结构，不能直接照搬Django的Model

2. API接口的适配要细致 #

WP REST API的端点格式、参数逻辑和DRF完全不一样：

• 比如DRF里你可能用/api/posts/，WP REST API默认是/wp-json/wp/v2/posts
• 分页参数也不同：DRF常用page_size+offset，WP用page+per_page
• 权限验证差异更大：DRF常用Token或JWT，WP REST API默认支持Cookie验证（适合WP后台登录用户），如果你的前端是独立SPA，需要支持匿名或第三方登录，得装个JWT插件（比如JWT Authentication for WP REST API），同时调整前端的鉴权逻辑

3. 业务逻辑得换个方式实现 #

Django里的自定义视图、信号、中间件这些业务逻辑，在WP里得用它的钩子系统来替代：

• 自定义API端点：用register_rest_route()函数注册自定义路由，写对应的处理逻辑，替代DRF的ViewSet
• 数据校验：DRF有Serializers做自动校验，WP里要么在自定义端点里手动写校验逻辑，要么用rest_request_before_callbacks钩子拦截请求做校验
• 后台管理：如果你的Django有自定义后台界面，WP可以通过自定义Metabox、调整CPT的编辑界面来适配，不用从零搭建后台

4. 前端部署要避免路由冲突 #

如果你的前端是独立的单页应用，部署时得注意：

• 可以把前端文件放到WP的主题目录下，或者用WP媒体库托管静态资源
• 一定要配置WP的Permalink设置（比如改成“文章名称”），避免前端SPA的路由和WP的路由冲突，或者用template_redirect钩子来处理前端的路由跳转

实操步骤建议 #

• 先把Django的核心数据导出成JSON/CSV格式，写脚本导入到WP的对应数据类型（核心类型或自定义文章类型）
• 搭个WP测试环境，先注册必要的自定义API端点，模拟前端请求验证逻辑是否和原来一致
• 逐步修改前端JS里的API调用，替换成WP REST API的格式，每个接口都单独测试响应
• 迁移权限验证逻辑，确保前端用户的登录、授权流程和原来的体验一致
• 最后跑一遍完整的业务流程，调整WP的主题、插件配置来匹配原来的站点功能

内容的提问来源于stack exchange，提问作者ChrisM