sublime text的ctrl+k ctrl+c不能实现多行首字母大写，因其仅对选区内空格分隔的单词统一首字母大写，不识别行边界；可靠方案是正则替换：find what填^1*(\w)，replace with填\u$1\e，确保仅每行首个字母大写且精准可控。\n\s ↩
Ctrl+K Ctrl+C 不能直接实现多行首字母大写
Sublime 自带的 Ctrl+K Ctrl+C（macOS 用 Cmd+K Cmd+C）命令只对当前选区做「空格分隔的单词」首字母大写，它不识别换行符边界，也不会自动把每行第一个单词拎出来处理。如果你选中了多行文本再按这个组合键，结果是每行内所有单词都首字母大写，而不是“仅每行第一个单词大写”——这和你想要的“规范排版”目标不一致。
常见错误现象：粘贴一段列表（如 CSV 字段、配置项、日志条目），想让每行开头那个词变成大写，结果整行所有单词都被改了，比如：user_name → User_Name，created_at → Created_At，完全偏离预期。
- 该命令对连字符、下划线、撇号等分隔符无感知，
multi-word变成Multi-word，don't变成Don't，但XMLHttpRequest还是原样 - 它不区分上下文：代码中的变量名、字符串字面量、注释内容全被一视同仁处理
- 若选区跨多行但首行开头无字母（比如缩进或空格），第一行可能跳过，后续行却正常触发
正则替换才是可靠方案：匹配行首非空白字符
真正可控的做法是打开 Ctrl+H（macOS Cmd+H），勾选 Regular Expression（点 .* 按钮），然后填入精确模式：
Find What：^[^\n\S]*([a-zA-Z])
Replace With：\U$1\E
说明：
— ^ 锚定行首
— [^\n\S]* 匹配行首任意数量的空白（不含换行，避免跨行干扰）
— ([a-zA-Z]) 捕获第一个可见字母（跳过数字、符号、下划线）
— \U\E 强制把捕获的单个字母转大写，\E 确保不污染后续字符
- 这个表达式能跳过空行、纯空白行、以数字开头的行（如
123abc不会触发） - 对
user_name、\t\tid、status都有效，且只动第一个字母 - 如果文件编码含 BOM 或 UTF-8 with signature，建议先用
File → Reopen with Encoding → UTF-8统一格式，否则^可能失准
多光标 + 单词级操作更适合小范围精准控制
当你要处理的不是“每行一个词”，而是“每行某固定位置的标识符”（比如日志里每行第 3 个字段、YAML 的 key 名），用多光标更稳：
- 按住
Ctrl（macOSCmd）+ 鼠标左键，在每行目标单词开头点出光标 - 确保每个光标都落在字母上（哪怕只覆盖首字符），然后执行
Ctrl+K→ 松手 →Ctrl+U - 每个光标独立触发其所在单词的全大写，不会波及其他部分
注意：这个方法依赖人工定位，不适合上百行；但它绕过了正则的边界陷阱，对含特殊字符的字段（如 api_v2/token 中的 api）更可控，且不依赖语法高亮模式——即使光标落在 JSON 字符串里，只要没被插件禁用，依然生效。
为什么 \u$0 不适合做行首大写？
很多人试过 Find What 填 ^[^\n]，Replace With 填 \u$0，结果发现只有第一行第一个字符变了，其余行没反应。根本原因是：\u 只影响紧邻的下一个字符，而 $0 是整行匹配内容（包括空格、制表符），\u$0 实际只把匹配到的第一个字符（可能是空格）强行大写，毫无意义。
更危险的是误用 \U$0：漏写 \E 会导致从匹配位置开始，后面所有文本（包括未匹配部分）全变大写，恢复只能靠 Ctrl+Z，且无法批量撤销跨文件操作。
真正容易被忽略的地方是：Sublime 的大小写元字符（\U、\u、\L）只在正则替换面板中生效，且必须配合 Regular Expression 开关；它们不是通用正则语法，也不能用在 Find in Files 或命令面板里——想批量处理多个文件，得逐个打开，或改用外部工具（如 sed 或 Python 脚本）。
