whole word选项在查找/替换面板右下角点击aa图标启用；它对下划线、数字视为单词字符，故\buser_name\b会误匹配，应改用(?
Whole Word 选项在哪开，为什么点了还不管用
Sublime Text 的「Whole Word」不是默认开启的，必须手动勾选查找/替换面板右下角的 Aa 按钮（图标是大小写字母叠在一起），点一下变蓝才算激活。但很多人开了还是没效果，核心原因是：\b 在 Sublime 里把下划线 _ 和数字当作单词字符，所以 \buser_name\b 会错误匹配到 username 或 user_name_old。
真正稳的全字匹配写法是：(?——它用否定字符类替代 <code>\b，明确排除前后紧邻字母、数字、下划线的情况。如果上下文干净（比如只在 JS 变量声明区操作），加空格前缀 user_name 配合 Whole Word 也能快速避坑，但得人工扫一眼结果列表确认没漏掉边界情况。
Ctrl+H 和 Ctrl+Shift+F 的 Whole Word 行为差异
这两个面板的 Whole Word 是独立开关，互不影响。按 Ctrl+H 打开的是单文件替换面板，Whole Word 只作用于当前文件；按 Ctrl+Shift+F 打开的是「Find in Files」面板，Whole Word 控制的是跨文件搜索时是否整词匹配。
- 想改整个项目里的
console，但不想动console.log或JSON.parse里的console？必须用Ctrl+Shift+F+Whole Word+Where填. - 只想改当前文件里所有独立出现的
true，不碰return或truthy？用Ctrl+H+Whole Word就够了 -
Whole Word对中文、符号（如-、/）无效，它只认 ASCII 字母、数字、下划线和 Unicode 字母——搜api-key时别指望这个选项能帮你卡住连字符边界
Whole Word 配合正则时的常见翻车点
一旦启用正则模式（点 .* 图标），Whole Word 按钮就自动失效——Sublime 不允许同时使用 \b 语义和自由正则表达式。这时候你写的 \buser_name\b 会被当普通字符串处理，除非你显式写出等价的环视断言。
更麻烦的是：正则里 . 默认不匹配换行符，如果你的“全字”目标跨了两行（比如
const<br>user_name），
Whole Word 根本不起作用，必须额外勾选 . matches newline（或按 Alt+.）并改用 (? 写法。<p>实操建议：</p>
<ul>
<li>先关掉 <code>.*，用 Whole Word 快速试一遍匹配数量是否合理
.*，把 user_name 替成 (?，确保正则本身带边界控制
my-var），直接放弃 Whole Word，用 (? 显式定义分隔符
替换后怎么验证 Whole Word 是否真生效了
点 Replace All 之后别急着关面板——Sublime 不会自动高亮新插入的内容，也不会标记哪些地方被跳过了。最可靠的方式是：用原查找内容再搜一次，看是否还有残留匹配项。如果有，说明 Whole Word 没拦住某些边界，或者你漏掉了注释、字符串、正则字面量里的干扰项。
尤其要注意这三类盲区：
- JS 字符串里：
"user_name"——Whole Word会把它当完整字符串匹配，而非变量名 - HTML 属性值里：
data-user-name="xxx"—— 连字符-不是单词字符，Whole Word完全不生效 - Python 注释里：
# user_name is deprecated—— 注释属于语法作用域，但Whole Word不管这个，照样匹配
真正安全的重构，从来不是靠一个开关兜底，而是靠 Find All 看列表、人工过一遍高亮位置、再结合 Git diff 做二次校验。
