大小写之争：你的按钮标签写对了吗

你有没有盯着两个按钮标签发呆——"Save changes"还是"Save Changes"？这看似微不足道的选择，却藏着界面设计的底层逻辑。

两种写法的本质区别

标题式大小写（Title Case）把几乎每个词的首字母都大写："The Best Free Tools for Writers and Developers"。

句子式大小写（Sentence Case）只大写第一个词和专有名词："The best free tools for writers and developers"。

差别就这一个规则，但应用场景泾渭分明。

正方：标题式大小写更正式

支持方认为，标题式大小写适合这些场景：

导航菜单项——很多设计系统偏爱这种风格。代码示例里，"Home""About Us""Contact"整齐划一，视觉上更有层级感。

页面标题和标签——浏览器标签栏、搜索引擎结果页，标题式大小写让信息更醒目。

营销标题——传统出版业的遗留习惯，"The Ultimate Guide to..."这种句式自带权威感。

正式文档的章节标题——技术白皮书、API文档的一级标题，标题式大小写暗示"这是结构性内容"。

代码注释里引用的书名或产品名——保持与外部引用一致，避免混淆。

核心论点：标题式大小写是一种"装饰性语法"，它告诉读者"此处是标题，请放慢阅读速度"。

反方：句子式大小写更自然

反对方的论据更具体——直接搬出Google、Apple、Notion的行业实践。

UI标签和按钮——"Save changes"比"Save Changes"更友好。后者有种"命令感"，前者像日常对话。

错误提示和系统通知——"Something went wrong"读起来像人话，"Something Went Wrong"像在朗诵。

博客和文档的次级标题——连续阅读时，句子式大小写减少视觉噪音。

邮件主题行——移动端预览空间有限，小写词更省认知负荷。

社交媒体文案——算法时代，句子式大小写降低"营销感"，提升点击意愿。

反方的核心武器是"认知流畅性"：人脑处理句子式大小写的速度更快，因为它符合日常阅读预期。

技术实现：别硬改文本，用CSS和JS

实际开发中，内容来源和展示需求经常冲突。原文提供了三层解决方案：

CSS层做视觉转换——text-transform: capitalize能把所有单词首字母大写，但有个坑：它连介词也一起大写，不够"智能"。

需要真正的标题式大小写逻辑，得用JavaScript。原文给了一个实现：定义小词列表（a, an, the, and, but, or...），首词和不在列表里的词才大写首字母。

句子式大小写的JS实现更复杂——要处理句首大写，还要识别句号、感叹号、问号后的新句子。

一次性转换需求，原文推荐了TechMind.click的免费工具，粘贴即转。

我的判断：场景优先，一致为王

这场争论没有绝对赢家。原文最后给出的经验法则值得贴在工作区：

UI和数字内容用句子式大小写，正式标题、书名、导航用标题式大小写。

但比选择更重要的是——一致性。混用两种风格比选错风格更致命。用户不会记住你选了哪种，但会感知到"这里有点乱"。

Google Material Design全用句子式大小写，Apple Human Interface Guidelines同样。这不是审美偏好，是规模化产品的必然选择——减少决策点，降低协作成本。

小团队可以反着来，全用标题式大小写也没问题。关键是写进设计规范，代码审查时强制执行。

那个"Save changes"和"Save Changes"的选择，本质是问：这个按钮是在对话，还是在发号施令？答案取决于你的产品人格，而非语法正确性。

最讽刺的是，很多团队争论半小时，最后发现CSS里写死了text-transform: uppercase——全大写，争论归零。