WordPress 小程序开发
WP 做后台，小程序做前台，一套内容两处用
已经有 WordPress 站的工厂，最常见的诉求是：产品资料不想录第二遍，但客户要能在小程序里查型号、看参数、留询盘。WordPress 小程序开发的核心，就是把 WP 变成一个稳定的内容接口，前端用原生小程序接。这页讲架构、REST API 和登录态怎么落地。
为什么用 WordPress 当后端
而不是另起一套系统
关键在于内容只有一个来源。另建后台意味着产品参数要维护两份，三个月后必然对不上。
内容只录一次
产品、案例、新闻在 WP 后台维护，官网和小程序读同一份数据。改一个参数，两边同时生效，不需要人工同步，也不会出现官网上写着 DN50、小程序上是 DN40 这种事故。
编辑习惯不用改
外贸公司的运营同事已经会用 WP 后台发文章、传图、填 ACF 字段。小程序接进来之后，他们的工作流程完全不变，不需要再培训一套新系统。
SEO 资产继续累积
小程序内容不被百度收录，官网的收录和排名还得靠 WP。两边共用一套内容，等于同一份工作同时服务两个渠道，这是套壳方案给不了的。
如果站上已经跑了 WooCommerce，订单和会员体系可以复用，不必在小程序里重写一套购物车逻辑，相关细节见 WooCommerce 商城搭建。
接口层怎么写
默认接口直接用会踩的四个坑
WP 自带 REST API，开箱能用，但默认输出是给管理界面设计的，直接丢给小程序会又慢又乱。
字段太肥，必须裁剪
请求 /wp-json/wp/v2/posts 默认返回几十个字段，正文还带一堆 inline style。用 _fields=id,title,excerpt,featured_media,date 只取需要的，单次响应能从 80KB 降到 12KB 左右，列表加载速度差别很明显。
产品字段要自定义端点
产品用 CPT 存，参数放在 ACF 里，用 register_rest_route 注册 /xinke/v1/products，一次性把价格、材质、规格、图片拼好返回，前端不用发三次请求。permission_callback 必须显式写，返回 true 也要写，否则会有安全告警。
列表接口要加缓存
小程序首页一进去就是三四个列表请求，每次都查库、跑 ACF、拼图片，PHP 扛不住并发。用 set_transient 缓存 5-10 分钟，发布文章时在 save_post 钩子里清掉对应 key。数据延迟几分钟，对产品展示完全可接受。
分页参数要收敛
per_page 上限锁在 20，page 做边界校验，超出返回空数组而不是报错。小程序的 onReachBottom 触底加载要防重复请求，用 loading 标志位挡住，否则用户快速滑动会发出五六个相同请求。
- 接口域名必须是已备案的 HTTPS 域名，不能是 IP，也不能带端口，微信后台的 request 合法域名只认 443。
- 开发阶段在微信开发者工具里勾选「不校验合法域名」，上线前必须去掉，否则真机直接请求失败。
- 图片走对象存储或 CDN，不要直接引用 WP 的 wp-content/uploads，原图动辄两三兆，小程序列表会卡。
- 接口返回统一包一层 code、msg、data，前端好做错误处理，不要有的接口返回数组、有的返回对象。
登录态怎么设计
别把密钥写进小程序
这是最容易出事的一环。小程序代码包是可以被解出来的，任何写在前端的 secret 都等于公开。
拿 code
前端调 wx.login 拿到临时 code，有效期 5 分钟、只能用一次。不要缓存它，每次登录重新取。
后端换 openid
code 传到服务端，由服务端带 appid 和 secret 调 jscode2session，拿回 openid 和 session_key。secret 只存在服务器环境变量里。session_key 绝对不能下发给前端。
签发自己的 token
用 openid 查 wp_usermeta，有就取用户，没有就建一个 subscriber。签发 JWT 或随机串存进自定义表，设 7 天过期，前端存 storage，之后每次请求带 Authorization 头。
校验与刷新
服务端在 rest_authentication_errors 钩子里校验 token，过期返回 401，前端捕获后静默重新 wx.login，不要弹窗打断用户。
手机号绑定
getPhoneNumber 拿到的是加密 code，要后端调 phonenumber.getPhoneNumber 接口解密，需要 access_token。解密出的手机号写进用户资料，用于询盘跟进和订单通知，不要存在前端本地。
Application Password 不适合
WP 自带的应用程序密码是给服务端对服务端用的，把它放进小程序等于把后台账号公开。它的正确用途是内部系统对接，不是 C 端登录。这一点很多教程写错了。
后台内容模型
先定字段，再写页面
小程序页面是死的，字段是活的。字段没设计好，后期加一个参数就要改接口、改前端、重新提审。
自定义文章类型
产品（product）、案例（case）、资料下载（download）各建一个 CPT，用 taxonomy 做分类，不要全塞进普通文章。归档页的 URL 前缀单独设，避免和官网页面冲突。
字段用 ACF 管理
产品至少要有：型号、材质、规格范围、认证、MOQ、交期、主图组、PDF 图纸。字段类型选对，规格用 repeater 存多行，不要塞进一个文本框靠换行分隔，前端没法解析。
内容模型定型之后，如果需要额外的业务逻辑，比如询盘表单写库、报价单生成，就要动到插件层，建议看 WordPress 插件定制开发 的做法，不要直接改主题的 functions.php。
三条技术路线
成本和体验对照
同样叫「做个小程序」，实现方式差别很大，选错路线后期返工成本最高。
| 路线 | 体验 | 开发量 | 审核风险 | 适用场景 |
|---|---|---|---|---|
| 原生小程序 | 最好，接近 App | 大，需前端人力 | 低 | 产品目录、询盘、会员 |
| uni-app 多端 | 接近原生 | 中，一套代码多端 | 低 | 同时要 H5 和 App |
| WebView 套壳 | 一般，有白屏感 | 小，复用官网 | 高，交易类易被拒 | 纯展示、内部使用 |
套壳方案便宜，但小程序审核明确要求「不能是网页简单封装」，纯展示类偶尔能过，一旦涉及支付和会员基本会被打回。我们通常建议原生或 uni-app，把官网作为内容源而不是页面源。
上线前必须过的六关
少一关就卡在审核
技术做完不等于能上线，微信侧的合规要求经常被忽略，导致反复提审拖一个月。
- 域名备案：接口域名必须完成 ICP 备案，主体和小程序主体一致或有关联证明。
- HTTPS 证书：有效期要盯住，证书过期当天小程序全站白屏，这是最常见的线上事故。
- 类目选择：企业展示选「企业服务」，带交易要选对应类目并提供资质，选错直接被拒。
- 隐私协议：首次进入必须弹隐私授权，说明收集哪些信息、用途、存储方式，2023 年后这是硬性要求。
- 内容合规：不能出现「最」「第一」「国家级」这类绝对化用语，产品页的文案要按广告法过一遍。
- 订阅消息：询盘提醒用一次性订阅消息，必须用户主动点击授权，不能默认勾选。
上线之后的稳定性是另一件事：接口监控、证书到期提醒、WP 核心与插件更新，这些属于日常运维范畴，可以交给 WordPress 托管维护 统一处理，避免小程序和官网各自为政。
WordPress 小程序开发
常见问题
不用。只要官网是 WordPress 且产品用 CPT 加自定义字段管理，接口直接读现有数据。唯一需要补的是字段完整性——很多老站的产品参数写在正文里，这种要先做一轮结构化整理，工作量取决于产品数量。
能调，但不要直接用。WooCommerce 的 cart 依赖 session cookie，小程序没有 cookie 机制，硬接会出现购物车串号。正确做法是自己封装一层，用 token 对应购物车数据，或者干脆只做询盘不做在线支付。
要。至少做三件事：按 openid 限频，同一用户每分钟不超过 30 次；询盘提交加验证码或行为校验；token 校验失败直接 401，不要返回详细错误原因。没有这些，接口被人扫一遍就能把数据库塞满垃圾询盘。
可以，接口按 appid 区分来源即可。但要注意两点：不同小程序的用户体系要隔离，openid 在不同 appid 下不通用；缓存 key 要带来源标识，否则会互相覆盖。站群场景还要考虑数据库压力。
需要，而且更重要。小程序不被搜索引擎收录，官网才是自然流量的入口。两者的关系是官网负责被搜到、小程序负责被复用，不能因为做了小程序就把官网放着不管。
先看现有 WP 站能不能直接接
再定开发范围
把域名和小程序要做的功能发我们，先评估接口改造量：字段是否够用、接口是否需要重写、登录体系要不要新建。评估不收费。电话/微信 13280692153，邮箱 web@wordpressx.com。