常见grep搜不到内容是因shell提前解析引号和通配符；find的-mtime按24小时整数倍向下取整；curl默认无User-Agent易被WAF拦截；管道命令需用pipefail、规避grep自匹配并加-0处理空格。
grep 搜索时为什么找不到匹配内容
常见现象是 grep 在文件里搜不到明明存在的关键词，尤其是含空格、斜杠或特殊符号的字符串。根本原因不是命令写错，而是 shell 会提前解析引号和通配符，导致传给 grep 的参数已经变形。
实操建议：
- 用单引号包裹搜索模式：
grep 'user.name' config.json，避免 shell 展开点号或星号 - 搜索固定字符串（不走正则）加
-F参数：grep -F 'https://api.example.com' log.txt，既安全又快 - 确认文件编码：如果文件是 UTF-16 或含 BOM，
grep默认读不出来，先用file -i log.txt查编码，必要时转成 UTF-8 再搜 - 注意大小写：默认区分大小写，临时不区分就加
-i，但别养成习惯——线上查日志时大小写常是关键线索
find 命令按修改时间筛选总不准
find 的 -mtime 看似简单，实际行为反直觉：它按“24 小时整数倍”向下取整计算，不是从现在往前推 N 天。比如今天是 5 月 10 日 14:30，-mtime -1 只匹配 5 月 10 日 00:00 之后修改的文件，而非最近 24 小时内。
实操建议：
- 要精确到小时，改用
-newermt：find /var/log -newermt "2024-05-09 14:00" - 批量清理旧文件时，优先用
-delete而非| xargs rm，前者原子性强，且自动处理含空格路径 - 慎用
-exec ... \;：每匹配一个文件就 fork 一次进程，大量文件时很慢；改用+结尾可批量传参：find . -name "*.tmp" -exec rm {} +
curl 请求返回 403 却没被网站拦截
很多 API 接口返回 403 Forbidden 并非权限问题，而是服务端根据 User-Agent 或缺失的 Accept 头直接拒掉默认 curl 请求。原始 curl 不带任何头，某些 Nginx 配置或云 WAF 会把它当爬虫拦截。
实操建议：
- 加基础请求头：
curl -H "User-Agent: Mozilla/5.0" -H "Accept: application/json" https://api.example.com/v1/data - 调试时加
-v看真实请求头和响应头，重点检查Server、X-RateLimit-Remaining这类字段 - 如果目标要求 cookie 登录，别手动拼
-b，用-c和-b配合保存/复用：curl -c cookie.txt -d "u=a&p=b" https://site/login，后续请求用-b cookie.txt
管道组合命令出错时怎么快速定位
像 ps aux | grep nginx | awk '{print $2}' | xargs kill 这类链式命令，中间任一环节失败，错误信息常被吞掉或指向错位。最麻烦的是 grep 匹配到自身进程（如 grep nginx 出现在 ps 列表里），导致误杀。
实操建议：
- 用
set -o pipefail让管道中任意命令失败都触发退出，配合if判断更可靠 - 规避
grep自匹配：把关键词拆开写，ps aux | grep [n]ginx，方括号让正则匹配失效，但 shell 仍能搜到 - 调试阶段加
tee中间截流：ps aux | tee /tmp/ps.log | grep nginx，出问题立刻看/tmp/ps.log - 涉及
xargs时，默认以空格分隔，遇文件名含空格就崩；统一加-0配合find -print0：find . -name "*.log" -print0 | xargs -0 rm
真正难的不是记命令，是理解每个工具默认行为背后的假设——比如 find 假设你懂时间取整，curl 假设你清楚 HTTP 头语义，grep 假设你意识到 shell 先解析再传参。这些假设不戳破，就总在“明明应该对”的地方卡住。
