snake_case 怎么转？下划线命名的适用场景与限制

snake_case 用单个下划线连接全小写的词，例如 user_profile。Python 的变量与函数、Postgres 的列名、YAML 与 env 的键名，基本都按这个写法来。

什么时候该用下划线

前后端分家时最常见：JavaScript 那边字段是 userName，Python 后端和数据库列名是 user_name，两边对不上就要在序列化层做映射。建表、写 ORM 模型、整理配置文件的键名时，先把一批名字统一成下划线形式，后面的映射代码会少很多特例。

另一类场景是给一批已有名字做规范化：从旧系统导出的表头有大写、有空格、有短横线，混在一起写 SQL 和 ORM 都很别扭。统一转成小写下划线，顺手把空格和符号清掉，至少能让后续的查询和迁移脚本好写一些。

它比小驼峰多一步：先按「小写字母或数字 + 大写字母」的边界把词拆开，再整体转小写，把连续的非字母数字字符合并成一个下划线，最后去掉首尾多余的下划线。所以 userProfile 会变成 user_profile，而小驼峰转换器做不到这一点。

两个细节要留意。连续的分隔符会合并成一个，a b 和 a--b 都得到 a_b，不会出现空段。数字原样保留，version2 还是 version2，不会自动断开。中文会被整段删除，因为它不属于字母数字；要保留中文含义，请先翻译成英文再转换。

网址路径和 CSS 类名通常用短横线而不是下划线。Google 明确把连字符当作词分隔符，下划线不作为分隔符处理，所以 /user-profile 比 /user_profile 更容易被正确切词；CSS 生态里连字符也已经是事实标准。要生成链接或类名时，请改用短横线形式。

还有两件事工具替你做不到：一是避开语言保留字，order、user、class 做列名时在多数数据库里需要加引号；二是避开 Python 的双下划线命名（如 __init__、__str__），那是语言保留的语义，不是普通分隔符。转换完把结果放进真实的建表语句或代码里跑一遍，比肉眼检查可靠。

snake_case 和 kebab-case 该用哪个？

看它出现在哪里：变量名、数据库列、配置键用 snake_case；网址路径、CSS 类名、文件名用 kebab-case。原因是连字符在 URL 和 CSS 里更通用，而下划线在多数编程语言里可以合法出现在标识符中。

数据库列名为什么常用小写下划线？

多数数据库对不加引号的标识符大小写处理不一致，Postgres 会把未加引号的标识符折叠成小写，混用大小写就得处处加双引号。统一成小写下划线可以省掉这类麻烦，也让 SQL、ORM 和查询结果里的写法保持一致。

连续的下划线会被保留吗？

不会。连续的非字母数字字符合并成一个下划线，所以 a___b 和 a b 都变成 a_b，不会留下空段。首尾的下划线会被去掉，中间原有的单个下划线位置不变。