命名规范：camelCase 还是 snake_case？

架构精进之路

发布于 2026-03-25 14:21:58

2060

文章被收录于专栏：架构精进之路架构精进之路

在分布式系统架构设计中，API 接口既是各系统间的交互通路，更是衔接不同技术栈、组织文化与开发阶段的核心契约。

而在 RESTful API 的设计细节里，有一个看似细微、却常引发持续争论的议题：

“字段名究竟该用 camelCase（小驼峰）还是 snake_case（下划线）？”

这从来不止是审美偏好的选择，其背后直指后端持久层与前端表现层的 “阻抗失配” 问题，同时牵涉序列化性能、网络传输效率、开发者体验（DX）乃至认知心理学等多重维度。

本文将立足编程语言演进脉络、底层技术实现机制，结合 Google、Stripe 等行业巨头的架构决策实践，为这一问题提供一份可落地的决策指南。

一、历史溯源：符号学的选择

要理解这场争论，我们必须回溯计算机语言的发展脉络。命名规范并非凭空产生，而是特定时代硬件限制与社区文化的产物。

1.1 snake_case 的起源：C 语言与 Unix 哲学

snake_case（如 user_id）的流行可追溯到 70 年代的 C 语言和 Unix。当时的键盘设备（如 Teletype Model 33）虽然有大写键，但许多早期编译器对大小写不敏感。为了在低分辨率显示器上清晰地区分单词，程序员引入下划线模拟自然语言中的空格。这种习惯深深植根于 SQL 数据库标准中，至今 PostgreSQL 和 MySQL 的默认列名风格依然是下划线，这也为后来 API 与数据库的字段映射埋下了伏笔。

1.2 camelCase 的崛起：Java 与 JavaScript 的霸权

camelCase（如 userId）则随着面向对象编程（Smalltalk、C++、Java）兴起。Java 确立了“类名大驼峰，方法/变量名小驼峰”的工业标准。

决定性的转折点在于 JavaScript 的诞生。JSON 源自 JS 对象字面量，JS 标准库（如 getElementById）全面采用驼峰命名。随着 AJAX 和 JSON 取代 XML 成为数据交换霸主，camelCase 获得了 Web 领域的“原生”地位。

二、核心冲突：技术栈的阻抗失配 (Impedance Mismatch)

当数据在不同语言间流转时，不可避免地会遭遇“阻抗失配”。

2.1 后端视角的惯性（Python/Ruby/SQL）

Python/Django/FastAPI：Pydantic 模型通常直接对应数据库表结构

classUserProfile(BaseModel):
    first_name: str# 符合 Python 习惯
    last_name: str

如果 API 强制返回 camelCase，就必须在序列化层配置别名（Alias）或转换器，增加了映射逻辑。

SQL 数据库：绝大多数数据库列名使用 snake_case。API 使用 camelCase 意味着 ORM 层必须始终承担转换工作。
Stripe 的选择：早期架构构建在 Ruby 栈上，直接暴露内部模型可保证后端一致性，因此坚持 snake_case。

2.2 前端视角的统治（JavaScript/TypeScript）

代码风格割裂：API 返回 snake_case，会破坏前端代码风格

const user = awaitfetchUser();
console.log(user.first_name); // 违反 ESLint camelcase 规则
render(user.email_address);

解构赋值的痛点：字段是 snake_case 时，需要繁琐重命名

const { first_name: firstName, last_name: lastName } = response.data;

这不仅增加样板代码，还提高出错概率。

三、性能误区：序列化与网络传输

两个常见误区：

3.1 误区一：运行时转换开销

动态语言：Python 或 Ruby 中，频繁正则转换确实消耗 CPU，但现代框架（如 Pydantic v2，基于 Rust）通过预计算 Schema 映射，将开销降至极低。
静态语言 (Go/Java/Rust)：转换几乎零成本，运行时只是简单字节拷贝。

注意：前端浏览器主线程不要做全局递归转换，否则会导致页面掉帧和内存抖动。

3.2 误区二：传输体积差异

理论上 first_name 比 firstName 多一个字符，但开启 Gzip/Brotli 后差异几乎消失。
压缩算法利用重复字符串引用，JSON 数组中键高度重复，后续仅用短指针代替。
实测：Gzip 级别 6 下，两种风格 JSON 体积差异通常在 0.5%–1% 之间。

结论：传输体积不是问题，转换工作应由后端承担。

四、开发者体验 (DX) 与认知心理学

snake_case 可读性优势：下划线提供清晰视觉分隔，处理连续缩写词时更易解析。例如 parse_db_xml 比 parseDbXml 更快被理解。
camelCase 一致性优势：全栈 JS/TS 团队统一 camelCase，可直接复用类型定义（Interface/Zod Schema），消除“脑内翻译”认知负荷。