用Python写代码，代码写着写着就忘了某个函数到底在哪个文件里定义过。搜索翻遍项目目录，代码Ctrl+F一个个文件点开找，搜索这种事我干过太多次。代码后来学乖了，搜索直接上grep -rn "def function_name" .，代码一秒钟出结果。搜索但grep有个问题——它不认识Python语法，代码字符串里出现的搜索同名词照样给你匹配出来，噪音不少。代码

Python标准库其实自带了一个更聪明的搜索工具：ast模块。它能解析Python源码，代码把代码变成一棵抽象语法树，搜索你可以在树上精确定位函数定义、代码类定义、变量赋值。比如想找项目里所有定义了process_data函数的地方，用ast.walk遍历每个文件的语法树，判断节点类型是不是ast.FunctionDef，再比对名字就行。这比正则靠谱得多，不会把注释和字符串里的内容误判进来。

import ast def find_function(filepath, func_name): with open(filepath, 'r') as f: tree = ast.parse(f.read()) for node in ast.walk(tree): if isinstance(node, ast.FunctionDef) and node.name == func_name: return node.lineno return None

这段代码短得可以贴在便签上，但实际项目中文件多了就得配合os.walk批量处理。我一般会加个缓存层，把解析结果存成JSON，下次搜索直接查缓存。项目代码没变就不用重新解析，速度差出几十倍。

IDE内置的搜索为什么有时候不够用

PyCharm的“Find in Path”和VSCode的全局搜索已经很好用了，但它们的搜索逻辑偏向文本匹配。你想找“所有调用了requests.get且超时参数小于5秒的地方”，IDE的搜索框就无能为力了。这时候需要写脚本做结构化搜索。

另一种场景是跨项目搜索。手头有五六个仓库，想统一查某个内部库的某个API在哪些地方被引用。IDE只能管一个项目，脚本可以遍历多个目录，把结果汇总成一张表。我曾经用这种方式找出过十几个项目里还在用废弃API的代码，批量提了PR替换掉。

ripgrep配合Python，速度起飞

ripgrep（命令是rg）比grep快得多，而且默认忽略.gitignore里的文件。但它的输出格式对机器解析不太友好。我习惯用Python调subprocess跑rg，拿到结果后再用ast做二次过滤。

import subprocess, json result = subprocess.run( ['rg', '--json', 'process_data', '.'], capture_output=True, text=True ) for line in result.stdout.strip().split('\n'): data = json.loads(line) if data['type'] == 'match': print(data['data']['path']['text'], data['data']['line_number'])

这样搜出来的结果既快又准。rg负责粗筛，Python负责精筛。两段逻辑各干各擅长的事，拼在一起比单独用任何一个都舒服。

搜索这件事，本质是理解代码结构

文本搜索把代码当字符串看，结构化搜索把代码当树看。后者能回答的问题更复杂：这个变量在哪些分支里被重新赋值了？这个类的哪些方法调用了self.db？这些用ast都能做，只是要写更多代码。但写一次脚本，后面反复用，省下的时间很可观。

有个小技巧：把常用搜索逻辑封装成命令行工具，用argparse接收参数。比如psearch --func process_data --dir ./src，比每次打开编辑器敲一长串Python代码方便得多。我自己的工具箱里攒了七八个这样的脚本，覆盖了函数查找、类继承关系分析、导入依赖检查这些场景。

代码搜索不是一锤子买卖。项目在变，搜索需求也在变。今天找函数定义，明天可能要找某个装饰器的所有使用位置。与其每次重新想怎么写，不如维护一套自己的搜索脚本库，随用随取。