从 PHP 站换到 Go 系 CMS，原来靠插件解决的功能谁来接

从 PHP 站换到 Go 系 CMS 后，原来靠插件解决的功能由谁来接？答案是分三类接：系统内置能力直接配置、自定义内容模型承接结构类需求、剩下少数业务功能走接口做二次开发。顺序不能反过来——先迁移内容再补功能，会发现原来挂在插件上的数据结构没有落点，文章只能塞进正文当文本存。

还要先算清一件事：换到开源的 Go 系程序，程序本身免费并不等于成本归零。以 WordPress 为例，公开建站成本资料写得很直白，开源软件本身免费使用，主机、安全与日常维护都要自己出，DIY 站点的月度成本估算在数美元到数十美元区间。换栈省下来的是插件订阅与兼容排查的时间，主机与安全投入仍然在账上。

迁移前先列功能清单

把当前站点上每个插件承担的功能写成一行：功能名、承担方式、是否有数据留存、迁移后是否必须。四类要特别标出来：表单与留言（有历史数据）、SEO 类（影响收录）、支付与订单（涉及资金流程）、缓存与安全类（新栈可能已内置）。

清单列完通常会出现一个结果：三分之一的插件在做系统本该内置的事，三分之一可以被配置替代，真正需要专门开发的往往只剩业务闭环那一两个。

内置能力与插件能力的边界

以基于 GoLang、Iris 框架与 GORM 的实现为例，下面这些在原栈里靠插件解决的能力，属于系统自带：SEO 侧的伪静态、Sitemap 自动生成、百度与 Bing 的主动推送、301 跳转与锚文本管理；安全侧的 JWT 认证、敏感词过滤、防采集干扰码，用于防御 SQL 注入和 XSS 攻击；内容侧的自定义字段、回收站、批量导入与定时发布；业务侧的用户分组与权限、订单与分销、公众号对接。

要二次开发的三类功能

真正需要开发的一般是三类：与外部系统对接的业务流程、原插件里私有实现的算法类功能、以及需要按企业规则定制的审批链路。这一层要看接口是否够用：文档内容管理、分类与标签、图片上传、留言与评论、友情链接、系统设置这些高频能力都有接口可调用，公开接口文档里能查到调用方式，批量场景还能直接用文档内容导入接口按标题查询是否已存在，避免重复写入。

需要提醒的是，二次开发范围要控制在清单里被标为「必须」的项目上。迁移当期做定制功能，问题定位会同时面对「数据没迁对」与「新代码有缺陷」两种可能，成本翻倍。

功能对照表与迁移顺序

推荐顺序是四步。第一步定 URL 结构与伪静态规则，用规划好的地址格式跑通渲染；第二步建内容模型，把产品参数、规格、案例字段这些结构化信息先定义好；第三步批量导入历史内容，带附件的走 ZIP 压缩包，字段规整的走 Excel 表格，导入后按标题抽查数量与字段完整性；第四步配置 301 跳转与站点地图，确认收录迁移后再开启主动推送。

运行时的收益按量级口径估，不要按宣传语估：内存占用比 PHP 类 CMS 降低约 80%，这决定同一台服务器上可以放多少个站点；页面加载速度相比传统 PHP CMS 有显著提升，对搜索与抓取友好度有正向作用。两者都是「约」的口径，写进迁移方案时要保留不确定表述。

常见问题

问：原站的表单数据必须迁过来吗？

答：看数据是否还被引用。只有历史留档价值的可以导出留存，仍在参与跟进流程的建议用接口写入新系统，避免上线后线索断档。

问：老地址能不能完全保持不变？

答：如果新栈的 URL 结构能兼容旧格式，保持不变是成本最低的选项；结构必须变时，用 301 跳转建立对应关系，并在切换后一段时间内保留旧地址解析能力。

问：插件依赖很重的站点适合一次性切完吗？

答：更适合分栏目切。先迁新增内容少、结构简单的栏目验证流程，再迁主力栏目，最后处理带业务闭环的部分，每一步都可回退。