Ctrl+H（Windows/Linux）或Cmd+Option+F（macOS）才是当前文件查找与替换的真正入口，支持正则、整词、大小写等完整功能，且Where字段留空才确保仅作用于当前文件。
Ctrl+H 才是当前文件搜索的真正入口
按 Ctrl+F 只是临时高亮，不支持替换、不记录历史、关掉面板就消失；而 Ctrl+H（Windows/Linux）或 Cmd+Option+F（macOS）才是完整可用的当前文件查找与替换面板——它默认只作用于当前激活标签页，且自带正则、整词、大小写等全部控制项。
- 每次打开
Ctrl+H后，第一件事是看Where:输入框：如果里面写着src/、*.py或任何路径，说明被“污染”过，直接删空才能回归纯当前文件模式 -
Ctrl+F无法替换，Alt+F3虽能多光标选中全部匹配项，但只做字符串全匹配，不支持正则，也不区分上下文（比如console.log出现在字符串里也会被选中） - 如果你刚用过
Ctrl+Shift+F做全局搜索，切回来按Ctrl+H，面板会自动清空Where字段——这是 Sublime 少有的“善解人意”时刻，别浪费
搜 console.log 改成 debugger？先防误改
这是高频重构动作，但直接 Replace All 极危险：console.log 可能藏在注释、字符串、正则字面量甚至 JSON 值里。必须加约束。
- 启用正则模式（点
.*图标），Find框填：console\.log\([^)]*\)—— 匹配带括号的调用，排除掉// console.log(...)这类注释行（虽不完美，但比无脑替换强得多） -
Where框必须留空，确保只在当前文件生效；若填了路径，就变成多文件操作，容易波及不该动的文件 - 想快速验证效果？先按
Find All，看右下角Find Results面板里每条匹配是否真在可执行语句位置；上下文不够？改用户设置："find_results_file_context_lines": 3
为什么有时 Ctrl+H 还搜到了别的文件？
不是功能失效，而是 Where 字段残留了上次的路径配置。Sublime 不会重置这个字段，它记的是你上一次怎么关的面板。
- 常见错误现象：在
Ctrl+H面板里点过右侧文件夹图标、或手动输过./src，之后哪怕切换到新文件，只要没清空Where，它就继续按那个路径搜 - 使用场景：你在
utils.js里搜fetch，结果api/index.ts里的匹配也跳出来了——八成是Where里还存着./或项目根路径 - 参数差异：
Where留空 = 当前文件；填.= 当前项目目录；填open_files= 所有已打开 Tab（这不是当前文件模式，别混用）
别把 Ctrl+P 当内容搜索工具
Ctrl+P（或 Cmd+P）只模糊匹配文件名、符号（如 @function）、行号（如 :42），它完全不扫描文件内容。输完关键词没结果，大概率是用错了入口。
-
Ctrl+P→ 找“哪个文件有这个东西”（比如搜Header，可能命中Header.vue或index.html里的header片段） -
Ctrl+H→ 找“这个文件里哪几处有这个东西”（比如在Header.vue里搜props的所有出现位置） - 性能影响：Sublime 不维护后台全文索引，
Ctrl+P响应快是因为只查内存中的文件名缓存；Ctrl+H是实时文本扫描，但仅限单文件，基本无延迟
Where 字段的语义——它不等于“当前文件”，而是一个显式范围开关；留空才是安全默认，其他任何值都意味着你主动扩大了搜索边界。 
