sublime中千分位格式化需用正则(\d)(?=(\d{3})+(?:\.|$))匹配整数部分并替换为$1,，必须清理非数字字符、避开小数部分、注意边界和换行符设置，且务必预览防误匹配。
Sublime里不能直接格式化数字，得先转成字符串再处理
Sublime Text本身不执行JavaScript或数值运算，所有“千分位格式化”本质是字符串查找替换。你必须把原始数字当纯文本对待——比如1234567.89不是Number类型，而是7个字符+小数点+2个字符的字符串。这意味着：不能用toLocaleString()，也不能调用toFixed()；所有逻辑都得靠正则匹配和$1反向引用完成。
常见错误是直接写\d{3}去匹配并加逗号，结果把1234567.89变成1,234,567.89没错，但1234.5会错变成1,234.5（正确），而123.456却可能被误匹配为123.456 → 1,23.456（错误）。根源在于没限制匹配范围——必须让正则只作用于整数部分，避开小数点之后。
- 确保输入是干净数字字符串：不含空格、货币符号、括号等干扰字符
- 若原始文本含
$12345.67或¥1234567.89，需先用^[^\d.-]+或[^\d.-]+$清理前后非数字字符 - 小数点后位数不固定时（如
12345.6、12345.678），正则必须兼容任意长度小数，不能硬写\.\d{2}
匹配整数部分的正则必须锚定小数点或行尾
关键在断言位置：要找“前面是数字、后面跟着三连数字+小数点或行尾”的位置插入逗号。最可靠的是这个模式：(\d)(?=(\d{3})+(?:\.|$))。它表示：匹配一个数字\d，且其后紧跟着“三连数字重复多次，然后接小数点或行尾”。这样1234567.89中，只有1、234、567前的数字会被捕获，不会碰小数部分。
实际替换时用$1,——即把匹配到的那个单数字替换成“它自己+逗号”。例如：1234567.89经该正则匹配后，会在1后、234前、567前各插一个逗号，最终得到1,234,567.89。
- 不要用
\d{1,3}(?=(\d{3})+$)：它在1234.5中会匹配1234整体，导致错误插入 - 避免
^(\d+)开头匹配：万一数字在行中（如ID:1234567.89），就失效了 - 如果文件里混有整数和小数（
1000、2000.5、3000000），这个正则能统一处理，无需分情况
跨行、多数字批量处理时要开“.”匹配换行符
当你处理日志或表格导出文本，数字分散在不同行（如每行一个金额），默认情况下.不匹配换行符，$只认当前行尾。这时(\d)(?=(\d{3})+(?:\.|$))里的$无法跨行生效，会导致最后一行数字漏格式化。
解决方法很简单：打开替换面板（Ctrl+H），点击右下角.*图标激活正则，再点. matches newline（或按Alt+R勾选）。此时$才真正代表整个文本末尾，而.也能穿透换行——不过本例中其实不需要.匹配换行，关键是$语义要准。
- 未开启
. matches newline时，123456\n789.12会被当作两行，第二行789.12因不足四位不触发千分位 - 开启后，
$在789.12末尾仍有效，但该数字本身太短，不匹配，所以无影响；真正受益的是像1234567\n.89这种被折行的数字（极少见，但存在） - 更稳妥的做法是：先用
^[ \t]*\n删空行，再用[ \t]+\n合并被空格/Tab断开的行，确保每个数字独占一行或连续
安全预览和防误替换比一次到位更重要
正则替换一旦执行不可撤回（除非Ctrl+Z未切换文件），尤其面对财务数据时，错加一个逗号可能导致金额差十倍。务必养成习惯：先点Find All看高亮是否全是你想改的数字，再扫一眼上下文有没有意外匹配（比如IP地址192.168.1.1会被误格式化成192.168.1,1）。
典型误匹配场景：2023-12-31中的2023、1234567890（手机号）、123.45.67（版本号）。对策是增强边界约束：
- 加单词边界：
\b(\d)(?=(\d{3})+(?:\.|$))\b，可排除abc1234567def中的1234567 - 限定前后字符：
(?，排除小数点左右和相邻数字 - 最保险：先用
Find All选中所有疑似金额（如\d+\.\d{2}或\d+），再对选中区域运行千分位正则，避免全局污染
真正的难点不在正则本身，而在识别哪些“数字”确实是金额——这需要结合业务上下文判断，机器无法代劳。
