要不要关 WP-JSON 接口，这事比看起来复杂。9 月 WordPress 安全白皮书把这条接口列为自动化扫描高频目标，管理层一听就觉得该关——断源头，控风险，逻辑很顺。但这个逻辑顺的过程里，踩坑的企业不少。
插件兼容性是第一个没想到的坑
技术团队评估完说能关，管理层拍板，执行。没过多久就开始出状况：编辑器保存失败、表单提交没反应、SEO 插件的数据同步全断了。
这些插件在设计时默认 WP-JSON 接口可用，你把它关了，它们不会报错，只会沉默地失效。等你在后台发现数据不对的时候，问题已经蔓延开了。
更麻烦的是，这事不是一次性排查完就完了。未来加新插件、升级旧插件，都得再测一遍接口兼容性。运维团队等于多了一件事，而且这事没法彻底做完。
防御措施本身也在制造运维成本
有人说不用全关，做访问控制就行——IP 白名单、请求频率限制、GeoIP 过滤。这些能做，但每一条都需要人去配置、去监控、去维护。
白名单要更新，限制阈值要按真实流量调，误拦了要有快速处理通道……听着都是小事，但运维资源本来就有限的企业，这些小事堆在一起，关键时刻就变成拖慢业务响应的理由。
举个具体场景：第三方服务商临时需要对接数据，白名单加不加？流程不灵活的话，要走一圈审批；流程太灵活的话，白名单本身就失去意义了。
暴露信息和被攻破之间隔着一层
WP-JSON 接口确实会暴露版本号、用户名枚举、内容结构这些信息。攻击者拿到这些能加快定位漏洞的速度。
但暴露不等于被拿下。
补丁管理到位、插件精简、权限管控做好，攻击者即使知道版本号也找不到可用的突破口。这三层没做好的，关了 WP-JSON，攻击者还有一百种方式探测。接口防御是整体安全的一环，不是全部。
把资源全押在这上面，其他地方裸奔，不划算。
管理层真正要回答的不是”关不关”
技术团队会给你两个方案，各有优劣，你来选。这个问题没有标准答案，但有几个判断维度：
技术团队能不能承担关闭后的持续兼容性测试？如果不能，方案一的风险在积压。如果能，方案二的操作成本在积压。
整体安全体系里，有没有比 WP-JSON 更紧迫的漏洞在等着？这个答案只有你自己知道。