站点扩展的规划与取舍方法

站点级扩展和单个功能插件不同，它往往牵动导航、权限、搜索、通知等多个环节。做得好是能力放大，做不好是系统耦合。规划阶段最该问的问题不是“还能加什么”，而是“加进来之后谁负责、怎么退出”。

【先划能力边界，再排优先级】
把站点能力分成四层：内容层、互动层、账户层、运营层。内容层负责发布、分类、检索；互动层负责评论、私信、关注；账户层负责注册、认证、权限；运营层负责活动、公告、数据看板。每引入一个扩展，先明确它落在哪一层，是否跨越两层以上。跨层扩展耦合度高，要单独评估。优先级排序用两个维度：影响用户比例、缺失时的替代成本。影响面大且难以人工替代的排前面，影响面小且可临时人工处理的排后面。

【依赖管理与性能预算】
依赖管理要做两件事：记录扩展之间的调用关系，避免出现 A 依赖 B、B 又依赖 C 的链式结构；对共享资源做统一入口，例如统一的上传组件、统一的富文本编辑器，减少重复加载。性能预算则是在上线前设定可接受的增量：首屏资源增量、接口响应增量、数据库查询增量各设一个上限，超过上限的方案退回重做。预算不是精确科学，但它能迫使团队在方案阶段就考虑成本，而不是上线后被动优化。

【上线流程与灰度策略】
上线前准备三份材料：功能说明、回滚步骤、影响范围清单。功能说明写给运营看，讲清怎么用；回滚步骤写给技术看，讲清先停什么后停什么；影响范围清单写给所有人看，列出受影响的页面和角色。灰度策略按用户群分层：先内部账号，再活跃用户，最后全量。每一层观察指标包括错误率、页面加载、关键流程完成率。发现异常时按回滚步骤执行，不临时改代码救火。

【下线机制与长期治理】
扩展下线常被忽视，但它是治理的关键。为每个扩展设定评估周期，到期检查三项：使用频率、维护状态、替代方案是否成熟。三项都指向“可下线”时，先关闭入口观察一段时间，确认无内容依赖后再清理数据表和文件。长期治理建议每季度做一次能力盘点，画出当前能力地图，标出重复能力和空缺能力。重复能力合并，空缺能力再评估是否引入。站点扩展的本质是能力组合，组合清晰比数量丰富更重要。把退出路径设计好，扩展才不会变成负担。