多重选区批量转换需分步处理：先清理冗余下划线和短横线，再逐个选中目标字段名避开注释与字符串，用正则分两步处理camelCase→snake_case以正确拆分缩写，最后统一小写；title_case不可靠，应避免使用。
多重选区下怎么批量转 snake_case → camelCase
直接用 _(\w) + \U$1 是最稳的起点，但多重选区会放大错误——比如你同时选中了 JSON 字段名、注释里的示例、甚至字符串字面量中的 "user_name"，一替换全中招。
实操建议：
- 先用
Ctrl+D（Windows/Linux）或Cmd+D（macOS）逐个加选目标字段名，避开引号和注释；更稳妥的是用Ctrl+L选整行后，再按Ctrl+Shift+Right向右扩展到标识符边界 - 确保输入法为英文，否则
\U$1中的$1可能被当成中文标点解析失败 - 替换前务必关闭
Match Whole Word——它会让_(\w)在user_id_2中只匹配最后一个_2，漏掉_id - 连续下划线如
first__name不会被一次匹配完，得先运行_+→_清理冗余，再走主流程
camelCase → snake_case 时多重选区容易漏掉缩写
XMLHttpRequest 这类词在多重选区里若只用 ([a-z])([A-Z]) → $1_$2，会变成 x_m_l_http_request，而不是预期的 xml_http_request。问题不在选区本身，而在正则没覆盖「连续大写字母 + 首小写」这个边界。
实操建议：
- 分两步：先处理缩写部分，查找
([A-Z]+)([A-Z][a-z])，替换为$1_$2（把XMLHttp拆成XML_Http） - 再跑通用规则
([a-z])([A-Z])→$1_$2，此时XML_HttpRequest就能正确变成xml_http_request - 多重选区下，这两步必须分别执行——不能合并成一个正则，否则捕获组错位，
$1和$2指向混乱 - 最后统一小写用
Ctrl+K+L，不要用菜单里的Lower Case，后者在多光标下可能只作用于第一个选区
为什么 title_case 在多重选区里完全不可信
Ctrl+K+C 看似省事，但它按空格切分单词，对 API 字段这种无空格串完全失效：userProfileUrl 变成 Userprofileurl，parseJSON 变成 Parsejson。多重选区只会把这错误复制 N 份。
关键原因：
-
title_case不识别大小写拐点，也不处理下划线，纯靠空白符分词 - 它对 Unicode 字符（如带重音的法语变量名）直接崩溃，而正则
_(\w)至少能跳过非 ASCII 字符 - 在多光标下，它的行为不一致：有时只改第一个光标，有时全改但大小写逻辑错乱
- 真正可用的原生命令只有
Ctrl+K+U（大写）、Ctrl+K+L（小写），且必须确保每个光标都落在有效字母上，否则静默失败
批量处理 API 字段时最容易忽略的边界字符
API 响应里常混着 user-id、content-type、X-Forwarded-For 这类短横线或带连字符的字段，它们不是标准 snake_case 或 camelCase，但常被一起选中误操作。
实操建议：
- 先用正则
-([a-zA-Z])→_统一转成下划线，再走_(\w)流程；别试图一步到位，Sublime 正则不支持条件分支 - 开头带
X-的 HTTP 头（如X-Request-ID）要单独处理：先^X-(\w)→x$1小写首字母，再进通用流程 - 数字混入的字段（
user_2fa_token）没问题，_(\w)会跳过_2直接匹配_f；但2fa_user会被转成2faUser，符合惯例，无需额外干预 - 最危险的是不可见字符——比如从 Excel 复制的字段名带
\u200b（零宽空格），会导致正则完全不匹配，得先用[^\x00-\x7F]+扫一遍清理
多重选区本身不增加转换复杂度，真正卡住人的永远是字段里那些看似安静、实则破坏正则边界的字符：双下划线、短横线、连续大写、开头特殊符号。动手前花 10 秒扫一眼样本，比事后一行行手动修快得多。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
