建站周期，需求已取消但功能已开发时怎样评估留用或下线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d9b1c171906b.html
📄
建站周期，需求已取消但功能已开发时怎样评估留用或下线
先核对需求取消发生在哪个阶段：如果功能尚未进入真实用户路径，优先下线或封存；如果已有外部调用、合同承诺或数据依赖，则应改写为受控保留，而不是简单删除。判断依据不是沉没成本，而是继续保留会改变哪些后续动作。
保留的前提：它是否仍支撑当前业务
需求取消通常意味着目标变化，但功能本身可能仍在支撑别的东西。此时要区分“原需求”和“实际作用”。例如，一个为旧促销设计的报名入口，促销已取消，但后台仍用它汇总线下活动名单，那么它就从营销功能变成了数据入口。保留的前提是：有明确的使用者、明确的输入来源、明确的后续处理动作，三者缺一不可。
如果只有开发者知道它存在，没有页面入口，也没有定时任务或接口调用，保留的理由通常不成立。可以做一个短周期观察：假设未来两周内没有任何新数据写入、没有外部请求、没有人工导出，那么它更接近死代码，而不是待恢复功能。这里要注意，请求量归零不能单独证明可以删除，也可能是入口被隐藏、调用方尚未迁移或监控未覆盖；需要结合代码引用、数据库写入和人工确认一起看。
改写比保留更常见：把已开发功能降级为内部工具
很多已开发功能不值得继续面向用户，但可以改写成内部工具或临时校验手段。适用条件是：它依赖的数据仍然准确，操作者范围可控，且不会与当前主流程产生冲突。比如原计划给客户自助修改报价单，后来改为销售统一处理；这个功能可以保留为销售内部试算页，但必须去掉对外入口和自动通知。
改写的实际动作包括：关闭前台入口、限制账号范围、在页面或接口上标注内部用途、确认它不再触发对外邮件或订单状态。做完这些之后，下一步才能判断是否继续投入维护。如果改写成本高于重新实现，或者它依赖已下线的第三方服务，那么改写就不成立，应转向退出。
下线前先确认依赖，而不是先删代码
下线不是从代码库删除文件，而是先切断真实依赖。可以按以下顺序检查：
- 页面入口：导航、页脚、活动页、旧链接是否仍指向它。
- 接口调用：其他系统、定时任务、移动端或合作方是否仍请求它。
- 数据去向：它写入的表、文件或队列是否被报表、对账或人工流程使用。
- 账号与权限：是否有外部账号仍能登录并操作。
假设一个已开发的消息推送功能，原需求是通知客户订单变更，后来订单变更改为人工电话确认。此时直接删除推送代码，可能导致历史通知记录无法追溯。更稳妥的动作是：先停用发送开关，保留记录读取权限，观察一个结算周期。如果对账不需要这些记录，再安排彻底移除。这个动作的结果会直接影响下一步：能安全停用，才进入删除排期；不能停用，就转为受控保留并指定负责人。
退出时把决策写进后续排期
退出不是一句“不做了”。需要明确：谁确认不再需要、哪些入口已关闭、数据保留多久、是否通知相关使用方。如果这些没有落到具体排期，功能会以“暂时保留”的名义长期占用维护精力。对于建站周期而言，真正的成本往往不是当初开发用了多少时间，而是后续每次改版、升级依赖、排查故障时都要重新判断它能不能动。
因此，退出决策应产生一个可执行结果：从导航和站点地图移除、在代码中标注停用日期和原因、把数据导出或归档、把监控和告警关掉。完成这些之后，下一轮改版才不必再为它做兼容。反之，如果退出条件不具备，就应明确转为保留或改写，并指定复查时间，而不是继续以模糊状态存在。
