网站设计方案：需求已取消但功能已开发时怎样评估留用或下线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /97134bddad78.html
📄
网站设计方案：需求已取消但功能已开发时怎样评估留用或下线
先算清“留着”与“拆掉”各自的持续成本，再决定。判断依据不是功能有没有人用，而是它是否仍在产生可核对的维护负担、暴露面或数据责任。如果功能已上线且无人报错，留用通常比下线更省事；如果它已进入回归测试清单、依赖外部接口或涉及用户数据，下线往往更划算。
先区分两种取消：需求取消但代码已合并，与需求取消但代码未上线
这两种情况的选择完全不同。代码已合并进主干并随版本发布，说明它已经在生产环境里运行，下线意味着一次新的变更、测试和回滚预案；代码只在特性分支或未合并的提交里，下线成本主要是删除分支和关闭相关任务，几乎不影响线上。
一个可操作的判断动作是：在版本记录里查这个功能的合并提交，确认它是否出现在任何一次生产发布中。如果答案是否定的，直接删除分支并记录原因即可，不需要评估留用。如果答案是肯定的，才进入下面的成本比较。
留用的成立条件：维护负担接近零，且不承担数据与合规责任
留用不是“懒得删”，而是有明确条件的。同时满足以下几条时，留用是合理选择：
- 不依赖任何外部接口、第三方服务或密钥，不会因为对方变更而被动失效；
- 不写入、不读取用户个人数据，因而不产生数据保留和删除义务；
- 不在任何自动化测试、监控告警或构建流程中被引用；
- 不在页面导航、搜索或站点地图中暴露入口，用户无法自然到达。
满足这些条件的功能，实际状态接近“死代码加一个不可达页面”。此时可以留用，但要做一个动作：在代码注释或内部文档里标注它的来源需求已取消、留用原因和复查触发条件，例如“下次重构该模块时一并删除”。这个动作的结果是，未来接手的人不必重新追溯一遍历史，也不会误以为它还有业务方在维护。
下线的成立条件：它已进入维护路径，或涉及数据与安全边界
只要出现下列任一情况，留用的隐性成本就开始累积，应当安排下线：
- 每次框架升级、依赖更新或样式调整，都要顺带验证它是否还能正常工作；
- 它调用外部接口，对方一旦调整参数或停用旧版本，报错会出现在你的监控里；
- 它处理用户提交内容或存储个人信息，需要纳入隐私政策和删除流程；
- 它的路由或接口对公网可达，构成额外的攻击面；
- 它出现在测试用例集合中，每次回归都要跑一遍无人关心的断言。
下线的实际动作分三步：先确认没有真实流量和外部调用方，可以查访问日志和接口调用记录；再从导航、路由和接口注册中移除入口，观察一个发布周期内是否出现报错；最后删除代码和数据表。第一步的结果决定后面两步能否直接做——如果仍有外部调用方，就不能直接删接口，只能先隐藏入口并通知调用方，把删除推迟到确认无人依赖之后。
用一组可核对的证据区分“没人用”和“不能用”
常见的反常结果是：功能上线后访问量极低，团队据此判断“没人需要”，于是留用或直接删除。但低访问量至少有三种解释，需要分别取证：
- 确实没有需求：入口可见、页面正常、无报错，访问量仍接近零。证据是页面可正常打开且入口在导航中。
- 入口不可达：功能本身可用，但没有任何链接指向它，用户只能靠直接输入地址访问。证据是站内链接检查显示零个内部链接指向该页面。
- 功能已损坏：有入口但点击后报错或空白。证据是监控或日志中出现该路径的错误记录。
这三种解释对应不同处理：第一种支持下线，第二种说明评估对象其实是入口而不是功能，第三种应先修复再评估。把访问量归零直接当作“可以删除”的证据，会掩盖后两种可能。
一个注明假设的短例子
假设某网站设计方案中有一个“邀请同事协作”的页面，需求在开发完成后被取消，代码已随版本上线。假设它不写数据库、只调用一个已停用的内部接口。此时它同时命中两条下线条件：调用外部接口、进入回归测试清单。合理动作是先移除页面入口和接口注册，观察一个发布周期；若监控无报错，再删除代码。反之，若该页面只是静态说明文字、无接口无数据、无内部链接指向，留用并标注复查条件即可，不必为删除它专门安排一次发布。
例外：先别删的几种情形
有几种情况即使满足下线条件，也应暂缓。功能涉及已产生的用户数据时，删除代码前要先确认数据保留期限和删除义务，否则可能违反已公示的隐私说明。功能是付费客户合同里明确承诺的能力时，需求取消只代表内部不再推广，不代表可以单方面移除。功能被其他模块以隐藏方式复用，例如共用同一张数据表或同一个工具函数时，直接删除会连带影响仍在使用的部分，此时应先解除耦合再下线。这些情形下，正确动作是把功能标记为“冻结”——停止迭代、保留入口、记录原因，而不是立即拆除。
