freeCodeCamp 基础 JavaScript 挑战解读：理解变量的大小写敏感性（Case Sensitivity）

这篇技术指南以 freeCodeCamp 开源课程中 Basic JavaScript（基础 JavaScript）模块的经典挑战 "Understanding Case Sensitivity in Variables" 为主体，逐段拆解其原始挑战文件。你将掌握 JavaScript 中变量名与函数名大小写敏感的底层语义、大小写混用可能埋下的隐患，以及业界通行的 camelCase（驼峰命名法）最佳实践，并能完整复现该挑战的修改步骤、答案与全部自动校验规则。

挑战在课程体系中的位置

在 curriculum/structure/blocks/basic-javascript.json 中可以看到完整的挑战顺序（challengeOrder），本挑战（id 为 56533eb9ac21ba0edf2244ab）紧跟 "Storing Values with the Assignment Operator"、"Initializing Variables with the Assignment Operator"、"Declare String Variables"、"Understanding Uninitialized Variables" 之后，位于上述变量声明与赋值基础课与 "Explore Differences Between the var and let Keywords" 之前。也就是说，学习者此时已经知道如何用 var 声明变量、如何用赋值运算符初始化变量、如何处理未初始化变量，本挑战在此基础上聚焦命名规范这一常被忽略却极易踩坑的话题。

其 Markdown 头部的元数据也说明了它的组织方式：

---
id: 56533eb9ac21ba0edf2244ab
title: Understanding Case Sensitivity in Variables
challengeType: 1
forumTopicId: 18334
dashedName: understanding-case-sensitivity-in-variables
---

其中 challengeType: 1 表示这是一道常规编码题（非项目、非测验），学习者直接在代码编辑器中补全；dashedName 用于生成 URL 与文件标识；forumTopicId 对应当年论坛讨论主题。

核心概念：JavaScript 中的大小写敏感性

挑战说明开门见山地给出了这条贯穿整个 JavaScript 语言的规则：

In JavaScript all variables and function names are case sensitive. This means that capitalization matters.

翻译过来即：在 JavaScript 中，所有变量名与函数名都是大小写敏感的，大小写写法不同，标识符就不同。 注意这一规则不仅适用于变量，同样适用于函数名——也就是说，调用函数时必须与你定义它时的大小写完全一致。

原文用一组强烈对比来说明：

• MYVAR
• MyVar
• myvar

三者是三个完全不同的名字。因此语言层面完全允许你同时声明多个"仅大小写不同、拼写相同"的变量：

var myvar = 1;
var MYVAR = 2;
var MyVar = 3;

上面的代码在 JavaScript 中完全合法，三个变量各自独立、互不干扰。但挑战紧接着给出了强烈建议：

It is strongly recommended that for the sake of clarity, you do not use this language feature.

也就是：尽管语言允许，为了代码清晰起见，强烈不建议使用这种"仅靠大小写区分变量"的语言特性。 原因很直观：当代码规模变大，total、Total、TOTAL 同时存在时，阅读者（包括未来的你自己）将无法快速判断当前引用的是哪一个，极易出现改错对象或读到错误变量的问题。

最佳实践：使用 camelCase（驼峰命名法）

命名问题靠语言机制无法根治，只能靠约定。freeCodeCamp 在此处引入的正是 JavaScript 生态中最主流的变量命名约定——camelCase：

Write variable names in JavaScript in camelCase. In camelCase, multi-word variable names have the first word in lowercase and the first letter of each subsequent word is capitalized.

规则总结如下表：

组成	写法要求
首词	全部小写开头
后续每个词的第一个字母	大写
词与词之间	不加空格、不加下划线或连字符
整体形状	形似驼峰（camel）的隆起

挑战给出的三个标准示例：

var someVariable;
var anotherVariableName;
var thisVariableNameIsSoLong;

逐一对照规则：

• someVariable：首词 some 全小写，第二词 Variable 首字母大写；
• anotherVariableName：another 小写，Variable、Name 两处首字母大写；
• thisVariableNameIsSoLong：多词依次首字母大写，形成"驼峰"轮廓。

为什么变量名用 camelCase 而不用其它风格？从后续课程与真实项目看，一个重要的技术原因是 JavaScript 的内置构造函数与类名遵循 PascalCase（每个词首字母均大写，如 Date、Array），常量常用全大写加下划线（如 MAX_SIZE），如果普通变量混入这些风格，就会与语言约定和既有代码习惯冲突。camelCase 能把"这是一个普通变量"的意图用最小的视觉成本表达出来，这与函数名、类名天然区分。此外，在实际团队协作（包括 freeCodeCamp 课程后续内容）中，遵循统一命名可避免因大小写不敏感心智模型带来的低级 bug——例如把声明为 userName 的变量错写成 username。

实战任务：把 StudlyCase 改为 camelCase

理解了规则之后，挑战给出的任务是：

Modify the existing declarations and assignments so their names use camelCase. Do not create any new variables.

任务分两半：修改既有的声明与赋值，使变量名符合 camelCase；同时不得新建任何变量。 后者意味着答案只能改写既有名字，不能新增 var 语句。

初始代码（seed contents）故意被写成混乱的 StudlyCase（随机大小写）风格：

// Variable declarations
var StUdLyCapVaR;
var properCamelCase;
var TitleCaseOver;

// Variable assignments
STUDLYCAPVAR = 10;
PRoperCAmelCAse = "A String";
tITLEcASEoVER = 9000;

仔细观察会发现这段代码其实"处处是坑"：

1. 声明的变量名 StUdLyCapVaR、properCamelCase、TitleCaseOver 与赋值语句中的 STUDLYCAPVAR、PRoperCAmelCAse、tITLEcASEoVER 拼写相同但大小写不同，因此在 JavaScript 中它们根本不是同一个变量；
2. 对从未声明过的 STUDLYCAPVAR、PRoperCAmelCAse、tITLEcASEoVER 赋值，在非严格模式下会隐式创建全局变量（这是应避免的坏习惯），在严格模式（ES5 之后的标准）下则会直接抛出 ReferenceError；
3. 三个已声明的变量 StUdLyCapVaR、properCamelCase、TitleCaseOver 则始终保持着 undefined，值根本没赋进去。

换句话说，这段初始代码不仅风格混乱，而且在语义上根本达不到"给变量赋值"的目的——这正是大小写敏感特性制造的真实生产事故的迷你缩影。

分步推导标准答案

将每个变量统一为声明与赋值使用完全一致的名字，并调整为 camelCase：

• 第一组：var StUdLyCapVaR; 与 STUDLYCAPVAR = 10; → 统一为小写开头驼峰名 studlyCapVar；
• 第二组：var properCamelCase;（本已合法）与 PRoperCAmelCAse = "A String"; → 保留 properCamelCase，把赋值端拼写修正一致；
• 第三组：var TitleCaseOver; 与 tITLEcASEoVER = 9000; → TitleCaseOver 首词应小写，统一为 titleCaseOver。

TitleCaseOver 到 titleCaseOver 的转换是 camelCase 规则的直接体现：首词 Title 被降为全小写 title，后续词 Case、Over 保留首字母大写。

改写后即挑战自带的参考解答（solutions 段落）：

var studlyCapVar;
var properCamelCase;
var titleCaseOver;

studlyCapVar = 10;
properCamelCase = "A String";
titleCaseOver = 9000;

将变量名与赋值在视觉上区分：前三个 var 语句负责声明，后三个赋值语句只写名字不加 var 关键字，因为变量此前已声明，赋值时重复写 var 反而会退化为"重复声明"，容易引发混乱。此解满足"不新建变量"的要求——变量仍是原有的三个。

自动校验规则深度解读（hints）

freeCodeCamp 的每道题都配有可编程校验（hints），本题的校验逻辑值得逐条拆解，因为每条 hint 都对应着一个可能的踩坑点。

值断言：变量必须"确实存在且值正确"

assert(typeof studlyCapVar !== 'undefined' && studlyCapVar === 10);
assert(typeof properCamelCase !== 'undefined' && properCamelCase === 'A String');
assert(typeof titleCaseOver !== 'undefined' && titleCaseOver === 9000);

三条断言的结构完全一致，先看 typeof xxx !== 'undefined'——这要求变量已被声明（否则会抛出 ReferenceError 而不是断言失败），再看严格相等 === 要求值与目标完全一致（10 为数字、'A String' 为字符串、9000 为数字）。这直接否决了"只改声明不改赋值"或"只改赋值不改声明"的半吊子做法，因为一旦名字两端不一致，声明的变量仍会是 undefined，第一项检查即失败。

值得注意赋值的写法："A String" 使用双引号包裹字符串，与课程前面 "Declare String Variables" 一节保持一致的风格，字符串量可以用单引号或双引号，但必须成对闭合。

文本断言：注释剥离后恰好各出现两次

三条文本断言逻辑一致，这里以第一条为例：

assert(__helpers.removeJSComments(code).match(/studlyCapVar/g).length === 2);

它要求：把用户代码中的注释剥离后（removeJSComments），用全局正则 /studlyCapVar/g 统计标识符出现次数，结果必须恰好为 2——一次来自 var studlyCapVar; 声明，一次来自 studlyCapVar = 10; 赋值。

先剥离注释再匹配这一点很关键：学习者如果在代码里写"把 studlyCapVar 改成驼峰"这类注释，注释中的名字不会计入出现次数，因此不会干扰判定。.match(...).length === 2 的精确数量约束防止了两种常见误操作：声明与赋值大小写不一致（该名字只出现 1 次），或学习者为了"安全"额外多写了一次变量（出现 3 次）——但多出来的那次在未删除原声明的情况下会变成重复声明或重复赋值，同样不满足要求。

顺带一提，__helpers.removeJSComments 这类断言辅助函数在 freeCodeCamp 课程体系中大量复用，你可以在 curriculum/schema/challenge-schema.js 与 curriculum/src/filter.ts 中看到挑战 Markdown 的 front matter、字段与 seed/解决方案的解析约束；整个 curriculum 仓库（见 curriculum/package.json）通过 Vitest 等工具对挑战 schema、结构 JSON 与课程顺序做自动化验证，确保这类带元数据的挑战文件能被前端正常渲染与判题。

参照 var 的正确姿势：赋值前先声明

最后把本题与前面几节知识串成一条主线：JavaScript 代码执行到赋值语句 studlyCapVar = 10; 时，引擎需要先在作用域中"找到"名为 studlyCapVar 的绑定。本例的流程是：

1. var studlyCapVar; 声明一个名为 studlyCapVar 的变量，初始值为 undefined；
2. 赋值语句按名字精确查找 studlyCapVar——引擎对名字比较是逐字符区分大小写的，任何一处大小写不符都会被视为查无此名；
3. 找到后把 10 写入该变量。

这也解释了为什么只要声明端与赋值端大小写有任何一处不一致，程序行为就会彻底改变：赋值会落到一个未声明的隐式全局变量上（非严格模式），或直接报错（严格模式）。因此"声明与赋值、引用全程大小写完全一致"是让上述三步正确走通的前提，而 camelCase 正是保证这种一致性、且提升可读性的团队级约定。

实战建议：命名习惯要贯彻始终——声明、赋值、函数参数、条件判断里引用变量时，全程拷贝粘贴同一名字并统一采用 camelCase；不要把变量名中的字母随手改成大写或小写再回车，那往往是 undefined 与 ReferenceError 的来源。

小结

• 语言事实：JavaScript 的变量名与函数名大小写敏感，MYVAR、MyVar、myvar 是三个不同标识符；
• 工程建议：虽然可以利用大小写区分变量，但为了可读性不要使用该特性；
• 命名规范：多词变量名采用 camelCase——首词全小写，后续每个词首字母大写；
• 实战要点：改写既有声明与赋值时不得新增变量，且声明端与赋值端的名字必须逐字符一致，使 studlyCapVar === 10、properCamelCase === 'A String'、titleCaseOver === 9000 三项断言全部通过，同时每个标识符在剥离注释后恰好出现两次（声明与赋值各一次）。

如果希望亲手复现与验证，可在本地按 curriculum/package.json 中的脚本安装 curriculum 工作区依赖并运行其测试命令，对挑战文件做 schema 校验；要查看本挑战在整个学习路径中的精确位置（前后各是什么题目），可阅读 curriculum/structure/blocks/basic-javascript.json。原始挑战正文见 curriculum/challenges/english/blocks/basic-javascript/56533eb9ac21ba0edf2244ab.md。