一次迭代评审会上产品经理指着功能列表第 149 项问“这个功能到底有没有人在用”全场安静了三秒。这个场景在软件团队里太常见了。功能上线之后没人用但代码不会自动消失它会一直留在系统里占着维护成本、测试回归范围、接口文档篇幅甚至拖慢启动速度。“没用的功能介绍”不是一句吐槽而是研发团队绕不开的工程问题怎么定义“没用”怎么量化“没人用”怎么在不动业务的前提下把无用功能收敛掉。这篇文章不聊某个具体项目的安装部署而是讲清楚一套可落地的功能治理方案。你会看到功能数据的埋点设计、调用量统计 SQL、Feature Flag 下线策略、回归验证清单以及一套从“怀疑没用”到“确认下线”的流程。这套方法适用于 Web 应用、微服务、App 客户端也适用于你本地维护的任何内部工具。1. 核心能力速览能力项说明适用范围Web 后端接口、前端页面、App 功能模块、内部工具、微服务核心目标识别真正无人使用的功能降低维护成本与技术债判断依据埋点数据、接口调用日志、数据库操作记录、用户反馈主要手段功能埋点、日志分析、Feature Flag、灰度下线、代码清理启动成本低不依赖重平台日志 定时任务即可跑通是否支持批量任务支持批量统计功能调用量、批量生成废弃清单是否支持 API 接入支持统计数据可写入监控平台或导出报表关键收益减少无用代码维护量、缩小回归测试范围、降低接口被恶意调用的风险请先记住一个前提没有数据的“感觉没用”不算数必须用调用量数据说话。2. 适用场景与使用边界这套方法适合以下场景老项目接手开发人员自己都说不清某些接口为什么存在。功能迭代多年配置项越来越多默认参数没人敢动。团队准备做一次代码重构或服务拆分需要先确定哪些模块可以放弃。接口文档越来越长但导出的接口清单里有大量低调用量接口。管理层希望对技术债做一次量化盘点用数据驱动决策。边界也很明确不能用“调用量低”替代产品价值判断。有些低频功能是核心业务兜底比如退款、申诉、权限审批调用少但绝不能下线。这类功能必须结合业务评估。不能只统计一天的数据。要覆盖完整的业务周期至少统计 30 天最好包含月初、月末、节假日等特殊日期。下线操作必须保留回滚方案。即使数据再充分也可能存在未被统计到的调用方。涉及用户数据的功能下线前要评估数据保留与迁移方案。这个不需要多解释和合规直接相关。3. “无用功能”的判断标准与数据来源一个有资格进入“废弃候选清单”的功能需要同时满足以下几条这里给出判断标准判断维度标准调用量连续 60 天调用量低于阈值阈值按业务量级自行定义比如日调用 10 次用户覆盖调用来源集中在极少数测试 IP 或内部账号业务相关性接口、页面或配置项与当前核心业务流程无直接关联数据写入长期没有产生新的业务数据或产生的数据无人消费替代方案存在可以完全替代该功能的其他模块或接口判断需要的数据来源主要有四类接入层日志Nginx/Access Log、网关日志能统计接口请求量、来源 IP、UA。应用日志业务代码中打印的功能调用日志能统计某个功能分支的执行次数。数据库记录核心表的创建时间、更新时间分布能判断业务是否还在产生数据。前端埋点页面曝光事件、按钮点击事件配合 SDK 或手动埋点。把这些数据全部按照功能维度聚合就会得到一张功能使用热度表。4. 功能调用量与使用率分析直接看日志是最快的方式。假设你有一个网关层日志记录了每个请求的路径、来源 IP、时间下面是一段通用的统计 SQL可以按天统计每个接口的调用量SELECT DATE(request_time) AS day, uri_path, COUNT(*) AS call_count, COUNT(DISTINCT client_ip) AS user_count FROM access_log WHERE request_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(request_time), uri_path ORDER BY call_count ASC LIMIT 200;如果日志存放在 Elasticsearch 或 ClickHouse 中查询思路类似只是语法不同。重点不是 SQL 本身而是你要先有一个“功能到 URI 的映射表”。很多接口路径不直观比如/api/v1/internal/status/check这种路径必须靠代码搜索确认它对应哪个功能。更体系化的做法是建立功能调用统计表定期把结果写入一个汇总表CREATE TABLE feature_call_stats ( feature_name VARCHAR(128) NOT NULL, uri_path VARCHAR(256) NOT NULL, stat_date DATE NOT NULL, call_count INT DEFAULT 0, user_count INT DEFAULT 0, source_system VARCHAR(64), PRIMARY KEY (feature_name, stat_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;然后写一个定时任务每天凌晨从日志表聚合并写入。连续跑 30 天以后查一次低于阈值的结果废弃候选清单就出来了SELECT feature_name, uri_path, SUM(call_count) AS total_calls, COUNT(DISTINCT stat_date) AS active_days FROM feature_call_stats WHERE stat_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY feature_name, uri_path HAVING total_calls 100 OR active_days 5 ORDER BY total_calls ASC;补充一点使用率分析不只是做一次上线这个统计任务本身就是“治理无用功能”的一部分。没有统计数据后面的下线动作都是拍脑袋。5. 半自动识别关键词扫描与功能清单比对有了统计表还要做一层“代码层面的交叉验证”目的是避免遗漏掉那些没有被日志覆盖的隐藏调用入口。一个简单但有效的办法是在代码仓库里做关键词扫描。假设你怀疑一个名为deprecated_job_executor的功能模块没人使用那就全局搜索它的类名、方法名、Bean 名称、URL 路径等关键词# 搜索引用该功能的代码位置确认是否还有调用入口 grep -rn deprecated_job_executor src/ config/ jobs/ --include*.java --include*.xml --include*.yml如果搜索结果为空或者只有定义处没有任何调用方那么这个模块基本可以判断为死代码。如果搜索结果明确显示某个定时任务还在触发它就要回到日志统计确认触发后有没有实际执行业务逻辑。更进一步可以把所有接口路径拉出来与代码仓库里的RequestMapping、GetMapping等注解做一次交叉比对。这一步可以用简单的 Python 脚本完成核心思路是解析代码仓库中的路由定义生成“代码内已定义接口集合”。解析网关日志或接口文档中的“线上实际调用接口集合”。两个集合取差集代码里有但线上不调用的接口就是最值得怀疑的候选者。import re from pathlib import Path # 示例脚本从 Controller 文件中提取接口路径 # 实际使用中需要根据项目语言和框架调整正则表达式 controller_dir Path(./src/main/java/com/example/controller) defined_routes set() for file_path in controller_dir.rglob(*.java): content file_path.read_text(encodingutf-8) # 提取 RequestMapping 路径 paths re.findall(rRequestMapping\(\s*[\]([^\])[\]\s*\), content) # 提取 GetMapping/PostMapping/PutMapping/DeleteMapping 路径 paths re.findall(r(?:Get|Post|Put|Delete)Mapping\(\s*[\]([^\])[\]\s*\), content) defined_routes.update(paths) print(代码中定义的路由总数:, len(defined_routes)) for route in sorted(defined_routes)[:50]: print(route)注意这只是一个辅助脚本实际项目里的路由定义可能包含动态路径参数、多个 Controller、注解继承等情况所以脚本结果只能作为线索不能直接作为下线依据。6. 无用功能的处理策略与下线流程当候选清单确认之后不要直接把代码删除要分级处理。从材料来看稳妥的路径是“先收敛、再替换、最后清理”。处理策略适用情况操作方式风险等级入口下线功能仍有潜在用途但入口暴露风险高在前端隐藏入口、在后端关闭路由注册低灰度停止调用方不明确需要观察通过 Feature Flag 关闭功能保留回滚开关中逻辑保留配置关闭代码改动风险大先验证是否有人依赖通过配置中心关闭定时任务或消息消费者中完全删除确认无调用、无数据、无业务需求删除代码、数据库表、接口文档、测试用例高其中最推荐先做的是Feature Flag 方案也就是功能开关。在配置中心加一个开关默认关闭目标功能观察一段时间流量。如果关闭后没有产生新的线上问题、没有新增相关工单再进入代码删除阶段。一个比较典型的 Feature Flag 配置结构如下feature_flags: legacy_job_executor: enabled: false owner: backend-team created_at: 2025-01-15 description: 旧版定时任务执行器2025年2月计划下线业务代码里通过开关控制执行分支这是很通用的做法from flask import current_app def run_legacy_job(): flag current_app.config.get(FEATURE_FLAGS, {}) if not flag.get(legacy_job_executor, {}).get(enabled, False): current_app.logger.info(legacy_job_executor disabled, skip) return # 原有逻辑继续执行 do_something()这样即使盲目依赖旧功能的下游系统还在调用也不会真的执行核心业务逻辑服务端会返回一个明确的空结果或 404。等开关关闭并观察 2 到 4 周后确认没有任何异常再开始删代码。删除时要包含以下内容业务代码类与方法。数据库表结构如有专用表需要先备份再删除。接口文档中的对应 API。测试用例。配置项。前端对应的页面、组件与路由。7. 资源占用与性能观察方式“无用功能”不是安安静静躺在代码里的它同样会消耗资源。治理前后的资源对比能直接支撑后续决策。建议重点观察这几个维度观察对象治理前可能存在的问题如何观察服务启动时间无用功能模块被 Spring/Guice 扫描到执行了多余初始化对比关闭开关前后的冷启动时间内存占用无用对象被缓存、提前加载到内存观察 JVM / Node 进程的 Resident Set Size日志量无用功能每次执行都打印日志混入日志系统统计按功能维度过滤日志条数数据库连接池废弃定时任务的连接占用了连接池上限观察连接池活跃连接数接口文档数量废弃接口仍然出现在 Swagger 文档中对比治理前后接口文档总数在实际操作中先记录治理前的一组基线指标比如启动耗时、接口平均响应时间、内存占用曲线下线后跑一轮同样的压测或观察再对比数据。不要凭感觉说“变快了”要有数字。8. 常见问题与排查方法问题现象可能原因排查方式解决方案统计数据显示零调用但代码搜索有引用引用发生在初始化阶段不是业务调用检查引用位置是否在构造器、启动监听器区分“初始化依赖”和“业务调用”初始化依赖可以通过懒加载去除功能关闭后下游报错下游系统仍通过接口调用该功能检查网关日志中来源 IP 和调用方标识先不下线联系调用方确认后协商改造方案删除代码后启动失败存在动态反射或字符串路径调用启动时观察 NoClassDefFoundError 或 Bean 缺失日志回滚删除操作补充调用链分析统计口径与真实行为不一致多个微服务共用同一个 URI或网关做了路径重写核对网关转发规则与业务日志链路 ID按链路 ID 重新聚合确保统计维度准确数据表清理后历史报表异常历史报表依赖已删表检查报表 SQL 关联表保留数据备份提供临时视图供报表查询排查的核心原则只有一个每一步操作都要能回滚。9. 功能治理最佳实践与使用建议做一次完整的无用功能治理建议按下面的节奏推进先建统计再做判断。没跑完一个完整业务周期的数据之前不要下结论。给每个废弃候选功能打标签。标签建议包含功能名称、怀疑理由、统计周期、调用量、代码路径、负责人、建议处理方式。小步试点先拿一个不影响核心链路的边缘功能走完整个下线流程。通过这个试点验证日志统计、开关控制、回滚机制都可用再铺开到其他功能。每一次下线都要走版本发布流程不能直接在主干改代码。即使功能没用也要留给团队 Review 和备案。保留一个异常开关。如果下线的功能在观察期被用户反馈“还在使用”需要能第一时间通过配置中心恢复。批量处理时给任务增加失败重试和告警。如果团队用脚本批量修改代码或批量下线配置建议配置一个通知渠道失败时及时收到通知。与产品团队同步一份数据报告。调用量数据不仅是研发内部的技术债证据也是产品功能迭代的重要输入。如果团队里还没有功能治理机制可以从最简单的方案开始写一个日志统计脚本 一个共享表格每周更新一次。等数据积累到一定程度自然会发现哪些功能可以下线。这个过程不需要购买额外平台也不一定需要引入复杂的配置中心。10. 总结与下一步这篇内容从“第 149 个没用的功能”这个具体场景出发梳理了一套从数据收集、调用量分析、候选清单生成、Feature Flag 下线到代码清理的完整流程。重点不是教你用某个工具而是提供一个可复制的方法先统计再怀疑最后处理。最有价值的一步是先把你自己的接口日志按功能维度聚合起来输出第一张“功能使用热度表”这个动作一天之内就能完成。最容易踩的坑是直接删代码正确的做法永远是先通过开关收敛观察周期走完后再删。如果你正在维护的老项目已经出现了“接口清单膨胀、没人敢动配置、功能互相嵌套”的情况这篇文章建议收藏备用。下一步可以从统计 30 天日志开始把“感觉没用”变成“数据证明没用”。
用数据驱动治理无用功能：调用量统计与Feature Flag下线实践
一次迭代评审会上产品经理指着功能列表第 149 项问“这个功能到底有没有人在用”全场安静了三秒。这个场景在软件团队里太常见了。功能上线之后没人用但代码不会自动消失它会一直留在系统里占着维护成本、测试回归范围、接口文档篇幅甚至拖慢启动速度。“没用的功能介绍”不是一句吐槽而是研发团队绕不开的工程问题怎么定义“没用”怎么量化“没人用”怎么在不动业务的前提下把无用功能收敛掉。这篇文章不聊某个具体项目的安装部署而是讲清楚一套可落地的功能治理方案。你会看到功能数据的埋点设计、调用量统计 SQL、Feature Flag 下线策略、回归验证清单以及一套从“怀疑没用”到“确认下线”的流程。这套方法适用于 Web 应用、微服务、App 客户端也适用于你本地维护的任何内部工具。1. 核心能力速览能力项说明适用范围Web 后端接口、前端页面、App 功能模块、内部工具、微服务核心目标识别真正无人使用的功能降低维护成本与技术债判断依据埋点数据、接口调用日志、数据库操作记录、用户反馈主要手段功能埋点、日志分析、Feature Flag、灰度下线、代码清理启动成本低不依赖重平台日志 定时任务即可跑通是否支持批量任务支持批量统计功能调用量、批量生成废弃清单是否支持 API 接入支持统计数据可写入监控平台或导出报表关键收益减少无用代码维护量、缩小回归测试范围、降低接口被恶意调用的风险请先记住一个前提没有数据的“感觉没用”不算数必须用调用量数据说话。2. 适用场景与使用边界这套方法适合以下场景老项目接手开发人员自己都说不清某些接口为什么存在。功能迭代多年配置项越来越多默认参数没人敢动。团队准备做一次代码重构或服务拆分需要先确定哪些模块可以放弃。接口文档越来越长但导出的接口清单里有大量低调用量接口。管理层希望对技术债做一次量化盘点用数据驱动决策。边界也很明确不能用“调用量低”替代产品价值判断。有些低频功能是核心业务兜底比如退款、申诉、权限审批调用少但绝不能下线。这类功能必须结合业务评估。不能只统计一天的数据。要覆盖完整的业务周期至少统计 30 天最好包含月初、月末、节假日等特殊日期。下线操作必须保留回滚方案。即使数据再充分也可能存在未被统计到的调用方。涉及用户数据的功能下线前要评估数据保留与迁移方案。这个不需要多解释和合规直接相关。3. “无用功能”的判断标准与数据来源一个有资格进入“废弃候选清单”的功能需要同时满足以下几条这里给出判断标准判断维度标准调用量连续 60 天调用量低于阈值阈值按业务量级自行定义比如日调用 10 次用户覆盖调用来源集中在极少数测试 IP 或内部账号业务相关性接口、页面或配置项与当前核心业务流程无直接关联数据写入长期没有产生新的业务数据或产生的数据无人消费替代方案存在可以完全替代该功能的其他模块或接口判断需要的数据来源主要有四类接入层日志Nginx/Access Log、网关日志能统计接口请求量、来源 IP、UA。应用日志业务代码中打印的功能调用日志能统计某个功能分支的执行次数。数据库记录核心表的创建时间、更新时间分布能判断业务是否还在产生数据。前端埋点页面曝光事件、按钮点击事件配合 SDK 或手动埋点。把这些数据全部按照功能维度聚合就会得到一张功能使用热度表。4. 功能调用量与使用率分析直接看日志是最快的方式。假设你有一个网关层日志记录了每个请求的路径、来源 IP、时间下面是一段通用的统计 SQL可以按天统计每个接口的调用量SELECT DATE(request_time) AS day, uri_path, COUNT(*) AS call_count, COUNT(DISTINCT client_ip) AS user_count FROM access_log WHERE request_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(request_time), uri_path ORDER BY call_count ASC LIMIT 200;如果日志存放在 Elasticsearch 或 ClickHouse 中查询思路类似只是语法不同。重点不是 SQL 本身而是你要先有一个“功能到 URI 的映射表”。很多接口路径不直观比如/api/v1/internal/status/check这种路径必须靠代码搜索确认它对应哪个功能。更体系化的做法是建立功能调用统计表定期把结果写入一个汇总表CREATE TABLE feature_call_stats ( feature_name VARCHAR(128) NOT NULL, uri_path VARCHAR(256) NOT NULL, stat_date DATE NOT NULL, call_count INT DEFAULT 0, user_count INT DEFAULT 0, source_system VARCHAR(64), PRIMARY KEY (feature_name, stat_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;然后写一个定时任务每天凌晨从日志表聚合并写入。连续跑 30 天以后查一次低于阈值的结果废弃候选清单就出来了SELECT feature_name, uri_path, SUM(call_count) AS total_calls, COUNT(DISTINCT stat_date) AS active_days FROM feature_call_stats WHERE stat_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY feature_name, uri_path HAVING total_calls 100 OR active_days 5 ORDER BY total_calls ASC;补充一点使用率分析不只是做一次上线这个统计任务本身就是“治理无用功能”的一部分。没有统计数据后面的下线动作都是拍脑袋。5. 半自动识别关键词扫描与功能清单比对有了统计表还要做一层“代码层面的交叉验证”目的是避免遗漏掉那些没有被日志覆盖的隐藏调用入口。一个简单但有效的办法是在代码仓库里做关键词扫描。假设你怀疑一个名为deprecated_job_executor的功能模块没人使用那就全局搜索它的类名、方法名、Bean 名称、URL 路径等关键词# 搜索引用该功能的代码位置确认是否还有调用入口 grep -rn deprecated_job_executor src/ config/ jobs/ --include*.java --include*.xml --include*.yml如果搜索结果为空或者只有定义处没有任何调用方那么这个模块基本可以判断为死代码。如果搜索结果明确显示某个定时任务还在触发它就要回到日志统计确认触发后有没有实际执行业务逻辑。更进一步可以把所有接口路径拉出来与代码仓库里的RequestMapping、GetMapping等注解做一次交叉比对。这一步可以用简单的 Python 脚本完成核心思路是解析代码仓库中的路由定义生成“代码内已定义接口集合”。解析网关日志或接口文档中的“线上实际调用接口集合”。两个集合取差集代码里有但线上不调用的接口就是最值得怀疑的候选者。import re from pathlib import Path # 示例脚本从 Controller 文件中提取接口路径 # 实际使用中需要根据项目语言和框架调整正则表达式 controller_dir Path(./src/main/java/com/example/controller) defined_routes set() for file_path in controller_dir.rglob(*.java): content file_path.read_text(encodingutf-8) # 提取 RequestMapping 路径 paths re.findall(rRequestMapping\(\s*[\]([^\])[\]\s*\), content) # 提取 GetMapping/PostMapping/PutMapping/DeleteMapping 路径 paths re.findall(r(?:Get|Post|Put|Delete)Mapping\(\s*[\]([^\])[\]\s*\), content) defined_routes.update(paths) print(代码中定义的路由总数:, len(defined_routes)) for route in sorted(defined_routes)[:50]: print(route)注意这只是一个辅助脚本实际项目里的路由定义可能包含动态路径参数、多个 Controller、注解继承等情况所以脚本结果只能作为线索不能直接作为下线依据。6. 无用功能的处理策略与下线流程当候选清单确认之后不要直接把代码删除要分级处理。从材料来看稳妥的路径是“先收敛、再替换、最后清理”。处理策略适用情况操作方式风险等级入口下线功能仍有潜在用途但入口暴露风险高在前端隐藏入口、在后端关闭路由注册低灰度停止调用方不明确需要观察通过 Feature Flag 关闭功能保留回滚开关中逻辑保留配置关闭代码改动风险大先验证是否有人依赖通过配置中心关闭定时任务或消息消费者中完全删除确认无调用、无数据、无业务需求删除代码、数据库表、接口文档、测试用例高其中最推荐先做的是Feature Flag 方案也就是功能开关。在配置中心加一个开关默认关闭目标功能观察一段时间流量。如果关闭后没有产生新的线上问题、没有新增相关工单再进入代码删除阶段。一个比较典型的 Feature Flag 配置结构如下feature_flags: legacy_job_executor: enabled: false owner: backend-team created_at: 2025-01-15 description: 旧版定时任务执行器2025年2月计划下线业务代码里通过开关控制执行分支这是很通用的做法from flask import current_app def run_legacy_job(): flag current_app.config.get(FEATURE_FLAGS, {}) if not flag.get(legacy_job_executor, {}).get(enabled, False): current_app.logger.info(legacy_job_executor disabled, skip) return # 原有逻辑继续执行 do_something()这样即使盲目依赖旧功能的下游系统还在调用也不会真的执行核心业务逻辑服务端会返回一个明确的空结果或 404。等开关关闭并观察 2 到 4 周后确认没有任何异常再开始删代码。删除时要包含以下内容业务代码类与方法。数据库表结构如有专用表需要先备份再删除。接口文档中的对应 API。测试用例。配置项。前端对应的页面、组件与路由。7. 资源占用与性能观察方式“无用功能”不是安安静静躺在代码里的它同样会消耗资源。治理前后的资源对比能直接支撑后续决策。建议重点观察这几个维度观察对象治理前可能存在的问题如何观察服务启动时间无用功能模块被 Spring/Guice 扫描到执行了多余初始化对比关闭开关前后的冷启动时间内存占用无用对象被缓存、提前加载到内存观察 JVM / Node 进程的 Resident Set Size日志量无用功能每次执行都打印日志混入日志系统统计按功能维度过滤日志条数数据库连接池废弃定时任务的连接占用了连接池上限观察连接池活跃连接数接口文档数量废弃接口仍然出现在 Swagger 文档中对比治理前后接口文档总数在实际操作中先记录治理前的一组基线指标比如启动耗时、接口平均响应时间、内存占用曲线下线后跑一轮同样的压测或观察再对比数据。不要凭感觉说“变快了”要有数字。8. 常见问题与排查方法问题现象可能原因排查方式解决方案统计数据显示零调用但代码搜索有引用引用发生在初始化阶段不是业务调用检查引用位置是否在构造器、启动监听器区分“初始化依赖”和“业务调用”初始化依赖可以通过懒加载去除功能关闭后下游报错下游系统仍通过接口调用该功能检查网关日志中来源 IP 和调用方标识先不下线联系调用方确认后协商改造方案删除代码后启动失败存在动态反射或字符串路径调用启动时观察 NoClassDefFoundError 或 Bean 缺失日志回滚删除操作补充调用链分析统计口径与真实行为不一致多个微服务共用同一个 URI或网关做了路径重写核对网关转发规则与业务日志链路 ID按链路 ID 重新聚合确保统计维度准确数据表清理后历史报表异常历史报表依赖已删表检查报表 SQL 关联表保留数据备份提供临时视图供报表查询排查的核心原则只有一个每一步操作都要能回滚。9. 功能治理最佳实践与使用建议做一次完整的无用功能治理建议按下面的节奏推进先建统计再做判断。没跑完一个完整业务周期的数据之前不要下结论。给每个废弃候选功能打标签。标签建议包含功能名称、怀疑理由、统计周期、调用量、代码路径、负责人、建议处理方式。小步试点先拿一个不影响核心链路的边缘功能走完整个下线流程。通过这个试点验证日志统计、开关控制、回滚机制都可用再铺开到其他功能。每一次下线都要走版本发布流程不能直接在主干改代码。即使功能没用也要留给团队 Review 和备案。保留一个异常开关。如果下线的功能在观察期被用户反馈“还在使用”需要能第一时间通过配置中心恢复。批量处理时给任务增加失败重试和告警。如果团队用脚本批量修改代码或批量下线配置建议配置一个通知渠道失败时及时收到通知。与产品团队同步一份数据报告。调用量数据不仅是研发内部的技术债证据也是产品功能迭代的重要输入。如果团队里还没有功能治理机制可以从最简单的方案开始写一个日志统计脚本 一个共享表格每周更新一次。等数据积累到一定程度自然会发现哪些功能可以下线。这个过程不需要购买额外平台也不一定需要引入复杂的配置中心。10. 总结与下一步这篇内容从“第 149 个没用的功能”这个具体场景出发梳理了一套从数据收集、调用量分析、候选清单生成、Feature Flag 下线到代码清理的完整流程。重点不是教你用某个工具而是提供一个可复制的方法先统计再怀疑最后处理。最有价值的一步是先把你自己的接口日志按功能维度聚合起来输出第一张“功能使用热度表”这个动作一天之内就能完成。最容易踩的坑是直接删代码正确的做法永远是先通过开关收敛观察周期走完后再删。如果你正在维护的老项目已经出现了“接口清单膨胀、没人敢动配置、功能互相嵌套”的情况这篇文章建议收藏备用。下一步可以从统计 30 天日志开始把“感觉没用”变成“数据证明没用”。