根本原因是\b在sublime的pcre中unicode支持弱，将_、-、.等视为单词边界，且中文、emoji或bom utf-8文件会导致\b失效；应改用^[\s]*([a-za-z])锚定行首并捕获首字母。
为什么\b([a-z])\U$1\E不能稳定匹配首字母大写单词
这个正则看似合理，但实际在 Sublime 里常漏匹配或误匹配。根本原因是 \b 在 Sublime 的 PCRE 实现中对 Unicode 支持弱，且它把下划线 _、连字符 -、点号 . 都当作单词边界——比如 user_name 会被切为 user 和 name 两段，XMLHttpRequest 则完全不触发（因首字母 X 前无 \b）。更麻烦的是，中文、emoji 或带 BOM 的 UTF-8 文件会让 \b 失效。
实操建议：
- 避免用
\b定义“单词”，改用显式锚定：比如(? 表示「行首或空格后的小写字母」 - 若目标含中文，必须用
[^\s]替代\w，并确认文件编码为 UTF-8（菜单 → File → Reopen with Encoding → UTF-8） - 测试时先点
Find看高亮，别直接Replace All；尤其注意是否误中字符串字面量或注释
匹配「每行首个可见字母」并转大写的可靠正则
这不是匹配“首字母大写单词”，而是让“每行第一个字母变成大写”——这才是多数排版场景的真实需求（如日志字段、配置项列表）。原生 Ctrl+K Ctrl+C 会作用于整行所有单词，不可控；正则才是解法。
推荐表达式：
Find What: ^[^\n\S]*([a-zA-Z])Replace With: \U$1\E
说明：
-
^锚定行首，不是整个文档开头 -
[^\n\S]*匹配行首任意空白（跳过缩进、制表符），但排除换行符，防止跨行干扰 -
([a-zA-Z])只捕获纯字母，跳过数字开头行（如123abc）、符号开头行（如#status） -
\U$1\E仅将捕获的单个字母大写，\E是必须的，否则后续字符可能被意外大写
想保留缩进又只动首字母？用 $1 捕获空白再还原
上面的正则虽精准，但会丢掉缩进——因为 [^\n\S]* 被匹配却没被捕获。要保留格式，就得把空白也放进捕获组。
替换为：
Find What: ^([^\n\S]*)([a-zA-Z])Replace With: $1\U$2\E
关键点：
-
$1是缩进部分（空格/Tab），原样保留 -
\U$2\E只影响第二个捕获组里的那个字母，不会波及$1 - 如果某行是纯空白或空行，该正则自动跳过，不报错也不污染
- 不要用
\u$2代替\U$2\E——\u只影响下一个字符，但万一$2后面紧跟着其他内容（比如换行符解析异常），行为不可控
遇到缩写、驼峰名、数字前缀时别硬套正则
正则擅长规则文本，但对语义敏感的大小写转换（如 iPhone、XMLHttpRequest、3dModel）极易翻车。例如 ^[^\n\S]*([a-zA-Z]) 会把 3dModel 的 M 大写成 3dmodel → 3dModel，看似对，但若原始是 id，就会变成 ID，破坏 JSON key 兼容性。
这时应切换策略：
- 优先安装
Case Conversion插件：右键 →Case Conversion → To Title Case，它内置缩写识别（iPhone不变，html→HTML可选） - 对代码上下文敏感的场景（如变量重命名），用两步正则：
_(\w)→\U$1先转驼峰，再人工校验首字母 - 批量处理前，务必用
Find in Files验证：勾选Whole Word和Case Sensitive，避免误触注释或字符串
真正容易被忽略的，是文件编码和 \b 的隐式依赖——同一正则在 UTF-8 with BOM 和 Latin-1 下表现完全不同，而多数人直到替换出乱码才回头检查编码。
