站点扩展评估：从需求到取舍

站点扩展的诱惑在于“装上就多一个功能”，但每引入一个扩展，站点就多一层不确定性。与其逐个试用，不如先建立一套从需求出发的评估路径：先判断需求属于哪一类，再看扩展的依赖关系、作用边界和失效模式，最后做取舍。

【第一步：把需求分成三类】
第一类是基础能力，比如内容展示、访问控制、数据备份，这类需求应当优先用系统自带能力满足，扩展只做补充。第二类是效率增强，比如批量操作、快捷入口，这类可以引入扩展，但要接受它可能随主程序变化而失效。第三类是实验性需求，比如某种新的内容组织方式，适合先用轻量方案验证，验证有效再考虑固化。分类的意义在于设定预期：基础能力要求稳定，效率增强允许波动，实验性需求允许放弃。把三类混在一起比较，就会得出错误结论。

【第二步：查依赖与作用边界】
依赖包括对主程序版本的依赖、对其他扩展的依赖、对外部服务的依赖。逐项确认：是否声明了兼容范围；是否要求先安装别的扩展；是否在运行时请求外部资源。作用边界则看它影响哪些页面、哪些数据表、哪些用户角色。一个只在管理后台生效的扩展，风险远小于一个影响所有前台页面的扩展。操作建议：在测试环境启用后，逐页浏览并对比启用前后的请求与渲染差异，把受影响的范围记下来，形成一张影响清单。

【第三步：推演失效模式】
失效模式指扩展出问题时会发生什么：是局部功能消失，还是整页报错；是静默失败，还是给出提示；能否一键停用而不影响其他功能；停用后数据是否还在。评估方法：在测试环境直接停用扩展，观察站点是否正常；再模拟主程序升级，观察扩展是否阻断流程。注意事项：优先选择能安全停用的扩展，避免那种停用后留下残缺数据或页面错位的方案。失效模式清晰的扩展，即使出问题也可控。

【第四步：算总账再做取舍】
总账包括安装成本、配置成本、学习成本、长期维护成本，以及它替代掉的人工操作量。一个扩展如果只是把三次点击变成一次，却带来持续的升级负担，就不划算；如果它替代的是每天重复的批量操作，价值就明显。取舍原则：能用配置解决的不用扩展，能用轻量脚本解决的不用重型扩展，能合并的不要拆成多个。每季度回顾一次已启用的扩展，停用长期不用的，减少升级链路。

【常见误区与检查表】
误区一：把扩展数量当作能力象征，实际只增加维护面。误区二：在正式环境直接试装，出问题再补救。误区三：忽视卸载残留，换扩展后旧数据仍在影响查询。检查表：是否在测试环境验证过；是否记录影响范围；是否确认可安全停用；是否评估过升级影响；是否有明确的停用条件。五项都通过再引入，能避开大部分后期麻烦。