find 与 grep 必须配合使用才能可靠实现目录内内容搜索；单独用 find 无法查文本，grep -r 则存在跳过二进制文件、不兼容旧版本、权限错误干扰及无预筛选等缺陷。
直接说结论： find 负责找文件，grep 负责在文件里找文本——两者必须配合使用才能实现「在指定目录下搜索内容」；单独用 find 找不到字符串，单独用 grep 又无法递归进子目录自动遍历所有文件。
为什么不能只用 grep -r？
很多用户以为 grep -r "pattern" /path 就够了，但实际踩坑不少：
-
grep -r会默认跳过二进制文件（比如.so、.o、.zip），而你可能正想搜编译产物里的符号或字符串 - 某些旧版
grep（如 BusyBox 环境）根本不支持-r，执行直接报错unrecognized option: r -
grep -r对权限错误（如Permission denied）默认输出到 stderr，容易淹没真实结果，也不方便重定向过滤 - 它无法按文件类型、修改时间等条件预筛文件，全量扫效率低，尤其面对
/usr/src或大型代码仓库时
find … -exec grep … {} + 是最稳的组合
这是生产环境最可靠、兼容性最好、可控性最强的方式。关键点在于结尾用 {} + 而不是 {} \;：
-
{} \;：对每个匹配文件单独执行一次grep，开销大，且当文件数超限会报Argument list too long -
{} +：把多个文件名拼成一批传给单次grep，类似xargs的行为，性能好、无截断风险 - 示例：在
/work/linux下搜所有.c和.h文件中含CONFIG_DM9000的行（含行号）
find /work/linux \( -name "*.c" -o -name "*.h" \) -exec grep -n "CONFIG_DM9000" {} +
注意括号需转义，否则 shell 会提前解析；如果只想看文件名不关心哪一行，加 -l 参数即可。
过滤掉二进制文件和权限错误的干扰
常见问题：grep 报一堆 Binary file xxx matches 或 Permission denied，结果被刷屏。解决方法是分层过滤：
- 用
-type f排除目录、软链、设备文件等非普通文件 - 用
-readable预判可读性（部分系统支持，比靠grep报错更主动） - 用
2>/dev/null抑制Permission denied（但别滥用，有时这提示真代表权限配置异常） - 若明确要跳过二进制，可在
grep加-I（大写 i），它会静默跳过二进制文件，不报 warning
组合起来就是：
find /opt/app -type f -name "*.py" -readable -exec grep -In "def api_" {} + 2>/dev/null
容易被忽略的细节：空格文件名和特殊字符
当路径或文件名含空格、换行、括号时，find | xargs grep 会出错，因为 xargs 默认按空白分割——哪怕加 -print0 | xargs -0 也得确保两端都支持 null 分隔。
而 -exec … {} + 原生安全，shell 自动处理引号和转义，无需额外适配。这点在 CI/CD 脚本或自动化部署中特别关键，否则某天突然因一个带空格的分支名导致搜索失败，排查成本很高。
真正复杂的地方从来不在语法，而在你是否意识到：那个看似普通的 find 命令，正在跨文件系统、混杂权限模型、应对各种命名习惯的真实环境里运行。
