建站步骤，需求已取消但功能已开发时怎样评估留用或下线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a08cfee6fdf1.html
📄
建站步骤，需求已取消但功能已开发时怎样评估留用或下线
结论先行：在多数情况下，已开发但需求取消的功能应当下线，但有一个明确例外——如果该功能正在被真实用户使用，且下线成本高于维护成本，则可以留用并转为“维护模式”。判断的关键不是沉没成本，而是三个可验证的条件：当前是否有真实流量、是否产生数据依赖、是否与其他在跑功能耦合。
先分清“需求取消”的两种性质
需求取消不等于功能无用，要先区分取消的原因，因为不同原因指向不同决策。
- 业务方向变了：例如原计划做会员积分，后来公司转向只做一次性交付。这类功能通常可以下线，因为它服务的业务路径已经不存在。
- 优先级推迟：功能本身仍符合业务方向，只是这一期不做了。这类功能适合留用但隐藏入口，等条件成熟再启用。
区分方法很简单：问一句“如果明天资源充足，这个功能还会被排进计划吗？”如果答案是否定的，偏向下线；如果答案是肯定的，偏向留用。
用三个信号判断留用还是下线
不要凭感觉决定，用可观察的信号来判断。
信号一：是否有真实用户访问
查看该功能页面的访问日志或埋点数据。如果连续一段时间访问量接近于零，这支持下线，但要注意：访问量归零也可能是入口被隐藏、链接失效或统计代码未覆盖导致的，不能单独作为下线依据。需要交叉验证入口是否可达、统计是否正常。
信号二：是否被其他功能依赖
如果该功能写入了数据库表、生成了文件、被其他模块调用，直接删除可能引发连锁故障。此时更稳妥的做法是先标记为废弃，停止新入口，保留数据读取，观察一个周期后再决定物理删除。
信号三：维护成本是否持续产生
留用不是零成本。只要代码还在，就可能需要跟随框架升级、安全补丁、依赖更新。如果这个功能长期无人使用却每次升级都要额外处理，下线反而更省事。
一个假设例子：两种条件走向相反结论
假设某网站开发了“批量导出报表”功能，上线前业务部门取消了需求。情况A：该功能入口从未对外发布，无任何访问记录，且代码独立、无其他模块调用——此时应直接下线，删除路由和页面，减少后续维护面。情况B：测试期间已有运营人员习惯使用，且该功能生成的报表被用于每周对账——此时应留用，但把它从主导航移除，改为内部链接，并在代码注释中标注“非正式需求，仅供内部使用”。两种情况的前提不同，结论自然不同。
下线时的一个实际动作及其影响
决定下线后，不要直接删除代码。先执行一个动作：关闭功能入口，保留后端逻辑和数据表，观察一个完整业务周期（例如一个月）。这个动作的结果会直接影响下一步——如果周期内没有用户反馈找不到该功能，也没有其他系统报错，就可以进入物理删除；如果出现反馈或报错，说明存在未识别的依赖，需要先解除依赖再删除。这个动作把“删除”从一个不可逆操作变成可回退的两步，降低了误判风险。
什么情况下前面的结论会失效
如果该功能涉及合规留存、审计要求或已对外承诺的数据保留义务，那么即使需求取消、无人访问，也不能简单下线。此时应转为归档模式：停止功能入口，保留数据只读访问，并记录归档原因和责任人。这类情况需要根据实际业务约束判断，不能套用前面的通用结论。
下一步动作：先拉出该功能的访问记录和依赖清单，对照上面三个信号打分，再决定是关闭入口观察、转为维护模式，还是直接进入归档流程。
