网站开发必备要素：需求已取消但功能已开发，留用还是下线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ac528bc77301.html
📄
网站开发必备要素：需求已取消但功能已开发，留用还是下线
结论先给：如果这个功能已经上线、有人用、且维护它不会拖住主流程，可以留用并把它降级为“只修不扩”；如果它从未上线、没有真实入口、或者每次改动都要额外回归测试，就应下线。判断依据不是当初的需求是否取消，而是它现在是否还产生可验证的价值，以及保留它的边际成本是否会转嫁给下一次发布。
先区分两种“已开发”：能独立运行还是挂在主流程上
同样叫“功能已开发”，实际状态差别很大。一种是代码已经合并、有独立入口、可单独关闭；另一种是深度嵌入注册、下单、结算等主流程，关掉它要改动公共逻辑。前者留用的代价低，后者即使需求取消，也往往不能简单删除。
可以按三个条件判断：
- 入口是否独立：有单独页面或开关，留用不会影响主路径；没有独立入口、只能靠参数触发，通常说明它从未真正面向用户。
- 数据是否可读：能查到真实调用量或使用记录，说明可以量化判断；没有任何可观测数据，保留就只是凭感觉。
- 回归成本是否外溢：每次发布主流程都要顺带验证它，成本就落在别人身上，应优先下线。
一个假设例子：某后台功能已开发完成但入口未开放，代码独立、没有数据写入。此时留用等于长期背着一块死代码，下线更合理。反过来，如果它已对部分用户开放、有稳定调用，且关闭需要迁移历史数据，那么先留用、同时冻结新需求，通常是更稳的选择。
会使“留用”结论失效的反例
最容易误判的情况是：功能看起来有人在用，但用的人其实来自内部测试、爬虫或旧链接跳转。此时调用量不能证明真实需求。另一个反例是，功能虽然使用量低，却是合规、对账或售后流程的一部分，删掉会留下无法追溯的缺口。
所以看到调用量归零或很低时，不要直接当作可以下线的证据。它还可能来自入口被隐藏、埋点未覆盖、统计口径变更或页面本身加载失败。要先把这些解释逐一排除，再决定是否下线。
还有一种反例：需求取消只是因为业务方向调整，但功能本身已经被外部用户依赖。强行下线会带来投诉或数据迁移问题，这时应转为维护模式，而不是立即删除。
用一次可执行动作把判断落地
下一步动作建议是：给这个功能加一个可关闭开关，并设定一个观察窗口。假设窗口为四周，观察期内不推广、不新增入口，只记录真实调用和报错。窗口结束后按结果分三档处理：
- 有稳定真实调用：保留，标记为维护模式，只修缺陷，不接新需求。
- 调用接近零且无外部依赖：下线，删除入口和关联代码，确认没有旧链接或数据引用。
- 调用低但涉及数据留存：隐藏入口、保留数据读取能力，停止写入新数据。
这个动作的结果会直接决定下一步：如果关闭开关后主流程发布不再需要额外回归，说明它确实是独立负担，可以进入删除排期；如果关闭后出现报错或用户反馈，说明它仍被依赖，应回到维护模式并补上迁移方案。
下线前必须确认的迁移条件
决定下线后，真正的工作不是删代码，而是确认没有遗留引用。至少要检查：旧链接是否仍被外部页面指向、数据表是否还被其他功能读取、定时任务或消息队列是否仍在调用它。任何一项没有确认，删除都可能引发线上异常。
如果这些检查无法在发布前完成，就先隐藏入口并保留代码，把它从用户路径中移出，而不是直接物理删除。这样既降低了维护面，也保留了回退空间。
最终判断可以归结为一句话：需求取消只说明当初的理由不成立，不说明功能现在没有价值；留用还是下线，取决于它是否还有可验证的真实使用，以及保留它是否会让下一次改动变得更贵。
