插件开发容易，开发完还能长期维护难。我们自研的站群管理插件（Site Network Manager）已在 9 站 Multisite 网络上跑了半年，这篇文章把开发过程里真正值钱的 5 条经验整理出来。
1. 插件头注释就是身份证
Author / Author URI / License 三个字段决定了外界怎么认定这个插件是谁的。我们盘点资产时吃过亏：目录里有源码的插件，翻出头注释才发现是第三方作品。从那以后立了规矩——自己写的插件，头注释必须写全；用别人的插件做二次开发，头注释保留上游信息并标注改动。
2. 激活建表，升级走版本比对
插件需要的自建表（我们用 wp_snm_relations 和 wp_snm_logs）在激活钩子里用 dbDelta() 创建；结构变更不直接改表，而是把表结构版本号存进 option，每次加载时比对，不一致才执行迁移。别在每次加载时都跑 dbDelta——它不便宜。
3. REST 端点自己写 permission_callback
注册 REST 路由时省掉 permission_callback，WordPress 会回默认的 rest_forbidden；自己写一个，返回的错误码（如 snm_forbidden）就成了「插件在线且权限生效」的可验证信号——我们案例页上那个「访客可直接验证」的接口就是这么来的。安全上，能只读就只读，写操作一律上鉴权。
4. 双写换性能，幂等保生存
「这篇文章分发到了哪些站」是跨站查询，存全局表；「这篇文章的源在哪」是站内高频查询，存 post meta。两份都写，写入时多一步，两种读都快。而所有涉及复制的操作（尤其是媒体）必须幂等：用映射表记录「源附件 → 目标附件」的对应关系，重复同步不会产生第二份——没有幂等，媒体库迟早被重复文件撑爆。
5. 发布纪律：Stable tag 与主文件版本同步
主文件头注释升到了 1.1.0，readme.txt 的 Stable tag 还停在 1.0.1——这种不一致不会报错，但会让依赖版本判断的工具全部失灵。我们最后加了一步发布清单：版本号、readme、更新日志三处一起过。
这 5 条没有一条是高深的，但都是「当时省事了、后来还债」换来的。插件的完整案例（含架构决策与运行数据）见站群管理插件案例。