locate找不到刚创建的文件是因为它查询的是静态数据库/var/lib/mlocate/mlocate.db，需手动运行sudo updatedb更新；支持-b、-i、-r等参数实现精准匹配，但无法按时间、大小等条件过滤，且结果需用-e验证存在性。
locate找不到刚创建的文件？先确认数据库是否最新
locate不扫描磁盘，它查的是/var/lib/mlocate/mlocate.db（或/var/lib/locatedb）这个静态快照。系统默认每天用cron跑一次updatedb，所以你今天新建的文件，大概率搜不到。
解决办法只有一条：手动触发更新。
- 运行
sudo updatedb（普通用户无权限写数据库） - 若提示
command not found，说明mlocate未安装：sudo apt install mlocate（Debian/Ubuntu）或sudo dnf install mlocate（Fedora/RHEL） - 更新耗时取决于文件系统大小，通常几秒到一两分钟；期间可继续用其他命令，不影响操作
怎么避免搜出一堆无关路径？用好-b、-i、-r这些参数
默认locate nginx是子串匹配，会命中/usr/share/nginx、/var/log/nginx.access.log甚至文件内容里的“nginx”字符串——这不是你想要的。
精准匹配靠这几个关键参数：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
locate -b '\nginx.conf'：只匹配**完整文件名结尾**为nginx.conf的项（-b表示 basename 匹配，\防止 shell 展开） -
locate -i 'readme'：忽略大小写，同时匹配README.md、Readme.txt -
locate -r '\.log$'：用基本正则匹配以.log结尾的路径（注意$锚定行尾） -
locate -n 5 python：限制最多输出 5 条，避免刷屏
为什么有时候locate比find快几十倍？别在错误场景硬用
速度差异来自底层机制：find每次都要读 inode + 遍历目录树，I/O 开销大；locate纯内存字符串检索，毫秒级响应。
但它有硬性限制，用错就白忙：
- 不能按修改时间、文件大小、权限过滤（数据库里根本没存这些字段）
- 不能确认文件是否真实存在（
locate foo返回的路径，可能已被rm -rf掉）——加-e参数可过滤掉已删除条目 - 不支持通配符
*直接写在命令行（如locate *.conf会被 shell 展开成当前目录下文件，应写成locate '\.conf$'） - 数据库默认跳过
/proc、/sys、NFS 挂载点等路径，行为由/etc/updatedb.conf控制
plocate正在取代mlocate，但参数不完全兼容
Ubuntu 22.04+、Fedora 35+ 等新版系统已默认用plocate替代mlocate。它索引更小、搜索更快（快 2–3 倍），但部分参数行为有差异：
-
--regex在plocate中是默认启用的，而mlocate需显式加-r；旧脚本里写locate -r 'pattern'在plocate下仍能工作，但locate --regex 'pattern'可能报错 -
plocate不支持-1（安全模式）和某些mlocate特有选项 - 查当前用的是哪个：运行
locate -V，输出含plocate即为新版
真正容易被忽略的不是语法，而是意识：当你需要“是否存在”“什么时候改的”“有多大”，locate已经不在能力范围内了——这时候该切回find，而不是给locate套一堆过滤管道。
