WordPress搬家，需求已取消但功能已开发时怎样评估留用或下线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7c7428ec2f7a.html
📄
WordPress搬家，需求已取消但功能已开发时怎样评估留用或下线
先看这个功能是否仍被真实业务使用、是否产生对外承诺或数据依赖，再决定留用还是下线。如果它已经无人使用、没有外部引用、数据可归档，下线更干净；如果它仍被内部流程、客户合同或历史数据查询依赖，即使当初的需求取消，也应留用并补维护说明。判断依据不是开发投入多少，而是继续运行会带来什么成本和风险。
先确认功能是否真的“无主”
需求取消只说明发起人不再推进，不等于功能没有使用者。搬家后要查三件事：访问日志里是否还有稳定请求；后台是否有角色或账号仍在调用；数据库里是否持续写入新记录。若三项都接近零，只能说明当前没有明显使用，不能单独证明可以安全删除，因为定时任务、外部接口回调、邮件模板或静态页面引用都可能不经过普通访问日志。
实际操作可以先在旧环境和新环境各跑一轮检查：导出最近一段时间的访问记录，搜索该功能的入口路径和接口地址；在代码库中搜索函数名、短代码、模板文件和钩子名；在数据库中查该功能专属数据表是否有近期新增行。把结果记成一张表，再进入下面的取舍。
条件一：仍有业务或数据依赖时，留用并补维护边界
当功能被以下任一情况绑定时，优先留用：客户合同或对外页面仍承诺该能力；财务、订单、会员等数据与它关联；内部人员每周仍在用它处理事务；已有内容中嵌入了它的短代码或区块。此时下线会造成承诺落空或数据断裂，修复成本通常高于保留。
留用不等于原样放着。搬家后应做三个动作：第一，为该功能补一份最小维护说明，写清入口、依赖的插件或主题文件、数据表名和负责人；第二，在代码中标注“需求已取消，因某依赖保留”，避免后来者误删；第三，给它加一层可观测性，例如记录调用次数和报错，设定一个复查周期。做完这些，下一次评估才有依据，而不是继续凭印象争论。
假设一个例子：某活动报名功能的需求已取消，但历史报名数据仍被客服用于核对。此时把功能整体删除会让客服失去查询入口，合理做法是保留只读查询、关闭前台新报名入口。这个动作的结果是前台不再产生新数据，后台仍可查旧记录，下一步只需定期确认查询是否还有必要。
条件二：无业务依赖且可归档时，下线并清理入口
如果确认没有外部承诺、没有关联数据写入、没有内部流程使用，下线比留用更省事。留用的隐性成本包括：每次搬家都要重新验证；依赖的旧插件或旧代码可能与新环境冲突；废弃入口可能被扫描或误用；后来者需要反复判断它是否重要。这些成本不会因为功能“不占地方”而消失。
下线动作要按顺序做，避免先删代码后才发现还有引用。第一步，关闭前台入口和公开接口，观察一段时间是否有报错或询问；第二步，导出该功能的数据并归档到可检索的位置，记录归档时间和字段说明；第三步，移除模板、短代码、钩子和相关文件；第四步，在搬家检查清单中标记该项已处理。每一步的结果决定下一步：如果关闭入口后出现异常请求，说明还有未发现的依赖，应暂停删除并回到留用分支。
用一组可区分原因的证据做最终判断
下面这组信号可以帮助区分“暂时没人用”和“确实可以删”：
- 访问记录为零，但定时任务日志仍有执行记录：更可能是后台依赖，不能直接删。
- 访问记录为零，代码库中也没有模板或短代码引用：可以进入归档流程。
- 数据表无新增，但存在外键关联或导出报表引用：保留数据，先下线界面。
- 有内部人员偶尔使用，但没有对外承诺：可先关闭公开入口，保留内部权限，再约定复查时间。
这些信号都不是单独成立的证据。请求量归零可能只是入口被隐藏、统计未覆盖或访问转移到了其他路径；代码搜索无结果也可能因为引用写在数据库内容或序列化配置里。因此至少交叉两项以上再决定。
搬家过程中的执行顺序与例外
在WordPress搬家中，处理这类功能应放在数据迁移之后、正式切换之前。先在新环境还原数据库和文件，再按上面的条件判断留用或下线，最后做一次入口和报错检查。若时间紧张，优先保证留用分支的功能可用，下线分支可以延后清理，但必须记录待办，避免旧入口在新环境继续暴露。
例外情况有两种：一是功能涉及合规留存或审计要求，即使无人使用也不能删除，只能限制访问；二是功能依赖的第三方服务已经停止或无法确认状态，此时不应假设它仍可用，应改为静态归档页面并说明数据范围。无论哪种例外，都要把决定和理由写进搬家记录，供下一次复查使用。
