WordPress 二次开发
在跑着的网站上，补上它缺的那块能力
站点已经上线，主题看着也还行，但询盘表单接不进 CRM、产品参数要人肉排、批发价算不出来。这类问题不该靠推倒重做来解决。我们做的 WordPress 二次开发，是在你现有站点上做定向改造：不动内容、不动链接、不推翻设计，只把业务真正缺的那部分功能写进去。
先判断清楚
该二次开发，还是该重做
不是所有问题都值得改造。下面四条里占了两条以上，二次开发通常比推倒重来划算。
框架和设计仍然能用
主题的模板层级清晰，移动端显示正常，后台编辑体验也没大毛病，只是功能缺项。这种情况下重做，等于把一套还能跑的壳子连里面攒了几年的内容一起推平。
内容和收录不能清零
几百上千条产品页、新闻、案例已经积累了收录和外链。二次开发可以保持 URL 结构不动，重做则要做一整套旧链到新链的 301 映射，任何一个漏掉的栏目都可能让流量掉一截。
业务流程确实特殊
询盘要按国家分派给不同业务员、报价要按客户等级走、产品要按十几个参数组合筛选、图纸只给认证客户看。这些通用插件覆盖不到，硬凑组合插件的结果通常是后台越来越卡、数据越来越乱。
预算和窗口都紧张
赶展会、赶旺季，三个月内必须上线。二次开发的工期一般是重做的三分之一左右，而且可以拆成几期，先上最影响询盘的那一块，剩下的排到后面。
技术边界
哪些文件能改，哪些一行都别碰
二次开发出问题，九成不是功能写不出来，而是写在了不该写的地方。改错位置，一次主题或插件升级就能让功能凭空消失，还留下一堆没人敢删的残代码。
可以动的部分
- 子主题的 style.css 与 functions.php
- mu-plugins 目录下的常驻模块
- 自建插件（业务逻辑放这里最稳）
- ACF 字段组、自定义文章类型注册
- 自建 REST 端点与后台设置页
不能动的部分
- wp-admin 与 wp-includes 核心目录
- 父主题的模板文件和核心函数
- 第三方插件的原始文件
- 数据库里的 WordPress 核心表结构
- wp-config.php 里除常量外的逻辑
原因很直接：父主题和插件都有升级通道，改的那一行会在某次更新里被原版覆盖，功能悄悄失效，报错往往几周后才被业务发现。正确做法是把改动挂在钩子上，让原文件保持干净。
子主题接管
建 child theme，只放需要覆盖的模板文件，其余全部继承父主题。
钩子优先
能用 add_action、add_filter 解决就不复制模板，改动量越小越好维护。
数据结构先行
用 register_post_type 加字段组，把产品参数、证书、案例各建成独立类型。
接口单独封装
对外系统一律走自建端点，做 nonce 与权限校验，不在模板里直连数据库。
五类最常见的改造
几乎每家出口企业都会碰到
下面这些需求，我们在 3000 多家企业站上反复做过。写法不同，坑基本是同一批。
询盘链路改造
表单提交后写入自建数据表、走 SMTP 发信、同时推送到企业微信或 CRM，并带上来源页面、UTM 参数、访问设备。防垃圾提交用隐藏字段加时间戳校验，不挂图片验证码——那东西挡掉的有效询盘比垃圾还多。
产品参数与下载中心
把型号、材质、尺寸、认证存成自定义字段，前台据此生成对比表和参数筛选，而不是把参数写死在详情页正文里。图纸和目录 PDF 放在受保护目录，下载前校验权限，避免整套图纸被搜索引擎直接抓走。
WooCommerce 价格体系
按用户角色、购买数量设置阶梯价，用 woocommerce_before_calculate_totals 挂钩改价。要注意与优惠券、税费、运费的叠加顺序，顺序错了会出现结账金额和小计对不上。
多语言结构改造
不建议用主题自带的一键切换，那种方案通常靠 JS 换文案，搜索引擎抓不到。改用 WPML 或 Polylang 分离语言目录，hreflang 成对输出，语言间的内链互相对应。
老数据批量导入
几万条产品从 Excel 或旧库导进来，用 WP All Import 分片跑。先拿 50 条验证字段映射和图片抓取，确认分类、标签、缩略图都对，再放全量，失败批次要能回滚。
后台易用性改造
把业务员每天要点的十几个菜单收敛成一个工作台，产品编辑页只留必要字段。后台清爽了，客户才愿意自己更新内容。
代码怎么验收
不看演示视频，看这五条
功能点通只是及格线。真正决定这套代码三年后能否维护的，是下面这些看不见的地方。
查询次数
装 Query Monitor 看单页查询数。列表页超过 60 条就要排查是不是在循环里查库，典型的 N+1 写法会让页面越用越慢。
外部请求
汇率、库存、物流接口不能每次开页都请求，用 transient 或对象缓存压到 5 到 15 分钟一次，并设超时与降级。
转义与校验
输出走 esc_html、esc_url、wp_kses_post，入库走 sanitize，表单加 nonce，接口加 current_user_can 判断。这几条不做到位，等于给站点留后门。
版本管理与文档
自写代码进 Git，交付给仓库权限而不是一个压缩包。每个钩子注明挂载位置和原因，字段结构出一份对照表，换人接手不用猜。
工作量与周期
按改造类型拆开看
下表是常规复杂度下的经验区间，实际以需求清单和现有代码状况为准。老站代码混乱的，评估前先做一次体检。
| 改造类型 | 典型工作量 | 交付周期 | 最容易踩的坑 |
|---|---|---|---|
| 表单与通知链路 | 3-5 人日 | 约 1 周 | SMTP 未配置，通知信进垃圾箱；附件上传未限制类型 |
| 产品参数与筛选 | 5-8 人日 | 1-2 周 | meta_query 条件过多导致慢查询；筛选结果页未做 canonical |
| WooCommerce 价格体系 | 8-15 人日 | 2-3 周 | 与优惠券、税费叠加顺序错误；购物车缓存未失效 |
| 多语言结构改造 | 6-12 人日 | 2-3 周 | 旧内容翻译缺失；hreflang 与语言目录不一致 |
| 旧数据批量导入 | 3-10 人日 | 1-2 周 | 图片未本地化仍指向旧域；SKU 重复导致商品覆盖 |
如果站点本身还有结构性问题，比如主题是几年前买的、插件装了四十多个、打开要五秒以上，建议先看 WordPress 网站改版升级；想从零重做主题层，看 WordPress 主题定制开发；需要独立功能模块，参考 WordPress 插件定制开发。
二次开发常见问题
动手前先把这些问清楚
能。前提是改动都走子主题和自建插件，父主题保持原样。升级前先在测试站跑回归，确认模板覆盖和钩子仍然生效再推生产。若某次升级动了依赖的钩子，我们会给出替代方案。
不必。功能重复、两年没更新、或者已经和当前 WordPress 版本不兼容的插件，建议替换掉。替换前要先确认它往数据库写了什么，把历史数据迁到新结构里，否则旧内容会变成查不到的孤儿数据。这一步通常比装新插件费时间。
合同里写明归甲方。交付内容包括 Git 仓库完整权限、部署说明、自定义字段结构对照表，以及一份改动清单，注明每一处挂在哪个钩子上。后面换服务商接手，不需要重新猜一遍代码逻辑。
可以，按人日计。这类小改动一般合并到一次维护窗口里做，避免频繁动生产环境。加字段看着简单，但如果表单数据已对接下游系统，字段名和格式要同步改，否则会出现前台能提交、后台收不到。
不需要。开发在测试环境完成，上线通常安排在访问低峰，切换时间控制在半小时内。涉及数据库结构变更的，会先做全量备份，确认无误后再执行，出问题可以整体回滚。上线后一周内我们盯着错误日志和询盘到达情况。
这种情况一般不是改造本身造成的，而是新功能带了额外查询或外部请求。上线前我们做一次性能基线对比，记录首字节时间和查询数；如果确实有拖慢，用缓存或改查询方式解决，必要时参考 WordPress 速度优化 做整体调优。
把需求说清楚，
报价才有意义
告诉我们站点地址、想加的功能、现在卡在哪一步，我们先判断值不值得改。需要长期有人盯更新和备份的，可以看 WordPress 托管维护。电话/微信 13280692153，邮箱 web@wordpressx.com。