站点扩展怎么挑：先画边界再选型

扩展选型最容易犯的错，是先看到功能列表再倒推需求。更稳的顺序是反过来：先把「不做什么」写清楚，再去比对候选方案。下面这套流程适合自建站点、内容站、小型社区等场景，用于在多个扩展之间做取舍。

功能边界：先划三条线
把需求拆成「必须有」「可以忍」「坚决不要」三档。必须有指缺了它业务就跑不通的能力，比如权限分级、内容审核流转、数据导出；可以忍指体验略差但能用替代流程解决的；坚决不要指会引入额外风险的能力，比如自动改写正文、强制注入脚本、对外回传数据。三条线写完后，你会发现候选方案往往只剩两三个，比较成本大幅下降。注意：不要因为某个扩展「顺便带了个功能」就把它列进必须有，附带能力通常是耦合来源。

兼容成本：看它和谁绑在一起
扩展的价值不只在于自身功能，还在于它依赖什么。重点核查四项：是否要求特定运行环境版本、是否改写核心数据结构、是否与其他扩展争抢同一处挂载点、升级时是否需要同步改动主题或模板。任何一项答案为「是」，都要在评估表里加一行迁移成本。判断方法很朴素：在测试环境装一遍、卸一遍，观察残留文件和配置项；残留越多，说明它对系统的侵入越深，将来更换的代价越大。

维护责任：谁为长期可用负责
扩展停更、接口变动、安全补丁滞后，是长期运营中最常见的三类隐患。选型时要问：出问题时谁能改、改动范围多大、回滚需要几步。优先选择配置项清晰、日志完整、可一键停用的方案；回避那些停用后页面直接报错、必须手工清理数据库的实现。若团队没有开发能力，应把「可停用性」放在功能丰富度之前。

使用步骤与自查清单
第一步，写出三档需求清单并排序；第二步，收集候选方案，逐一记录依赖项与侵入点；第三步，在测试环境完成安装、配置、停用、卸载四步验证；第四步，评估升级路径与回滚成本；第五步，形成一页结论，注明选择理由与放弃理由。自查清单：是否记录了停用后的页面状态；是否确认配置可导出；是否核对与现有扩展的挂载冲突；是否明确后续维护人。常见问题是只看演示效果不看卸载表现，结果换方案时被迫停机。把卸载当成选型的必测项，能省掉大部分后患。

补充一点判断框架：把每个候选方案按「功能覆盖、侵入程度、可停用性、维护活跃度」四项打分，前两项看当下，后两项看未来。当下分数接近时，一律选未来分数高的那个。这条规则在多数场景下比逐项对比更省时间。