要确认代码是否被调用，需追踪引用链：先用 grep 全局搜索，再验证调用路径是否活跃，辅以 Codex 分析和运行时日志/断点观察，覆盖所有入口场景。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要确认一段代码是否还被项目其他地方调用，不能只看它自己有没有语法错误或能否单独运行，必须主动追踪它的引用链——函数名改了但调用处没同步、接口字段删了但前端还在取值、类方法移走了但继承链里还有 super()，这些都会导致运行时报错。
全局搜索函数/变量名
打开终端，进入项目根目录，执行：grep -r "functionName" . --include="*.js" --include="*.ts" --include="*.py" --include="*.java"。
这一步会递归扫描所有主流语言文件，比 IDE 的“查找引用”更底层、更可靠。IDE 有时会漏掉字符串拼接调用、动态 import 或 eval 场景，而 grep 不管逻辑，只认字面量。
如果返回结果只有定义行本身，没有其他 【调用位置】，那大概率已废弃；但若出现 user.service.js:42: await userService.getUserName(); 这类明确调用，则必须继续验证该调用是否真实生效。
检查调用方是否仍处于活跃路径
找到调用位置后，不要停在那一行。顺着调用栈往上追：这个调用是谁触发的？它所在的函数是否被更高层调用？入口是否还在路由表、事件监听器、定时任务列表中？
例如发现 calculateFee() 在 orderController.ts 中被调用，那就立刻查：
① orderController.ts 是否被 router.ts 引入并注册；
② 对应的 API 路由是否还在 Swagger 文档或 Postman 集合里；
③ 前端页面是否仍有按钮点击后发此请求。
很多“看似被调用”的代码，其实挂在已下线的旧管理后台里，或者只存在于被注释掉的测试用例中。不验证调用链终点，就等于没验证。
通过 codex-reset-radar.pages.dev 监控 Codex 使用重置窗口。轮询 current.json，检测窗口开启/关闭、预测等级变化以及概率跳变。
用 Codex 辅助识别隐式调用
方法一：直接让 Codex 扫描整个项目上下文，输入指令：“请列出所有调用 【getUserById】 的位置，并说明每个调用是否仍在主流程中（比如是否被路由、事件、定时任务触发）。”
方法二：把疑似废弃的函数定义和周边文件一起发给 Codex，要求它模拟执行路径：“假设现在访问 /api/v1/users/:id，从 Express 路由开始，逐层展开调用链，直到进入数据库查询，请指出 getUserById 是否出现在其中。”
注意：Codex 只有在你明确给出入口点（如路由路径、CLI 命令、页面 URL）时，才能判断调用是否“有效”。光说“它被用了”没意义，必须绑定真实触发场景。
运行时验证：加日志或断点观察
在函数第一行插入 console.log('getUserById called', arguments); 或设置断点，然后完整走一遍用户操作流程：登录→进用户页→点详情→刷新页面。
如果控制台始终没输出，且断点从未命中，基本可判定该函数当前无实际调用。这比静态分析更可信，因为绕过了配置化路由、动态插件加载等 IDE 和 grep 都难以覆盖的情况。
删除前务必确认：日志未输出 ≠ 绝对没人调，有可能是调用发生在夜间定时任务或某个冷门管理后台里。所以【必须覆盖所有已知入口场景】，包括 cron、webhook 回调、MQ 消费者。
